Adding Kanban
Intermediate
difficulty
Stage 4
Agile IQ® Level
Kanban
Tools
Lean
Framework
Introduction
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.
Components of Kanban
Kanban has:
- Four mandatory practices: Visualising workflow, limiting WIP, actively managing work item progress and inspecting and adapting the definition of workflow.
- Four mandatory metrics: WIP, cycle time, work item age and throughput.
Visualising work dosn't make it a Kanban Board
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.
ORIGINS OF KANBAN
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.
How is Kanban different from a task board?
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;
- Eliminate overproduction (waste);
- Support visual control; and to
- Support and encourage improvements.
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]
There's no such thing as a 'Kanban Team'
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".
VISUALISATION
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]:
- Identification of unanticipated events or actions
- Identification of variance in process or quality
- Identification of team and/or business performance
- More intuitive communication of process-related data
- Real-time or near real-time reporting
LIMITING WORK IN PROGRESS (WIP)
The analogy Taiichi Ohno used was that of lowering the water levels in a running river. By doing so you are able to observe the rocks (issues) that impede the smooth flow of water (work items).
Optimising flow is hard
Kanban isn't for new teams. It takes great discipline to actively limit WIP in order to increase throughput.
PROGRESSION CRITERIA
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].
Ready Criteria
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.
Definition of Done
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.
METRICS
There are four essential and mandatory metrics to measure flow for Scrum team utilising Kanban [2]:
- Work in Progress (WIP – the number of work items started but not finished.
- Cycle Time – the amount of elapsed time between when a work items starts and finishes (e.g. effort).
- Lead Time – the amount of time between when a work item starts and finishes (e.g. duration).
- Throughput – the number of work items finished in a given amount of time.
Note: for further definitions see Lean Lexicon – Cycle Time. [8]
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.
Things to watch out for
- Teams should be consistent in their application of Scrum before applying additional aspects related to Kanban. Premature adoption of Kanban practices may cause unintended consequences.
- The Definition of Ready and Definition of Done are quality standards. They can be misused to perpetuate inefficient or unnecessary business practices and processes.
- Value stream maps are not necessarily the most appropriate tool for immature or unstable processes.
Actions to try
- Select one aspect of Kanban and apply it within your team. After applying the change for a sprint assess the progress and results of the change in the team’s retrospective.
- Seek opportunities to automate the collection of time stamps that enable the calculation of Lead Times and Cycle Times.
References
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
