Managing

How to run a retrospective

A retrospective is a short, structured meeting where a team examines how it worked, not what it produced, and commits to two or three changes for next time. Run it in five moves: frame it, gather what happened, find the pattern, decide the changes, close. The format matters far less than the first sentence you say, because that sentence decides whether anyone tells you the truth.

Most retrospectives fail politely. Everyone turns up, everyone agrees the last few weeks went fine apart from some pressure at the end, somebody writes “improve communication” on a board, and nobody looks at it again. That is rarely a format problem. It is a script problem: the person running the meeting never says anything specific enough for anyone else to risk being specific back. So this guide is mostly sentences. Steal them, change the nouns, say them out loud.

The sequence, with timings

For five to nine people looking back over two to four weeks, book sixty minutes. Ninety if the period was rough or the team is new. Under thirty minutes you are running a status update in a costume.

  1. Frame it (5 minutes). State the purpose, the scope, the ground rules and what happens to the output. Do not skip it because “everyone knows”. They don't.
  2. Gather what happened (15 minutes). Facts and moments first, opinions later. Silent writing, then share. Silence before speech is the cheapest upgrade to any retrospective.
  3. Find the pattern (15 minutes). Cluster the raw material, then ask what caused the cluster. Everyone rushes this part, and it is where the value is.
  4. Decide the changes (15 minutes). Two or three, each with a named owner and a date. More than three and none of them happen.
  5. Close (5 minutes). Read the actions back, check the previous retrospective's actions, and ask one question about the meeting itself.

The first five minutes decide the rest

People arrive guessing at what the meeting is for and how safe it is. Answer both, explicitly, before you ask a single question. Something close to this:

That last one carries most of the weight, and only if it is real. “I could have communicated better” is not a confession, it is a shield. “I sat on the client's scope change for four days hoping it would go away, and that's why the last week was compressed” is a confession, and it changes what the room believes is permitted. That belief has a name: psychological safety.

A retrospective that produces no change is worse than no retrospective. It teaches the team that saying the true thing costs something and buys nothing.

Wrong way, better way

The difference is almost always specificity. Vague questions get vague answers, and vague answers cannot be acted on.

Instead ofSayWhy it works
“So, how did everyone think that went?”“Let's start with the Tuesday of week two, when the build broke. Walk me through what you saw from where you were sitting.”A concrete moment gives people something to describe instead of something to judge
“Any blockers?”“What did you wait on last week, and how long did you wait?”Turns a yes/no question into a measurable one
“We should improve communication.”“Priya posts a two-line status in the channel every Thursday by 4pm, from this week.”A person, a verb and a date is the only kind of action that survives the meeting
“That's not really what happened.”“That's not how I saw it, which is interesting. Say more about what you were seeing.”Keeps two accounts on the table instead of ending the discussion
“Who missed the handover?”“At what point could we have caught this, and what would have had to be different?”Moves from person to system without pretending the failure didn't happen
“Great, thanks everyone.”“Three actions: Sam, Priya, me. Dates on all of them. First item next retro is whether they happened.”Closing the loop is what makes the next retrospective honest

Retrospective formats, and when to use each

Formats are scaffolding for the “gather what happened” stage. Rotate them; the same three columns every fortnight stops producing new information after about the fourth run.

Getting past “everything went fine”

Silence is almost never “nothing to say”. It is “I'm not going first”. These prompts move it:

Then the discipline everything else rests on: after you ask, stop talking. Count to ten. Managers fill silences at about the four-second mark and conclude nobody had anything to say. See active listening for what to do with the answer when it arrives.

Turning talk into two or three changes

Aim for the smallest change that would have altered the outcome. Ambitious process redesigns die within a week; “we move the standup to 9:30 so the Manila team isn't dialling in at 7pm” survives, because it is one decision, already made.

  1. Ask for changes as sentences starting with a name and a verb. “We should” is not a change. “Ravi drafts the brief before the kickoff, not after” is.
  2. Pick two or three. If the list is longer, ask: “which one, if we fixed it, would make the others smaller?”
  3. For each, write the owner, the date, and how you'll know it happened. Not a metric, just an observable: “a written brief is in the folder by Friday”.
  4. Say what you, the manager, will stop doing. Most teams are constrained by something their manager does, and nobody will nominate it. Nominate it yourself.
  5. Put the actions where the team already looks daily. A retro board nobody opens is where actions go to die.

