AgentSkillsCN

retrospectives

当你的冲刺或项目结束时，不妨运用结构化的反思框架，将团队的经验转化为可落地的改进措施。

SKILL.md
--- frontmatter
name: retrospectives
description: When your sprint/project ends - structured reflection framework that turns team experience into actionable improvements
tags: [agile, continuous-improvement, team-dynamics, learning, facilitation]

Retrospectives (Agile Team Reflection)

Overview

Structured team meetings held at regular intervals (typically end of sprint/project) to reflect on what happened, identify improvements, and commit to changes. The cornerstone practice of continuous improvement in agile methodologies.

Core Principles

The Prime Directive (Norman Kerth)

"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."

This statement, read at the start of every retrospective, establishes psychological safety by assuming good intent and focusing on systems/processes rather than individual blame.

  • •Blameless Culture: Focus on what happened, not who caused it
  • •Psychological Safety: Create space for honest feedback without fear of retribution
  • •Action-Oriented: Generate concrete experiments, not just complaints
  • •Team Ownership: The team identifies and commits to improvements
  • •Regular Cadence: Continuous small improvements beat rare big interventions

When to Apply

Use Retrospectives when:

  • •End of sprint/iteration (every 1-2 weeks for agile teams)
  • •Project completion (regardless of success/failure)
  • •After significant incidents or changes
  • •Team dynamics feel stuck or deteriorating
  • •Process changes need team buy-in
  • •Onboarding new practices or tools

Don't use (or adapt) when:

  • •Team lacks psychological safety (address this first)
  • •Leadership uses retros for performance reviews (destroys trust)
  • •No authority to implement improvements (creates cynicism)
  • •Time pressure makes it performative (better to skip than rush)

How It Works

The Five-Phase Structure (Esther Derby & Diana Larsen)

Phase 1: Set the Stage (5-10 min)

  • •State the Prime Directive
  • •Define the retrospective goal and scope
  • •Use icebreaker activity to engage everyone
  • •Example: "One word to describe this sprint" (round-robin)

Phase 2: Gather Data (10-15 min)

  • •Collect facts about what happened during the period
  • •Use timeline, metrics, events, feelings
  • •Ensure shared understanding before interpretation
  • •Example: "On the timeline, mark when you felt energized (green) or drained (red)"

Phase 3: Generate Insights (15-20 min)

  • •Identify patterns, root causes, systemic issues
  • •Ask "Why did this happen?" (but avoid blame)
  • •Surface hidden assumptions and mental models
  • •Example: "Group similar items, name each cluster, discuss underlying causes"

Phase 4: Decide What to Do (10-15 min)

  • •Generate potential improvements
  • •Prioritize using dot voting or impact/effort matrix
  • •Commit to 1-3 concrete experiments for next iteration
  • •Assign owners and define "done"
  • •Example: "What's ONE thing we could try next sprint to address this?"

Phase 5: Close the Retrospective (5 min)

  • •Summarize action items and owners
  • •Appreciation round (thank team members for contributions)
  • •Meta-retrospective: "How was this retro? What would make it better?"
  • •Example: "Rate this retro 1-5, why?"

Popular Retrospective Formats

1. Start-Stop-Continue

When to use: Simple, effective, works for any team

  • •Start: What should we begin doing?
  • •Stop: What should we quit doing?
  • •Continue: What's working well that we should keep?

Execution:

  1. •Silent writing (5 min): Each person writes on sticky notes
  2. •Cluster items on board (5 min)
  3. •Discuss each category (10 min)
  4. •Vote on top 2-3 actions (5 min)

2. Glad-Sad-Mad

When to use: Emotional processing after intense sprints

  • •Glad: What made you happy?
  • •Sad: What disappointed you?
  • •Mad: What frustrated you?

Execution:

  1. •Draw three columns on board
  2. •Silent generation: everyone adds items (7 min)
  3. •Read aloud and cluster (5 min)
  4. •Discuss themes (10 min)
  5. •Identify actions to address "Sad" and "Mad" (8 min)

3. Sailboat Metaphor

When to use: Visual teams, exploring forces affecting progress

  • •Wind: What's helping us go faster?
  • •Anchor: What's slowing us down?
  • •Rocks: What risks do we face?
  • •Island: What's our goal?

Execution:

  1. •Draw sailboat with wind, anchor, rocks, distant island
  2. •Team adds items to each element (10 min)
  3. •Discuss anchors and rocks in depth (15 min)
  4. •Commit to actions: harness wind, cut anchors, avoid rocks (10 min)

4. The Four Ls

When to use: Learning-focused, works well for project retrospectives

  • •Loved: What went really well?
  • •Learned: What new insights did we gain?
  • •Lacked: What was missing?
  • •Longed For: What do we wish we had?

5. Timeline Retrospective

When to use: Long iterations, complex projects with many events

Execution:

  1. •Draw timeline on board (sprint start → end)
  2. •Team adds events, decisions, changes along timeline (10 min)
  3. •Mark emotional highs/lows with color (green/red dots)
  4. •Discuss: What patterns do we see? What caused the lows? (15 min)
  5. •Commit to experiments to increase highs, reduce lows (10 min)

Execution Steps

Before the Retrospective

