How to Run a Retrospective That Works: A Real Session from Our Team

Retrospectives tend to turn into two kinds of meetings: one where the process is completed and everyone says a few polite words, and one that becomes indirect blame until nobody is willing to tell the truth. We prefer a retrospective that solves one concrete problem: next time a similar situation appears, the team does a little better.

Before the meeting: facts only, no conclusions

Collect the timeline, change records, defect list and key decisions in advance so everyone discusses based on the same facts. Avoid conclusion-style descriptions such as poor communication or weak execution. They sound right but cannot guide action.

During the meeting: separate decisions from execution

• Which problems were decision errors caused by insufficient information at the time;
• Which problems came from a correct decision that was poorly executed;
• Which problems are external constraints that cannot change in the short term.

Separating these three categories keeps the discussion away from whose fault it is and moves it toward how to judge and collaborate next time.

After the meeting: keep only three actionable items

The output does not need to be long, but every action needs an owner, a due date and a way to verify it. We usually keep only the three items that most affect future projects, and check at the next retrospective whether the previous actions were truly completed.

A retrospective is not an explanation for the past. It is a better starting point for next time.

When the team sees that retrospectives really change how work is done instead of just following a process, more people become willing to speak honestly.