Retrospectives

Definition

A retrospective — what the Agile software community popularized after retiring the darker term “post-mortem” — is a simple habit of continual process improvement: at the end of any major activity, take time to answer a few honest questions about the experience, and turn the answers into concrete actions for next time. As G.K. Chesterton put it, “if a thing is worth doing, it is worth doing badly” — and Zig Ziglar’s refinement is closer to the spirit of a retrospective: “anything worth doing is worth doing poorly, until you can learn to do it well.” A retrospective is the mechanism for that learning.

Learning Outcome

After using this technique, you should be able to close out any significant piece of work — individual or group — by turning raw experience into a short list of specific, actionable changes for the next time you do something similar.

Core Structure

Three questions, asked in order, at the end of any major activity:

1. What worked well for us?
2. What did not work well for us?
3. What actions can we take to improve our process going forward?

The first two are diagnostic — they surface what actually happened, without judgment attached yet. The third is where the retrospective earns its keep: it forces the group (or the individual) to convert observations into something concrete enough to actually change behavior next time, not just a shared complaint or a compliment.

For a group retrospective, a workable process is: have each person answer all three questions individually first, then come together to discuss and synthesize — especially the third question, where the group needs to agree on what will actually change, not just list everyone’s individual preferences.

Worked Example

Retrospective on a semester-long research project, condensed:

What worked well: Starting resource-gathering in the first few weeks meant there was no scramble before the first major deadline. Reviewing a peer’s draft before submitting sharpened the final version considerably.

What did not work well: The topic was scoped too broadly at first, and narrowing it mid-way through meant reworking earlier sections. Presentation slides were finalized the night before each talk rather than practiced in advance.

Actions for next time: Apply the sufficiency/achievability test from Scoping a Thesis Statement before starting research, not after finding the topic is unworkably broad. Build in a fixed “practice run” two days before any presentation, not the night before.

Notice the third answer isn’t just “be better organized” — it’s specific enough to actually do differently next time.

Common Pitfalls

• Stopping at questions one and two — cataloging what happened without ever converting it into action is reflection without improvement.
• Vague actions (“communicate better”) that aren’t specific enough to actually change behavior next time.
• Skipping the individual-answers-first step in a group retrospective, so the loudest voice in the room ends up setting the whole narrative.
• Treating a retrospective as a one-time event for a single project, rather than a habit applied after any major activity.

Rubric / Checklist

• All three questions were asked, not just the first two
• “What worked” and “what didn’t” are specific observations, not vague impressions
• Every action item is concrete enough to be checked next time (“do X before Y,” not “be more careful”)
• In a group setting, individual responses were collected before group synthesis
• The retrospective actually gets applied to the next similar effort, not filed away