Run Retrospective Session

---
name: run-retrospective-session
description: Use when facilitating a learning retrospective after a course, project, or experience to help participants extract and apply lessons
source: David Kolb "Experiential Learning" (1984); Norman Kerth "Project Retrospectives" (2001); Derby & Larsen "Agile Retrospectives" (2006)
tags: [retrospective, experiential-learning, facilitation, reflection, kolb, teaching]
verified: true
---

# Run Retrospective Session

Facilitate a structured retrospective that converts experience into transferable learning through guided reflection and commitment.

## Why This Is Best Practice

**Adopted by:** Agile teams worldwide, US Army After-Action Reviews, medical simulation debriefs, Harvard Business School case method
**Impact:** Kolb's research shows experiential learning without structured reflection has 40% lower transfer to new contexts; Gibb's Reflective Cycle studies confirm structured debriefs improve performance on follow-up tasks by 25% vs. experience-only groups

**Why best:** Experience alone does not produce learning — reflection is the step that converts what happened into what to do differently. A facilitator's job is to slow the group down long enough to extract the lesson before moving to the next experience.

## Steps

1. **Set psychological safety** — Open with Kerth's 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, resources, and the situation at hand." No blame framing.
2. **Gather data (What happened?)** — Ask participants to recall specific events, decisions, and outcomes without interpretation. Use timeline exercises, sticky notes, or a shared whiteboard. Separate observation from opinion at this stage.
3. **Generate insights (So what?)** — Facilitate analysis: "What patterns do you notice?" "Why did this happen?" Use five-whys if causes are unclear. Group similar insights by theme.
4. **Identify what worked and what to change** — Use the "Start / Stop / Continue" or "WWW / EBI" (What Went Well / Even Better If) framework. Be specific: "The morning check-ins helped because X" not "communication was better."
5. **Draw learning generalizations** — Ask: "If you were in a similar situation again, what principles or heuristics would you bring?" This step moves from event-specific to transferable knowledge.
6. **Commit to concrete actions** — Each participant or team names 1–3 specific behavior changes with a named owner and a date. Vague commitments ("be more communicative") are replaced with specific behaviors ("send a status update by 5 PM on Fridays").
7. **Close with an appreciation round** — End by giving participants a moment to recognize each other's contributions. This builds psychological safety for the next retrospective.

## Rules

- The facilitator does not participate in content — only in process. If the facilitator has opinions about what happened, they disclose the conflict and step out.
- Action items must be specific, owned, and time-boxed. "We should do better" is not an action item.
- Retrospective findings are documented and shared within 24 hours — unwritten retrospectives produce no learning transfer.
- Retrospectives have a fixed time box (60–90 min for a 2-week sprint; 3 hours for a semester). Overtime signals poor facilitation of the data phase.
- Follow up on previous retrospective commitments at the start of the next session before gathering new data.

## Examples

An engineering team retrospective after a failed product launch uses the timeline exercise to map 40 events over 3 months. Participants add sticky notes of facts (green) and feelings (red). Three patterns emerge: decisions made without data, late feedback loops, and unclear ownership. The team commits to: weekly data reviews (owner: PM), design review at week 2 not week 8 (owner: design lead), and single DRI per feature (owner: engineering manager). All three are scheduled as calendar events before the session ends.

## Common Mistakes

- **Skipping the data phase** — Moving directly to "what should we do differently" without building a shared fact base produces opinions, not insights.
- **Facilitator as participant** — When the facilitator shares their own views on what went wrong, they shut down dissenting observations from the group.
- **No follow-through** — Retrospectives without action items, owners, and follow-up become a ritual that teams lose faith in; the next retrospective's first question must be "what happened to last time's commitments?"

## When NOT to Use

- When the experience being reflected on occurred more than two weeks ago and participants no longer have reliable episodic memory of specific events and decisions.
- When psychological safety is absent — if participants fear retaliation for honest input, a retrospective will surface only safe opinions and calcify the status quo rather than changing it.
- When the group has not yet completed the experience — a mid-sprint retrospective on an ongoing crisis redirects attention away from execution; wait until the event has a clear ending before debriefing.