Scrum, day 41: a Retrospective that leads somewhere

Today's objective: turn a recurring complaint into an improvement the team can act on and inspect, including when previous attempts have stalled.

Read alongside: Mastering Professional Scrum, chapter 6, focusing on Retrospectives. Revisit day 18's first experiment and compare what you would do differently now. Allow roughly five minutes for this companion, plus the book section.

A familiar complaint returns

At the fictional ShiftSwap Retrospective, someone says that important decisions still arrive late. The same complaint appeared two Sprints ago. The team agreed to “involve stakeholders earlier,” but nobody can identify what changed afterward.

It would be easy to choose a new workshop format and hope for a more energetic discussion. The immediate problem is more concrete: the previous improvement did not specify which interaction would change, who would arrange it, or what evidence would show that it helped.

The team needs to inspect the unfinished improvement alongside the delivery work. Otherwise, each Retrospective can produce another list of good intentions while the recurring obstacle remains intact.

Reconstruct one event

Radu asks the team to examine the responsibility rule discussed during the last Sprint. A question about overlapping supervisors remained unanswered until implementation had begun. The relevant manager was available, but nobody had agreed who would contact them or what decision was needed.

That account is more actionable than “stakeholders are unavailable.” It also avoids treating every delayed answer as the same problem. Another question may have waited because the organization genuinely lacked an agreed policy.

The team identifies what was known, what was assumed, and where the next action became unclear. People can then discuss the process without reducing the event to a judgment about who cared enough.

Examine the previous improvement fairly

“Involve stakeholders earlier” contained a reasonable intention. It lacked an observable trigger and a practical response. The team should learn from that weakness rather than conclude that improvement work is pointless or that colleagues failed to obey.

Perhaps someone tried to arrange a conversation but could not obtain the right participants. Perhaps the action was forgotten because it lived only in the Retrospective notes. Perhaps the team selected too many improvements to give any of them sustained attention.

These explanations suggest different changes. The team should check what actually happened before selecting another solution. A failed attempt can provide useful information if the team preserves enough detail to inspect it.

Choose a change within reach

ShiftSwap proposes that an unresolved product-rule question on likely upcoming work will include a named next conversation, the person arranging it, and the decision it needs to support. This is a local practice for making the next step visible, not a requirement to assign all product decisions to the Scrum Master.

For the next two relevant questions, Elena and the Developers will agree who can best obtain the information. They will inspect whether the answer arrives before implementation depends on it and whether the conversation actually resolves the uncertainty.

The change is narrow enough to try. It does not promise that every stakeholder decision will become immediate. It targets the ambiguity the team observed in its own coordination.

Put the action where work is managed

If the improvement exists only in a retrospective document, it can disappear from everyday attention. The team places the relevant action alongside the affected work and makes its relationship to the delivery plan clear.

The effort should be visible too. Preparing examples and arranging a discussion takes time. Treating improvement as something people must do invisibly after their “real work” makes it difficult to prioritize honestly.

The Scrum Guide's Retrospective section emphasizes changes that improve quality and effectiveness. The practical implication here is to carry one useful change into the work, then inspect what it produces.

Make space for disagreement about the explanation

One Developer believes the late decision came mainly from weak refinement. Elena believes the main issue was that the café had not decided its operating policy. Both may have observed something important.

The team can test the narrower explanation without demanding immediate agreement on a complete diagnosis. Recording the unresolved decision and arranging the right conversation may reveal whether information was missing, authority was unclear, or the question itself was poorly framed.

A Retrospective need not end with everyone sharing an identical story. It should create enough shared understanding to choose a sensible next action and recognize what further evidence would change the team's view.

Inspect the result, including the inconvenience

After two relevant items, the team finds that one question was resolved earlier. The other still waited because the managers disagreed. The new practice helped make the disagreement visible but did not resolve it.

That is a useful distinction. The team can retain the coordination improvement and separately address the authority needed for the policy decision. It should also examine whether the practice added unnecessary administration to straightforward items.

Keeping, changing, or stopping the practice should follow from the evidence. The aim is a more effective team, not a growing archive of actions marked complete.

Revisit an old action

Choose an improvement your team previously agreed to but cannot clearly evaluate. Reconstruct what prompted it, what people actually tried, and what prevented or enabled the change.

Rewrite it as one observable action with a review point. Identify the decision it should improve and where the action belongs in ordinary work. If the obstacle is outside the team's authority, name the conversation needed to address that boundary.

Reflection: what would you remove from your next Retrospective's action list so that one meaningful improvement has a realistic chance of receiving attention?

Next, day 42 examines obstacles that require help beyond the immediate team.