What do the Kanban Method's review cadences inspect, and how do they nest?

## Why several cadences instead of one meeting A team improving its flow needs several different questions answered, and they do not move at the same speed. Whether a card moved yesterday is a question for today. Whether a service is meeting what its customers were led to expect needs several weeks of finished work before it can be answered honestly. Bundle them into one weekly meeting and the fast questions crowd out the slow ones - which is the mechanism behind the familiar team that holds a process meeting every week and still never changes anything. The Kanban literature answers this by naming distinct **cadences**: recurring meetings, each with its own rhythm, its own attendees and one question it exists to answer. They form nested loops. The inner loops inspect individual work items; the outer loops inspect the system that produces them. ## The loops, fastest to slowest **The daily meeting at the flow board.** Held in front of the board, it inspects work in progress rather than people. The useful version walks the board from the delivery end backwards and asks about items that are blocked or ageing, instead of asking each person in turn what they did yesterday. **The replenishment meeting.** Decides which items enter the workflow next and at what rate. Its inputs are what the requesters most need and what the team can actually take on; its output is a small selected set, not a quarter of planned work. **The delivery planning meeting.** Looks at the far end - what is finished or nearly finished, and how it reaches customers. Its subject is the shape and timing of delivery, not the composition of the queue. **The service delivery review.** The cadence that most directly drives improvement. It inspects one service against the expectations set for it: the flow data of recently finished work, which explicit policies are producing that data, and which single change is worth trying next. It is also where the previous change's result is read, which is what stops improvement being a list of good intentions. **The operations review.** Wider than one team. It inspects how demand and capability balance across the whole set of services an organisation runs, and it is the meeting where a dependency between services can be settled because the people who own both are present. The literature names further, slower reviews above this - risk and strategy reviews among them - built on the same nesting logic. ## What each one decides | Cadence | Inspects | Typical output | |---|---|---| | Daily meeting | items in progress, blockages, ageing | today's unblocking actions | | Replenishment | what should start next | a small selected set of items | | Delivery planning | what is finished and how it ships | a delivery decision | | Service delivery review | one service's flow data and policies | one policy change to try | | Operations review | demand against capability across services | rebalanced capacity, escalated dependencies | The rhythms themselves are a team's own choice and vary widely between organisations, so an interviewer is listening for what each meeting **decides**, not for a schedule recited from a book. ## How the nesting does the work The fast loop manufactures raw material: blocked cards, ageing items, the queue that keeps re-forming at the same stage. On its own it produces only unblocking - the same obstacle cleared repeatedly, heroically, forever. The slower loop turns that material into a change of policy, because it is the first place with enough finished work to say whether a pattern is real. The slowest loop handles what a single team cannot: a constraint owned by someone who never attends the team's own meetings. Two failure modes follow directly: 1. **Only the fast loop runs.** The team is busy and responsive, unblocks the same dependency for the ninth time, and nobody ever asks why it keeps happening. 2. **Only the slow loop runs.** The reviews are data-rich and the decisions are sound, but nobody has the daily habit of recording what actually stopped, so the data describes the work and not the impediments. ## Anti-patterns worth naming - A service delivery review held with no data, which collapses into opinions about how the last few weeks felt. - A review attended only by the team, so nothing about a dependency owned elsewhere can actually be decided in it. - An operations review that becomes a status report presented upward rather than a rebalancing decision taken jointly. - A daily meeting that walks people rather than the board, so blocked and ageing items go unmentioned. - Treating any cadence as untouchable: a meeting that has produced no decision in two months has the wrong rhythm, the wrong attendees or the wrong question, and the cadence set is as improvable as anything else on the board.