The Team Retrospective: What Went Well, What Didn't, What We Change

Why does the team retrospective often lead nowhere?

The idea of a look back is simple. Every two to four weeks the team sits down and asks: what went well, what didn't, what do we change? In software development this round is called a retrospective and is a fixed part of Scrum. Workshops, sales teams, and offices now use it too.

Just as familiar is its typical failure. The round collects impressions, everyone nods, and next time the same points are on the flip chart. This leads to the guiding question of this guide: how must a team retrospective be structured so that the conversation actually turns into a change? To answer it, we clarify the terms, present a thinking model from team research, review the findings, weigh two perspectives, and describe a 45-minute procedure.

A retrospective without a change is a conversation about the weather: pleasant, but without consequence.

What is a retrospective, and how does it differ from a project closure?

A retrospective is a regular, short look back by a team at its own work and collaboration over a completed period, such as the last two weeks. Its aim is to improve the way of working for the next period. The term comes from agile software development. The idea is older and can be found in every form of debrief.

It is to be distinguished from the project closure with lessons learned. The guide on project closure and lessons learned describes an evaluation at the end of a project, comparing plan and actual and producing at most three lessons. The retrospective, by contrast, takes place during ongoing work and concerns mainly collaboration. The two complement each other: the retrospective improves along the way; the closure secures what was learned for the next project.

The thinking model: team reflexivity in three stages

The British organizational psychologist Michael West described what he calls team reflexivity: the extent to which a team jointly reflects on its objectives, strategies, and processes and adapts them to the situation. He distinguishes three stages. In reflection, the team looks back on its own performance and considers possible improvements. In planning, it develops new approaches. In implementation, it applies them. Only all three together make a retrospective effective (Santos et al. 2026, citing West).

An analogy from sport makes the difference tangible. A team that watches the recording after the match is reflecting. Only when the coach derives a changed line-up from it and practices it in training will the next match be different. Most retrospectives in businesses stop at watching the recording.

What studies show about debriefs and team reflection

That structured debriefs work is well documented. Tannenbaum and Cerasoli (2013) combined 46 samples with a total of 2,136 participants in a meta-analysis. Debriefs improved performance by about 25 percent on average. A fixed procedure and a clear purpose strengthened the effect.

Leblanc, Harvey, and Rousseau (2024) analyzed research on team reflexivity in a meta-analysis. According to them, reflection is associated with better team performance, but the benefit depends on team size and how long the team has worked together. They also show how leadership makes reflection possible: leaders who actively involve members in discussion and decisions foster psychological safety, the shared belief that mistakes and concerns can be raised in the team without penalty. This safety favors reflection and, through it, better performance.

Santos, Uitdewilligen, van der Vegt, Schippers, and Passos (2026) tested in two experiments when a guided look back brings the most. In the first, 37 teams of three officer cadets completed three successive missions in a military simulation; in the second, 77 teams of three students worked on an emergency management simulation. The guided reflection between rounds consisted of dedicated time, a place, and prompts for evaluating feedback and setting new goals. In both studies it improved performance over time much more strongly in teams with directive leadership than in teams whose leadership already invited people to think along.

Not all findings are so clear. De Jong and Elfring (2010) studied ongoing teams in tax consulting. Trust within the team improved performance, but through mutual monitoring and effort, not through reflection. In well-established teams with routine work, reflection did not contribute measurably to performance in this study.

Learning tool or time waster? Two perspectives

The first perspective sees the retrospective as a learning tool. Without a fixed date, the team hardly talks about its own way of working, because day-to-day business is always more pressing. The findings on debriefs and the experiments on guided reflection support this.

The second sees it as a time waster. Reflection costs attention, and without a visible benefit it costs more than it yields, as Santos and colleagues also concede. In well-established teams with clear routines, the study by De Jong and Elfring found no contribution of reflection to performance.

I consider the first perspective correct, under one condition from the second: the retrospective must be short and end with a change that gets checked. It brings the most where little joint thinking happens in everyday work, for example in teams where the owner or a foreman directs the work closely. That is exactly where the experiments show the greatest gain. In a well-established team with unchanging work, a longer interval is enough, such as once a month or quarter.

A retrospective in 45 minutes: the procedure

1. Check last time's changes (5 minutes)

   Were the two changes implemented, and did they work? Yes, no, or adjusted. Without this step, every retrospective repeats itself.

2. Facts on the table (5 minutes)

   What happened in the period? Orders, dates, complaints, outages, special events. Figures and events first, assessments afterwards.

3. What went well, what didn't? (15 minutes)

   Everyone first writes down two points for each question on their own, then they are collected. Identical points are merged.

4. Clarify causes (10 minutes)

   For the two most important points, the team asks: what caused it? The search is for a process, a handoff, or a rule, not a person to blame.

5. Set at most two changes (10 minutes)

   Each change gets a responsible person, a start date, and a question by which the team will recognize at the next retrospective whether it worked.

The first step is the most important. It turns individual rounds into a cycle, as described in the guide on the PDCA cycle in everyday work: a change is a small experiment that is checked and then made standard or discarded. Writing things down before the discussion has a reason of its own. What everyone notes beforehand is more likely to come up before the group settles on the opinion of the loudest.

A worked example shows how much the review step matters. Over six months, a team counts how many agreed changes are still practiced four weeks later. The figures are freely chosen.

• The retrospective has a fixed date and lasts at most 45 minutes.
• It starts with the changes from last time.
• Everyone notes their points before discussion.
• The search is for causes in processes, not for people to blame.
• At the end there are at most two changes with names and a review question.
• The changes are in the minutes and in the task list.

What follows beyond the individual retrospective

A retrospective only works if mistakes can be spoken about. That depends less on the method than on the owner's reaction when someone says what went wrong. Whoever asks for the culprit at that moment will next time only hear what harms nobody. How to learn from mistakes without looking for culprits is described in the essay learning from wrong decisions.

For this reason it helps if the owner speaks last and first names a mistake of their own. This is not a gesture of modesty but a signal: this is allowed here. The findings by Leblanc and colleagues on the role of participation support this order. So that agreed changes do not vanish from memory, they belong in action minutes with names and dates, as described in the guide on minutes that get read.

In the longer run, the retrospective connects two tools that already exist at Owners Council. Small improvements from everyday work are collected by the weekly improvement suggestion. The retrospective adds a look at the collaboration itself.

Conclusion: when does a retrospective become a change?

We set out to ask
a retrospective must be structured so that the conversation becomes a change. The answer follows from the thinking model of team reflexivity: it needs all three stages, looking back, planning, and implementation, and it must start by checking the last changes. Without implementation, it remains a conversation.

The findings support this. Structured debriefs improve performance markedly, guided reflection helps especially where little joint thinking happens in everyday work, and in well-established routine teams its contribution is smaller. A retrospective is therefore not a ritual one introduces, but a tool one uses as often as it produces changes.

What you can do this week

1. Set a fixed 45-minute date for the first retrospective, covering a period of two to four weeks.
2. Prepare three to five facts from the period, such as dates, complaints, or outages.
3. Have everyone note two points on what went well and what didn't before the discussion.
4. End the round with at most two changes, each with a name, start date, and review question.
5. Start the next retrospective by asking whether these changes worked.