Kanban is a tool to optimise the flow of work.
Once teams are up and running with Scrum they will be familiar with how Product Backlogs are managed and how work flows to and from Sprint Backlogs. To further evolve the management of items worked on by teams and improve the flow of work, teams should introduce additional characteristics applied in Kanban.
The practices in Kanban help enhance and complement the Scrum framework and its implementation.
Kanban has:
Don't mistake Kanban for visualising work using sticky-notes on a board with "to do", "in-progress" and "done". Kanban is a tool for optimising flow and has strict rules about how to achieve that outcome.
The roots of Kanban are based in a statistical inventory management method known as the reordering point method. It enables the reordering of the same volume of parts or products each time inventory is depleted. [1] Taiichi Ohno of Toyota who was a pioneer of Kanban systems was influenced by supermarket replenishment systems adopting such methods.
The methods were extended and evolved under Ohno’s leadership at Toyota, with the primary purpose of reducing waste in processes.
This makes Kanban’s origins in Lean, not Agile.
Kanban systems facilitate just-in-time production and involve pulling work rather than pushing work (onto teams and individuals). This enables Product Backlog items to be worked on when teams have ready capacity, allowing for greater flexibility in planning of work. Kanban systems are designed to allow workers to more readily identify and measure wastes within processes. In turn this improves overall productivity.
The primary functions Kanban provide are to: [1]
Provide work order information
Kanban (cards) provide information about what needs to be produced, in what quantity, and any directions on the where and how the work is to be produced.
Eliminate overproduction (waste)
As work is pulled from a curated Product Backlog or Sprint Backlog, only work that is required at that time will be produced by the team. (In a knowledge worker environment this is less of a risk, particularly when the Product Owner is consistently updating the Product Backlog.)
A key component of Kanban is that work is pulled by the team, not pushed onto the team. Adopting a push approach will result in more work than the team has capacity and impacting overall performance.
Support visual control
See Visualisation.
Support and encourage improvements
Kanban will naturally lend itself to have less work in progress, leading to greater awareness and visibility of issues that impede the flow of work. Flow is the movement of value through the product development system. [2]
Kanban is a tool, not a methodology or process. Just as you wouldn't call a team a "Jira Team" you don't call a team a "Kanban Team".
A visual workplace is self-ordering, self-explaining, self-regulating, and self-improving; where what is supposed to happen does happen, on time, every time, day or night – because of visual devices. [3] Visualisation is more than just making work visible. It provides for systems that enable more effective and efficient management of work activities.
Benefits derived form visual management can relate to process adherence and process performance [4]:
Kanban isn't for new teams. It takes great discipline to actively limit WIP in order to increase throughput.
One of the rules for Kanban [1] is that we only send 100 percent defect-free products onto the recipient. Quality is built in at each process, and processes should never send on any defective products. Doing so creates confusion in downstream processes, conceals problems that cause defects, and ultimately reduce overall performance of teams and the organisation.
Common checks to ensure quality are known as Ready Criteria [6] and Definition of Done [7].
The Ready Criteria are the quality requirements for a work item from the Product Backlog before the team moves it to a Sprint Backlog. The nature of such requirements are specific to individual teams and the work that they perform.
Example 1: A work item involving the implementation of new firewall walls may not be accepted into a Sprint Backlog without the source and destination IP addresses and ports.
Example 2: A work item involving a marketing campagin may not be accepted into a Sprint Backlog without an expiry date and approval from the Legal Department.
The Definition of Done in Kanban contains the quality requirements for a work item in the Sprint Backlog before it is accepted as being completed by the team.
The nature of such requirements are specific to the recipient of the work item, and as such may not be independently defined by the team completing the work item.
Example 1: An operations team may require test results and a rollback procedure in place before accepting code to be deployed into a Production environment.
Example 2: A reporting team may require specific inputs to generate desired reports.
There are four essential and mandatory metrics to measure flow for Scrum team utilising Kanban [2]:
The Lead TIme for a particular work item may involve multiple processes, each with their own cycle time.
By tracking these metrics teams will obtain a better understanding of where to focus to improve the flow of work. Value stream maps are one tool that can assist in documenting an end-to-end process, the related Lead Time and Cycle Time, and what parts of the process are creating bottlenecks or delays.
7. Mitchell, I. (2017) Walking Through a Definition of Done. https://www.scrum.org/resources/blog/walking-through-definition-done
8. Lean Lexicon – Cycle Time. https://www.lean.org/lexicon/cycle-time