Retrospective

A retrospective is a structured review of a completed period of work. It asks three questions: What went well? What didn't? What will we change? It's the simplest tool for continuous improvement, and the most neglected.

The Principle

"Insanity is doing the same thing over and over and expecting different results."

If you don't stop to examine what happened, you'll repeat every mistake. A retrospective is the forcing function that turns experience into learning.

The Basic Format

1. What Went Well?

Start positive. What worked? What should you keep doing? What surprised you in a good way?

This isn't fluff. Recognizing what works is as important as fixing what doesn't. Teams that only focus on problems burn out. Teams that celebrate wins and understand why they won build momentum.

2. What Didn't Go Well?

What frustrated you? What took too long? Where did communication break down? What would you do differently?

Ground rules:

No blame. Focus on systems, not people.
Be specific. "Communication was bad" isn't useful. "We didn't know the API spec changed until production broke" is.
Include things that almost went wrong. Near-misses are free lessons.

3. What Will We Change?

This is where most retrospectives fail. Without concrete action items, the retro was just venting.

Good action items are:

Specific: "Add a staging environment check to the deploy process" not "improve testing"
Owned: One person responsible, with a deadline
Measurable: You can tell if it was done
Small: One change is better than ten aspirations

Limit to 1-3 action items. If you try to change everything, you change nothing.

Retrospective Formats

Start/Stop/Continue

Start: What new things should we try?
Stop: What should we stop doing?
Continue: What's working that we should keep?

Good for teams that need to shake up habits.

Mad/Sad/Glad

Mad: What made you angry or frustrated?
Sad: What disappointed you?
Glad: What made you happy?

Good for surfacing emotional responses that logic-focused retros miss.

4Ls

Liked: What did you enjoy?
Learned: What did you discover?
Lacked: What was missing?
Longed for: What do you wish you had?

Good for learning-focused teams.

Sailboat

Visual metaphor:

Wind (propelling): What's pushing us forward?
Anchor (dragging): What's holding us back?
Rocks (risks): What could sink us?
Island (goal): Where are we trying to get?

Good for teams that think visually or need a fresh format.

Timeline

Map out the project chronologically. At each major event, capture:

What happened?
How did it feel at the time?
What was the impact?
What would you do differently?

Good for longer projects where cause-and-effect matters.

Running an Effective Retro

Before

Schedule it. Don't skip it because you're "too busy." That's when you need it most.
Set the stage. Remind everyone: this is about improvement, not blame.
Review last retro's action items. Did you do them? If not, why not?

During

Time-box it. 60-90 minutes max. Use a timer for each section.
Equal voice. Introverts write silently first. Then discuss. Don't let the loudest voice dominate.
Facilitator rotates. Having the same person run every retro creates patterns. Rotate.
Vote on priorities. If 20 items surface, dot-vote to find the top 3.

After

Write up action items. Assign owners and deadlines.
Share the notes. Even with people who weren't in the room.
Follow up. Check on action items before the next retro.

For Solo Practitioners

Retros aren't just for teams. A weekly personal retrospective is one of the highest-leverage habits you can build:

Friday, 15 minutes: What went well this week? What didn't? What's one thing I'll do differently next week?
Write it down. Your memory is unreliable. A written log compounds into real self-knowledge.
Review monthly. Patterns emerge that aren't visible week-to-week.

Common Pitfalls

Blame Games

"John didn't finish his work" is not a retrospective insight. "Our estimation process consistently underestimates front-end work" is. Focus on systems, not individuals. If someone isn't performing, that's a separate conversation.

No Follow-Through

The fastest way to kill retrospectives: never act on the action items. If nothing changes after the retro, people stop engaging. Check on action items at the start of every retro.

Too Infrequent

Monthly retros are too late. By the time you discuss a problem from week 1, you've already repeated it 3 more times. Run retros at the end of each sprint or work cycle.

Too Long

If a retro takes 3 hours, it's not a retro — it's a therapy session. Time-box ruthlessly. If issues are too complex for the retro, create a separate working session.

Recency Bias

Teams remember last week's crisis but forget the quiet success from three weeks ago. A timeline format or pre-retro survey helps counter this.

The Meta-Lesson

A retrospective is itself a feedback loop. You do work, observe results, reflect, and adjust. Teams that master this loop improve exponentially. Teams that skip it repeat the same year of experience ten times and call it "ten years of experience."