Scrum, day 58: inspecting the change itself

Today's objective: define a feedback loop for an organizational change effort, including evidence that could alter or stop the current approach.

Read alongside: Software in 30 Days, chapter 10. Use the chapter as a prompt to examine how your organization manages change, while distinguishing a Scrum implementation from a loosely named improvement meeting. Allow roughly five minutes for this companion, plus the reading.

The change plan can make the same mistake

The fictional café organization behind ShiftSwap adopts Scrum to learn earlier and adapt product decisions. Its adoption plan, however, fixes every training session, team rollout, and reporting milestone for the next year. Deviations are treated as failures even when teams discover conditions the plan did not anticipate.

The organization is asking teams to use evidence while managing the change through an inflexible prediction. It needs to examine the adoption effort itself: what outcome is intended, which interventions are expected to help, and what observations would justify a different next step?

The purpose of inspection is to improve the change, not merely to confirm that the rollout calendar was followed.

Define an outcome beyond adoption counts

“Ten teams using Scrum” describes an adoption milestone. It does not establish that users receive better products or that the organization responds more effectively to new information.

The organization might instead focus on reducing consequential late surprises in a defined group of initiatives. It could also examine whether teams can create usable results and make product decisions from feedback.

These outcomes need careful interpretation, but they provide a more meaningful direction. Training, tools, and team formation become possible interventions supporting the outcome rather than the final proof of success.

Make the intervention's hypothesis explicit

The organization proposes protecting Product Owner availability for two teams. It expects that clearer access to product decisions will reduce waiting and conflicting instructions.

That hypothesis names a mechanism. It can be examined through actual questions that teams need answered, how long they wait, and whether the resulting decisions remain coherent. Simply counting the hours marked “Product Owner time” would not establish the expected effect.

The intervention should also identify possible unwanted consequences. Other responsibilities may be displaced, or the Product Owner may still lack authority despite having more time. Those possibilities belong in the inspection.

Use a small visible improvement backlog

The change effort can maintain an ordered set of problems and proposed interventions. Each should identify the consequence, the intended effect, the people involved, and the evidence to inspect.

The organization should avoid starting every improvement at once. Multiple simultaneous changes can overload the same people and make results difficult to interpret. A focused set of interventions is easier to support and evaluate.

Calling this list a backlog does not by itself mean the change effort is using Scrum. If the organization chooses Scrum for this work, it needs to satisfy the framework as a whole, including a suitable product conception, accountabilities, events, and usable Increments. It should describe its actual approach accurately.

Inspect what people experience

After the availability trial, the organization asks the affected teams about recent product decisions. Were the right questions answered sooner? Did conflicting instructions decrease? Did the Product Owners have the authority and information needed to decide?

It also examines actual examples rather than relying only on a survey score. A team may report satisfaction while important decisions still bypass the Product Owner. Another may report frustration because previously hidden disagreements are finally becoming visible.

The interpretation needs context. An uncomfortable observation can be a sign of improved transparency rather than immediate deterioration, but that possibility should not become an excuse to dismiss every negative result.

Decide what the evidence changes

The trial shows that one team benefits from protected availability, while the other still waits because several department heads can override product decisions. The organization can retain the useful allocation and address the authority problem separately.

It should avoid extending the same intervention unchanged to every team merely because the rollout plan says so. The evidence suggests that time and authority are distinct conditions.

At each review point, the organization should be able to name a decision: continue, modify, stop, expand, or investigate further. If no result can change the plan, the feedback loop is incomplete.

Include the cost of the change effort

Training, meetings, coaching, reorganizations, and new reporting all consume attention. The organization should inspect whether that effort supports the intended improvement and where it burdens teams without helping their work.

An adoption program can become self-sustaining even when its activities no longer address the main constraint. Periodic review should include removing practices and reports that do not support a useful decision.

The same principle applies to the improvement backlog. A long list of stale interventions is not evidence of ambition. It may indicate that the organization needs clearer priorities and more honest choices about what it can support.

Design a change feedback loop

Choose an organizational improvement. Write its intended outcome, current intervention, expected mechanism, and the observations you will collect. Identify the people who experience the change and the people who can alter it.

Set a review point and describe at least two different decisions that could follow from different evidence. Include one cost or unwanted effect and one condition that would justify stopping the intervention.

Reflection: is your organization applying the same openness to its adoption plan that it asks teams to apply to their product plans?

Next, day 59 brings the three books and the current framework into a consistent reading practice.