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 an opinion.
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 industry.)
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 other things.
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.