Are Retrospectives a Waste of Time? Sometimes

“Retrospectives are a waste of time” can be an accurate diagnosis. If a team repeats safe phrases, records a long wish list, and never looks at it again, the meeting changes nothing.

The format itself is not the problem. A retro is useful when it helps the team identify a recurring obstacle and carry one improvement through to a result.

Not a status meeting or a search for blame

A status meeting asks where the work is. A retrospective asks why the work moved that way and what should change in the way it is organised.

Useful subjects usually concern the system of work:

• a task received essential context too late;
• an integration dependency appeared after development began;
• reviews accumulated at the end of the iteration;
• one person held too much critical knowledge;
• the team interpreted “done” in different ways.

Wording matters. “Who delayed testing?” invites defence. “What in our process allowed the release to begin before verification was complete?” leaves room for a shared solution.

The conversation needs a safe boundary

People do not have to discuss every conflict in front of the whole team. A retro suits systemic obstacles and shared agreements. Personal tension, individual feedback, and sensitive issues belong in a one-to-one or a separate conversation.

The manager sets the tone through their response. If every comment receives an immediate explanation or defence, the team quickly learns to stay quiet. Clarify the fact and its impact before moving to a solution.

A few rules help:

1. discuss an action or process, not a person’s character;
2. use a specific example instead of “always” or “never”;
3. do not demand a public admission of fault;
4. allow people to send a subject to the facilitator in advance;
5. do not use retro comments as material for later punishment.

Trust in the format does not come from an opening speech. It comes from what happens after the meeting.

When the team is silent

Silence does not always mean there are no problems. People may be unsure which level of openness is safe, may need more time to formulate an observation, or may not want to compete with more forceful voices.

Collecting facts before the meeting can help. A short form or shared board gives people time to think and lets the facilitator group related themes. An anonymous channel can remain useful, especially for sensitive concerns. The task is to investigate the observation and agree on an action without trying to identify the author or requiring them to speak publicly.

In a larger group, I sometimes let people discuss a question in pairs or groups of three first. It is easier to bring a formed thought back to the room than improvise while everyone watches.

Rotating the facilitator can also change the dynamic. When the manager always runs the retro, participants may see it as a management control mechanism. A team member or a neutral colleague can facilitate while the purpose and rules remain shared.

If the silence is a response to a particular manager’s behaviour, a new template will not solve it. That calls for a separate conversation and a different reaction to feedback. Teams judge safety by the consequences of earlier openness, not by promises at the start of the meeting.

The important work begins afterwards

A retro without follow-through loses credibility quickly. I prefer one or two changes the team can genuinely test before the next meeting.

Each item needs:

• a clear outcome;
• an owner;
• a date or event for review;
• a way to tell whether it helped.

Instead of “improve reviews,” try “assign a reviewer when work enters development and check waiting time after two weeks.” The wording may evolve, but ownership of the check should not disappear.

I begin the next retrospective with the previous agreements. Was the action completed? Did it help? If not, why? An experiment that fails is still a result. An experiment everyone forgets is not.

Choosing an action

There are usually more themes than the team can address. I compare them on two dimensions: how strongly the problem affects delivery and how much influence the team has over it.

A high-impact subject outside the team’s control should not disappear. The action may be to escalate it, collect evidence, or propose a solution to the process owner. The group should not promise an outcome it has no authority to create.

A problem within the team’s control is a candidate for a small experiment. There is no need to redesign the entire process immediately. Test a rule on one class of work, one iteration, or one integration and decide whether to scale it afterwards.

It helps to distinguish an observation from an action. “We wait too long for an environment” is an observation. “Measure the wait and agree an expedited route for critical releases” is an action. “Ask infrastructure to work faster” is a wish without a mechanism.

A useful action item is small enough to have one owner and meaningful enough for the team to notice the effect. If it requires a separate project, the retro should assign the first step and project ownership rather than pretend the issue will close by the next meeting.

Common ways the format breaks

Too many actions. Ten items make the meeting feel productive, then compete with delivery work and disappear.

The same owner every time. If every improvement goes to the manager or Scrum Master, the team does not become a participant in changing its own process.

A solution before the cause. The group begins with a favourite tool — another status, meeting, or template — and then reshapes the problem to justify it.

Using the retro instead of another format. A serious incident needs a separate review with a timeline and causal analysis. A personal conflict needs a focused conversation. A strategic choice needs the people with decision authority. The retrospective can identify the subject without resolving all of it.

No permission to change nothing. Sometimes the process worked and the difficulty was a one-off event. Do not invent an action item to fill the board. Keeping the current approach is a legitimate decision when the team has examined it deliberately.

A short working format

For a focused working retrospective, I suggest starting with four steps:

1. recall the goal of the period;
2. collect facts about what helped and hindered;
3. choose the most important cause;
4. agree on a change that can be checked.

There is no need for a new board or game every time. Variety can refresh the meeting, but it cannot replace follow-through.

A retrospective does not need to be emotional, and it will not solve every team problem. Its purpose is more modest: help people improve the way they work together. If a small change has an owner and the team checks its effect, the time was useful.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP