Kanban translated literally: “Kan” means visual, and “ban” means card or board. Kanban's aim is to minimize WIP (Work-In-Process), or inventory, between processes by making sure that the upstream process produces parts only if its downstream process needs it. Of late, Lean and Kanban are growing in popularity. More and more companies are setting up Kanban Boards, limiting WIP and eliminating Muda. Michael Dubakov investigated the wrong and right reasons for applying Kanban.
Michael suggested the following 5 false reasons for adopting Kanban, along with comments on why he felt they were fasle.
- Our stories vary in size a lot from 1 point to 40 points. Large stories just do not fit into an iteration – Team needs to understand how to split the story into smaller pieces. As per Queueing Theory, it is better to have small stories with roughly equal size.
- We can’t complete most stories in a single iteration – Having smaller iterations too might have transaction cost associated.
- Retrospective meetings are waste, they do not help in process improvement and we want to remove them – The team should analyse the reasons for failed retrospectives. One of the most common reason is "no Action Items after the meeting".
- We have a single pool of developers and share them between projects. We can’t form stable project teams - If a team is experiencing difficulty in planning sprints with shared pool of developers, try to fix the root of the problem first - switch to cross-functional teams and eliminate multi-tasking.
- Kanban is so simple! No plans, no estimations, no iterations, no overhead – There is no silver bullet and no alternative to hard work, discipline, target on perfection and constant improvements. All this is required to adopt any agile methodology.
Michael also suggested 5 right reasons for applying Kanban, according to him,
- Ability to release anytime – Scrum and XP, usually do not release in the middle of the sprint. This is not the case with Kanban.
- Ability to change priorities on the fly – Scrum is reluctant to change the priorities in the middle of the sprint. In Kanban, if there is an urgent request to implement or a really important user story, the team can just put it on top of the queue.
- No need in iterations – Iterations are perfect for getting into a rhythm. However, after a point, when the flow is established, iterations could rather become a waste.
- No need in estimates – Just as iterations, estimates could also become a waste. Michael suggested that in their case, they have a prioritized backlog and they just take the most important user story and implement it.
- Perfect flow visualization - Kanban Board provides a very clear view on current work in progress. It visualizes flow and enables fast planning and tracking.
Responding to a comment by Tobias Mayer on other good reasons to adopt Kanban, Karl Scotland mentioned the following,
Off the top of my head, 5 reasons to use Kanban approach:
- Model the whole value stream
- Visualise the work
- Limit work in progress
- Establish a Cadence
- Enable continuous improvement
Thus, just like any other process, Kanban too has its reasons for adoption. An Agile team should not switch to Kanban just because an existing process is not working from them. The key lies in doing an introspection on what they could improve in the current process and apply Kanban only if they have the right reasons.