The Retrospective That Never Changes Anything
A Scrum Master coaches a team of eight developers that has run Scrum for two years. Retrospectives are well attended and emotionally open; the team reliably identifies three to five improvement actions per Sprint. However, a review of the last twelve Retrospectives shows that 31 of 44 actions were never started, and the same three themes - unclear requirements, slow test environments, and too much unplanned support work - appear in nine of the twelve sessions. The team's Scrum Master has been in post for four months and has been focusing on making Retrospectives 'safe and engaging', which they now are. Two developers have started saying the Retrospective is 'a waste of an hour'. The team's Sprint Goal achievement rate is about 50%.
1. Diagnose why the Retrospectives are not producing change, and explain what the Scrum Master has misjudged.
Read the worked answer
The Retrospectives are succeeding at the first half of their purpose and failing at the second. The event exists so the team can inspect how the last Sprint went and plan ways to increase quality and effectiveness, with the most impactful improvements addressed as soon as possible. This team inspects well and plans poorly: 31 of 44 actions never started, and the same themes recur across nine of twelve sessions, which is the signature of a Retrospective that produces lists rather than change.
The Scrum Master has misjudged the problem as one of safety and engagement. Those were worth fixing, but they are inputs, not outcomes. A safe, engaging Retrospective that changes nothing will eventually lose credibility, which is exactly what the two developers are expressing. Their comment is data, not resistance.
The recurring themes suggest the actions chosen are too large, too vague, or outside the team's authority. 'Unclear requirements' and 'slow test environments' are systemic; a team-level action like 'improve communication with the Product Owner' will not move them. 'Too much unplanned support work' may require a decision from management about support rotas. If the team keeps choosing actions it cannot actually execute, non-completion is the predictable result, and repeated failure erodes the will to try.
2. How should the Scrum Master change their approach to the Retrospective and to follow-through?
Read the worked answer
Change what the team commits to. Coach the team to leave each Retrospective with one or two actions, not three to five, chosen for impact and feasibility within the Sprint. Fewer, completed actions build the evidence that the Retrospective works.
Make actions concrete and owned. Each action should name a person, a first step, and a way to tell whether it happened. 'Improve requirements' becomes 'Product Owner and two developers review the top five backlog items together before Planning, starting next Tuesday'.
Separate team-controlled from systemic. For each theme, the team should ask: can we change this ourselves? If yes, act. If no, the Scrum Master takes it as an impediment to remove or escalate, with a named owner and a date. The slow test environment and unplanned support work are likely in this category and need management involvement, not another team action.
Open each Retrospective by reviewing the last one. Spend the first ten minutes on what happened to the previous actions. This creates accountability without blame and makes non-completion visible early rather than at a twelve-Sprint audit.
Use the data. Bring the 31-of-44 figure to the team and let them interpret it. The Scrum Master should resist presenting it as a failure; it is an inspection finding.
Address the credibility issue directly. Acknowledge the two developers' point: they are right that an hour producing nothing is a waste. The remedy is not to defend the event but to make the next few Retrospectives visibly produce completed actions.
3. What coaching stance should the Scrum Master adopt with the two developers who call the Retrospective a waste?
Read the worked answer
Treat their statement as accurate feedback and an invitation, not as disengagement. The Scrum Master should speak with them privately, acknowledge that their observation matches the data, and ask what would need to be true for the Retrospective to be worth their hour. Their answer is likely to be specific and useful: for example, that actions get dropped, or that the same complaints recur.
In the conversation, the Scrum Master should avoid defending the event or explaining Scrum theory at them. Instead, invite them to help make the next Retrospective different, perhaps by co-facilitating the follow-up review of previous actions or by owning one concrete improvement. Giving critics a real role converts them into allies and tests whether the Scrum Master's diagnosis is right.
The Scrum Master should also be honest about what is and is not in the team's control. If slow test environments require a management decision, say so, and say what the Scrum Master will do about it and by when. Credibility comes from visible follow-through on the systemic items, not from better-facilitated conversations about them. If the two developers remain sceptical after several Sprints of completed actions, that is worth revisiting, because persistent scepticism may indicate the Scrum Master is still missing something.