Why Most Retrospectives Fail

Ask any Scrum Master what they dread most, and retrospectives will appear near the top of the list — not because the concept is broken, but because execution usually is. Teams gather, answer the same three questions ("What went well? What could be better? What will we commit to?"), write four action items on a sticky note, and then quietly abandon them before the next sprint begins.

A 2022 survey by Scrum Alliance found that 45% of Agile practitioners felt their retrospectives were "not effective" or only "somewhat effective." The most commonly cited reasons: the format feels repetitive, dominant voices hijack the conversation, and action items are vague enough to slip away unnoticed.

“The retrospective is the most underutilised ceremony in Agile. Done well, it is the engine of continuous improvement. Done poorly, it is theatre.”

— Esther Derby & Diana Larsen, Agile Retrospectives (2006)

The Sailboat Retrospective addresses the root cause of most retro failures: abstract questions produce abstract answers. A metaphor forces specificity. It is much harder to write "communication issues" on an Anchor card without someone asking "which communication? About what? Between who?" — and that follow-up question is where the real insight lives.

From Postmortems to Sprint Retros: A 60-Year History

The critical shift from aerospace postmortems to software retrospectives happened in the 1990s through two distinct threads. The first was W. Edwards Deming's Plan-Do-Check-Act (PDCA) cycle, originally developed for manufacturing quality control in the 1950s and widely adopted in Japan. Deming's core insight — that improvement must be systematic and continuous, not reactive — became foundational to Agile thinking.

The second thread was Alistair Cockburn's 1997 work "Surviving Object-Oriented Projects," which described "reflection workshops" held during projects rather than only at their end. This was a radical departure: instead of learning only after the damage was done, teams could adjust mid-flight.

• 1950s: Deming's PDCA cycle formalizes continuous improvement in manufacturing
• 1960s–70s: NASA and military postmortem culture becomes standard practice
• 1997: Alistair Cockburn describes "reflection workshops" mid-project in software teams
• 2001: Agile Manifesto enshrines retrospectives: "At regular intervals, the team reflects on how to become more effective"
• 2001: Norman L. Kerth publishes "Project Retrospectives: A Handbook for Team Reviews"
• 2006: Derby & Larsen publish "Agile Retrospectives: Making Good Teams Great" — the definitive practitioner guide
• 2000s–2010s: Visual metaphor formats (Sailboat, Starfish, 4Ls) emerge from facilitation practice

The Sailboat metaphor itself is most commonly attributed to Luke Hohmann, who included it in "Innovation Games" (2006) as one of a suite of product strategy activities. It was subsequently adapted by the Agile community as a retrospective format, where its four zones map elegantly onto sprint dynamics. The metaphor resonates because it captures both direction and forces — goals are not just tasks, they are destinations; blockers are not just problems, they are weight dragging the hull.

The Four Zones Explained

Each zone of the sailboat has a specific function. Understanding what belongs where — and what does not — is the key to facilitating a focused session.

🏝️ Island — The Goal

The island represents where the team is trying to go: the sprint goal, the quarter objective, or the north star of the product. In many retrospectives this zone is skipped entirely ("everyone knows the goal"), but that assumption is almost always wrong. Research on team alignment consistently shows that individuals' mental models of shared goals diverge significantly — often within the same two-week sprint.

Writing the island explicitly at the start of the retro aligns the team before they evaluate their performance. It also prevents a common failure mode: teams discussing tactics (anchor and wind items) when they disagree, unconsciously, about strategy (the island).

💨 Wind — What Helps Us

Wind notes capture what is working — the practices, tools, behaviors, or conditions that are accelerating the team. This zone is often under-populated because teams treat retrospectives as problem-solving sessions. But identifying and naming what is working is just as strategically important as identifying blockers. You cannot replicate success if you have not understood what caused it.

A well-run Wind zone surfaces the practices worth protecting during organizational change, the team behaviors worth scaling to other teams, and the quiet contributors whose positive impact is often invisible in daily work.

⚓ Anchor — What Slows Us Down

Anchor notes are the retrospective's most familiar territory — blockers, inefficiencies, recurring friction, and process overhead. The metaphor is deliberately physical: an anchor is not just inconvenient, it prevents forward motion entirely. This framing encourages teams to prioritize anchor items by severity, not by volume.

The most important facilitation principle for Anchor notes: they must describe the drag, not the person. "Unclear requirements from product" is an anchor. "Our PM doesn't listen" is a blame note that will shut down psychological safety immediately. The Sailboat format's systemic framing — forces acting on a vessel, not people failing — naturally discourages blame.

🪨 Rocks — Hidden Risks

The Rocks zone is what separates the Sailboat from simpler plus/delta formats. Rocks are not current problems — they are hazards ahead. Technical debt that will become unmanageable in two sprints. A key dependency with no documented runbook. A team member who is the sole owner of a critical service and is showing signs of burnout.

