The Scrum–Engineering Model
Measure · Fix · Hold
If you run an engineering organisation that is fully occupied and still permanently late, this series is about why, and what to do about it.
The problem is not effort. It is scheduling: work arrives, competes for finite capacity, and has to be ordered. That is the problem an operating system solves, and computer science has spent fifty years on it. The abstractions transfer — not because an organisation resembles a computer, but because both are systems where arrival, capacity and ordering decide the outcome.
And you don’t have to stop the fire to do it. The method isn’t the church of Agile — no hundred ceremonies, no clergy of titled roles. Its minimum is a handful of measurements your tracker already records. It runs inside the tactical hell you’re already in, and as a by-product produces the strategic roadmap, along with the evidence that it works.
By the end of the four parts you will be able to tell whether a delivery problem is a capacity problem or a scheduling one, read the two charts that distinguish them, and recognise the interventions that lower the arrival rate rather than raising the effort.
Where I did this, on-call volume went from roughly six thousand issues a year to roughly six hundred, and nine months of planned delivery landed in three.
An organisation drowning in on-call is an organisation in an interrupt storm. A team planning execution nine months ahead is a team whose working set doesn’t fit in cache. Both are scheduling failures. Both come out of the same budget.
Before anything, agree who sets policy and who runs mechanism. A product manager decides what matters; a product owner decides what goes next. Fuse the two and every scheduling decision reopens the strategy question.
These are roles, not job titles. I’ve seen engineering teams nominally led by their product manager — run as a kind of mini-CEO, and on paper the product owner too. It’s an anti-pattern: many of those PMs were associates, paired with engineering managers carrying ten years or more. The product-owner work got done anyway, quietly, by the seasoned EM.
Look at the Created-vs-Resolved chart, the Control Chart, and the depth of the standing queue. The Control Chart matters most: it is the one instrument nobody can produce the night before.
It tells you . At ≥ 1 the queue grows without bound, whatever anyone does.
Red flag: created and resolved lines that track each other. It looks like a team keeping up. It is a system parked at = 1, with a queue that never drains.
Interrupt work and planned work get separate queues and separate schedulers. Reduce the batch, shorten the loop, bound the lookahead, and let the timer — not the task — decide when work yields.
You will see the slope reverse inside a quarter. The slope, not the queue: it is the earlier signal and by far the more informative one.
→ Part III, The Process, and the first half of Part IV
Every incident gets two fixes: restore service now, and make that class of failure stop arriving. The second is deferred to scheduled context — which is what a separate on-call scrum is actually for.
Almost nobody reaches this phase, and it is the only reason the number stays down. Fixing only buys the right to attempt it.
It isn’t for want of literature. Queueing theory, Little’s Law, lean flow, the Theory of Constraints — the problem is close to universal, virtually every engineering organisation meets it, and the fixes have been in print for decades. The theory in this series isn’t new.
What is hard is seeing it from where you’re standing. Inside a tactical hell the 10,000-foot view is surprisingly difficult to get: the people who could spot the pattern are the ones answering the pager. So organisations do the locally rational thing — ship ad hoc, get it out first and fix it later1, and call the whole arrangement a dynamic work culture. Capacity ends up both fully utilised and permanently behind, and gets told to “work harder™”. But a system averaging 90%+ utilisation has little headroom and rapidly rising latency, and at ≥ 100% the queue does not converge at all.
That is what the method does from inside the fire. The instruments give you the 10,000-foot view the pager never will, and the classes of failure you remove one at a time become the roadmap, each one working evidence that the method holds.
Organisations can either work harder and wither, or apply the basics and weather the storm. But the tools and the measurements have to exist first — one CTO I worked with complained constantly that work never got done, and was himself the highest-priority interrupt in every sprint — which is why measurement comes first.
And also call it CI/CD.↩︎