1. Schedule Consistently

  • •Same day/time after every sprint
  • •60-90 minutes for 2-week sprints
  • •Never cancel (sends message that improvement doesn't matter)

2. Prepare Data

  • •Sprint metrics (velocity, completed stories, bugs)
  • •Key events (releases, incidents, team changes)
  • •Previous retro action items and their status

3. Choose Format

  • •Vary formats to prevent staleness
  • •Match format to team mood/issues
  • •Have 3-4 formats in rotation

During the Retrospective

4. Facilitate Neutrally

  • •Scrum Master or rotating facilitator
  • •Facilitator participates but doesn't dominate
  • •Enforce timebox, manage energy
  • •Redirect blame to systems/processes

5. Ensure Equal Voice

  • •Use silent writing before discussion (prevents groupthink)
  • •Round-robin sharing (introverts need structure)
  • •"What haven't we heard yet?" prompt
  • •Notice who's silent, gently invite input

6. Drive to Action

  • •Specific, measurable experiments
  • •Clear owners and definition of done
  • •Maximum 1-3 actions (focus beats sprawl)
  • •"What will we try differently next sprint?"

7. Document Outcomes

  • •Capture action items in shared location
  • •Assign owners, due dates
  • •Review status at next retro

After the Retrospective

8. Share Publicly

  • •Post action items where visible (wiki, Slack, board)
  • •Optional: summarize themes for leadership (without names)
  • •Celebrate completed experiments from last retro

9. Follow Through

  • •Check in mid-sprint on action progress
  • •If experiments aren't happening, discuss why in next retro
  • •Adjust retrospective format if actions never get completed

Anti-Patterns

The Complaint Factory: Venting without generating actions

  • •Fix: Timebox complaints, enforce "For every problem, propose a solution"

Groundhog Day: Same issues surface every retro, no change

  • •Fix: Start retro by reviewing previous action items, ask "Why aren't we doing these?"

Manager in the Room: Team self-censors when boss attends

  • •Fix: Manager attends less often, or team agrees on ground rules for psychological safety

Action Item Graveyard: Long list of commitments, none completed

  • •Fix: Limit to 1-3 actions max, make them experiments ("try for one sprint") not mandates

The Positivity Police: Only "Glad" allowed, problems swept under rug

  • •Fix: Facilitator explicitly invites criticism, validates those who share issues

Blame Ping-Pong: Retro devolves into finger-pointing

  • •Fix: Re-read Prime Directive, redirect to systems: "What process would prevent this?"

Facilitator Monopoly: Same person always facilitates, it becomes performative

  • •Fix: Rotate facilitation among team members

Quality Indicators

High Signal:

  • •Team arrives with topics ready to discuss
  • •Difficult conversations happen naturally
  • •Actions from previous retro are mostly completed
  • •Mix of celebration and critical reflection
  • •Junior members speak as much as seniors
  • •Meta-improvements to retro process emerge organically

Low Signal:

  • •"Everything was fine" becomes default response
  • •Same few people dominate discussion
  • •Action items are vague ("communicate better")
  • •No follow-through on commitments
  • •Team views retro as obligation, not opportunity
  • •Topics are superficial, real issues never surface

Facilitator Techniques

Generating Participation

  • •Silent writing first: Prevents bandwagon effect
  • •Dot voting: Visual prioritization, everyone gets 3 votes
  • •Round-robin: Forces equal air time
  • •1-2-4-All: Individual → pairs → quads → whole group (builds confidence)

Deepening Insights

  • •Five Whys: Ask "why?" repeatedly to find root causes
  • •Fishbone diagram: Map contributing factors to an issue
  • •Force field analysis: Identify forces for/against a change
  • •Plus/Delta: What to keep (+) and what to change (Δ)

Keeping Energy

  • •Timeboxing: Use timer visibly, keep pace
  • •Stand-up retro: Physical standing keeps energy high (30 min max)
  • •Music/props: Unconventional elements break monotony
  • •Rotate formats: New structure every 3-4 sprints

Real-World Examples

Software Team - Post-Outage:

  • •Format: Timeline + Five Whys
  • •Data: 3-hour outage, customer complaints, postmortem written
  • •Insight: Monitoring didn't catch issue because we don't test alerting
  • •Action: Add monthly "chaos engineering" slot to sprint, test alerts fire correctly

Design Team - Velocity Drop:

  • •Format: Sailboat
  • •Anchor Identified: Too many stakeholder review cycles
  • •Action: Pilot "design office hours" where stakeholders can give feedback without formal meetings

Cross-Functional Team - Collaboration Breakdown:

  • •Format: Glad-Sad-Mad
  • •Mad: Engineers feel designs aren't technically feasible
  • •Action: Add 30-min "feasibility checkpoint" before designers finalize mockups

Related Frameworks

  • •Project Retrospectives (Norman Kerth): Original handbook, Prime Directive
  • •Agile Retrospectives (Esther Derby & Diana Larsen): Five-phase structure
  • •Blameless Postmortems: Similar for incidents (more structured root cause analysis)
  • •After-Action Reviews (US Army): Military version, similar intent
  • •Kaizen: Japanese continuous improvement philosophy (retros are one kaizen practice)

Scoring (45/50)

  • •Practitioner Weight (10/10): Core practice in agile, SRE, DevOps communities
  • •Clarity (9/10): Well-documented structure and formats
  • •Proven ROI (9/10): Strong link to team performance and morale
  • •Novelty (7/10): Codifies reflection into structured practice
  • •Applicability (10/10): Universal across teams, industries, contexts

Sources

  • •Norman Kerth: "Project Retrospectives: A Handbook for Team Reviews" (2001)
  • •Esther Derby & Diana Larsen: "Agile Retrospectives: Making Good Teams Great" (2006)
  • •Scrum Guide: Sprint Retrospective as required ceremony
  • •Retrospective Wiki: 100+ activity formats
  • •Industrial Logic: Retrospective facilitation guides