Flow based delivery controls work by limiting how much is started, 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 and not a simplification, 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 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 which a list of assignments never does.
Second, and this is the practice which does the actual work, place a number on each column to limit how much may be in progress within it. Teams remove this one first, once it becomes uncomfortable.
Managing flow comes third. Watch where items wait and not how busy individuals appear, since the question to ask is whether work is moving and not whether everybody has something to do.
Explicit policies follow. What it takes for an item to move from one column to the next is written down and not assumed, because most disputes about whether something is finished turn out to be disputes about a policy which nobody wrote.
Last, improvement is collaborative and it proceeds on evidence taken from the measures rather than on anybody's opinion of how the work ought to feel.
Why limiting work in progress speeds things up
Underneath this sits 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 which 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 which were also started early.
| Work in progress | Throughput | Average cycle time |
|---|---|---|
| 10 items | 5 per week | 2 weeks |
| 20 items | 5 per week | 4 weeks |
| 30 items | 5 per week | 6 weeks |
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
Every column represents a state which work actually passes through, and this includes the waiting states which nobody would design deliberately. Ready for review, waiting for test environment and awaiting sign off are the columns which 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, whereas ten items in the done half waiting for the next stage represent a handoff problem. On a board which does not separate the two, they appear identical. That is the whole argument for the split.
Classes of service
Not everything deserves the same treatment, and to pretend otherwise pushes urgent work through informal channels.
An expedite class covers work which 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 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 and not from what somebody expected to happen.
For this reason flow based delivery is able to drop sizing entirely and still answer the question a sponsor asks. The forecast derives from measured behaviour of the system, and not from judgement about the work.
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 not as an alternative, 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 exam 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 which 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.