Since I’ve found myself advocating for Kanban more often
as I’ve advised teams on agile, I decided to write down some
of my reasoning. I started by discussing how sprints can
become counter-productive in the context of program oversight.
This time I want to talk about the dynamics within an agile team,
and how some kinds of teams thrive on the flexibility that comes from
a lean agile approach.
Hopefully everyone has had the experience of working on a really good team. In
that environment, lots of otherwise irritating things can be overlooked, even
normally catastrophic things like management uncertainty, poor quality
facilities, impossible deadlines. Indeed, sometimes these problem can only
heighten the pleasurable experience of working with a group that’s able to
overcome the odds and be successful.
One of the best things about working in that kind of team environment is that
the process by which the work gets done becomes invisible. It’s not necessary
to discuss who will perform some piece of work, or even who gets to decide
how the work is assigned, because everyone knows their teammates well enough
to know who to ask. Team decisions are collaborative, not because there’s
some process where everyone’s decision is requested, but because everyone is
engaged in the work, present when decisions are made, and comfortable giving
What I’ve witnessed working on these kinds of teams is how responsive they
can be to change. A new task comes in, the team talks about it briefly
(without having to schedule a meeting), and everyone knows what their particular
task is without being told.
When visualizing this kind of team, I have a hard time seeing where sprints
fit into it. And when I’ve worked with this kind of team, and we used sprints,
they seemed superfluous to what we were actually doing, both because by the
time we did sprint planning, we already had an idea of what we were doing next,
and because when something important came up, we didn’t wait for a new sprint
to figure out how to fit it into our plans. Oftentimes at the end of the sprint,
we would look back and decide we did very little of what we’d planned during that
sprint, but what we did was more important. So why do we have sprints at all?
Clearly they’re valuable to a lot of teams.
If you look at some stated advantages of breaking work up into sprints,
it’s interesting to notice that they’re entirely negative. “No changes are made….”
“Quality goals do not decrease….” “Each Sprint may be considered a project with
no more than a one-month horizon.” In other words, sprints exist in order to
protect the customer from the team, and to protect the team from the customer.
Sprints protect the customer from the team by limiting the cost of failure. If
the customer is getting value at the end of every sprint, and the customer decides
the value is not worth the cost, the customer can cut things off at any time and
lose at most the cost of one sprint. (I do sometimes wonder how many contracts are
written that actually structure things exactly this way. They don’t exist in my
Sprints protect the team from the customer by limiting the scope of change. During
the sprint, the team has a known quantity of work to perform. They might get
clarification on that work, but they will not suddenly be redirected to go work
So the advantages of a sprint methodology is negative, in the sense that it prevents
bad things from happening. Now that is not an insult; after all, the advantage of
a door lock is also purely negative, but that doesn’t mean we should get rid of them.
But it’s important to make the distinction, because it reminds us that we’re making
a tradeoff, not following a pathway to Heaven. With door locks, there is a tradeoff
in the cost of the lock and the inconvenience to authorized entrants if the lock
becomes too difficult to open. Similarly, when using sprints, if the cost of having
them outweighs the disadvantages, we should be agile enough to do away with them.
So what kind of team or project should do away with sprints? The kind that doesn’t
need or want the protection. If the team is able to accomplish productive work
without a time-boxed planning horizon, then that sprint planning becomes make-work
for the team. If the customer needs a team that responds quickly to changes, then
sprint planning will become superfluous (because the team won’t be doing what they
planned) or counter-productive (because the team will be doing what they planned
but not what the customer wants).
To be more specific, I believe sprints are often counter-productive when used
by research teams (i.e. teams that are exploring new solutions to problems),
when used for support (i.e. teams that are responding to and fixing problems as
they arise), and when used in cases where the customer doesn’t yet know what
the solution looks like. Since every program I’ve ever been on has had some amount
of all of the above, it’s probably true that every program I’ve ever worked would
benefit from having some team avoid a sprint-based methodology and instead use
a Kanban-style approach.
Next time I’ll get all business school and talk about the principal agent problem.