Does the development department in your organization have a tendency to keep too many balls in the air at the same time? Do you as an organization find it difficult to focus on one thing at a time and complete your assignments on a continuous basis? Kanban may be the answer – it’s a minimalist process tool that aims to limit the amount of work in progress. With the help of clear visual signals, such as brightly colored Post-it notes on a whiteboard, the team keeps track of how many tasks are being processed at a given time. Kanban can usefully be combined with other process tools.
Visitors to the Imperial Gardens in Tokyo get to see an ingenious Kanban system. The museum staff use a straightforward, yet foolproof method for keeping track of how many people are in the palace grounds at any one time. Entry to the palace is free of charge, but every visitor is given a plastic tile which has to be handed back on the way out. When there are no more plastic tiles available the staff know that the visitor quota is full. New visitors then have to stand in line and wait, or, alternatively, staff can fetch badges from any of the other palace entrances where there may be more tiles than are needed for the moment.
Three basic principles
The word Kanban means ‘signboard, billboard’. In the Lean world, Kanban means a signalling system that triggers action. It can be sticky notes, flags, colored balls, etc., signalling, for instance, that stocks are running low. Simplicity is crucial: Kanban systems must never be too complex, and should not use electronics, computers or anything that requires power and support.
Kanban is based on three principles:
The theory is that flows can only be controlled and improved when they are clearly visible. In a production environment, the flow is often most evident to the person looking out over the factory floor, so here signals such as flags can be placed physically in appropriate places. In a development environment, on the other hand, the abstract processes have to be made visible in some way – for example through the establishment of a Kanban board.
A pull principle should apply throughout the process – stations located downstream must demand
action from those situated further up the production line. This makes it possible to regulate the flow so that each station receives as much work as it can handle.
• Theory of constraints
All processes contain bottlenecks. Only here should efforts be made to optimize the flow. When putting the principles into practice the challenge is therefore:
1. to visualize, no matter whether the work is physical or intellectual.
2. to limit the amount of work in progress, so as to maintain the flow and help staff to focus on one thing at a time.
3. to measure lead times in order to detect bottlenecks
Many benefits – few problems
Kanban is a process tool that can help development organizations in their work, whether or not they work with Scrum:
- Less stress, better focus. Visualization and flow control spread the workload out more evenly, reducing work “sprawl”.
- Improved participation. It is basic psychology: what we can see and touch encourages greater interest and involvement.
- Developed working methods. Kanban helps identify constraints in the process, enabling the organization to better utilise its resources to resolve the underlying issue.
- Improved internal communication. For both management and customers it’s easy to see a project’s status, without having to barge in and disrupt the group’s work.
The Book “Kanban – successful evolutionary change for your technology business” by David Anderson, is a practical guide for how to start using Kanban, and how to adapt the system for advanced needs. The book can be ordered from David Anderson’s site.
Lean Magazine: What would you say can be the benefit for an organization already using Scrum, to introduce Kanban as well?
Henrik Kniberg: The main benefit is that knowledge of Kanban will expand their options. Initially Kanban can be used in addition to Scrum. For example: Visualize the whole value stream by “stretching” the Scrum Board so it includes the stuff that happens upstream (for example getting backlog items to a ready-ready state) and what happens downstream (for example deploying to production). This often leads to insights such as “Hey, look, we [the scrum team] are not the bottleneck, all the stuff we call “done” is really just piling up in front of the operations team”. Sometimes the bottleneck is upstream, for example the Product Owner is having trouble getting backlog items ready for a sprint. Visualizing the whole value stream increases collaboration and decreases the risk of suboptimization. Combining normal sprint work with more reactive work such as support and urgent maintenance issues (often referred to as “unplanned items” in Scrum teams). Kanban can be used to allow the team to be more responsive than “please put your request in the product backlog and we might get to it next sprint”. Work In Progress-limits within the sprint, for example a team may decide that they should have at most two stories in progress at a time. Some organizations successfully use Scrum to systematically identify and eliminate the biggest sources of waste, and after a few years reach a point where Scrum itself remains as the biggest source of waste. So they remove the wasteful parts and evolve into a Scrum- Kanban hybrid. This matches the Shu-Ha-Ri progression, they have now moved from Shu (follow the rules) to Ha (change the rules). This isn’t a failure mode of Scrum, it is a success mode. Scrum made itself redundant, just a like a good manager or Scrum Master should strive to make himself redundant.