A couple of days ago, I had a quick conversation with an old friend of mine about the place of done columns - also known as inventories - on the Kanban board. He wanted to know if the internal done column - where the work items that have been completed in that phase are kept -, or the internal queue column - where the work items done in the previous phase -, was the better option. There was a time when I would have said that it didn’t matter, just make it visible, but this time I gave a different answer: favour the internal done columns over the internal queue columns, because a system with internal queue columns might have hidden inventories. The story starts with a small push when one moves the work items to the queue of the next phase:
According to the board above, this push is perfectly legal. Let’s assume for the sake of the example that the developer’s focus is on finishing as many items as possible in Implementation, so she pushes Item D into the queue of Validation and pulls in Item G. Let’s say that the cycle time in Validation is higher than in Implementation, so there is a good chance that Item G will be finished and pushed before Item D is started in Validation. The WIP limits are still honored, and Item G can be pushed into Validation, but with that it becomes full. The flow will stop when she won’t be able to pull more items into Implementation after that fills up as well.
The flow stops because of the temporary slowness of Validation, but the problem has been exposed too late, and additionally an inventory has been created in a form of waste. With her push, she increased the actual capacity of Implementation with the unused capacity of Validation and introduced a hidden inventory in the system (actually, she didn’t do anything wrong here, because the current system allowed her to do those steps). I called it hidden, because it is not visible until a change happens in the flow. When the hidden inventory becomes visible, it generates different kinds of other waste such as muri.
This problem won’t make your organization go bankrupt, but can cause some damage, especially when the work in Implementation and Validation is done by completely separate sub-organizations (this damage usually manifests as in half-done features, feature studies, or documents waiting to be pulled one day).
There may be many solutions, I can think of two at the moment:
- Set the WIP limits according to the current capacity (this requires measurement of the capability and throughput in the different phases)
- Use internal done columns instead
Both of the solutions will signal early enough if there is a disturbance in the flow. There is one more obvious, but important detail which is worth mentioning: the inventories must be included in the WIP limits, not like in the example below:
Here, the flow is not continuous and the mura waste caused by an unlimited inventory is huge. Of course, the visualization will show when the situation gets critical, but again this signal comes too late when a lot of effort has already been put into the work items staying in the inventory, and that investment won’t pay off in the near future.
comments powered by Disqus