Kanban Method
Kanban visualises work in progress on a board and limits WIP to improve flow. Unlike Scrum, it has no sprints or prescribed roles - it is an evolutionary change method.
What is the Kanban method?
Kanban is a method for managing and improving work using visualisation and flow optimisation. Originating from Toyota's manufacturing system (Just-In-Time production), it was adapted for knowledge work by David J. Anderson.
Key difference from Scrum: Kanban has no sprints, no prescribed roles, and no required ceremonies. It is an evolutionary, change-management method applied to an existing process - rather than a prescriptive framework.
Core Practices
1. Visualise the Work
Create a Kanban board representing your workflow as columns:
| Backlog | Analysis | Development | Review | Testing | Done |
Each work item is a card moving left to right. Visualisation reveals bottlenecks - if cards pile up in one column, that's your constraint.
2. Limit Work in Progress (WIP)
Each column (or the entire board) has a WIP limit - the maximum number of items allowed in that state simultaneously.
Example: Development: [WIP limit: 3] - if 3 items are in development, no new items can start until one moves to Review.
Why WIP limits work:
- Multitasking reduces throughput (context switching overhead)
- Limiting WIP forces the team to finish before starting new work
- WIP limits surface bottlenecks: when Development is full but Review is empty, the team pulls from Development to Review - cross-functional collaboration
- Lower WIP -> shorter cycle times (Little's Law:
Cycle Time = WIP / Throughput)
3. Manage Flow
Optimise the smooth movement of work through the system. Metrics:
- Lead time: total time from request to delivery
- Cycle time: time from starting work to delivery
- Throughput: items completed per time period
- Flow efficiency: % of time items are actively worked (vs waiting)
4. Make Policies Explicit
Define and post the rules: what does it mean for an item to be ready to pull? What is the definition of done per column? Who can pull items? Explicit rules reduce misunderstandings and enable objective discussion.
5. Implement Feedback Loops
Regular cadences (not mandatory, but encouraged):
- Daily standup: not a Scrum standup - walk the board right to left, focus on blocked/near-done items
- Replenishment meeting: pull new items from backlog when capacity exists
- Service delivery review: review metrics, SLAs, customer satisfaction
- Operations review: higher-level process health across teams
6. Improve Collaboratively, Evolve Experimentally
Use flow metrics and retrospectives to identify improvement opportunities. Run experiments (change a WIP limit, add a column, change a policy) and measure impact.
Kanban vs Scrum
| Kanban | Scrum | |
|---|---|---|
| Cadence | Continuous flow | Fixed sprints |
| Roles | None prescribed | PO, SM, Developers |
| Planning | Pull when capacity | Sprint planning |
| Commitment | No sprint commitment | Sprint goal |
| Change | Anytime | Between sprints |
| Metrics | Cycle time, throughput | Velocity, burndown |
| Best for | Operations, support, continuous delivery | Product teams with feature roadmap |
Scrumban
A hybrid: use Scrum's structure (roles, reviews) but add Kanban's WIP limits and flow metrics. Common in teams transitioning from Scrum to more continuous delivery.
Cumulative Flow Diagram (CFD)
A visualisation of work item counts in each state over time. A widening band indicates a bottleneck - work is accumulating in that state. A narrowing band means flow is improving. Used for cycle time forecasting and process health monitoring.
Interview Angle
Kanban appears in architecture interviews when discussing DevOps, continuous delivery, or team organisation. Key insight: WIP limits are the mechanism - they force focus, reduce context switching, and surface bottlenecks. Connect to Little's Law: reducing WIP is the most direct way to reduce cycle time. For operations/support teams or continuous delivery pipelines without fixed releases, Kanban is often better suited than Scrum.