run-team-retrospective

name	run-team-retrospective
description	Use when a team needs to reflect on a completed period, project, or significant event — to extract what worked, what didn't, and what specific changes to make before the next cycle, rather than repeating the same patterns.
source	Kerievsky & Derby "Agile Retrospectives: Making Good Teams Great" (Pragmatic Bookshelf, 2006); Lencioni "Death by Meeting" (Jossey-Bass, 2004) — quarterly reviews; Amy Edmondson "Teaming" (Jossey-Bass, 2012) — team learning loops
tags	["retrospective","team-learning","continuous-improvement","reflection","feedback","agile","team-performance","learning-culture"]

Run Team Retrospective

Facilitate a structured team reflection on a completed period or project — to name what worked (reinforce it), name what didn't (understand why), and commit to specific behavioral changes before the next cycle.

Why This Is Best Practice

Adopted by: Retrospectives are a core ceremony in the Scrum framework (used by 87% of Agile teams, State of Agile 2022) and adapted across non-engineering business functions; Edmondson's "Teaming" research at hospitals, flight decks, and product teams identifies structured after-action review as the primary mechanism for team learning; the US Army's After-Action Review (AAR) — the military equivalent of a retrospective — is used after every significant operation and is credited with transforming the US Army's training effectiveness in the 1970s; IDEO, Pixar (creative post-mortems), and McKinsey (project learnings) all institutionalize structured team reflection Impact: Edmondson's research (2012) found that teams with structured reflection cycles improved performance 25% faster than comparable teams without them; Google's Project Aristotle data showed that psychological safety combined with team learning processes (including retrospectives) was the strongest two-factor predictor of high team performance; the US Army's institutionalization of AARs is credited in the military literature with improving training effectiveness by 30–40% (Army Research Institute, 1993) Why best: Teams that do not reflect repeat their patterns — both the effective ones and the dysfunctional ones; without a structured reflection, the successful practices from a good quarter are not codified (they depend on the same people staying and doing the same things), and the failures from a bad quarter are rationalized rather than understood; structured retrospectives convert team experience into team learning

Sources: Kerievsky & Derby "Agile Retrospectives" (Pragmatic Bookshelf, 2006); Edmondson "Teaming" (Jossey-Bass, 2012); US Army "Center for Army Lessons Learned" AAR methodology; Google Project Aristotle research (2016)

Steps

1. Choose the right cadence and scope

Sprint/project retrospective: after any bounded work period (2-week sprint, project completion, product launch). Focus: the work practices, collaboration, and process of that specific period.

Quarterly team retrospective: for business teams not running sprints. Focus: team health, goal achievement, working dynamics, and what to change next quarter.

Event retrospective: after a significant event — a major failure, a crisis, a significant win. Focus: what specifically caused the outcome and what to do differently.

The cadence must be regular — quarterly at minimum for non-engineering teams. Retrospectives that only happen after something goes wrong are post-mortems, not continuous improvement.

2. Prepare the psychological conditions

Retrospectives require psychological safety to produce honest output. Without it, the session produces polished, diplomatic answers that are safe to say — and useless.

Before the session:

• State the purpose: "This is not about blame or performance evaluation. It is about our collective patterns and how we improve them."
• Separate retrospective findings from performance data: what is said in a retrospective must not appear in a performance review.
• Make it the norm that the manager shares their own failures first — this models fallibility and signals that vulnerability is safe.

Prime directive (Norm Kerth, adapted for all teams):

"Regardless of what we discover, we understand and genuinely believe 
that everyone did the best job they could, given what they knew at 
the time, their skills, available resources, and the situation at hand."

Read this at the start. It shifts the frame from blame to learning.

3. Run the core retrospective structure

The most effective general-purpose structure: 5-phase retrospective (Kerievsky & Derby), adapted to 60–90 minutes.

