part five · the retrospective
The Retrospective
Three questions. One change. Compounding rather than listing.
Held once per cycle, after the signal reading is written and the first postmortems (if any) are filed. Sixty minutes maximum. Outputs one change, not a list.
A retrospective is not a venting session. It is the team's regular act of tightening the chain by exactly one notch. The discipline is to compound — each cycle's retrospective change still in effect when the next cycle's runs — instead of listing — eight things to improve, none owned, all forgotten by Tuesday.
Three questions
Same three, every cycle. The repetition is the point.
- What carried? What did we do this cycle that we want to keep doing? Specific. We held amigos before code began on every story counts. Communication was good does not.
- What broke? Where did meaning leak between phases? The brief was unclear, the ADR was missed, the prediction was forgotten, the postmortem produced a feeling instead of a fix. Concrete.
- What changes? One change. Owned by name. Dated. Testable.
That last constraint is the whole game. Lists of improvements compound to nothing. One owned, dated, testable change compounds.
What "testable change" means
A change is testable if a person who wasn't in the retro can, by looking at the chain artifacts in the next cycle, see whether it happened.
| Not testable | Testable |
|---|---|
| Communicate better with the client | Send the weekly client update every Friday by 4pm, written by the PO, before the team's Friday wrap |
| Get amigos done earlier | Amigos for every story is scheduled within 24 hours of the story being pulled |
| Clean up the bugs | The chain-level distribution of open bugs is reviewed in the Wednesday triage and discussed in monthly portfolio review |
| Write better briefs | The brief template now has an "I have witnessed this" line that the PO signs |
How to run sixty minutes
Five minutes — read the signal reading aloud. Anchors the room in what reality answered.
Twenty minutes — what carried and what broke. Round-robin so everyone speaks once before anyone speaks twice. Notes go to a single shared doc.
Twenty minutes — propose the change. Name the owner. Set the date. Say what would prove it happened.
Five minutes — write the change down where it will be seen. Pinned in the team channel, added to the chain-artifact list, linked from the next cycle's kickoff.
Ten minutes — buffer for the conversation that always wants to keep going. Then it ends.
What the retrospective is not
Not the postmortem. The postmortem is incident-specific and produces structural fixes to runbooks and brief templates. The retrospective is cycle-specific and produces process changes to how the team runs.
Not the model update. The retrospective produces one change to how the team operates. The model update writes down what the team learned about the world. Different artifacts, different audiences, different lifetimes.
Not therapy. The retro is short, dry, and outputs an artifact. If the team needs the conversation about feelings, that is a separate conversation in a separate room.
Enough to know one thing is moving.
One change is named, owned, dated, testable. It is visible in the team's working space. The change from the previous retrospective is still in effect — or has been deliberately retired with a note explaining why.