Skip to content

Retrospectives & Continuous Improvement

A retro is not a feelings round or a complaint session — it's how a team turns a window of real data into a small number of owned, verifiable improvements.

When this matters

At the end of a work period — weekly is the usual cadence — when it's time to step back from the day-to-day and ask "what should change." Also any time the same friction gets grumbled about more than once: that's a signal it deserves the systemic treatment below, not another one-off fix.

The practice

Set the stage blameless. The prime directive: everyone did the best they could with the information and constraints they had at the time. Critique the system — the process, the config, the missing check — never the person. A retro that names a person as the cause teaches people to hide the next problem instead of surfacing it.

Gather the data before the opinions. Pull the window's actual signals first — metrics, completion notes, blocker counts, what broke — before anyone forms a take. A claim with no number behind it is a hypothesis, not a finding. Starting from data instead of the loudest complaint in the room is what keeps a retro honest.

Find the pattern, not the one-off. Cluster what you found and ask "why" repeatedly (5-whys) until you hit a systemic cause, not a surface symptom. You're looking for the recurring pain — something that shows up again and again — not whichever single incident is freshest in memory.

Decide on few, owned, verifiable actions. Resist the urge to fix everything at once. Pick the one or two changes with the highest leverage (weigh cost of delay against your confidence it'll help), and turn each into something concrete: a named owner, a specific change, and a way to check later whether it actually worked. "Be more careful" is not an action — it can't be verified.

Close the loop on last time. Every retro starts by checking whether the previous retro's actions actually moved the thing they were meant to move. An action nobody verified stays open — it doesn't get silently dropped just because time passed.

Run daily noticing, weekly deciding. Log friction as you hit it — day to day — so it isn't forgotten by the time the retro comes around. But don't act on a single day's annoyance in the moment; let the pattern accumulate and make the actual call at the weekly retro. Reacting to every day's noise individually is how a team ends up thrashing its own process instead of improving it.

Checklist

  • Did I set the stage blameless — system and process, never a person?
  • Did I pull real data before forming an opinion?
  • Did I 5-whys to a systemic cause instead of stopping at the first symptom?
  • Is this a recurring pattern, or the loudest one-off in the room?
  • Did I pick a few actions, not a long list nobody can attribute later?
  • Does each action have a named owner and a way to verify it worked?
  • Did I check whether last retro's actions actually moved the metric — and reopen the ones that didn't, instead of letting them quietly disappear?

Template

## Retro — <period, e.g. Week of <date>>

### Data
<the window's actual signals: metrics, counts, what broke — not opinions>

### Pattern
<what recurred, and the systemic "why" behind it (5-whys), not the loudest one-off>

### Actions (few, owned, verifiable)
1. <action> — Owner: <name> — Verify by: <how/when you'll know it worked>
2. <action> — Owner: <name> — Verify by: <how/when you'll know it worked>

### Closing the loop on last retro
- <last action 1>: <verified / not yet — reopened>
- <last action 2>: <verified / not yet — reopened>

Adapted from

  • SE's retrospectives skill — the data → insight → action cycle (blameless stage-setting, evidence before opinion, 5-whys to a systemic cause, few owned verifiable actions, closing the loop on the last retro), and its anti-patterns: blame, actions with no owner or no check, and proposing many changes at once so none can be attributed.
  • SE's own real weekly retro records — the practice runs on a genuine weekly rhythm, not a vague "when we get to it," and each one explicitly re-checks whether the prior week's elected action actually landed before proposing anything new, rather than treating every week as a clean slate.

Practice it

Ask the onboarding-tutor: "Help me run a mini-retro on <a recent week of my own work> — push me to find data before opinions, dig to a systemic cause with 5-whys, and land on one action I can actually verify."