Phase 1 — Set the stage (10 min) A brief check-in that gets everyone speaking before the substantive discussion. Simple: "One word or phrase for how you're feeling coming into this conversation."

Phase 2 — Gather data (20 min) Structured, parallel input. Use silent brainstorm first (sticky notes or digital equivalent), then cluster.

Two prompts:

• "What went well? What should we do more of or protect?"
• "What didn't go well? What created friction or slowed us down?"

Silent brainstorm prevents anchoring: the loudest voice doesn't shape everyone else's answers. Cluster similar themes after everyone has written their own.

Phase 3 — Generate insights (20 min) Move from "what happened" to "why did it happen":

• "Which of these patterns are about our process, and which are about our environment?"
• "Where in this list do we have the most control to change things?"
• "What's the root cause of our biggest frustration?"

Do not skip this phase. It is what distinguishes a retrospective from a complaint session. Naming what happened (Phase 2) without understanding why produces fixes that don't stick.

Phase 4 — Decide what to do (15 min) From the insights, identify 1–3 specific actions the team will take in the next period. More than 3 is unrealistic — they will not all get done, and the ones that don't train the team to expect retros to be performative.

Each action must have:

• A specific behavior (not "communicate better" → "share blockers in the daily standup before end of day Tuesday")
• An owner (one person, not "the team")
• A due date

Phase 5 — Close the retrospective (5 min) Two closing questions:

• "What was most useful about this session?"
• "What would make the next retrospective even more effective?"

Document and share the agreed actions within 24 hours.

4. Open the next retrospective by reviewing last cycle's commitments

The most common retrospective failure: the agreements from last time were never reviewed. This trains the team that retrospective commitments are optional.

Every retrospective opens with: "Let's look at what we committed to last time. What did we do? What didn't happen? Why?"

This accountability loop is what converts retrospective insights into actual behavioral change. Without it, retrospectives produce good conversations but not improvement.

5. Rotate facilitation

When the manager always facilitates, the retrospective carries the manager's implicit agenda and employees self-censor. Rotating facilitation across team members:

• Builds facilitation skills across the team
• Reduces the power dynamic that filters candor
• Produces more honest signal about what the team actually thinks

Give a team member the facilitation guide 3 days before their session. Offer to co-facilitate the first time.

Rules

• Separate retrospective findings from performance data — findings shared in a retro cannot be used in performance evaluation; violation destroys psychological safety permanently
• Open by reviewing last cycle's commitments — without this accountability loop, retrospective agreements are advisory and not behavioral
• No more than 3 actions per retrospective — more than 3 ensures some will not be completed, which signals that retro commitments are optional
• Manager shares their own failures first — this models the vulnerability required for the team to be honest
• Regular cadence is non-negotiable — retrospectives only after failures are post-mortems; continuous improvement requires regular structured reflection

Common Mistakes

• Pure venting without insight generation: "what went wrong" sessions without "why did it go wrong" produce a list of complaints but no understanding; always run Phase 3 (generate insights).
• Agreeing to vague actions: "we'll communicate better" is not a retrospective action; it has no owner, no specific behavior, and no due date; every action must be specific.
• Manager dominates the session: if the manager speaks first for each phase, anchors the discussion, and evaluates each suggestion, the output reflects the manager's views rather than the team's.
• Skipping the closing review of last cycle's actions: this is the single highest-leverage retrospective practice; teams that start each retro with accountability for last retro's commitments improve 2× faster.
• Annual retrospectives instead of quarterly: annual retrospectives produce a year of patterns to address simultaneously; the team cannot act on all of them; quarterly retrospectives produce a manageable 3-month window.

When NOT to Use

• During active crisis — when the team is in a delivery emergency, a retrospective consumes the focused energy needed for the crisis; run the retro after the immediate pressure is resolved.
• As a venue for individual feedback — retrospective data is team-level; using a retro to surface feedback about a specific person's performance changes the psychological safety of the session; individual feedback belongs in one-on-ones and performance processes.