This document is an excerpt from a book that provides techniques for Scrum Masters to help teams continuously improve using minimal time and resources. It discusses some common issues that prevent teams from improving such as dual-role Scrum Masters being too busy to focus on improvement work. It also discusses how to identify and remove impediments, waste, and other obstacles that prevent teams from working efficiently. The overall goal is to help Scrum Masters maximize their limited time to drive improvement within their teams.

2. Continuous Improvement In A Flash
A Guide For Scrum Masters
Tim Ottinger
This book is for sale at http://leanpub.com/smtb
This version was published on 2013-06-25
This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.
©Tim Ottinger 2012 - 2013

3. Tweet This Book!
Please help Tim Ottinger by spreading the word about this book on Twitter!
The suggested hashtag for this book is #smFlash.
Find out what other people are saying about the book by clicking on this link to search for this
hashtag on Twitter:
https://twitter.com/search/#smFlash

4. For all the teams I’ve coached and learned from.

5. Contents
Two Hours Per Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
What’s wrong with dual-role? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
What is a dual-role SM to do? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
What is here for me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
What if I’m a “proper” Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
About This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
How does it help me? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
How complete is this book? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Is this scrum? Agile? XP? What? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Why do you say “he” all the time? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Removing Impediments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Obstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Waste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Politics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
A more fluid environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Invite Them In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Whose Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Wish List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Round-tripper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Waste Snake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Ring of Scrum Masters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Epilogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

6. Two Hours Per Day
“I know that agile expects continuous improvement, but I am dual-role, and have been
told to keep my Scrum Master duties down to two hours a day.”
In 2012, most of my clients were large enterprise organizations (you would recognize the names)
who were transitioning to more agile methods.
I was surprised to see that the companies had been advised to have dual-role Scrum Masters. Often
it was assumed that being a scrum master was a minor role that wasn’t deserving of more than two
hours a day “distraction” from “real work.”
What’s wrong with dual-role?
There is nothing wrong with dual-role, except that we don’t want our scrum masters choosing
between the work that is important to them personally and the work that is important to the team.
Too often they have to short the team to make their own goals.
As a result of scrum masters letting their process work slip, teams were conforming to scrum
ceremonies without living up to agile values. I call it “conformance scrum.” It is also known as
“scrum-but.” It’s the kind of scrum implementation that you hear people complaining about in on-
line forums.
Not much was being tracked. Not much was being inspected. Little adaptation was occurring.
Continuous improvement could not happen; there was too much “real work” to do. Some teams
dropped standups and retrospectives as an “optimization” (really an “abandonment”) of the process.
Some benefit may be realized by colocating the team members, and forming multi-disciplinary
teams. The idea of working to shorter timeframes may help some programmers focus, or at
least avoid over-building. Having more frequent planning and measurement of progress can help
companies plan for product completion more accurately. Still, these changes are hardly sufficient to
create the highly effective teams promised by agile evangelists.
Agile methods are built on the idea of continuous improvement. If you read the Scrum Guide, you
will see that the intention of the scrum founders was to build an environment of transparency,
inspection, and adaptation.
A team can be stuck in conformance scrum for years, and never even realize that they’re not agile.
There is one other problem with dual role: a scrum master can be so busy doing that he forgets the
importance of learning. Many of the scrum masters who requested early copies of this book reported
after week that they could not even start it because they were too busy.

