Retrospectives

Read this before your first retrospective and whenever they have become a formality; it gives you the formats that produce actions instead of complaints.

A retrospective is a structured conversation where the team examines how it worked, not what it built. It is the primary mechanism for continuous improvement in software engineering. Without regular retrospectives:

Problems that are obvious to everyone get discussed privately but never fixed.
Teams repeat the same mistakes across sprints and terms.
Wins go unacknowledged, and the team underestimates its own progress.
Interpersonal friction accumulates silently until it becomes a crisis.

A good retrospective is psychologically safe, time-boxed, and action-oriented. It is not a blame session, a status meeting, or a performance review.

Types of Retrospectives

Retrospectives serve different purposes depending on the scope and timing. The format and depth should match what the team is reflecting on.

Sprint Retrospective

Run at the end of each sprint. The team reflects on the sprint just completed: what worked, what did not, and what will change next sprint. Time-box this to 30 to 45 minutes. It should feel lightweight, a habit rather than a ceremony.

Term Retrospective

Run at the end of each term. Broader in scope than a sprint retrospective, it covers the term’s arc: major successes, major failures, team dynamics, and what to carry forward. The term retrospective should produce a written artifact that captures themes and commitments, not just meeting notes.

Time-box the meeting to 60 to 90 minutes. The written document takes additional time to produce.

Project Retrospective

Run at the end of the project. Covers the full lifecycle from initial requirements through delivery. A project retrospective is a good time for individual reflections, where each team member documents their own growth, contributions, and lessons learned.

Incident Retrospective (Post-Mortem)

When something breaks (or nearly breaks) in production, run a targeted retrospective focused on root cause analysis. The output is a post-mortem document. The goal is systemic improvement, not assigning blame.

Formats

There is no single right way to run a retrospective. Different formats surface different kinds of insight. Try a few and settle on what works for the team, or rotate formats to keep the conversation fresh.

Start, Stop, Continue

One of the simplest and most effective formats. Each team member contributes to three lists:

Start: things the team should begin doing.
Stop: things the team should stop doing.
Continue: things that are working and should be preserved.

After individual contributions, cluster similar items and select two or three to act on. Avoid trying to address everything.

4Ls

Each team member reflects on four dimensions:

Liked: what did you enjoy or appreciate this sprint?
Learned: what did you learn?
Lacked: what was missing or insufficient?
Longed for: what do you wish had happened?

4Ls surfaces individual emotional experience, not just process observations. It works well when the team has been under stress or when something significant happened.

Timeline

Draw a shared timeline of the sprint or term. Each member adds events: technical milestones, good moments, hard moments, surprises. The exercise builds shared memory and often reveals patterns (“every integration push happens in the last two days of the sprint”).

Sailboat

Draw a sailboat with:

Wind (things pushing the team forward)
Anchors (things slowing it down)
Rocks ahead (upcoming risks)
Destination (the goal)

Good for mid-project retrospectives when the team needs to reconnect with why it is doing what it is doing.

Running a Good Retrospective

The format matters less than how the retrospective is facilitated. A well-run retrospective with a simple format will outperform a poorly facilitated one with an elaborate structure.

Set the Stage

Open with a brief check-in. Ask each person a low-stakes question (“One word for how the sprint went?”) to ensure everyone has spoken before the harder topics come up. This reduces the activation energy to contribute.

Psychological Safety First

People will not share real observations if they fear embarrassment or retaliation, which is the practical face of the psychological safety research: teams where people can admit a mistake without being penalized surface more problems, not fewer, and are better for it. A retrospective where everyone says things went fine is not evidence that they did.

The oldest convention here is Norm Kerth’s Prime Directive, read aloud at the start of many retrospectives: everyone did the best job they could given what they knew at the time. It sounds like a platitude and it does real work, because it moves the question from who failed to what made failure likely, which is the only version anyone can act on. Ground rules:

What is said in the retrospective stays in the retrospective, unless the team decides to document it.
Observations are about systems and processes, not about individuals.
The facilitator actively invites quieter voices before closing a topic.

Facilitate, Don’t Dominate

Rotate the facilitator role across team members. The facilitator’s job is to run the process, not to share the most opinions. A good facilitator asks questions, synthesizes contributions, and keeps time.

Focus on Actions

A retrospective without concrete action items is a vent session. For every theme the team selects, define:

What will change? (a specific action, not a vague intention)
Who owns it? (one person, not “the team”)
By when? (a sprint number or a date)
How will we know it worked? (a success indicator)

Review action items from the previous retrospective at the opening of the next one. If they were not completed, understand why before adding new ones.

