When retrospectives go stale, and how to revive them

Most teams run good retrospectives for a few months, then slowly stop. Nobody decides to stop. The cards get shorter, the same two people talk, the actions become "communicate more", and one Friday the event is moved "just this once". It is a very common failure and rarely a dramatic one, which is why it lasts.

Why it matters

The Guide gives the Retrospective a clear place at the end of the Sprint, as the event that concludes it, with a maximum of three hours for a one-month Sprint. Its purpose is to plan ways to increase quality and effectiveness, and it expects the most impactful improvements to be addressed as soon as possible. The Guide also states that failure to operate any event as prescribed results in lost opportunities to inspect and adapt.

A stale retrospective is therefore not a harmless loss of enthusiasm. It breaks the loop that lets the team improve its own working practice. The Agile Manifesto's last principle says the same thing in plain words: at regular intervals the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. A team that stops adjusting is still working, but it has stopped learning how to work.

Symptoms

You can usually see staleness before anyone names it.

• The same topics return every Sprint, in the same words.
• Attendance slips, or people join late and leave early.
• Cards are brief and general: "communication", "meetings", "estimates".
• Nobody can name an action from the last retrospective.
• One or two people do most of the talking.
• The facilitator does the preparation alone and the energy comes from them.
• The event is the first to be moved or skipped when the calendar is tight.

A quick test is to ask each team member to name the change from the last retrospective that made their work better. If the answers are blank, the event is not producing change.

Causes

Actions are not done. The most common cause. If last Sprint's actions are not visible at the start of the next one, speaking up has no payoff. See retrospective actions that actually happen.

Actions are too large. "Improve our testing" cannot be finished in a Sprint. Large actions fail quietly.

The format is fixed. The same three columns for a year is a script. A vendor guide to retrospectives recommends varying the format while keeping timing, attendees and the general shape consistent.

Problems are outside the team's control. If the same issue is raised each time and the team cannot fix it, the event becomes a venting session. Such issues belong with the Scrum Master for organisational action.

Lack of safety. If people do not feel able to say what they think, they stop trying. See psychological safety in retrospectives.

Things are going fine. A team that works well may feel it has little to discuss. This is an opportunity as much as a problem, and the answer is to look at different areas, such as the Definition of Done or the relationship with stakeholders.

No one owns it. If the Scrum Master does all the work, the team treats it as theirs, not its own.

A worked example

This is an illustrative case. A team of seven has run retrospectives for a year. The Scrum Master notices that for the last five Sprints the top card has been "too many meetings". Each time the team agreed to "review our meetings". Nothing changed.

The Scrum Master begins the next retrospective with a different opening. She asks the team to list every action from the last five retrospectives on a wall. There are fourteen. Three have been done. She asks which of the eleven would still matter if finished. The team picks two. For the "meetings" topic she asks for something specific: a list of every recurring meeting, with duration and attendees.

The list shows eleven hours a week of recurring meetings per person, four of them with unclear purposes. The team chooses one action: for the next Sprint, they will drop two meetings and shorten one, and measure the time recovered. The owner is a Developer who raised it, and the check is the next Daily Scrum.

In the following retrospective, the team reports six hours saved. The Scrum Master notes that people spoke more than they had in months, and that two new topics appeared.

The example changed four things at once, which is not a recommended method. But it shows the pattern: confront the history, reduce the scale, make one action specific and show the result.

Repairs, from small to large

1. Start with last time's actions. Open every retrospective by reviewing the previous ones. Cheap, and often enough.
2. Limit actions to one to three. Fewer actions get done.
3. Make actions specific and owned. Who, what, by when.
4. Change the format. Try a different prompt. See Start, Stop, Continue, the Sailboat and the 4Ls and Mad Sad Glad for alternatives.
5. Rotate the facilitator. Different leaders bring different questions. A guest facilitator from another team can bring a fresh view.
6. Change the subject. Focus one retrospective on the Definition of Done, another on the relationship with stakeholders, another on the technical practice.
7. Look at a longer period. Every few Sprints, step back and review a quarter. Patterns invisible in two weeks appear.
8. Change the setting. A walk, a different room or a shared meal can shift energy. The Guide says optimally events are at the same time and place, so use this sparingly.
9. Escalate what the team cannot fix. Bring recurring blockers to the Scrum Master with evidence.
10. Ask the team. Dedicate five minutes to "what would make this event worth your time?"

When to stop and when to carry on

If a team has done all this and the retrospective still produces little, there may be nothing more to find, and a shorter event can be reasonable. The Guide's timeboxes are maximums, and for a stable team a thirty-minute retrospective that ends with one real action is better than ninety minutes of habit. Skipping it altogether is a different matter. The Guide treats the event as part of the framework.

How to practise it

Review the last five retrospective actions in your team and note which were finished. That number tells you where to start. In the simulator the retrospective at step 4.2 produces action items that you can follow in later steps, so you see what happens when they are, or are not, carried through.