7. Two Hours Per Day ii
Would you really like to be agile, productive, accomplished? Reveal, Inspect, Adapt – on a continual
basis.
If you’re too busy to learn, you are in the wrong business.
Programming, coaching, agile practices, testing – this world moves very quickly. As a result, we
have to keep up at least well enough to be effective.
This is why we need a very short book on scrum mastering.
What is a dual-role SM to do?
We normally enlarge the scrum master’s role and importance in the scrum team. If you invite a
process coach to your company, that’s probably what will happen, and it will be the Right Thing To
Do.
Maybe this is a more interesting problem. Why can’t a scrum master have significant impact in one
or two hours a day? Does the loss of full-time support really make improvement an impossibility?
Doesn’t the team share responsibility for improving their effort:results ratio? Aren’t they vested in
the result?
My first Agile (XP) team with Object Mentor did not include a full-time process role. We took turns
officiating the ceremonies, and we all worked to remove obstacles and get work done.
The whole team (save me) knew the agile process by the time I’d joined. I had a lot to learn.
W. Edwards Deming once said
“It is not enough to do your best; you must know what to do, and then do your best.”
Our problem might be one of education.
What is here for me?
Here you will find my experiment with equipping scrum teams so that they can continuously
improve without sacrificing an entire software developer to the process gods.
Does it work? The techniques have all worked individually, saving time and helping teams improve
their practice.
Will this book transform a “compliance scrum” team into a powerful force for continuous im-
provement? Who knows? This book is an experiment, as is anything else you are doing with agile
development.

8. Two Hours Per Day iii
What if I’m a “proper” Scrum Master
Congratulations on being able to devote all of your time to helping your team become more capable
and efficient!
Don’t turn away. These techniques will not degrade in the presence of sufficient time.

9. About This Book
How does it help me?
This is a little book full of small ideas.
If we have learned anything in software development, we have learned that it is not possible to focus
on dozens of goals at a time. We tend to limit work-in-progress so that we can maximize focus. We
focus teams through pairing and “swarming” behaviors. It gets things done.
Far be it from me, then, to give you a million things to do. My goal is to make your work easier.
Don’t try to use all these ideas at once, or to use as many as you can. Instead, use the fewest possible
so that you are able to honor the dual role you are in and still create some positive pressure for
improvement.
If you are a full-time scrum master, the advice still stands. Use as little as you can to meet the needs
of your team. Remember that they are busy producing functionality, and you don’t want them
defocused by a plethora of graphs and side-activities.
So, the steps for using this book are:
1. Start by skimming the book, so that you have a sense of how to approach your four
primary areas of responsibility (Presiding, Tracking, Removing Impediments, and Improving
Capabilities).
2. Listen. The team has issues, and brings them up all the time in the form of complaints, jibes,
arguments, rolled eyes, sighs, and excuses. More enlightened teams even bring them up in
retrospective meetings. Listen for trends. Elicit feedback when possible.
3. Focus on the team’s existing problems. Look into impediment removal and tracking.
4. If no problems are recognized, apply tracking techniques to uncover opportunities for
improvement.
5. If there no impediments, focus on improving capabilities.
6. If the team has no issues and is supremely capable, retire from scrum mastering and become
an author and consultant, so I can learn from you.
How complete is this book?
This book is still a work-in-progress. As we know, nothing is ever finished; only abandoned. Since
this is a LeanPub book, I will put out updates whenever I feel I’ve done enough writing to merit it.
That might be several over a weekend or once a quarter, but it will happen as circumstances allow.

10. About This Book ii
It would be hypocritical for a book on continual improvement to have a single release and then
stagnate.
Please email me¹ any techniques or stories (supportive or otherwise) which might make the book
more useful to others.
Is this scrum? Agile? XP? What?
The book is about continual improvement, and how to create conditions that make it easier. It is
written in the context of scrum because:
1. Scrum is a highly popular agile framework in large companies
2. Scrum is largely silent on practices and techniques, leaving a gap
3. Scrum teams have a tendency to stop at mere “adoption”
4. I am concerned for the efficacy dual-role scrum masters
This book is not intended to help you pass a scrum certification class; it is to help you take on the
much larger contest to come.
The mental model and techniques here are highly compatible with scrum, and assume that the team
is using scrum, but these are core agile concepts and can easily be transplanted.
Why do you say “he” all the time?
Your ability to serve your team has nothing to do with your chromosomal configuration. I’ve learned
much from male and female coaches and leaders.
I have struggled with this issue in prose, and had to make a decision that did not make me crazy
when making revisions. I can’t just say “you” all the time, or even “the scrum master” without the
text getting awkward and weird.
Just as we sometimes have to write clunky integer-indexed loops in some programming languages,
we find that English is not as elegant as we might hope.
Herein, I use the English grammar rule of using the masculine form.
It is grammatical, not political.
¹mailto:tottinge@gmail.com