Teamwork ActivitiesTeam health and process assessment activities that pair well with retrospectives.

Post-Mortem Format

For incidents, a lightweight post-mortem covers five areas:

Summary: what happened, and what was the impact?
Timeline: a chronological reconstruction of events.
Root cause: what was the underlying cause, not the proximate trigger?
Contributing factors: what conditions made this outcome possible?
Action items: what will prevent recurrence?

The 5 Whys technique is useful for root cause analysis: ask “why did this happen?” recursively until you reach a systemic cause rather than a human error.

Best Practices

Run retrospectives even when things are going well. Normalizing the practice means it is not treated as a fire alarm.
Keep sprint retrospectives short. If they are running over an hour, the format is too heavy.
Limit action items to three. More than three usually means none of them get done.
Assign one owner per action. “The team” is nobody.
Follow up. The fastest way to kill retro culture is to never check in on last sprint’s commitments.
Vary the format occasionally to avoid habituation.

Some Truths About Retrospectives

The retrospective is the ceremony teams drop first, and it is worth being precise about why. Planning and review produce something you can point at, so skipping them feels like skipping work. A retrospective produces a conversation, so skipping it feels like reclaiming an hour. What you actually lose is the only scheduled moment when a process problem can be raised by the person experiencing it, rather than by whoever happens to be annoyed enough to bring it up unprompted. A team that has quietly stopped running retros almost always has an unspoken problem; the retro is how it would have surfaced while it was still small.

The failure mode that kills retrospectives is not awkwardness, it is action items that go nowhere. A team generates six improvements, does none of them, and by the third retro everyone understands the meeting is theater and stops offering real observations. The fix is unglamorous and it works: leave with at most two actions, each with a named owner and a date, and start the next retrospective by reading last time’s actions out loud. Two completed actions beat six aspirational ones, because the second retro’s honesty depends entirely on whether the first one changed anything.

Expect a gap between the team’s mood and individual experience. Teams that feel things are going fine routinely discover that one person has been quietly carrying a problem for weeks, and the reason is structural rather than personal: the people most likely to speak up in an unstructured discussion are the ones already comfortable, so an unfacilitated retro systematically samples the wrong end of the team. This is what the formats are for. A round where everyone contributes before discussion opens is not ceremony, it is how you hear from someone who would not have interrupted.

Finally, a written retrospective is harder than it looks, and it is worth knowing that in advance so you do not start from a blank page in the last week of the term. The effort is in reconstructing what happened, not in the writing. Teams that keep a running note through the term, even a short one per sprint, produce a better document in a fraction of the time, which is the argument for the Learning Journal habit rather than a retrospective-shaped memory exercise in week 10.

Retrospectives in Industry and Academia

Retrospectives are a core practice in Scrum, but the concept predates agile. NASA, aviation, and the military all use structured after-action reviews (AARs) to learn from operations. The format varies, but the intent is the same: systematic learning from experience.

Google’s Site Reliability Engineering (SRE) culture has formalized the blameless post-mortem as a standard practice, documented in detail in the SRE Book. Atlassian, GitHub, and Stripe publish public post-mortems as a transparency and trust-building practice.

In academic settings, retrospectives build the metacognitive habit of reflecting on your own process, a skill that distinguishes strong engineers throughout their careers regardless of the tools or methodologies they work with.

Additional Readings

Retrospectives have one canonical book and a large body of practitioner material of varying quality. The incident-review sources are worth reading even if you never have an incident, because the blameless postmortem is the most developed version of the idea this whole practice rests on: that you learn more from studying the conditions than from identifying the culprit.

Sources and further reading

Agile Retrospectives, Esther Derby and Diana Larsen: the standard book, and the source of the five-stage structure most formats follow.
The Prime Directive, Norm Kerth: one paragraph, read at the start of a great many retrospectives.
Retromat: a searchable collection of retrospective activities, for when Start-Stop-Continue has gone stale.
Postmortem Culture, Google SRE book: how blameless incident review actually works in an organization that depends on it.
Blameless postmortems, Atlassian: a shorter practical treatment, with a usable template.
A list of post-mortems, Dan Luu: real published incident reports, which are more instructive than any template.
Psychological Safety, Amy Edmondson: the research behind why some teams can say the difficult thing.

Activities that exercise this

Team Health Assessment: the structured check that gives a retrospective something concrete to discuss.
Learning Journal: the running note that makes the written retrospective tractable.
External Feedback Session: the same reflective habit, with an outside perspective.
Team Dysfunctions Assessment: useful when a retrospective keeps surfacing the same unresolved thing.