Kanban
Kanban makes work visible on a board, limits how much is in progress at once, and manages the flow across it, so bottlenecks show up immediately instead of hiding in a backlog.
Cards move across columns on a board, each one capped so work in progress never piles up.
Reach for this when…
- Everyone is busy but very little is actually finishing.
- Work in progress is invisible until something is late.
- A new task queue-jumps constantly and nobody can see the cost of that.
How to run it
- Visualise the work: a column for every stage it passes through.
- Limit work in progress per column, with a hard cap.
- Manage flow: watch where cards pile up, not just where they start.
- Make the rules for moving a card explicit, so everyone applies them the same way.
- Review the board together and adjust the limits as the team learns.
A worked example
Situation. Kenji Tanaka led Osaka Code Works, a software team in Osaka, Japan, where every developer had four or five tasks open and almost nothing shipped in a given week.
Applied. He put a three-item limit on the "In Progress" column and made the team finish or explicitly park a task before starting another, with blocked items surfaced daily.
Result. Fewer things were open at once, but finished work per week roughly doubled within a month, because the real bottleneck, a slow review step, was suddenly visible.
The catch
Kanban only exposes a bottleneck, it does not fix it, and teams sometimes stop at the board instead of addressing the constraint the board revealed. Physical or loosely policed boards drift out of date fast, and a limit nobody actually enforces is not a limit. It also says little about prioritising across competing projects, only about flow within one.
A board with no work-in-progress limit is a to-do list wearing a costume.
Origin: Taiichi Ohno (origin, Toyota); David J. Anderson (knowledge-work Kanban)