11. Removing Impediments
Obstruction
Don’t be blocked. Ever. – R.C. Martin
Developers tolerate frustration better than the average rush-hour driver.
If they have to wait for five, ten, or fifteen minutes for some task to complete it’s not considered a
problem.
If there are tests that intermittently fail, he can just rerun the suite. It’s not a big deal. It only takes
a half an hour.
If the version control system is down for backup or maintenance, or the build server is unavailable,
or they have a question needing answered, they can send an email. They get an answer eventually.
One of your developers finished a feature on the third day of the sprint, but she is in the second
following sprint by the time she gets the results of the review. She will have to drop her current
work to make changes, or else ignore the review. Oh well.
Testers are used to having to wait for other people to provide them with databases, test servers,
scripts, solutions. They have been taught to be patient and wait. Testers multitask to tolerate the
long down-times.
An agile team is supposed to be different.
An agile team is expected to be efficient.
A scrum master’s explicit, primary duty it to clear obstacles for the team. That is easy enough when
the team members state their obstacles at the morning stand-up meeting.
It is not so easy when they quietly tolerate inefficiencies. A scrum master has to develop the skill of
sniffing out obstacles and removing them forcefully. This chapter is about finding and eliminating
wait states.
Waste
Waste is an ambush predator.
People accustomed to working alone are less aware of their teammates than those who have
embraced collective work. The work process of the team seems to be largely unrelated to the quality

12. Removing Impediments iv
and quantity of the work they personally produce. They naturally see teamwork as a matter of each
person doing their independent task well and dealing with their own issues as they arise.
It is natural, then, that they have trouble adjusting to a system where the throughput of the team
and current immediate health of the product are the primary concerns. They often can’t see that
optimizing their personal process may actually be degrading the team’s performance.
Many programmers work in a state of hyperfocus. They mentally shut out all distractions and focus
on the task at hand. In this state they tend to merely cope with problems that they could easily solve
if they were more aware of their process. They write-off issues as “intermittent” or “low-grade” or
“unimportant” or “unsolvable” and forget about them for now.
Ubiquitous, invisible waste destroys the effectiveness of many teams.
One team I worked on shared a code base with many others. They felt that it didn’t really matter if
the build was broken or not, as long as their code could be demonstrated to work on their machines.
They checked code in while the build was “red” (failing).
The person who was trying to fix the build now had to go through extra merge sessions in order to
commit his fix, and if the tests still did not pass, he had to debug a larger and more complex change
set to determine if his code was at fault.
By keeping the builds broken for a longer time, the team whose code worked in isolation from the
build was keeping most of the other teams from making progress.
Later on, the entire company shared a common concern for the health of the system and created
a protocol to use when the tests were broken. As a result, tests were broken far less often and for
shorter periods of time.
This chapter is about spotting and eliminating waste.
Politics
Bureaucracy: promoting learned helplessness for almost 5000 years.
One of the biggest problems we face in agile teams is ownership.
Too often it is someone else’s job to take care of the build, test the code, provide a database, or even
edit a particular body of code.
If it is someone else is job, then it is not our job. We’re helpless. The best we can do is wait until
they’re finished.
In this way, corporate “division of responsibility” creates learned helplessness and develops individ-
uals with skills and opinions into mere functionaries.
Imagine a team of 8 where each spends an average of two hours out of each two week sprint waiting
for someone else. They lose about 800 hours a year, 20 weeks of full-time employment. That’s one
hour a week – 12 minutes a day, just six minutes in the morning and six minutes in the afternoon.

