The theory
Why Kanban works
The short version takes a minute. The five chapters under it take about 23 minutes, and every number in them is measured from a workflow simulated a day at a time, so if you doubt a claim, you can press play and watch it happen.
The short version
- Most boards show where the work is, and never how long it has been there. Put a counter on every card and the first surprise arrives: a team of eight, with about four days of work in each change, takes 12 days to finish one.
- The work is not slow; it waits. A developer starts a second card while the first waits for review, and 24 cards in progress for eight people means every card spends most of its life waiting for somebody.
- Limit how much each phase may hold, about one card per developer, and the same team finishes about as much (9.6 a week against 10.0) in 6.5 days. Half the wait, for the same work.
- Why: the wait is the work in progress divided by what the team finishes. That is Little's Law. A team cannot finish twice as much tomorrow, but it can hold half as much today.
- When a limit stops somebody, they move another card forward (review it, validate it, unblock it), and the team finishes 10 a week against 5 for people each counting their own.
- A workflow runs at the pace of its slowest step. Keep that step fed, hold the others to its pace, and make it faster before you add anybody to it.
Five chapters, one at a time
Chapter 1 · 3 min The board you already have Why does four days of work take twelve?Chapter 2 · 6 min Limit the work What happens when a team may only start so much?Chapter 3 · 5 min Why limits work Where does the wait come from, and why does less work make it shorter?Chapter 4 · 6 min The slow step What sets a team’s pace, and how do you protect it?Chapter 5 · 3 min What to do on Monday Six changes a team can make next week, and a place to try them first.
Start with the first chapter
It is three minutes long, and it ends on the number most teams have never looked at.