Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
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 neat. 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.
Published at DZone with permission of Henrik Mårtensson . See the original article here.
Opinions expressed by DZone contributors are their own.