13. Removing Impediments v
We can say that the productivity is not lost, because the team member can take on another task
to fill the time. The time lost to a task swap is about 15 minutes², so it might be more efficient to
wait 6 minutes than to start up a different task. Besides, if one team mate (or pair) has laid claim to
two tasks, what happens when another team mate (or pair) want to take on that work? The work is
waiting for the availability of the first person/team.
One company I worked with had assigned an individual to be the “pixel police.” The pixel police
would enlarge each screen produced by the GUI team to enormous proportion and count the pixels.
She would determine if each element on the screen was the precisely the right size and precisely in
the right position.
Every team member had to wait for the pixel police, and for each incident where some element
varied from spec by a single pixel, the team member had to put their work on hold to correct any
defect found during inspection. Code would often make several round-trips. Each round trip might
take days.
Nothing was “done” at the end of the sprint, and nobody was having fun.
We replaced the pixel police with automated tests, and all of our stories were done on the day we
declared them done - within minutes or hours. Then we found an even faster way – the designer of
the screen visually inspected it in seconds, sometimes approving changes made by developers.
Waiting for task owners, sending code on round-trips, and doubling up on tasks are waste.
This chapter is about not waiting around for someone else to detect or solve our problems.
A more fluid environment
The foremost way a scrum master increases velocity is by eliminating “friction” (waste) so that teams
accomplish more without trying any harder. This is a rich source of improvement.
Most teams have so many kinds of waste and impediment that a full-time scrum master would have
trouble addressing them all. The good news is that only the most egregious needs to be solved at
any given time (see The Theory of Constraints³).
Here are several techniques a scrum master can use to recognize and remove impediments, including
some techniques for determining whether the impediment is worth removing.
All of these techniques require very little time out of the scrum master’s day.
The scrum master needs to maintain awareness of the team. He must observe their work-in-progress,
their wait states, the practices that cause them stress or rework, and the frustrations they quietly
endure. Without spending some time observing the team each day, the SM is left with only the daily
scrum as input. That is not enough feedback.
²
³http://en.wikipedia.org/wiki/Theory_of_constraints

14. Removing Impediments vi
Invite Them In
Problem
Your team either has to wait for outside people to complete work, or else your team finishes work
only to have it returned by outside reviewers.
This frequently is the case when there is an external UI design team, external architects, code review
czars, a QA team, source management, or a build-and-deploy department that is not represented in
your team.
Mechanism:
A standard Agile definition is that a team consists of everyone necessary to bring a product to
market. That is why we have multi-disciplinary teams. However many companies in pre-agile times
have divided people into departments based on their specific disciplines.
The best answer in this case is to reorganize, but that is not the kind of thing a two-hour-a-day
scrum master has the clout to accomplish. He can, however, ask that the external team designate a
contact to spend some time each day with the team.
Barring that, the scrum master can get a volunteer of his team (someone with some passion for the
subject) to go to the other team’s standups and try to connect with them in a way that is helpful.
One other mechanism is to bypass the external team. There is never a good time to be blocked, since
a scrum master’s first duty is to remove impediments. This mechanism has political ramifications
and should be weighed carefully, but never ignored. If you can’t get cooperation, work without it.
Time
In most cases, one can go visit the external resource for 5-10 minutes once or twice a day, tapering
off as needs are met.
The team may end up devoting their time and skills to becoming more self-sustaining, and this will
of course reduce velocity in the immediate term in order to maintain forward progress and improve
velocity going forward. In such cases, it is a matter of timing. Choose this action when there are
more important sprints coming up or when the team’s passion for progress is high.

15. Removing Impediments vii
Whose Job
Problem:
You do not have enough time or clout to solve all the problems you see.
This leads to learned helplessness, which is hard on team morale and relationships with the people
on the other side of the problem.
One trick to effectiveness is using the people in the organization to get your work done efficiently.
This isn’t abuse, it is the whole reason you have an organization to work in – everyone works
through everyone else to get the best result they can (see “Teamwork is an Individual Skill”).
Mechanism
Rather than abandoning a problem because you are not empowered to solve it, or because your two
hours won’t let you, determine who in the organization might benefit from solving this problem for
you.
Sometimes there is a person with ambitions to become a corporate QA expert. That person may
already have contacts and background on quality practices, and may help you.
Someone may be in a department formed entirely to handle the kind of problem you’re having. Do
they see it as a trivial problem? An interesting challenge? You can make it their problem to solve.
Is the problem one related to budget, talent pool, or schedule? Why not talk with some managers?
Would it help to have a customer handy? Talk with a customer.
For almost any problem, it is likely that someone else is interested in the problem and would benefit
from its solution. Make it their problem.
Note that the goal is not to “become a problem to them” but to bring them problems that they want
(or should want) to solve.
Time
If you work in a larger organization and have a scrum-of-scrums this is easy, because the other
scrum masters should know who to talk to. In a group of five or six scrum masters, a problem-solver
is never hard to find.
It is easiest if you know a lot of people. Networking is an important scrum master skill. If you
already know someone who loves working with maven, then problems in your .pom file are easily
routed to him. If you don’t know what people like to fix, this becomes a breadth-first search of your
environment.

