Sunday, June 01, 2008

Kanban: efficient or predictable, you decide

I have written a little about the Kanban method of software development in the past. And thanks to the comments from Karl and Wayne, plus a few on the side conversations with other people I have a better understanding of what is going on. (Although I’ve still to see it in action.)

Well after much thinking I’ve come to a conclusion, I’ve worked out why it is different to other Agile methods like XP, Scrum and my own Blue-White-Red. And this is is - drum role....

• The focus of most Agile methods is to bring order to the development process, one way they do this is by trading efficiency for predictability.
• Kanban - it seems to me - makes the trade in the opposite direction: predictability is reduced to increase efficiency.

I’m not saying Agile methods don’t care about efficiency, they do. And I’m not saying Kanban ignores predictability, it has an different method of delivering it. And I’m not saying Kanban isn’t part of the Agile/Lean family, it is.

But I am saying there is a trade off. And there has to be a trade off. Its not very nice to say but it is true.

It is true and can be proved mathematically through queuing theory. I can bore you silly with queuing theory but I’ll leave that to one side for now - if you want to know get in touch with me or read another site.

In summary queuing theory explains why in any production system you can have predictable deliveries up to 76% of utilisation. Once your system utilisation goes beyond 76% predicability is lost.

Just to be clear: You can have predicability or efficiency but not both.

The way most Agile processes work the highest priority items are more-or-less guaranteed to be done in the next time-boxed iteration, whether that be a week, two weeks, a month or what ever. Lower priority items might, or might not, get gone. But you can’t squeeze a pint into a quart pot, if you do bad things happen. People don’t sit around for 24% of the time but there is a buffer.

These processes reduce maximum theoretical throughput in order to increase predictability. There is nothing wrong with that, remember our 76% rule. Management might not like it but they are up against mathematics.

In Kanban the team remove (some of) the time-box constrains, planning processes and such that create predictability and go all out for efficiency. If you like they take a gamble, they aim to complete the work before there is need for predictability.

That in a but nut-shell is it. However Kanban does have one twist in the tail. As I understand it teams then apply statistical methods and observation to calculate the flow through the system. This can return some degree of predictability.

One more thing to note. All Agile methods, including Kanban and Lean are actually more efficient than traditional methods for another reason: quality improvement leads to less (re)work.

All Agile-family methods place a high emphasis on avoiding re-work, they are prepared to invest more in up-front quality in order to reduce tail end (bug) fixing. The net effect is to reduce the total amount of work. So, while Scrum and Blue-White-Red may trade some efficiency for predictability they do so and are still be more efficient than traditional approaches.

So it all comes down to choosing what is more important: out right efficiency or predictability. Then set up in your process appropriately.

Having written these words I can already hear senior managers responding: but we want both efficiency and predictability, why should we settle for one or the other? We need both, we are different.

Managers get brought up on these kind of contradictions: they are taught “the magic of and” to implement “simultaneously tight and loose controls” and so on. In many cases these are good ideas and putting the contradictions together leads to creativity but in this case it won’t end.

Still we all live in the real world so if you really need efficiency and predictability you can have it. The magic ingredient is illusion of control. Just d this and all things are possible - especially those “when will it be ready” and “why can’t IT deliver?” conversations.


  1. I think the predictability argument is more subtle than that. It's a matter of focussing on Flow, on getting tasks to flow smoothly through the system.

    By highlighting, but not mandating, the time to deliver a job, they claim that the team will learn to make them mostly the same size. Once you have a bucket of similar tasks, and a reliable time to produce each one, then predictability should follow.

  2. I've posted a response here:

    In short, I think its more about dynamics of reliability and effectiveness.


Note: only a member of this blog may post a comment.