The 47-item Kanban board at Northwind Retail

The constraint is not headcount - it is work in progress and batch size.

Evidence to present:

1. WIP vs capacity. 47 items in progress across 9 engineers is roughly 5 open items per person. No individual or team can actively progress five things at once, so most of those items are not being worked on; they are queued while appearing 'active'.
2. Little's Law. Lead time = WIP / throughput. At 47 items and an observed lead time of ~19 days, throughput is about 2.5 items per day. If WIP were capped at 18, lead time would fall to roughly 7 days at the same throughput - no extra staff required.
3. Failure demand. 55% of capacity going to unplanned fixes is not a resourcing problem, it is a quality-of-flow problem. Batching 30-60 changes into one deployment makes each release a large, hard-to-diagnose risk event; a 40% change failure rate (8 of 20) is the direct consequence.
4. The CAB is a symptom. A 20% rejection rate for documentation means the control is a paperwork filter, not a risk filter.

Implication: adding four engineers adds WIP and coordination cost before it adds throughput. Present WIP, lead time, change failure rate and % capacity on unplanned work as the four headline measures, with a target trajectory for each.

Choose (b) - smaller, more frequent releases - but pair it with a light WIP limit as the enabling mechanism.

Reasoning:

• (b) attacks the largest downstream cost. The 55% of capacity lost to unplanned work and the 40% change failure rate are both products of batching. Smaller releases shrink the blast radius, make cause easier to isolate, and reduce the size of the CAB conversation. Nothing else on the list removes that much waste.
• (a) is necessary but not sufficient. WIP limits make flow visible and would quickly expose that 47 items is unworkable, but without smaller releases the team will simply hit the limit and stall behind a large deployment.
• (c) is the weakest option. Automating a low-value control makes a bad control faster; it does not reduce risk or improve flow.

Practical 30-day plan: reduce batch size to no more than 10 changes per deployment, move to weekly or on-demand releases for low-risk changes, and set an explicit WIP limit per stage (start with roughly two items per engineer).

Expected signals: average item age drops below 10 days; release count rises while change failure rate falls; proportion of capacity on unplanned work trends toward 30-35%. If failure rate does not fall as batch size falls, that is genuine evidence for a capability gap and the hiring conversation becomes legitimate.

The CAB should be reduced in scope, not abolished - it should stop being a queue and become a risk decision point.

• Standard changes: pre-authorise categories that are low risk, repeatable and well understood (config changes, routine deployments behind feature flags) so they never reach a board. Automate the check.
• Normal changes: route by risk. Low and medium risk go to peer review and automated pipeline gates; only genuinely high-risk or high-impact changes reach a change board, and that board should meet more often or asynchronously.
• Emergency changes: explicit fast path with retrospective review, so a fix is never delayed by a meeting schedule.

Key shift: the purpose of change enablement is to maximise the number of successful changes, not to minimise the number of changes. Move the control measures from 'rejections' to change failure rate and lead time for change. A board that rejects 20% of changes for documentation is measuring the wrong thing and adding delay to the 80% that were fine.

Watch for: removing the board without replacing it with automated risk classification simply transfers risk to the deployment pipeline. The controls must exist; they should not all be human meetings.