Skip to content

The Retrospective

Three questions, in order. One change — specific, owned, testable. The discipline of compounding rather than listing.

Events in this phase

The retrospective is calendar-locked at the cycle's close. Trio plus anyone whose work is being examined. Inputs: the signal reading and any postmortems. The retro doesn't re-litigate them — it learns from them.

This is where meaning's journey through the cycle is evaluated honestly — not as a feelings session, but as a comparison between what was predicted and what happened.

Without written predictions before the cycle, this is impossible. A reconstructed prediction is a description. Only a prediction written before the cycle can be honestly evaluated.

Three questions, in order

Name the practice, not just the outcome. "The amigos session caught the concurrent submit edge case" is a link holding. "Things went well" is not. Name what worked so it is consciously preserved.

Trace to a level, not a person. Scenario gap? Observation mismatch? ADR drift? Prediction not checked? Each broken link names a structural gap with a structural fix.

3 · What is the one change we are making?

One. Not a list. Specific enough to test, owned by a named person, with a measurable outcome and a check date. "We should communicate better" is not a change. "A template prompt added by Thursday, checked at the next retrospective" — that is.

Resolution gate — Retrospective to Model Update

Enough to compound rather than list.

One change is named, owned, and dated. A retrospective that produces more than one change produces zero changes — because five action items implemented zero is feelings. One action item implemented is compounding. The volume's argument hangs on the difference.

Part 6 — The Model Update →

200apps · How We Work · NWIRE