Retrospectives¶
A retrospective ("retro") is a scheduled meeting where a team — or a person — reviews what just happened, names what went well and what didn't, and picks one or two things to change next time.
Done well, the retro is one of the highest-leverage habits in project work. Done badly, it is theatre.
Where it comes from¶
Norm Kerth wrote the canonical book in 2001: Project Retrospectives: A Handbook for Team Reviews (Kerth, 2001). The Agile community adopted retros as a core ceremony, and Esther Derby and Diana Larsen wrote the modern playbook (Derby & Larsen, 2006).
Kerth's most important contribution is the Prime Directive:
"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."
The Prime Directive is what makes retros safe. Without it, retros become blame sessions. With it, they become learning sessions.
The 5-step Derby/Larsen format¶
- Set the stage. State the Prime Directive. Get everyone's attention.
- Gather data. What actually happened? Use the audit log (S-3.3) or the meeting decisions log (T-2.4).
- Generate insights. Patterns. Why did the slow thing slow down? Why did the fast thing speed up?
- Decide what to do. Pick one or two changes. Not five. Five is theatre.
- Close. Document the changes. Assign owners. Schedule the next retro.
Total time: 60–90 minutes for a team; 15–30 for a solo retro.
Cadences¶
- Solo Operator — monthly retro using the audit log (S-3.3).
- Team Lead — end-of-project retro after each major project ships; monthly mini-retro on each active project (T-2.8).
- Programme/portfolio — quarterly portfolio review (T-3.4), which is a retro at portfolio level.
How dooer supports retros¶
| Step | dooer surface |
|---|---|
| Set the stage | Open a meeting with all stakeholders as RACI attendees |
| Gather data | Audit Log (Settings → Audit) filtered to time range + project |
| Generate insights | Discuss as group; note common patterns |
| Decide what to do | Capture as decisions (T-2.4); convert action items to tasks |
| Close | Meeting page IS the documentation; tasks IS the assignment |
The retro meeting page becomes the permanent record. Next quarter's retro starts by reading last quarter's.
The two failure modes¶
Failure mode 1: ritual without action. The retro happens. People talk. Nothing changes. Within 3 months people stop showing up.
Cure: the only output that matters is "what will we change?" If a retro doesn't produce one concrete change, it failed. Stop the meeting 15 minutes before scheduled end to force this output.
Failure mode 2: blame session. Someone gets singled out. People learn to hide problems instead of surface them.
Cure: restate the Prime Directive at the start, every time. If blame creeps in, name it and move on. The leader's job in a retro is to make truth-telling safe (see Psychological safety).
Solo retros¶
You can do this alone. The format is the same; the conversation is internal.
Tools for a solo retro:
- A 30-minute calendar block on the last Friday of the month.
- The audit log filtered to the month.
- Your closed-task list.
- A notebook (or a dooer note).
Ask three questions:
- What surprised me this month?
- What did I do that's worth doing again?
- What would I change?
Write three lines. Schedule one concrete change. That's the retro.
Where to read more¶
- Kerth, N. (2001). Project Retrospectives: A Handbook for Team Reviews. Dorset House. The canonical book; introduces the Prime Directive.
- Derby, E. & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf. The modern facilitator's manual.
- Edmondson, A. (2018). The Fearless Organization. Wiley. Why psychological safety is the precondition for retros that work.