Defining Kanban

There has been a long thread in the kanbandev group at Yahoo about how to define what a kanban system is, and is not. Defining kanban is important because without an unambiguous definition it is difficult to discuss kanban.

A kanban system is a system for process control. Kanban was invented by Taichi Ohno at Toyota more than fifty years ago. There are many types of kanban systems, for production processes, for administrative processes, for software development... All kanban systems have certain characteristics in common.

We in the software community are new to kanban, and it is easy to get a bit too enthusiastic, and unintentionally change the meaning of kanban when we discuss it. It is my opinion that this would be unfortunate. One reason is that we dump a lot of knowledge that has been amassed under more than half a century. When we do that, we have to rediscover what other people have discovered before us. That slows us down, because we loose the ability to build further on the existing knowledge base.

The following Intermediate Objective Map reflects my current understanding of kanban (feel free to laugh if you are from Toyota, Honda, or one of the many other companies that has spent decades building a thorough knowledge of kanban):

Note that some things necessary to have a kanban system are external to the kanban system itself. It is also worth noting that you cannot describe a kanban system by describing only the physical system. Kanban is a system with an attitude. This is something that often trips up Western (and many Eastern) companies that try to introduce Lean and kanban.

Here is a somewhat simplified map of a kanban system:

Note that there are two types of kanban tokens in the system:
  • Work-In-Process (WIP) kanban move with work items. A WIP kanban serves as identification and job instruction.
  • Withdrawal kanban move in the opposite direction of the work items in the process. They serve as identification and transfer tags.
If you have used a kanban board for software development, usually a whiteboard with sticky notes, you are familiar with WIP kanban. That's the sticky notes.

Where are the withdrawal kanban? Well, they are there. Withdrawal kanban are the release signals that tell that it is okay to move more work into a process step. On a kanban board, that is the empty space left when you move a WIP kanban. Look at the drawing of a board below. It is a simple kanban system with only one kanban slot at each process step:

It is actually pretty neeat. As you move sticky notes (WIP kanban) to the right, holes (withdrawal kanban) will move to the left, so you can move more sticky notes to the right.

A topic that is related to how to define kanban, is the scope of kanban. This is also a topic that has been debated for awhile. Armed with a definition of kanban, we can figure out what the scope is. The IO Map below is a generic description of a process. There are only two necessary conditions in the map that are fulfilled by kanban. I have drawn a rectangle around them.
If you look at Lean, or the Toyota Production System, the complete system fulfills all of the conditions in the map, but kanban, which is only a small part of the complete system, fulfills only the conditions in the red rectangle.

That is my opinion on how to define kanban.


jackvinson said…
Henrik- Have you seen Goldratt's comment that while Kanban cards drastically help reduce WIP, that they can still be viewed as a Push system rather than Pull? His take is that the Kanban system encourages activation any time there is an available card, rather than when there is a specific order for the work.

For high turnover systems, like car manufacture, there is almost no difference. But in lower turnover, it is more obvious. Is software development high enough turnover that it doesn't matter?

(I am not a Lean / Kanban expert, I am just reflecting an interesting comment and my current understanding.)
Kallokain said…
Hi Jack,

No, I have missed that. It is true that as used in software development, kanban will cause an early start, where TOC's Critical Chain prefers late start of tasks not on the critical chain itself. (Late start reduces the amount of Work-In-Process. That reduces lead time and increases the flexibility of the system.)

However, I find it difficult to see kanban as a push system. The release signals, the withdrawal kanban, always go in the opposite direction of the work.

The kanban system does not activate any time there is a free withdrawal kanban. It activates when the order point is reached. (I haven't seen the order point concept used in software development though.)

Someone (I do not recall whom) pointed out in the CriticalChain group recently, that if you have a high degree of uncertainty in the task estimates, early start is better than late start. (Well, I suppose one could increase buffer sizes too.)

My guess is that in most projects the early start caused by kanban does not cause any problems in software development.

This is an area where I believe we could learn a lot from using computer simulation to study the behavior of different types of process control systems under different circumstances. A pity no one seems interested in funding such studies. (If anyone reading this is interested, please call me :-)
Unknown said…
I'm currently planning a software simulation with David Raffo and Merwan Mehta. We plan to write it up as an academic paper as a sequel to our top rated paper from 2008 on Lean Software Development.
Kallokain said…
@agilemanager: That is interesting. Have you decided on the simulation approach? I used a very simple model where I actually moved objects around in the process model to create the simple animation on this page:

Click on the animation to see a slightly larger version.

For a more complex system, System Dynamics may be the way to go.
Anonymous said…
Very useful post, thank you.
I usually explain how a Kanban Board is different to a task board as the following:
Kanban means visual indication, so a card in a 'done' column is a visual indication that work is available.
A Kanban Board should also have WiP limits.

Viewing the holes on the board as withdrawal kanban makes a lot of sense.
Joshua Lewis said…
Would it make sense to create physical withdrawal Kanban? Ie instead of representing available capacity as an empty space or slot on a Kanban board, represent it with a (differently coloured) card.

You make a very good point about the existence of two types of kanban. I did not realize that enough when I wrote my post about the visualization of pull. I think it is very valuable to make it explicitly state what type of kanban you're displaying when you're introducing a kanban board in a software development team. Especially if you tell the story about the essence of pull in lean systems, which talks primarily about withdrawal kanban.

Anonymous said…
Leading on from my comment above, I had the following thought: the total number of withdrawal Kanban ‘collected’ at the beginning of the value stream in a given period could be a useful metric in terms of trending capacity.

For example we could say ‘we had 30 total withdrawal Kanbans (i.e. available capacity slots) in the past month, over a team of 10 people’.

Does that tell us anything?
Kallokain said…
Hi Joshua,

About physical withdrawal kanban: I almost answered "no", but then I thought a bit about it, and under some circumstances it might be useful.

For example, suppose you have two or more teams that are in relatively close proximity, but use different boards.

For example:

A user interaction design team
A client development team
A server application development team
A test team

You could use withdrawal kanban to transmit information from one team whiteboard to another.

I have never tried this though.
Enfoque said…
In the article "Standing On the shoulders of giants", Eli Goldratt explains how the Flow Lines developed by Ford and Kanban systems developed by Ohno are derived on what he calls the fundamentals concepts of flow.
He demonstrates a fundamental step in all these systems is to reduce the WIP. DBR and Critical Chain is also derived from these concepts.
A truly recommended reading:
Enfoque said…
In the article "Standing On the shoulders of giants", Eli Goldratt explains how the Flow Lines developed by Ford and Kanban systems developed by Ohno are derived on what he calls the fundamentals concepts of flow.
He demonstrates a fundamental step in all these systems is to reduce the WIP. DBR and Critical Chain is also derived from these concepts.
A truly recommended reading:

Popular posts from this blog

Waterfall - The Dark Age of Software Development Has Returned!

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Interlude: The Cost of Agile