Because rocks are hypothetical, they tend to get deprioritized in retros that focus only on "what happened." The Sailboat format gives risks a dedicated, equal-weight zone — ensuring that the team looks forward as well as backward.

The Research Case for Visual Metaphor Formats

The psychological mechanism is well-established: concrete metaphors reduce the cognitive load required to categorize ambiguous experiences. When a team member is deciding where to place a note about "the deployment pipeline being unreliable," the abstract question "is this positive or negative?" is harder to answer than "does this slow the boat (anchor) or could it sink us if it gets worse (rock)?" The metaphor provides a decision frame that speeds categorization and improves specificity.

Amy Edmondson's seminal research on psychological safety (Harvard, 1999) established that teams speak up more freely when the framing is systemic rather than personal. The Sailboat format operationalizes this insight: by naming problems as anchors (things dragging the boat) rather than complaints (things that annoy me), it shifts the frame from interpersonal to systemic — making honest participation safer.

The dot voting mechanic reinforces this further. Anonymous upvoting allows quieter team members to signal agreement with concerns they might not have raised themselves, creating a more representative picture of team health than vocal-majority formats produce.

How to Run a Sailboat Retrospective: Step by Step

The following process is designed for a 60-minute remote session with 4–12 participants. Adjust timing for larger groups.

• Step 1 — Set the Island (5 min): Before adding any other notes, ask the team to confirm the sprint goal in writing. If people disagree, surface it now. This alignment step prevents the rest of the retro from being evaluated against different standards.
• Step 2 — Silent note generation (10 min): Each person adds notes to Wind, Anchor, and Rocks independently, without discussion. Silence prevents anchoring — the first person to speak should not determine what others write.
• Step 3 — Share and cluster (10 min): Go around the board zone by zone. The author reads each note aloud (one sentence), and similar notes are grouped. No discussion yet — just clustering.
• Step 4 — Dot voting (5 min): Each participant gets 3–5 votes to distribute across any notes in any zone. They may put multiple votes on a single note. This surfaces team-wide priorities, not just individual concerns.
• Step 5 — Discussion (25 min): Work through the top-voted items in each zone, starting with Anchors (most actionable) and Rocks (highest risk). For each item, agree on a specific, time-bound action with a named owner.
• Step 6 — Close (5 min): Read back all action items. Ask: "Is there anything important that did not get a note today?" This catches the things people held back.

Common Mistakes and How to Avoid Them

• Skipping the Island: Teams assume everyone knows the goal. They usually do not. Always write it explicitly at the start.
• Only filling Anchors: Retrospectives are not complaint sessions. If Wind notes are sparse, the facilitator should ask directly: "What has been making our work easier lately?"
• Vague action items: "Improve communication" is not actionable. Push for: who does what, by when, measurable how.
• No follow-up from previous retros: Start each session by reviewing last retro's action items. Teams that never revisit actions learn that action items are optional — and stop generating honest ones.
• Dominant voice problem: If one person fills the board before others have started, use a strict silent generation phase. No speaking until the timer ends.
• Over-long sessions: 60–75 minutes is optimal. Beyond 90 minutes, energy drops and the last items get rushed. If you have too much to cover, that is itself a Rock worth noting.

Variations: When to Use a Different Format

The Sailboat is highly effective for sprint-level retrospectives and for teams in a stable working state. There are situations where a different format serves better:

• New team (< 3 sprints): Use Start/Stop/Continue instead. Simpler zones reduce cognitive overhead when the team is still establishing norms.
• Post-incident retrospective: Use Five Whys or a blameless postmortem template. The Sailboat's future orientation is less suited to deep-diving a specific incident.
• Team in significant conflict: Use a facilitated 1:1 structure first to surface interpersonal issues before bringing everyone to a shared board.
• Quarterly or release retrospective: The Sailboat scales well to longer time horizons. Consider adding a fifth zone — "Crew" (people and relationships) — for longer-cycle reviews.
• Very large groups (> 15): Run the Sailboat in sub-teams of 5–7, then merge the top-voted notes from each group into a single shared board for priority discussion.

The best retrospective format is the one your team will engage with honestly. If the Sailboat becomes stale after 10 sprints, rotate to a different metaphor. The format is a vehicle for the conversation — not the goal itself.

Measuring Whether Your Retros Are Working

Most teams have no idea whether their retrospectives are actually improving anything. These four signals will tell you:

• Action item completion rate: Track what percentage of retro action items are completed before the next retro. Below 50% is a red flag — either items are too vague, unowned, or the team does not believe they matter.
• Anchor recurrence rate: If the same anchor appears three sprints in a row, the action items it generated were ineffective. This is the single clearest signal of a broken retro process.
• Participation breadth: Count how many people contributed notes vs. how many attended. A ratio below 70% indicates psychological safety issues or dominant-voice problems.
• Team-reported retro value: Once a quarter, ask anonymously: "How much value did our retrospectives provide this quarter?" (1–5 scale). Trending downward is an early warning.