Day 16: Make Retrospectives Lead to Change

The Concept

A retrospective is not a ceremony for saying what went well and what did not. It is a chance to improve the system that produced the work. The most useful retrospectives connect observations to conditions: unclear ownership, late information, unrealistic sequencing, missing review, or a decision process that created delay.

Protect the room

People need enough safety to describe what happened honestly. Do not paste identifiable personal criticism into an AI tool. Use generalised examples and let the team decide what belongs in the record. AI can help organise themes, but it should never be used to rank people or diagnose their character.

Fewer actions are stronger

Three owned changes are better than twelve wishes. Each action needs an owner, a first step, and a point where the team will check whether it helped. Without the review point, the action is an intention rather than an experiment.

Example: turn frustration into a system change

“Reviews took too long” is a useful observation but not yet an action. Ask what made the delay likely. Perhaps reviewers were invited after the work was complete, the approval criteria were unclear, or one person was the only available specialist. A system-level action might be to agree review criteria at the start, reserve a review slot before the milestone, and name a backup reviewer.

The action should be small enough to try on the next piece of work. Define what will change, who will introduce it, and what evidence will show whether it helped. If the team cannot tell whether the action made a difference, it is probably too vague.

Create a useful sequence

Start with silent reflection or written input so the loudest voice does not set the agenda. Group observations into themes, then test the themes against examples. Ask which conditions were within the team's influence and which need escalation. End by choosing the few changes that are both valuable and possible.

AI can cluster anonymised observations and suggest questions, but keep the team in control of the interpretation. A neat theme can still be wrong. Ask people whether the summary reflects their experience before using it in the final record.

Revisit the action

Put the review point on the calendar before the retrospective ends. At that point, ask whether the change was attempted, what happened, and whether it should be adopted, adjusted, or stopped. Closing an experiment is learning too. Do not keep an action open forever because nobody wants to declare it unsuccessful.

A final check before sharing

Make sure the summary distinguishes observations, themes, decisions, and experiments. Do not attach a person's name to a criticism unless there is a legitimate process for doing so. The retrospective should make the next project more capable, not make the previous project more uncomfortable.

Use evidence without turning it into prosecution

Bring examples, dates, handoffs, and outcomes to the conversation, but do not use them to build a case against a person. Ask what the process made easy, what it made difficult, and what information arrived too late. When an individual action mattered, discuss the condition around it as well as the action itself.

For remote teams, collect input before the meeting and make the themes visible in advance. For a sensitive project, limit the record to what the team needs to learn and store it where the appropriate people can access it. A retrospective summary should not become an uncontrolled archive of personal comments.

Connect learning to the next plan

The strongest retrospective action appears in the next project plan, kickoff agenda, risk review, or checklist. Add it to the place where the behaviour needs to happen. A lesson that lives only in the retrospective document is easy to forget.

At the next kickoff, ask which previous actions were adopted and which need another attempt. This makes learning part of the operating rhythm rather than a separate activity after delivery.

A small improvement that survives the next project is more valuable than a perfect list that stays in the retrospective notes.

Choose the smallest behaviour that tests the lesson. If it works, make it part of the normal process; if it does not, learn why before choosing another response.

Use this today

If the action did not help, that is useful learning when the team records why.

Use that evidence to improve the next experiment.

Write the result down while the example is still fresh.

Name the person who will check the experiment at the agreed review point.

The review should ask what happened in practice, not whether everyone liked the idea. Evidence of changed behaviour is the useful result.

Choose one completed phase and ask what the team should repeat, stop, and try. Convert the answers into system-level changes. Review the previous retrospective before starting; repeating the same observation is evidence that the old action did not stick.

Remember this

• Retrospectives improve systems, not personalities.
• An action without an owner and review point is only a wish.
• Learning is valuable when it changes the next piece of work.