The Retrospective Where Nobody Says Anything
A Scrum Master facilitates a retrospective for a distributed team of eight across three time zones. Attendance is optional and typically five or six join. The same two people do most of the talking. The last three retrospectives produced the same action item: 'improve communication.' Nothing has changed. One developer wrote privately: 'Nothing we say matters - the last time we raised the on-call rotation, nothing happened.' The team has just missed its Sprint Goal for the second time, and the manager has asked the Scrum Master for a written report on 'who is underperforming.' The Sprint is 10 days; the retrospective is timeboxed to 90 minutes.
1. Why has the retrospective stopped producing change, and what is the Scrum Master's responsibility here?
Read the worked answer
The retrospective has become a ritual without follow-through. 'Improve communication' is not an action - it has no owner, no observable change, and no way to tell whether it worked. When the team raised the on-call rotation and nothing happened, they learned that speaking up is pointless, which explains the silence and the same two voices.
The Scrum Master's responsibility is to create the conditions for a useful retrospective: psychological safety, a format that surfaces real issues, and - critically - that a small number of concrete improvements are actually carried into the next Sprint. The SM owns the process and the follow-through, not the content of what the team decides.
2. What should the Scrum Master do about the manager's request for a report on 'who is underperforming'?
Read the worked answer
The request conflicts with the retrospective's confidentiality and with the Scrum Master's role. A retrospective is a space for the team to be candid; reporting individual performance from it would destroy what little safety remains and is likely to be the final nail in the team's willingness to speak.
The SM should decline to name individuals and instead redirect to what the SM can legitimately share: systemic observations - e.g., the team has missed two Sprint Goals, the on-call rotation is a recurring concern, and the team has identified specific impediments. The SM can offer to facilitate a conversation between the manager and the team about the missed goals, or help the manager understand what the team needs.
If the manager insists, the SM escalates the conflict rather than complying quietly - this is a servant leadership moment: protecting the team's ability to improve is the job.
3. Design the next retrospective so it produces at least one change that survives the Sprint.
Read the worked answer
A workable shape for 90 minutes:
- Acknowledge the history (10 min): name that 'improve communication' hasn't worked and ask why. This validates the developer who said nothing happens.
- Surface real data (20 min): use a structured format (e.g., timeline of the Sprint, or 'what made the Goal hard') so quieter members contribute in writing or in pairs before the group discussion - this reduces the dominance of the two talkers.
- Choose one or two improvements (20 min): force prioritization. Each improvement must have an owner, an observable change, and a check date. Reject anything that can't be observed.
- Commit and schedule (10 min): put the improvement on the team's board so it's inspected at the Daily Scrum, not forgotten until the next retro.
- Close (10 min): confirm the team believes the improvement will actually happen.
Also address attendance: optional attendance undermines the event. The SM should raise with the team whether the time zone arrangement is workable, rather than accepting chronic absence.