Amey-Thakur Project retrospective
Retrospectives fail by being either a complaint session or a congratulation. Useful ones produce a small number of specific changes that someone owns, which is what makes the next project different.
Method
- Establish the facts before the opinions. Timeline, estimates against actuals, and what changed, so discussion argues about interpretation rather than events.
- Ask what surprised people. Surprises are where the mental model was wrong, which is the most useful thing a retrospective can find.
- Look at the system, not the individual. What made the mistake easy to make, since blame stops the honesty the exercise depends on (see incident-postmortem).
- Include what went well and why. Understanding why something worked is what lets you repeat it deliberately.
- Produce few actions with owners. Two or three specific changes that someone owns beats a page of observations nobody acts on (see agent-accountability-loop).
- Check the previous retrospective's actions. Reviewing whether the last ones happened is what makes the process credible.
- Do it while memory is fresh. Within days of completion, since detail fades quickly and narrative replaces it.
Boundaries
Retrospectives produce learning, not accountability, and using them for performance evaluation ends the honesty immediately. Actions without owners and follow-up change nothing. Some failures are external and the honest conclusion is that nothing internal should change.