Most teams that do retrospectives do not improve from them. They meet. They list things. They write action items on a digital whiteboard. They close the meeting. Nothing changes. Two weeks later, they do it again.
This is not because retrospectives are a bad idea. It is because running a retrospective that produces actual change is harder than running a meeting that feels productive. The difference between the two is significant and specific.
This article explains what retrospectives are for, the major formats, the psychological conditions required for them to work, the most common failure modes, how to make action items stick, and how to run them effectively with remote teams.
What Retrospectives Are For
The agile retrospective (often shortened to "retro") is a structured team event in which the team examines its own working practices -- not the product, not the deliverables, but the process of how the team works together -- and identifies specific improvements.
In Scrum, retrospectives are one of the five core ceremonies (alongside sprint planning, daily standup, sprint review, and sprint retrospective). The Scrum Guide specifies the retrospective is held at the end of each sprint and focused on three questions: what went well, what did not go well, and what changes will the team commit to?
The underlying theory is simple: continuous improvement requires regular reflection. Teams that do not periodically examine how they work tend to accumulate small inefficiencies, unaddressed interpersonal frictions, and habitual practices that made sense at one point but no longer do. The retrospective is the scheduled space for surfacing and addressing these.
But the theory only works if the meeting produces actual behavior change. A retrospective that surfaces problems without changing anything is not just ineffective -- it is actively corrosive to team morale, because it demonstrates that reflection does not lead to improvement, which makes future reflection feel pointless.
"The retrospective is the most important ceremony in Scrum -- and the one most often done badly. When it works, the team gets better every sprint. When it doesn't, it's just a meeting about a meeting." -- Lyssa Adkins, Coaching Agile Teams (2010)
When to Run a Retrospective
Retrospectives are typically held:
- At the end of each sprint (standard Scrum cadence -- weekly, biweekly, or monthly depending on sprint length)
- At the end of a project or phase (milestone retrospective)
- After a significant incident or failure (post-mortem or blameless retrospective)
- When a team is newly formed (early retrospective to establish norms)
- When team performance is clearly suffering (emergency retrospective)
The sprint retrospective is the recurring operational form. The post-mortem is the incident-specific form. Both serve the same basic purpose -- learning from experience -- but differ in scope and emotional intensity.
The Core Retrospective Formats
Format choice matters. Different formats surface different information, work better at different levels of team trust, and suit different specific objectives. The best facilitators choose formats deliberately rather than defaulting to the same template every time.
Start / Stop / Continue
The most commonly used format. The team generates items in three categories:
- Start: Things the team is not currently doing but should begin
- Stop: Things the team is doing that are not serving it well
- Continue: Things that are working and should be preserved
Best for: Teams newer to retrospectives, situations where a structured template helps participation, when you want broad coverage of process issues.
Limitation: The three-bucket structure can feel generic and produce generic responses. It does not naturally prompt deeper analysis of why things are happening.
The 4Ls
Developed by Mary Gorman and Ellen Gottesdiener, the 4Ls asks team members to sort reflections into four categories:
- Liked: Things the team appreciated
- Learned: Things the team discovered or came to understand
- Lacked: Things the team needed but did not have
- Longed For: Things the team wishes it had had
Best for: Teams that need to surface learning and aspirations, not just problems. The "Longed For" category often reveals systemic issues (support, tooling, clarity) that "Stop/Start" formats miss.
The Sailboat (or Speed Boat)
A visual metaphor format:
- Wind at your back (or sails): Things that helped the team move forward
- Anchors: Things that slowed the team down or held it back
- Rocks ahead (in some versions): Risks or upcoming obstacles
- Sunny island (destination): Goals or aspirations
Best for: Teams that respond well to visual metaphors, mixed groups including less technical participants, when you want to make the discussion feel less clinical. The metaphor can lower emotional temperature around difficult topics.
Mad / Sad / Glad
Participants categorize experiences into three emotional states:
- Mad: Things that frustrated or angered them
- Sad: Things that disappointed them or that they will miss
- Glad: Things they appreciated or that went well
Best for: Surfacing emotional undercurrents that more analytical formats miss. Useful after difficult sprints, following a project cancellation, or with teams that have experienced significant stress. Requires reasonable psychological safety.
Five Whys (Root Cause Analysis)
Rather than collecting a broad inventory of issues, the Five Whys focuses on one problem and drills into its root cause. The facilitator asks "why?" iteratively (typically five times) until arriving at a systemic cause rather than a surface symptom.
Example:
- Problem: We shipped three bugs that should have been caught in QA.
- Why? Because the QA review was rushed.
- Why? Because it happened the day before the sprint deadline.
- Why? Because testing is always scoped last and cut first when time is short.
- Why? Because there is no explicit time allocation for testing in sprint planning.
- Why? Because testing is considered implicit rather than explicit work.
- Root cause: Testing is not treated as a first-class sprint item in planning.
Best for: Recurring problems that keep appearing without resolution. Teams that are ready to move from symptom identification to genuine root cause analysis.
The Lean Coffee Retrospective
A participant-driven format where team members propose topics, vote on priorities, and discuss in order of vote count with time-boxing. No predetermined agenda.
Best for: Teams with high psychological safety who have clear issues they want to discuss. Empowers participants; reduces facilitator control. Requires maturity to execute well.
| Format | Structure | Best use case | Psychological safety required |
|---|---|---|---|
| Start/Stop/Continue | Three buckets | General process review | Moderate |
| 4Ls | Four categories | Learning-oriented teams | Moderate |
| Sailboat | Visual metaphor | Mixed or newer teams | Moderate |
| Mad/Sad/Glad | Emotional | Post-difficulty processing | High |
| Five Whys | Root cause drilling | Recurring problems | High |
| Lean Coffee | Participant-driven | Self-directed teams | High |
The Non-Negotiable: Psychological Safety
No retrospective format overcomes insufficient psychological safety. This is the most important factor in retrospective effectiveness, and the one most often treated as a given when it is not.
Psychological safety -- the team climate in which people believe they can speak up, share concerns, and identify problems without fear of punishment, ridicule, or marginalization -- was documented by Amy Edmondson at Harvard Business School as the primary predictor of team learning behavior. Her 1999 study found that psychologically safe teams surfaced errors and reported more problems -- not because they made more errors, but because they reported them more honestly. Teams without psychological safety appeared to perform well on narrow measures while hiding the information that would have made them genuinely better.
In a retrospective, the most valuable information is also the most risky to raise: the interpersonal conflict everyone is tiptoeing around, the manager behavior that is slowing the team down, the process change that should happen but implicates someone with authority. In low-psychological-safety environments, these topics do not surface. The retrospective produces safe commentary on safe topics and changes nothing that matters.
Signs of Low Psychological Safety in Retrospectives
- The same themes appear every sprint without resolution
- Participation is uneven, with quiet members and a few dominant voices
- Feedback is abstract rather than specific ("communication could be better" instead of "we need to decide who communicates with the stakeholder before sending messages")
- No one ever raises concerns about the manager or team lead
- Action items are consistently not completed, without anyone acknowledging this
Building Psychological Safety
Safety is built over time through consistent behavior, not through a single exercise or icebreaker. Contributing factors include:
- Facilitators modeling vulnerability: Sharing their own mistakes or uncertainties
- No-blame norms explicitly stated and enforced: Distinguishing between systemic problems and individual failures
- Managers responding non-defensively when their own behavior is discussed
- Demonstrated follow-through: Teams that see action items acted on trust the process more, which increases willingness to raise real issues
- Regular retrospectives: Frequency builds familiarity and trust over time
Common Failure Modes
The Action Item Graveyard
Teams generate five, eight, or ten action items in a retrospective and review none of them at the next one. New items are added. The list grows. Nothing is ever implemented. The team learns that retrospectives are where good ideas go to die.
Fix: Limit action items to two or three per retrospective. Start every retrospective by reviewing progress on the previous items before generating new ones. If previous items are not done, understand why before adding more.
The Sanitized Session
In environments with low psychological safety, retrospectives produce inoffensive observations that do not touch the real issues. "We could improve our documentation" is a safe statement. "The product manager is providing requirements too late for us to scope them properly" is the same problem, stated usefully.
Fix: This requires psychological safety work, not format adjustment. Consider anonymous input collection (sticky notes, digital tools like EasyRetro or Parabol) as a bridge while safety is being built.
Facilitator Capture
When the manager or team lead facilitates their own team's retrospective, the team often produces feedback that is acceptable to that person rather than feedback that is accurate. The implicit power dynamic constrains honesty.
Fix: Rotate facilitation. Use external facilitators for teams where manager-as-facilitator dynamics are clearly distorting the output. Consider separating the facilitator role from the manager role explicitly.
The Complaint Session
Retrospectives without forward-looking structure can devolve into venting without resolution -- a list of frustrations with no analysis of causes or commitment to specific changes.
Fix: Structure formats to require identification of potential actions, not just problems. Ensure the "what should we do differently" portion is as structured as the "what went wrong" portion.
Missing the "What Went Well"
Teams in difficult periods, under pressure, or with high negativity bias may spend the entire retrospective on problems and never identify what is working and should be protected. This produces a distorted picture and erodes morale.
Fix: Enforce time allocation for positive identification. Start with "what went well" to establish a balanced tone before moving to problems.
Making Action Items Stick
The single most common reason retrospectives fail to produce improvement is the action item problem. Here is what works:
Limit to 2-3 items per retrospective. A short list of items with genuine follow-through beats a long list of aspirations no one acts on.
Assign a named owner, not "the team." "The team will document our deployment process" assigns responsibility to no one. "Alex will write the first draft of the deployment runbook by next Friday" assigns it to a specific person with a deadline.
Make items specific and behavioral. "Improve communication" is not an action item. "Hold a 10-minute alignment meeting every Tuesday before the sprint review" is. The test: can you tell whether the action was taken?
Review explicitly at the start of the next retrospective. Before generating new items, spend 5-10 minutes on the previous cycle's items. Were they done? If not, why not? Was the item unclear? Did priorities change? Did the owner not have capacity? The answers to these questions are as valuable as any new insight the current retrospective might generate.
Track somewhere visible. Action items that live only in retrospective notes get forgotten. A team task board, a running document the team regularly consults, or a standing agenda item in weekly standups keeps items visible.
Remote Retrospectives
Distributed teams face specific challenges with retrospectives: lower social cue richness, more difficult facilitation, greater risk of participation inequality, and the awkwardness of silences on video calls.
Tools
Several tools are designed specifically for remote retrospectives:
- Parabol: Free, open-source, integrates with Jira
- EasyRetro (formerly FunRetro): Simple, visual, widely used
- Miro / MURAL: General whiteboard tools that work well for visual retrospective formats
- Metro Retro: Specifically retrospective-focused with good real-time collaboration
- Reetro: Free option with good format variety
Adapting for Remote
Use asynchronous input collection. Ask team members to add sticky notes before the synchronous meeting. This equalizes participation (introverts contribute as much as extroverts), reduces groupthink (people form independent views before seeing others'), and makes the synchronous time more productive.
Protect against silence penalties. Video call silence is more uncomfortable than in-person silence. Build in explicit quiet time for individual thinking; do not rush to fill pauses.
Rotate facilitation deliberately. In remote settings, a dominant facilitator has more control over who speaks and how long topics run. Rotation distributes this influence.
Keep remote retros shorter than in-person ones. The fatigue of video calls reduces productive engagement time. A tight 45-60 minute remote retrospective often produces better output than a sprawling 90-minute one.
Time zone awareness for global teams. Teams spanning multiple time zones should rotate meeting times rather than consistently disadvantaging participants in earlier or later zones.
Running the Retrospective: A Session Structure
A functional sprint retrospective for a team of 5-10 people can follow this structure:
Check-in (5 minutes): A brief, non-work question to shift from task mode to reflection mode. "What is one word that describes your experience of the last sprint?" A mood thermometer. Something that activates presence.
Review previous action items (5-10 minutes): Status of last cycle's items. What was done? What was not, and why?
Data gathering (15-20 minutes): The core format activity. Participants add input individually (silently) before sharing and discussing.
Insight generation (10 minutes): Identifying themes, patterns, root causes. Moving from observations to understanding.
Action item generation (10 minutes): Translating insights into specific, owned, time-bound commitments. Strict quantity limits apply.
Close (5 minutes): Brief check-out. "What is one word for how you are leaving this meeting?" Rate the retrospective itself (it is a practice that benefits from its own feedback loop).
The total: 50-60 minutes for a sprint retrospective. Post-mortems and milestone retrospectives may run longer, but most sprint retrospectives should not.
Retrospectives as Organizational Learning
The deeper purpose of retrospectives extends beyond fixing individual sprints. Teams that run effective retrospectives develop a learning culture -- a shared orientation toward reflection, experimentation, and adjustment. This is harder to measure than a specific process improvement but more valuable.
Peter Senge's concept of the learning organization in The Fifth Discipline describes organizations that continuously expand their capacity to create results they truly desire. The retrospective, run well and consistently, is one of the few organizational practices that actually operationalizes this aspiration at the team level.
The retrospective is not a ceremony. It is a discipline. Run it badly -- as a box to check, a complaint session, a list-generating exercise without follow-through -- and it produces nothing. Run it well -- with psychological safety, honest input, root cause thinking, and rigorous action item ownership -- and it is one of the most reliable tools for sustained team improvement available.
Frequently Asked Questions
What is a retrospective in agile?
An agile retrospective is a structured team meeting held at the end of a sprint, project phase, or defined time period, in which the team reflects on how it worked together -- what went well, what did not, and what specific changes it will make. Originating in Scrum methodology, the retrospective is one of the five Scrum ceremonies and is designed to drive continuous improvement of team process, communication, and collaboration rather than reviewing the product itself.
What are the most common retrospective formats?
The most widely used formats include Start/Stop/Continue (what should we start doing, stop doing, and continue doing), the 4Ls (Liked, Learned, Lacked, Longed For), the Sailboat (wind at your back are things helping you, anchors are things holding you back), Mad/Sad/Glad (sorting feelings into three emotional categories), and the Five Whys (drilling down to root causes). Format choice depends on team maturity, the specific issues being addressed, and how much psychological safety exists in the team.
Why do most retrospectives fail to produce real change?
The most common failure is generating action items without ownership, deadlines, or follow-up. Teams list improvements enthusiastically, leave the meeting with a long list, and revisit none of it at the next retrospective. Other failure modes include insufficient psychological safety (people say what they think is safe rather than what is true), facilitator dominance (the meeting becomes a top-down feedback session rather than genuine team reflection), and focusing only on negatives (missing what is working and should be preserved or amplified).
Why is psychological safety essential for retrospectives?
Psychological safety -- the belief that one can speak up without fear of punishment or humiliation -- is a prerequisite for retrospectives to surface real problems. Without it, teams perform retrospectives: they say things that are socially acceptable rather than diagnostically useful. The most valuable information in a retrospective (the interpersonal conflict no one is addressing, the process that slows everyone down, the decision that was clearly wrong) is also the most risky to raise. Teams with low psychological safety produce sanitized retrospectives that change nothing.
How should retrospective action items be structured to ensure follow-through?
Effective retrospective action items should be specific (a concrete behavior or change, not a vague aspiration), assigned to a named person (not 'the team'), given a deadline or target date, limited in number (two or three maximum per retrospective), and reviewed explicitly at the start of the next retrospective before new items are generated. The SMART framework (Specific, Measurable, Achievable, Relevant, Time-bound) is a useful check. Teams that carry forward incomplete items before adding new ones create accountability that teams with unlimited lists never achieve.