Northwind Mutual: Mandated Sprints, Unchanged System
Northwind Mutual runs shared IT services for 380 staff across 24 teams. Last Q3 the CIO mandated that every team, including the nine teams doing incident and request work, adopt two-week Scrum sprints by the end of Q1. Seven months later: 11 teams hold all ceremonies, but 45% of each sprint is consumed by incidents that arrive mid-sprint; the change advisory board still meets weekly and rejects roughly one change in five, so deployable work waits up to nine days for a slot; product owners are team leads with no budget authority and a 70% operational workload; a capability assessment scored 2.1 out of 5, and leadership now wants to skip the basics and procure a scaled framework this quarter. The learning budget was cut 12%. In the pulse survey, 58% of staff say they understand why the change is happening, while 22% say they have time to do it. Attrition in the two most constrained teams is 19%.
1. Diagnose where Northwind actually sits on its agile service management journey. What are the next three moves, and how do you answer the request to scale now?
Read the worked answer
Diagnosis: team-level ceremony adoption with an unchanged operating system. The evidence points away from a discipline problem. Ceremonies are present; the constraints around them are not. Three signals matter most:
- 45% unplanned work in a sprint commitment means the team is forecasting arrival-driven demand. The model is mismatched to the work type, not badly executed.
- 22% report having time is the binding readiness constraint. Awareness (58%) is adequate; capacity and permission are not. A 19% attrition rate in constrained teams is the cost of ignoring that.
- 2.1 maturity with a weekly CAB rejecting 20% shows the delivery system still gates at the point of deployment, so team-level agility produces inventory, not flow.
Next three moves.
- Segment by work type: move incident and request teams to flow-based Kanban with classes of service and WIP limits; keep Scrum where demand is genuinely plannable. Measure cycle time, not velocity.
- Attack one system constraint with visible evidence: the CAB. Its 20% rejection rate is likely an intake-quality filter disguised as risk control, and it converts that into nine-day queues.
- Repair the product owner role: real prioritisation authority, or split it from team lead. Without this, planning is theatre.
On scaling now: a scaled framework multiplies coordination cost across 24 teams while the constraint is unchanged, and the 12% learning cut removes the mechanism that would make any framework stick. Propose one quarter of constraint removal, then reassess with data.
2. The CIO asks you to fix the change bottleneck without touching the sprint model. What evidence do you gather first, what do you propose, and what would you refuse to do?
Read the worked answer
Evidence before design. Pull 12 weeks of CAB records: volume, rejection reasons, queue time before and after the board, failure rate of approved changes, and a classification of rejected changes into missing information versus genuine risk. My working hypothesis is that most rejections are incomplete submissions, which makes the board a quality filter for a bad intake process rather than a risk control. I would also check whether the same people who build changes sit on the board.
Proposal: risk-tiered change enablement.
- Pre-approved standard changes where the pipeline enforces the checks and evidence is generated automatically.
- Peer review plus automated policy checks for medium-risk work, no board attendance.
- A small board only for high-risk or irreversible changes, meeting asynchronously with a published response time.
The test is not speed alone: track change failure rate by path and pause-clock definitions alongside queue time.
What I would refuse.
- Blanket CAB abolition before failure-rate data exists. That swaps queue risk for failure risk and destroys credibility on the first bad deploy.
- A second board or a fast lane that becomes a second queue with the same members.
- Any redesign that leaves rejection reasons unaddressed, since intake quality will simply re-clog the new path.
3. Which two leading indicators would you use to judge whether readiness is genuinely improving, and what result would make you conclude the transformation is failing despite high ceremony adoption?
Read the worked answer
Indicator 1: percentage of change volume flowing through the pre-approved path, paired with that path's change failure rate. This is leading because it tests whether control is being replaced by automation rather than removed. Rising volume with a flat or falling failure rate means the system is learning. Rising volume with a rising failure rate means the gate was load-bearing and the org is now exposed.
Indicator 2: 85th-percentile cycle time for a standard request or change, plus the share of capacity consumed by unplanned work. p85 exposes the tail that customers experience; the average hides it. The unplanned share tests whether capacity planning has been reconciled with reality or just re-labelled.
I would not use ceremony counts, story points, or maturity scores as progress evidence; they move without the system moving.
Failure criteria, stated in advance. If after two quarters the unplanned share is unchanged, p85 cycle time has not fallen by at least a third, and attrition in constrained teams remains above 15%, the transformation is not working at the system level regardless of how many teams hold retrospectives. At that point the honest recommendation is to stop expanding scope, staff the constraint, or accept a narrower ambition. Defining this trigger before the data arrives is what makes the judgement credible rather than retrospective.