Visualising work is easy; limiting it is the hard part

Six practices, and the book that names them

The Kanban Guide, as retrieved on 16 September 2026, states its own basis directly: 'The Kanban Method as described here is based on Kanban: Successful Evolutionary Change for Your Technology Business, by David J Anderson,' a book an Open Library catalogue record confirms was first published in 2010 by Blue Hole Press. The guide sets out six general practices: visualise work, limit work in progress, manage flow, make policies explicit, implement feedback loops, and improve collaboratively while evolving experimentally. Of these, the guide gives visualisation and limiting work in progress the most direct causal claim: 'Visualizing that work and the flow of that work greatly improves transparency,' and, on limits, 'when resources are fully utilized there is no slack in the system and the result is very poor flow.'

Evolutionary change for existing work, not a new process

The guide's stated motivation was 'to find a way to manage and improve professional service businesses as well as a way to provide a humane change method,' adapting ideas from lean manufacturing to knowledge work rather than importing a factory process wholesale. Its own three change-management principles say to start with the process a team already runs, pursue evolutionary rather than radical change, and encourage leadership at every level rather than only from management. That framing matters for who the method suits: teams that cannot or will not adopt a new workflow wholesale, and want a way to see and improve the one they already have, rather than teams looking for a prescribed set of roles and ceremonies.

The limit is the part software makes optional

A digital board that copies columns and cards is trivial to build and instantly recognisable as 'kanban' to most users, which is why the visualisation half of the method spread so widely through board software. Limiting work in progress is a different kind of feature: it requires the team to define a number, and then to actually stop pulling in new cards once a column is full, even when that is uncomfortable. Most board tools ship without a default limit and treat the work-in-progress field as optional configuration rather than an enforced constraint, so a board can display a column at ten cards indefinitely with no visible consequence. The guide's own claim is that this is exactly the condition — full utilisation with no slack — that produces poor flow; a tool that never enforces the limit cannot produce the improvement the guide attributes to it.

• Does the board actually block or flag new work when a column's limit is reached, or only display a number?
• Who set the current limit, and when was it last reviewed against actual flow?
• Is the team managing flow, or just moving cards to make the board look busy?

Visualising work is the easy half of the method to adopt and the half every tool now offers by default. Limiting it is the half that asks a team to say no, which is why so many boards display a system with no slack left in it at all.