Description
Here is an exercise most organisations skip. Take your delivery pipeline as it is today, with your team sizes, your automation and your review capacity. Now double the volume arriving at the front of it. Walk the stages: review, integration, testing, security, deployment, the people who watch it in production. Where does the queue form first? Not in principle. In your system.
Most leaders assume that finding the bottleneck and fixing it ends the problem. It does not, because the pipeline is a chain of dependent stages and only one of them is the limit at a time. Relieve review and integration saturates. Speed up integration and deployment becomes the chokepoint. Automate deployment and the people absorbing incidents cannot keep up. Identifying the constraint is not a project with an end. It is a loop, and it has to be re-run every time one is relieved.
What makes this urgent rather than merely true is that queues do not degrade in proportion to load. As a stage approaches full utilisation, waiting time grows out of all proportion to the extra work arriving, so a system that looks comfortably busy is much closer to a standstill than it feels. Acceleration pushes on both sides of that at once: more arrives, and each item takes longer to handle because it is larger and needs more careful reading. Doubling the input is more than enough.
So the question this dimension scores is whether you know where your limit is and whether anything defends it. A work-in-progress cap that tooling enforces stops work entering a stage that is full. A cap that everyone agrees to is a cap until the quarter it matters. Most organisations discover the answer during an incident, which is the most expensive possible way to run the exercise.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Nothing describes where work waits. Queue depth and waiting time are not measured by stage, so the constraint is a matter of opinion and usually gets named after whichever team complained most recently. Adding capacity is guesswork with a budget attached.
The tellAsk which stage fills up first if merge requests double. If you get several confident answers that disagree, nothing is measuring.
- 2
Tacit
Some people know exactly where work piles up, because they have spent a year watching it happen. They avoid the jam and warn other people away from it. The knowledge is real and it sits in a few heads, so nothing acts on it unless one of them is in the room.
The tellAsk three people where the pipeline jams. If they agree and none of them can point to a number, the constraint is known and unmeasured.
- 3
Visible but inert
Waiting time and queue depth are measured per stage, so the constraint is visible on a chart. Nothing acts on it. Work keeps entering at whatever rate it arrives, no cap slows the input, and the chart records the queue lengthening rather than shortening it.
The tellFind the stage with the longest queue on your own dashboard, then find what limits the work entering it. If nothing does, the measurement is describing the problem.
- 4
Acted on
The constraint is identified and the system defends it. A work-in-progress limit is enforced by tooling rather than agreed in a meeting, so work stops entering when the constraint is full, and the limit comes from measurement rather than from what felt reasonable at the time.
The tellFind the last time your constraint hit its limit. Something held or refused new work automatically, rather than a lead noticing the queue and asking people to slow down.
- 5
Durable
Finding the constraint is a repeating practice rather than a project. When one stage is relieved the next one is identified and capped, limits are revised deliberately, and the caps are still enforced in the quarter when delivery is behind, which is when they matter and when they usually get abandoned.
The tellLook at where your constraint was a year ago and where it is now. If it moved and the limits moved with it, this is maintained. If the cap sits where it was first set, nobody has revisited it.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Reinertsen, The Principles of Product Development Flow (book, 2009)
Set out the economics of queues in development work: as a stage approaches full utilisation its waiting time grows out of all proportion to the extra load, and large batches lengthen every queue behind them.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Velocity and the constraint →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.