Kanban is used to balance the amount of work with available capacity. To achieve that, all tasks are visualised as cards and their progress is being tracked on a Kanban Board as a basis for continuous improvement of the underlying process until optimal flow is reached.
To improve a team‘s effectiveness by visualizing process and work items as well as limiting work in progress (WIP) to match the capacity available.
Outcome / Deliverables
A transparent and continuous workflow that optimally matches a team‘s capacity.
Kanban – Japanese for „card you can see“ – originally developed as an inventory control and production load management method as part of the Toyota Production System (TPS) in the 1950s, started to get applied to knowledge work from the mid 2000s on.
To apply Kanban to a workflow, processes are being broken down into the steps that are necessary for their completion (e.g. Planning>Design> Development>Testing>Review>…). These steps are then usually represented by vertical lanes on a Kanban Board (see illustration).
Kanban cards or sticky notes are subsequently created for each work item and placed on the board, normally starting out from a „to do“ lane. When a work item is being „pulled“, the name of the team member(s) working on it are being added to the card and the card is moved forward to the respective process step‘s vertical lane. Cards can in addition be color-coded or designed to carry additional information such as urgency, type of work, estimated hours, and the like. With every step in the process completed, the card moves forward until it reaches „done“.
By continuously visualizing where items are in relation to the process, Kanban Boards help to identify process bottlenecks where work tends to get stuck.
Through continuous improvement based on experiments and analysis, the process is being optimized and the amount of allowed work in progress is over time adapted to match the individual team‘s capacity (WIP limitation) such that logjams are avoided and a steady workflow is being achieved.
Dos & Dont’s
- Do map your process before applying Kanban
- Use physical boards to improve team discussion
- Measure and discuss frequently and regularly to continuously improve
- Do apply Kanban in Agile environments that defy standard sprint planning such as ticket driven break/fix or DevOps processes.
- Don‘t try to map a process you do not control entirely
- on‘t start with locally dispersed teams
- Don‘t start out with a software-based Kanban system
- David Anderson‘s Kanban blog