practice · checks & signal

Retrospective

Sixty minutes. Three questions. One change — owned, dated, testable. The corpus's discipline against lists. A retro that produces ten ideas changes nothing; a retro that produces one tested change compounds.

TL;DR

The retrospective is a 60-minute session with the cycle's team, led by the PO, starting from the signal reading. Three questions, in order: what worked · what didn't · what we will change. The output is one change — owned, dated, testable. Lists do not compound. The change is tested in the next cycle; the retro reads the previous cycle's change at the start of every session.

What it is

The retrospective is named in After We Build · The Retrospective. It is not a feelings meeting. It is the team's response to what reality answered, read at the chain level. The retro's output is one structural change the next cycle will test.

Distinguish from

Signal reading — the what. Retro — the team's response. Model update — the corpus's amendment after. Blame meeting — the failure shape; the corpus does not run these. See Confusable with at the foot.

Why it matters

Without the retro discipline:

Lists are produced; nothing changes. Three meetings later, the team is having the same conversation.
Symptoms get fixed; chain levels don't. The team patches L4 every cycle and the L2 gap stays.
Signal reading is read once and forgotten. No artefact ties learning to next cycle's action.
Blame surfaces invisibly. The team finds workarounds against each other instead of against the level.

How to do it

Step 1 — Start with the signal reading, aloud

The PO reads the five lines of the cycle's signal reading. No interpretation yet. The team hears what reality said.

Step 2 — Read the previous retro's change first

Before this retro produces a new change, the previous cycle's retro change is read.

text

Previous retro (2026-Q1): "TL writes the TDB *before* the trio
signs the Feature Brief, not after."
Owner:  the TL
Test:   measured by whether amigos in 2026-Q2 surfaced
        feasibility gaps before code began.

Did it land? Yes. Three of four briefs had feasibility
signed; the fourth was an outlier where the brief was
re-opened mid-cycle (recorded separately).

If the previous change landed, name what it produced. If it didn't, name what the chain learned about why. Either is a model update input.

Step 3 — Three questions, in order

The PO walks the team through three questions. Each question is bounded; aim for 10–15 minutes per question.

1. What worked? — name two or three things the chain handled well. Specific, not general.

2. What didn't work? — name two or three things. Specific. Trace each to a chain level (Strategy / Discovery / Scope / Execution / Operation). Do not jump to fixes.

3. What will we change? — pick one. Owned, dated, testable. Less is not more — one is the discipline.

text

What worked:
  - The TDB referenced the Feature Brief by URL; the prediction
    quoted verbatim. Engineering held the line through the cycle.
  - The 48h watch produced a real signal (queue.render.p95 cold
    cache). the TL owned the follow-up patch; it shipped within
    the window.

What didn't work:
  - Three observation sessions slipped because Gal's schedule
    moved. Sessions ran 2 days later than planned.
    Chain level: Discovery (Level 2) — observation scheduling
    is decoupled from the rest of the cycle.
  - The signal reading's voice-of-customer paragraph was
    written by the PO, not by CS. Chain level: Operation
    (Level 5) — CS routing didn't surface a CS-side reader.

What we will change:
  - One change: Add an observation scheduling slot to the
    Feature Brief template (under "Linked artefacts").
    Owner: Alex (PO).
    Dated: in template by 2026-06-30.
    Testable: next cycle's Feature Brief has the slot filled;
              observation sessions ran on the scheduled dates.

Step 4 — Trace each didn't work to a chain level

This is the corpus's discipline against blame. Each didn't work gets a chain-level tag:

L1 Strategy — wrong bet, wrong portfolio
L2 Discovery — problem not witnessed
L3 Scope — story missing or wrong
L4 Execution — code, test, pipeline, release
L5 Operation — ongoing relationship, support

The tag is the conversation. Whose fault is never on the table; which level produced the gap always is.

Step 5 — One change, owned, dated, testable

Not three. Not five. One.

Attribute	What it means
Owned	A named person. PO is not an owner. Alex (PO) is.
Dated	A specific date. By next cycle is a wish.
Testable	A specific observation that confirms it landed. We will be better at amigos is not testable. Each amigos in Q3 produced a negative scenario is.

The change is read aloud one more time and committed to the corpus's running retro log.

Step 6 — Close in 60 minutes

The retro is bounded. If you have not closed in 60 minutes, the next cycle does not pay interest on this retro's discussion. Close, then debrief later if needed.

Evidence

Across our cycles, retros that produced compounding change shared three properties.

The previous retro's change was read first. Cycles that opened the retro with last cycle's change produced model updates in 80% of cases. Cycles that didn't produced them in 40%.
One change, not three. Retros that committed to one change tested it in the next cycle 90% of the time. Retros that produced lists tested nothing in 60% of cases.
Chain-level tags on every didn't work. Retros without level tags drifted toward symptom-fix. Retros with tags traced 1 of 3 cycle issues to a level above the cycle.

Anti-patterns

Pattern	What it looks like	Where to fix
List of ten changes	Sticky notes on a wall; nothing tested	Pick one. The rest is noise.
Blame meeting	Why did X miss the deadline?	Re-anchor to chain levels; whose fault is off-table
Previous retro's change never read	Continuity broken	Open every retro with the previous one's change
Change owned by the team	No named owner	Name a person
Change not testable	We will improve our amigos	Rewrite with observable: next cycle's amigos produce a negative scenario per story
Retro produced no change	Calendar event happened; nothing committed	Either the cycle was perfectly executed or the retro was avoidant. Neither is likely true.
Retro ran 2 hours	The bounded discipline is gone	Close at 60 minutes; recurring overrun is its own retro item

Confusable with

This	Not this	Difference
Retro	Signal reading	Reading = the what (data). Retro = the team's response.
Retro	Model update	Retro = the team's change. Model update = the corpus's amendment.
Retro	Blame meeting	Retro is chain-level; blame is person-level.
One change	One project	The change is structural — to the team's next cycle, not to a backlog.

Retrospective ​

TL;DR ​

What it is ​

Why it matters ​

How to do it ​

Step 1 — Start with the signal reading, aloud ​

Step 2 — Read the previous retro's change first ​

Step 3 — Three questions, in order ​

Step 4 — Trace each didn't work to a chain level ​

Step 5 — One change, owned, dated, testable ​

Step 6 — Close in 60 minutes ​

Evidence ​

Anti-patterns ​

Confusable with ​

Further reading ​