Kanban: Who invented it?
No, it was not the Swiss. Kanban was invented and developed by Taiichi Ohno from Japan‘s Toyota Motor Corporation. The reason was the insufficient productivity of the company compared to American competitors.
Kanban is a method of production process control, and when applied correctly, it can be used to make bottlenecks in the production process visible. Transparency can thus be created, as it is required above all by Scrum.
Scrum and Kanban at the same time?
Of course; a clear YES! Scrum is Scrum and Kanban is Kanban. The Sprint Board belongs, as the name suggests, to Scrum. Built as a Kanban Board, it can be used to find and fix bottlenecks.
But now to the topic:
Kanban misunderstood
The two common mistakes:
- The actual production process – the implementation of the Sprint Plan – is only represented by a single column (often titled „In Development“ or „WiP“ (Work in Progress)) and / or
- the waiting positions (Ready-4-…) are missing, from which the following production step can pull its work. Kanban works according to the pull principle
Wrooong …
How would you like to determine with only one column representing the entire production process, whether or not the process contains a bottleneck somewhere, if it is not broken down into its individual steps?
For example, how do you know if your colleagues are keeping up with testing if the software developers simply move all the completed user stories to the Testing column?
Kanban correctly used / applied
- The production process – the implementation of the Sprint Plan – was divided into the three work steps In Dev., Code Review and Testing.
- Since the pull principle applies in Kanban, a waiting position (Ready-4-…) was introduced before each step.
Interpretation of what is happening
Assumption:
The Sprint, which the present Sprint Board represents, lasts 3 weeks and we are in the middle of the last week.
- In the Ready-4-Testing column there are quite a few user stories that still need to be tested. It seems like testing is not keep up. Bottleneck!
- We are almost at the end of the sprint and in the To Do column there are still quite a few user stories whose implementation has not even started yet. Will the sprint goal be reached? Probably not.
If User Stories, and / or (Sub-) Tasks, are piling up in a waiting position, it seems that somewhere in this process things are not progressing. There is a bottleneck here. There can be many reasons for this and this of course needs to be investigated. However, it is important that a good Kanban board reveals such a bottleneck.
If the user stories pile up in the Ready-4-Approval column, then the product owner, who is responsible for the acceptance, would be the bottleneck.
Conclusion
It is not uncommon for the Velocity Chart (see Jira) to show that a team regularly misses its sprint goal. In such a case, an in-depth analysis of the reasons for this is required. But if there is not enough transparency about what is happening within the sprint, it won’t be possible to find a lever for optimization. The sprint process must not be a black box.
If you want to get more transparence about your production processes and reduce bottlenecks, then
