15Rebuilding from the bottom up

The most common response to Scrum-in-name-only is to retrain the team on the ceremonies: a better daily, a better demo, a new coach. It rarely works, because the ceremonies are the tip of the iceberg. Meaning has to be restored from the bottom up.

A sequence for recovery

1. Restore the goals. Define a Product Goal that every team member can state, and a release forecast expressed as a range. Start every sprint from a Sprint Goal connected to that forecast. Give the Definition of Done real teeth, including quality, documentation and, where relevant, regulatory deliverables. Without these commitments, nothing else in Scrum has a reference to inspect against.
2. Create the conditions for honest inspection. Remove velocity targets and comparisons between teams. Make it safe to report bad news early, and have leaders visibly reward it. Treat retrospectives as decisions with owners, not as conversations. This is Deming's "drive out fear" applied to delivery.
3. Reassign the orphaned accountabilities. Walk through the knowledge areas in Table 2 and name an owner for each, including integration and technical coherence. Decide explicitly who handles what Scrum does not cover: funding, contracts, dependencies and regulatory work. Where a project or delivery manager is needed, give the role a clear scope outside the team rather than letting it reappear in the shadows.
4. Restore engineering discipline. Slice stories vertically, limit work in progress, encourage swarming and pairing, and bring back the practices emergent design depends on: automated tests, refactoring and continuous integration.
5. Then revisit the rituals. With goals, honesty and ownership in place, the daily, the review and the retrospective regain their purpose almost on their own. Adapt their format to the team, including asynchronous forms where they serve transparency better.

The order matters. Starting with the rituals reinforces the surface. Starting with the goals gives every ritual something to inspect.

A health check for leaders

Leaders who want to know whether their teams practise Scrum or only its vocabulary can start with these questions. Each one corresponds to a layer of the iceberg or an accountability from Part I.

• Can every team member state the Product Goal and the current Sprint Goal?
• Is there a release forecast beyond the current sprint, expressed as a range and updated every sprint?
• Does the Definition of Done include quality, documentation and regulatory work, and is it respected?
• Does a stakeholder decision come out of every Sprint Review?
• Is someone explicitly accountable for architecture and technical coherence?
• Are enablers and technical debt visible in the backlog, with protected capacity?
• Is velocity used only for forecasting, never as a target or for comparing teams?
• Do stories produce usable increments, or collections of tasks?
• Has each PMBOK knowledge area a named owner, inside or outside the team?
• Did the last retrospective change something, and does the team know what?

A team with mostly negative answers is not failing at Scrum. It has not yet started practising it.