What should an iterative-Agile team do if it appears that not all the stories they signed up for will get done? Possibilities include:

  1. Just get done what you can, velocity is velocity;
  2. Crunch really hard because you’ve made a commitment;
  3. Renegotiate with the Customer / Product Owner;
  4. Stop doing iterations: use a Kanban approach instead.

It’s this last one we are here to talk about.

There is as yet no solid definition of Kanban for Software that satisfies me, and what people are talking about here is in essence a continous flow kind of approach, usually with limits on the amount of work you have “in process” in various stages of the project. See Kenji Hiranabe’s article for example.

I take the idea, tweeted by John Goodsen of RADSoft, among others, to mean that if we didn’t have a defined edge to the iteration, then no one could complain that we had failed if we got only nine out of ten things done that we “promised”. As John tweeted:

It’s about falling short because of iteration planning – remove iteration planning and you remove the entire wasteful exercise.

I’ve certainly seen teams whose management or product owner would berate them for falling short of the iteration “promise”, and this can lead to some very bad results. The initial response will be to “under-promise”. Not “under-promise and over-deliver” — they’ll say that, perhaps, but they won’t do it. No one does.

When the team tries to under-promise, this same manager or product owner will push them to commit to more: it’s part of that management pattern. Most teams will cave and try to do more. They want to be cooperative, they want to be appreciated, and so on.

This will not work. They’ll fall short again. Management will continue the pressure. Finally, the team will turn their secret screws and start producing code that is shiny on the outside and rotten on the inside. Velocity will continue to decline, pressure will continue to rise, and things will get bad. 

On the surface, we can see that a Kanban approach might fix this, because there is no defined point at which to apply this undue pressure. It’s not a bad idea: it might even be a good one, at least in the interim, for reducing the pressure.

Iterations provide rhythm

There can be a pleasant rhythm to the iteration, and there are things that fit naturally into it. It can be very pleasant to lift our heads up, look around, plan the week, then at the close of the week, lift up again, look around, and see how we did.

There’s work that needs to be done, such as reviewing the backlog, reviewing the product, perhaps some kinds of testing or other wrapup work that are not yet fully continuous. Some of those probably should not be continuous, though many of them should be. 

Now Kanban advocates will say that Kanban is better (what else would they say?) because it lets you have whatever rhythms you want rather than “imposing” one. Uh huh, yeah, and that’s why people who don’t cut the grass every week have yards that look like forests. 

Whack-a-mole

In my experience, a continous flow model becomes very relentless. There are always 7 things on your list. As soon as you get one off, another one pops up.  Every day begins to look like every other. 

I don’t know if this is inevitable or not. My experience suggests that it is at least very likely. 

Bottom line?

The small batch flow of Kanban has advantages, there’s no doubt about it. Certainly the Kanban board alone shows us that. 

I am not convinced at all that it’s always the best way: I don’t expect that there is an “always the best” way. 

If a team is getting too much pressure to sign up for more work, and too much hassle about not “keeping its promises”, Kanban might take off the pressure and let something good happen.  My guess, however, is that just moving to Kanban in such a situation might be ignoring the real problem. 

But we don’t know. It’s another trick in the bag. I hope teams at various levels will try it and tell us just what they did, and what happened.