16. Removing Impediments viii
The effort usually involves visiting some people and asking some questions. Give it 15 minutes a
day for a few days.
There is no guarantee that you will find someone. Don’t try forever, but rather start socializing the
problems you want to solve and see if anyone picks them up. If they don’t, the problem is still yours.

17. Removing Impediments ix
Wish List
Problem
Teams are not always self-aware. When people are busy writing and testing code, they may ignore
peripheral distractions. As a result, they miss opportunities to solve recurrent problems. Without
solving those problems they remain slightly less efficient than they could otherwise be.
On the other hand, if they dive into every peripheral distraction, they would never get any “real
work” done. This focus on accomplishing work is both a short-term advantage and a long-term
disability.
How does a team determine which problems they should solve, or which skills they should learn?
A wise man once said “you should never buy a tool until you have needed it three times.”
Mechanism
Start a big visible chart: a simple flipchart page with the words “wish list” at the top in dark sharpie
(I like black or blue).
As the team encounters a topic that they wish they knew, or a peripheral distraction they wish they
could avoid, or a question they cannot answer, they add it to the chart. If the subject is already on
the chart, they put a check mark beside it.
In the steady daily work, the SM listens for wish list items from peers and suggests adding them to
the chart. The SM checks the chart every day.
If one need is acute, the SM schedules working or learning sessions.
If the need is low-grade and chronic, the SM will bring it up at the next retrospective.
Time
Putting up a chart takes a minute or two. Developers add things to the chart, so there is only SM
involvement in reminding them to do so.
If the whole team clearly needs a specific skill or knowledge set, then there is time to locate people
(see “Whose Job”) or materials (“lunch and learn”) and schedule a meeting, but this is usually less
than 1/2 hour.
This is one of the easiest and most beneficial practices in this guide. Anyone can do it, either
personally or at a team level. Teams can compare charts and find organization-wide needs.

18. Removing Impediments x
Round-tripper
Problem
Products we considered “done” return to the team with defects, and this disrupts our work.
Mechanism
Create a big visible chart. You need to set up a space on a wall or flip chart with room for lots of
standard post-it notes. When any product is returned the first time, a card is stuck on the wall with
the date of the return in the upper left-hand corner. When the product is re-submitted, the date and
time of resubmission are written in the bottom right-hand corner.
Round Trip ticket
If the task is returned again, then the next round-trip gets a card attached with tape or post-it stickum
to the original card:

19. Removing Impediments xi
Two cycles, one repeated.
At the end of the sprint (or whenever you deem it prudent) the time is summed, so we know how
much elapsed time is required for the items returned.
We could list the reason for return, but teams usually remember that without aid.
The presence of the round-trip cards in the workspace is usually enough that the team will decide
to adapt their behaviors in one way or another.
1. Sometimes the team needs to change practices to institute higher quality
2. Sometimes the external party needs to be invited into the team so that they can help build
product instead of just rejecting it with a veto.
3. Sometimes the external party’s standards are inappropriately strict or are arbitrary and
unformulated, and are changed to become more appropriate.
Other actions are possible, and the “wisdom of teams” will uncover an appropriate action.

20. Removing Impediments xii
Time
It takes almost no time at all to create the round-tripper area, and of course adding a new card is a
task taking barely a minute. This is a tracking activity that is almost free, and returns a great deal
of value to a team struggling with “done.”
One might take an extra 10 or 15 minutes to “affinity map” the cards (organize into a topical group)
and sum them. The ability to say “we lost 4 man days to formatting issues this sprint” – with
confidence and data to back it up – is a powerful force for good.

