Scaling decisions while the basics are still missing
Four months into an Agile adoption, an insurer has five Scrum Teams: three feature teams on the claims platform, one shared services team that all three depend on, and one team maintaining a legacy policy system. All teams use two-week Sprints and story points, but refinement maturity differs sharply: the claims teams have about two Sprints of refined backlog; the shared services team has a three-week intake queue with a product owner who reports to the infrastructure directorate and takes work from all three claims teams plus two projects outside the adoption. Dependencies between teams are tracked in a spreadsheet the delivery manager updates weekly, and 40 percent of claims-team items in the last three Sprints waited on the shared services team. Leadership wants to introduce a Scaled Agile framework with a quarterly Programme Increment planning event, and has asked you to advise. Two teams are still learning basic Scrum; the shared services PO says she has no authority to refuse work; the legacy team has not had a retrospective in six weeks because of a production incident.
1. Should leadership introduce a scaled framework and quarterly PI planning now? Advise, with reasoning.
Read the worked answer
Scaling frameworks address coordination across multiple teams working on one product. They do not create the preconditions for coordination; they amplify whatever is already there. A quarterly planning event across five teams whose Product Owners cannot prioritise will produce a detailed, confident plan that nobody is empowered to keep.
Test the preconditions against the evidence:
- One empowered Product Owner per product? No for shared services - she reports into the infrastructure directorate and cannot refuse work. That is where the prioritisation problem lives, and no planning event fixes it.
- A releasable Increment each Sprint? Unknown, and the legacy team's situation suggests instability.
- Retrospectives and improvement actually happening? No for the legacy team.
- Capability to run basic Scrum? Two teams are still learning.
My advice: do not adopt a framework yet. Run a two-quarter improvement programme with a real backlog: resolve shared-services authority and intake; restore retrospectives; establish a Definition of Done and working software each Sprint on the claims product. Do one lightweight dependency-reduction cycle first and measure the wait share, which should fall from 40 percent.
If leadership insists on visible progress, run PI planning as a timeboxed experiment with the three claims teams and shared services only, with measures agreed in advance - dependency count, percentage of items waiting, escalations per Sprint - and a decision point. And use Scrum for the adoption itself: a backlog of change experiments, a cadence, and inspection.
2. Forty percent of claims-team items wait on the shared services team. Set out your options and argue which you would pursue first.
Read the worked answer
This is a queueing problem before it is a framework problem. Arrival from three feature teams plus two external projects exceeds a fixed capacity, so work waits; a weekly spreadsheet records the symptom but changes nothing.
Options:
- Fix intake and allocation. Publish an explicit capacity split (for example 70 percent claims, 30 percent other), impose a work-in-progress limit so requests beyond capacity are refused rather than queued, and standardise small requests with a definition of ready. Cheap, fast, and immediately reduces queue growth.
- Reduce demand. Move routine platform work into the feature teams' own capability so only genuinely specialist requests reach shared services.
- Reduce request size. Split large platform asks into small increments so each wait is shorter and less blocking.
- Structural change. Dissolve shared services and embed specialists in the three feature teams, or make it a genuine platform product with a Product Owner who has authority and a published service offering.
I would start with 1 and 3, because they are within reach and produce evidence, while simultaneously building the case for 4. The structural fix is the root cure but takes funding and reorganisation.
The critical point to put to leadership: the shared services Product Owner cannot refuse work because her reporting line sits in the infrastructure directorate. Until authority over her capacity moves to the claims product, any allocation agreement is advisory. Authority has to follow the work, otherwise the wait simply reappears in a new form.
3. The legacy team has not held a retrospective for six weeks because of a production incident. What do you do?
Read the worked answer
The absence of the retrospective is the finding, not a scheduling detail. A team firefighting a production incident is the team with the most to inspect: what caused it, what made recovery slow, and what would stop the next one. Six weeks without inspection means the team is learning nothing from the period that is costing it most.
Practical steps:
- Do not ask for a two-hour ceremony. Ask for 30 minutes with one question: "what about this incident do we change?" Hold it close to the incident review and use the incident timeline as the data.
- Make it blameless. Immediately after an incident, a retrospective can collapse into a search for a person. Use a format that examines conditions and decisions.
- Expect the real cause to be systemic - work in progress, on-call load, deferred technical debt, no capacity reserved for improvement. If so, the team's output is an impediment for the Scrum Master or manager to act on, not a self-help action.
- Give it a home. An improvement backlog with visible items and review points, so the retrospective produces tracked change rather than a conversation.
- Check ownership. If I am not that team's Scrum Master, my job is to raise it with whoever is and with their manager, not to run someone else's retrospective for them.
Link it back to the scaling question: a framework rollout that assumes every team is inspecting and adapting would be built on an assumption that is already false here.