yknothing Retrospective
The team that doesn't reflect doesn't improve. Retrospectives close the feedback loop.
Context
Retrospective is the skill that completes the lifecycle loop.
See context notes.
Inputs
I/O contract notes define required inputs and authority.
Process
Step 1: Set the Stage (5 min)
Establish psychological safety. The retrospective must be a blame-free zone:
- "We're here to improve the system, not to assign blame"
- Check in: how is everyone feeling about the last sprint/phase?
Step 2: Gather Evidence (15 min)
What happened? Use facts and metrics before opinions:
- incident timeline and postmortem findings
- review findings that should have stopped the issue earlier
- deployment or rollback decisions
- bugs found in production
- team coordination friction that was visible during execution
Step 3: Generate Insights (15 min)
Why did it happen? Techniques:
- 5 Whys: For each problem, ask "why" five times to reach root cause
- Fishbone diagram: Categorize causes (people, process, tools, environment)
- Start/Stop/Continue: What should we begin, stop, or keep doing?
- 4Ls: Liked, Learned, Lacked, Longed-for
Stay at the system/process level. If a problem belongs in a concrete downstream skill (pc-testing-strategy, pc-ci-cd, pc-incident-response, pc-tech-debt-management), call that out explicitly.
Step 4: Decide Actions (10 min)
Select 3-5 improvements (not 20). Each must be:
- Specific: "Add integration tests for payment flow" not "improve testing"
- Assigned: One person owns it
- Timeboxed: Deadline within the next sprint/phase
- Measurable: How will we know it's done?
- Routable: It is clear whether the action should go through intake, planning, delivery, or evolution next
Prefer actions that reduce recurrence risk and improve future handoffs instead of vague morale language.
Step 5: Close (5 min)
- Recap the action items
- Appreciations: call out what went well and who helped
- Confirm which follow-up items become intake-ready work
- Rate the retrospective itself (meta-improvement)
Outputs
Produce only declared outputs at their documented quality boundary.
Quality Gate
- No more than 5 improvement actions chosen
- Each action has an owner and a deadline
- Each action has a measurable success signal
- Each action identifies its next lifecycle destination
- Actions from previous retrospective reviewed (were they completed?)
- Insights documented for future reference
Anti-Patterns
- Retro without follow-through -- The #1 killer. If actions from last retro weren't done, why would new ones be?
- Blame fest -- Degenerates into finger-pointing. Facilitator must redirect to systems thinking.
- Too many actions -- 3 completed improvements > 10 abandoned ones. Be selective.
- Skipping retro when things went well -- Good sprints have learnings too. What made it good? How do we replicate it?
- Same format every time -- Rotate formats to prevent staleness (sailboat, timeline, mad/sad/glad).
- Action items with no route back into the system -- If follow-ups never become planned work, the retro is theater.