What is Kanban?
Basic
difficulty
Stage 1
Agile IQ® Level
Flow
Practices
Kanban
Framework
Introduction
Kanban is a tool for optimising the flow of value through a process that uses a visual, work in-progress limited pull system.
Kanban is most often used with Scrum or Lean.
History
There are a number of interpretations of how Kanban is defined and used. It was originally developed by Taiichi Ohno, an engineer at Toyota, to improve manufacturing efficiency and monitor inventory levels to remove waste.
In 2004, David Anderson published the book “Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results”, which covered concepts such as flow, bottleneck, visual control and cumulative flow diagram, all of which he later incorporated into the Kanban method in 2010.
In 2007, Daniel Vacanti helped to develop the Kanban Method for knowledge work and managed the world’s first project implementation of Kanban. Together with Yuval Yeret, he developed the Professional Scrum with Kanban course for Scrum.org.
What is Kanban?
Limit work in-progress
- Manage work items from the time they’re an idea through to the time they’re finished and in the hands of customers.
- Don’t overload the system of work. It reduces quality and increases rework.
- Actively reduce context switching. Context switching introduces a significant time overhead.
- Leave some capacity to jump on unexpected work. This promotes pairing and team-work and enables people to quickly switch to something else if necesary without abandoning work in-progress.
Visualise your team’s workflow
- Visualise all the work the team is doing.
- Don’t visualise each of the team’s projects – you won’t get a good picture of the volume of work the team is trying to do, or the impact of context switching.
- It’s easier to manage work when you can see all of it in one place.
Actively manage work item age
- Respond quickly to blocked items.
- Pull work at the same rate as it gets to Done.
- Ensure work items aren’t left to age unnecessarily.
Inspect and adapt the definition of workflow
- Document the team’s rules for how it progresses work from one step to another. The Definition of Done is an example of a set of rules for allowing work to pass from in-progress to Done.
- Make the rules for the workflow transparent to all team members.
- When work “goes backwards”, this is an example of rework and waste. Refine the workflow rules so it doesn’t happen again.
Metrics – Measure the flow of work
The four basic metrics of flow that teams using Kanban need to track are:
- Work in Progress (WIP): The number of work items started but not finished. The team can use the WIP metric to provide transparency about their progress towards reducing their WIP and improving their flow. Note that there is a difference between the WIP metric and the policies a Scrum Team uses to limit WIP.
- Cycle Time: The amount of elapsed time between when a work item starts and when a work item finishes.
- Work Item Age: The amount of time between when a work item started and the current time. This applies only to items that are still in progress.
- Throughput: The number of work items finished per unit of time.
Kanban Myths
Just visualising work?
While Kanban requires teams to visualise their work, visualisation alone isn’t Kanban. Kanban requires a team to:
- Do just-in-time planning.
- Actively manage and optimise the flow of work.
- Plan continuously and iteratively.
- Improve continuously and iteratively.
- Use visual management to understand the bottlenecks to flow and be proactive in removing them.
Kanban is very difficult for new teams to adopt as they are not used to the rigour that is required to manage flow.
Anti-pattern: Can't we just use Kanban?
Some teams don't want to change the way they work and, rather than adopt Scrum, ask "can't we just do Kanban". This is an excuse to not change and has nothing to do with Kanban. Most of these teams feel that Kanban = a visual board. This is a symptom of cargocult agile.
Scrum vs Kanban
Scrum is a framework for agile product development whereas Kanban is a tool. They are both complementary. Most advanced agile teams use both. Some key differences in their structure include:
| Kanban | Scrum | Prescribed events | None | Sprint Planning, Daily Scrum, Sprint Review, Retrospective and the Sprint |
|---|---|---|
| Planning | Just-in time | Sprint-sized batches and a formal Sprint Plan | Commitment | Based on capacity. Team members commit to completing work before taking on new work. | Quality (Done), the Sprint Goal, and the Product Goal. Team members hold each other to account. | Core Metrics | Lead time, cycle time, work item age. | Increment of Done by the end of the Sprint | Improvement | Continuous and iterative | Actively planned and executed Sprint-to-Sprint |
Myth: Kanban vs Scrum
Scrum has a minimal, pre-defined structure. When people are used to working in an ad-hoc way, and operate more as a workgroup instead of one team, the structure of Scrum can seem too prescriptive. This attitude has promoted much of the Scrum vs Kanban debate, suggesting that Kanban is a superior alternative to Scrum. The reality is that the discipline required to effectively do just-in-time planning and proactively manage flow is beyond most teams when they are starting out.
Kanban Teams
Kanban is often chosen by teams who feel Scrum isn’t suited to their work. As Kanban is a tool, however, there is no such thing as a “Kanban Team”. Many teams who don’t wish to change the way they work opt to simply visualise their work and call it “Kanban”. Kanban, however, is much more than just visualising work.
Kanban is used by teams to optimise the flow of their work. Teams, therefore, need another framework such as Scrum or Lean, to assist with work structure that Kanban can then be applied to.
Download
Kanban is a strategy for optimising flow. The practices in the Kanban Guide for Scrum Teams help enhance and complement the Scrum framework and its implementation.
All fields are required.