21. Removing Impediments xiii
Waste Snake
Problem
The team is unsure how much of their time is lost on peripheral tasks, wait states, and interruptions.
In one case, I was coaching a team who were often slowed because the version control system became
“intermittently” unavailable. They all suffered from it, but the system was hosted externally and it
usually came back “in a few minutes.”
I had recently learned about this technique, so we started using it. We found that outage was always
between 8:30 and 9:30 in the morning, just like clockwork. The team hadn’t realized it was regular
and predictable because they never had recorded any data. We found out that the remote team
has scheduled backups to take place “in the middle of the night” – our morning – so that nobody
would be inconvenienced. By scheduling backups to be two hours earlier, they alleviated the chronic
outages that had been plaguing my team for months.
The waste snake mechanism increases a teams awareness of their own encumberance, and quite
often collecting the data will suggest a solution.
Mechanism
This is very similar to the round-tripper above.
Create a large visible graph: a large wall space or whiteboard. Sadly, most flip-chart papers are too
small to make this work.
When time is wasted (lost, abused, spent waiting or distracted) a team member puts a card up on
the wall. The card records the kind of waste, the date, the member’s name, and the time lost.
Waste Snake Ticket
The next time any developer feels time is lost, another card is stacked next to the first. If there is no
room to the right of the first card, the next one is placed under it.

22. Removing Impediments xiv
Waste Snake Ticket
Similarly, each new card will be placed adjacent to the prior, so that the list of perceived time-wasters
may eventually snake along the wall from left to right, down and back again. Hopefully there is not
enough waste for too many round-trips across the wall.
Sometimes visibility into waste is enough to spur the team to action and resolve the problems.
Sometimes it will become obvious that an external entity needs to be brought into the team. Other
times, the team may save the snake and use it as base data for the retrospective.
Time
This takes hardly any scrum master time at all, certainly not even five minutes a day.

23. Removing Impediments xv
Ring of Scrum Masters
Problem
There are systematic problems larger than the team, and needs that are hard to address merely
within the context of one team.
Mechanism
Establish and expand the Scrum Of Scrums. Treat it as a team with goals and planning. Hold a
stand-up in which each scrum master tells what they have learned, what they need, what problems
they’ve encountered, and how the assembled group could help them complete their work.
Note that there has to be a real solidarity at work. If teams are being ranked against each other, or
cannot admit to struggles or offer aid to sister teams, then the meetings quickly become ineffective.
This idea has surfaced mightily in the form of Dynamic Governance⁴. Perhaps this is the best current
treatment of self-organizing as of the time of this writing.
Time
Meetings are 15 minutes a day, probably better scheduled just before or just after team stand-up
meetings.
Sometimes a Ring of Scrum Masters may have special meetings to solve tough problems, and they
might also add a periodic retrospective.
⁴http://www.governancealive.com/dynamic-governance/

24. Epilogue
These techniques are handy. Some of them have made a lot of difference to my clients or to me
personally. However, none of them are as valuable as a sincere interest in helping people work more
effortlessly in teams.
The joys of working in a great team are profound. Once you have had a really great team, other
efforts pale. Not knowing what to do next, waiting for someone to finish a dependent task, listening
to argument, coding and refactoring solo, seeing tasks carryover to yet another sprint, all of these
things come with disappointment and longing.
I had a few really great teams in my life, so great we seemed to work telepathically. We looked
forward to the things we could build together. We learned from each other voraciously. We got
things done, and those things mattered to people. We pushed the state of the art in our companies.
Those experiences change us. I like to think that they improve us, but I can say beyond a doubt that
they spoil us. Nothing else is ever as good. When a team is connected and firing on all cylinders it
makes all the individual “flow” state mumbo- jumbo seem second-rate.
I want you to share the pain; having worked with teams so resilient and brilliant and cooperative
that you spend years trying to recapture the experience.
Once we all know how great it can be, none of us will ever settle for anything else.
That’s a future worth every minute we invest today.