When it goes wrong

Four failure modes cover most of it. Each has a recovery move you can make in the room.

It turns into a pile-on

One person becomes the subject and the tone shifts from examining to prosecuting. Interrupt early: “We're three comments into one person's work now. I want to move to the process that let this reach a customer. What would have had to be in place to catch it?” Then take the individual conversation offline the same day, using SBI feedback. Do not leave it hanging.

Nobody says anything real

You get shrugs and “yeah, fine”. Switch mediums: five minutes of anonymous silent writing, then you read the cards out. If it stays flat across two retrospectives, the problem is upstream of the meeting. Ask one person privately: “In the retro, what didn't get said?” The answer usually arrives in about thirty seconds.

The same complaint arrives every time

Usually something outside the team's control: another department, a tool, a client. Name it and split it: “Fourth retro running, the data handover has come up. We can't fix their side from this room. So, two things: what makes their delay hurt us less, and what do you need me to take to their head of department, in writing, this week?” A recurring complaint you never escalate becomes proof the meeting is theatre.

The most senior voice goes first and everyone agrees

You will not spot this from inside; it looks like consensus. Prevent it structurally: written positions before discussion, most junior speaks first, or hand facilitation to someone else while you take notes. In a new team, expect it. Unearned agreement is a signature of the early stages in Tuckman's model, and it burns off only once disagreement is visibly survivable.

The part reading cannot do for you

Everything above is one skill wearing several hats: asking a question that makes honesty cheap, then not flinching at the answer. You can read that in four minutes and still not do it, because under mild social pressure people fall back on what they have practised, not on what they have read.

So this changes through rehearsal and feedback, not through articles. Run one badly. Have someone watch and tell you where you rescued the silence, where you defended your own decision, and where you took a vague action because the hour was nearly up. Then run it again on Thursday. That is what experiential learning means: behaviour shifts in the doing and the debrief, not in the reading.

Tour De Force runs this as live, experiential training for teams worldwide — online and in person. Talk to us, or play Gamified learning appsThe Weekly Challenge to see the method in ten minutes.

Questions

How to run a retrospective FAQs

What is a retrospective meeting?

A short, structured meeting where a team examines how it worked over a recent period and agrees a small number of changes. It looks at process, collaboration and decisions, not at output or individual performance. It comes from software development but works for any team that repeats a cycle of work: sales, operations, marketing, events.

How long should a retrospective be?

Sixty minutes for a two to three week period with a team of five to nine. Ninety if the period was difficult or the team is new to the practice. Under thirty minutes you cannot get past the first round of polite answers, and beyond ninety attention collapses and people start agreeing to things to end the meeting.

What questions should you ask in a retrospective?

Specific ones anchored to real moments. "Walk me through the Tuesday the build broke." "What did you wait on, and for how long?" "What did you spend time on that didn't matter?" "What nearly went wrong and we got lucky?" "What did you disagree with and not say?" Avoid "how did everyone think that went", which reliably produces nothing usable.

What are the best sprint retrospective formats?

Went well / didn't go well / try next is the fast default. Timeline works best after a messy period because it preserves the order of events. Start / stop / continue converts an agreed diagnosis into behaviour. Mad / sad / glad suits emotionally loaded periods. Sailboat looks forward as well as back. Rotate them: the same format repeatedly stops producing new information.

Should the manager facilitate the retrospective?

You can, but you have to work harder at it, because your reaction to the first piece of criticism sets the ceiling for the rest. Going first with a real admission of your own helps. If the team has gone quiet across two or three sessions, hand facilitation to someone else, or rotate it, and take notes instead of steering.

What is the difference between a retrospective and a post-mortem?

A retrospective is regular and rhythmic: every sprint, month or project phase, whether things went well or badly. A post-mortem is triggered by a specific event, usually a failure or incident, and digs into one causal chain. Teams that only run post-mortems learn exclusively from disasters, which is an expensive way to learn.

Keep reading

Related reading

Get in touch

Build it with your team.

Book a 30-minute discovery call and we'll shape an experiential programme around your goals.

Book a discovery call