Kanban and flow

Kanban is a way of managing work by limiting how much of it is started at once, and flow is the name for what that limit produces. It originated in lean manufacturing at Toyota, reached knowledge work through David Anderson's formulation of the practices in 2010, and PMI treats it as one of the adaptive life cycles. Flow based delivery controls work by capping what is in progress, where cadence based delivery fixes what will fit into a cycle. Work is made visible on a board, each stage carries a cap on how many items may sit within it, and nothing new is pulled in until something leaves.

This is a genuine alternative to cycles, because a great deal of work does not arrive in batches. Support, operations, compliance responses and anything with an unpredictable arrival rate all fit badly into a fixed cycle. A two week commitment made on Monday is invalidated by Tuesday's incident. Flow handles such work without abandoning control and without pretending that the interruptions are exceptional. The sections below describe the five practices, the arithmetic that makes the limit work, what the board models, how urgent work is handled and how a flow team forecasts.

The five practices and what each one is for

The first practice is to visualise the work. A board with a column per stage gives everybody the same picture of where things stand and where they are stuck, and its value lies in making a queue obvious in a way that a list of assignments never does.

The second practice, and the one that does the actual work, is to place a number on each column limiting how much may be in progress within it. Teams remove this one first, once it becomes uncomfortable.

Managing flow comes third. The team watches where items wait. The question is whether work is moving, and a busy person is no evidence either way.

Explicit policies follow. What it takes for an item to move from one column to the next is written down, because most disputes about whether something is finished turn out to be disputes about a policy nobody wrote.

Last, improvement is collaborative and it proceeds on evidence taken from the measures, and never on anybody's opinion of how the work ought to feel.

Why limiting work in progress speeds things up

The second practice rests on a piece of arithmetic. Average cycle time equals average work in progress divided by average throughput.

Read with numbers, the effect is stark. A team that finishes five items a week and holds ten in progress has an average cycle time of two weeks. That same team holding thirty in progress, and still finishing five a week, has a cycle time of six weeks. Nobody has become slower. Everything simply waits longer, because each item spends most of its life queueing behind others that were also started early.

What a requester experiences is the right hand column, and what the organisation receives is the middle one. Starting more work moves the first and leaves the second untouched. This is the trap, since starting work feels like progress and registers as responsiveness.

The board is a model of the real process

The queues in that arithmetic have to be seen to be managed, and the board is where they appear. Every column represents a state that work actually passes through, and this includes the waiting states nobody would design deliberately. Ready for review, waiting for test environment and awaiting sign off are the columns that teach, because they are where time is spent and where no work is happening.

Splitting a column into doing and done makes the queue visible. Ten items in the doing half represent capacity in use. Ten items in the done half waiting for the next stage represent a handoff problem. On a board that does not separate the two, they appear identical, and that is the whole argument for the split.

Classes of service

The board also has to show that some work is more urgent than the rest, because pretending otherwise pushes urgent work through informal channels.

An expedite class covers work that jumps the queue. Only one such item may be in the system at a time. A fixed date class covers work with an external deadline, started early enough to be finished by it. A standard class takes items in order. An intangible class covers work with no immediate return and a real long term cost, such as the reduction of technical debt.

Naming the classes and the policy attached to each is what prevents every request from becoming urgent. Where no expedite class exists, urgency is expressed by asking loudly, and the loudest requester then sets the order.

Forecasting without estimates

A requester who has been given a class of service also wants a date, and a flow team answers from history. A team with several months of history holds a distribution of cycle times, and such a distribution forecasts better than an average does.

A percentile is the useful statement. Where eighty five per cent of items over the last quarter finished within twelve days, twelve days is what to tell a requester, with the remaining fifteen per cent stated honestly. This is a stronger commitment than an estimate produced by examining the item, because it is built from what happened.

For this reason flow based delivery is able to drop sizing entirely and still answer the question a sponsor asks. The forecast derives from the measured behaviour of the system.

Where each syllabus puts it

Kanban originated in lean manufacturing and reached knowledge work through David Anderson's formulation of the practices. Scrum adds it as a complement, and teams commonly run a cadence for planning and review while managing the work inside the cycle by flow.

PMI treats it as one of the adaptive life cycles, and examination questions tend to describe a situation without naming the method. Unpredictable arrival, a support component alongside a project one and a team drowning in started and unfinished work are all descriptions of a problem that limiting work in progress addresses. Recognising the shape of the problem behind the description is what is being tested, and the method is rarely named in the question itself.