Retrospective, or Sprint Retrospective

The word retrospective comes from the Latin “retrospicere,” meaning “to look back.” In film, television, and literature, there’s a technique called a “flashback scene” — or analepsis — that connects different moments in time to develop a character or a context more deeply.

In that sense, the practice of the retrospective meeting makes a lot more sense to me, and it rises above the basic feeling of “we should improve.” An agile team is like an individual who builds a personality and a character. And the retrospective aims to develop exactly that character.

If the concept still feels abstract, I’d invite you to reflect on the role you play in each of the social and family groups you’re part of. In one group you might be the oldest, or the youngest, the funniest or the most serious, the most disciplined or the most disorganized. In that same sense, the team is a space where every member takes on a role and a position, one that has room to mature and grow stronger in service of the goal the group was formed around.

Retrospective Meetings

Retrospective meetings are, in essence, a space where the whole team reflects on past performance — the last day, the last presentation, or, in Scrum ’s case, the last Sprint.

The purpose of the reflection is a single one: to take clear action aimed at improving team spirit and performance.

Terms Associated With Retrospective Meetings

• Agile retrospective
• Sprint retrospective, or iteration retrospective. In Scrum specifically, the Sprint or iteration context tries to limit the reflection to the immediately prior period, or the one about to wrap up. In practice, though, I recommend centering the discussion on the prior period while leaving room to evaluate or compare the impact of decisions from other retrospectives. For example, evaluating the positive or negative impact of a decision or action plan from the retrospective right before it — or before that.
• Retro
• Heartbeat retrospective

A History of Retrospective Meetings

Please don’t think someone invented the practice of retrospection within the context of projects or agility. That said, this specific practice — which I’ll call the “agile retrospective” — has an origin we can trace as follows:

1997 — Iterations and continuous improvement

The book “Surviving Object-Oriented Projects ,” by Alistair Cockburn, hits the market. While the book doesn’t speak specifically to the practice, it lays the groundwork for iteration- and increment-based work. It discusses the importance of small teams (or subgroups), and the room iterative plans create for reflection. I’ll admit the book is fairly technical, and that focus extends to its treatment of reflection activities.

2001 — The Agile Manifesto

The Agile Manifesto is created, and several books on the agile software development process get published.

The “agile” movement is “officially” born. With the Agile Manifesto comes principle 12:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Manifesto

Several books also came out documenting the practice under different names, including:

• Reflection Workshop, from Alistair Cockburn’s book Agile Software Development.
• Project Retrospectives, by Norman L. Kerth.

Esther Derby and Diana Larsen also publish a book that speaks specifically to the practice as we know it today. In the book, they call it a “heartbeat retrospective.”

2006 — Agile Retrospectives Are Born

With the publication of the book Agile Retrospectives, Esther Derby and Diana Larsen’s book on the practice as we know it today becomes widely known — the one where they coined the term “heartbeat retrospective.”

Benefits of Retrospective Meetings

I could say a lot about the advantages and benefits of retrospective meetings. That said, I want to be clear that all these benefits depend directly on our own model of continuous improvement.

What good is a retrospective at the end of a project, if the project’s already wrapping up? What value can I actually capture within the project or with the team? The truth is, the practice of the retrospective meeting requires cadence — a rhythm, a regular repetition of certain events. Without cadence, the reflection exercise loses its greatest potential: transforming a team and the work it does.

The 5 key benefits of retrospective meetings are:

1. Retrospective meetings promote transparency

Giving the team — or multiple teams — the space and time to identify problems or challenges, propose solutions, and take ownership creates accountability and empowers teams. At the same time, it makes several management decisions transparent, and turns all of us into “owners” of the culture of the work itself.

Team members can discuss the team’s problems and situations while sharing their experiences and ideas on how to improve. This helps build trust and psychological safety.

2. Agile retrospectives promote collaboration and good communication

Retrospectives create a safe space where team or organization members can speak openly about their modus operandi. Offering this space regularly has a substantial, positive impact on collaboration between people. It builds trust and, when well guided, a culture of constructive criticism and teamwork.

It’s no accident that the 14th State Of Agile Report shows agile retrospectives are the second most widely used agile practice (81%), and that the boost in team morale is considered one of the five clearest benefits of adopting agile management models.

Running retrospectives frequently, combined with a governance model that listens and takes action, strengthens collaboration and good communication.

3. Team retrospectives promote respect for process

Let’s not lie: software developers — and, in general, professionals in fields close to software engineering and application delivery — aren’t exactly lovers of process. Or even of following rules just because.

When we actively participate in decisions, we commit to them. This promotes respect for the process and for the decisions we make as a team, even if they’re not decisions we would have made on our own.

This respect for process and for “good manners” helps drive faster adoption of models like Scrum, and even helps build team identity. Ultimately, it drives productivity gains and strengthens teamwork.

4. Agile Retrospectives are an early warning system

One of the most important benefits for high-risk environments is that these meetings create a model for risk management and quality assurance. A retrospective includes both a quantitative and a qualitative analysis of results that, done properly, creates an ideal space for risk management and assurance.

Retrospectives let the team assess what went well and what didn’t go so well, and, in that sense, tackle the source of certain risks head-on — and, of course, improve the quality that comes from a mature process.

5. Retrospectives promote technical excellence

We’ve talked about process and team spirit. But retrospectives are also a space to rethink the technical outcome. And I don’t mean the product’s features — I mean how the outcome was built, and what improvements — refactors — we can consider to guarantee a better result.

In the end, technical excellence is the result of reviewing and assessing the “forms” and “models” we’ve used to solve a given process or specific need. Retrospectives let the team, in a safe space, discuss the things they’re not proud of — technically speaking — and that could become a source of problems down the road.

The Structure of an Agile Retrospective Meeting

What does a meeting like this look like? What activities can we run? Here’s how, along with a few exercises you can use to get the most out of this time.

A retrospective meeting can be structured in 5 — sometimes 6 — steps, as follows:

Moment 1: Preparation, opening, or welcome

During this time, the moderator or facilitator sets the tone for the meeting. For example, if we’re coming off a good cycle with good results, it’s a time to celebrate without forgetting there’s always room to improve. But if we’re coming off a cycle with bad results or broken promises, it’s time to reflect on our mistakes, or even on the things that once made us assume everything was going to be fine. The tone will define the rest of the meeting. But remember — we’re not here to point fingers! We’re a team. We’re here to look for solutions and opportunities to improve.

Moment 2: Metrics and objective assessment

Once the context is set, it’s time to look at reality. Data is our best ally for keeping the discussion focused on facts and results, rather than on people and subjective opinions. In Scaled Agile, this part of the meeting is called quantitative analysis. If you’re using other practices like velocity or defect density, this is a good moment to present that data — and its history.

Moment 3: Discussing and understanding what happened

Now it’s time to discuss. What happened? How did we perceive the cycle? Was it a good one? Was it a bad one? What went wrong in our assumptions and plans? What worked? For that last question, I’d save the “why” for last. All of us need to build a narrative to justify results. If you jump to that question from the start, everyone will try to justify their answer with a story that’s often subjective and not necessarily tied to the data [ref]In the book “The Code of the Extraordinary Mind ,” Vishen Lakhiani refers to our brain as a “meaning making machine.” As a facilitator, I’d recommend mitigating the influence of this very human tendency.[/ref].

Moment 4: Decisions to improve the team and its productivity

With the discussion comes understanding — or at least a shared view within the group of what happened — and this is the perfect opportunity to weigh in on opportunities for improvement and the specific actions we can take as a team to get better.

And let me leave you with one recommendation for moment 4: don’t let the team commit to too many decisions. If a team commits to too many changes, it may become impossible to later determine which actions actually made the difference.

Pick two or three decisions on how to improve during the next cycle.

Moment 5: Wrap-up

You can probably imagine that some meetings get pretty intense. It’s time to lower the temperature and bring the team back to the context of continuous improvement. Always remind the team that nothing is personal, and that every piece of criticism stays within the team, kept private and focused on improvement.

Bonus moment: Reviewing past results

It’s often smart to remind the team of decisions from earlier retrospectives. That way, the team builds a stronger understanding and awareness of the impact of its own improvement decisions. Did the decisions from the immediately prior iteration actually work? Did they contribute to productivity the way we expected, or not?

Practical Tools for a Good Agile Retrospective

There are, of course, hundreds of practices and exercises we can run for each moment of the meeting. Here’s a list of the three I like best — and that have given me the best results with my teams.

1. ESVP

For the preparation stage, I like running an activity known as ESVP — Explorer, Shopper, Vacationer, Prisoner. The goal is for each attendee to assess their own disposition and perspective going into the meeting. These “positions” are:

1. Explorer: Someone ready to learn. They have a spirit oriented toward personal and team growth.
2. Shopper: Similar to walking into a store looking for something specific. You’re not willing to go down every aisle looking at “whatever you find.” You don’t see everything as useful or necessary. As a shopper, you evaluate what you like and what you’ll take with you.
3. Vacationer: When you’re in this position, you’re really escaping other responsibilities. That means the retrospective is a break from other things. So your intention to collaborate or make an effort is practically zero.
4. Prisoner: I’m not sure this position needs much explanation. But if the vacationer is escaping other responsibilities, the prisoner couldn’t escape and is forced to participate.

Worth noting: this technique is anonymous.

2. Standard Metrics

From the very start of working with a team, I like to set up a group of metrics and indicators that will later let us improve. It’s not for nothing that the saying goes “what isn’t measured can’t be improved.” With that in mind, I’ve defined a basic set of metrics — and an entire article on the topic.

I like to always chart these metrics historically — that is, as a sequence of values over time. I’d invite you to read my article on agile metrics.

3. Starfish

This is, by a wide margin, my favorite. Not only is it a powerful tool — it’s also profoundly simple. The goal is to invite team members — or the participants in any given activity — to share their ideas and feedback about that activity. To do it, they attach their idea to one of the following categories:

1. Keep: Something they liked and feel added value to the activity. Something they think should be kept in future activities.
2. Stop: On the flip side, ideas or comments left in this category represent things people didn’t like, or that should be dropped because they don’t add value to the activity.
3. Start: This category covers things people would like to start doing, or that were missing from the activity.
4. Less: Tools, activities, or techniques that were maybe used or done too much. For example: “fewer status meetings” or “fewer pairing sessions” could be examples.
5. More: The opposite of Less — this category means people want more of something, of an activity or attitude, or more of a given technique. It means going deeper or doing more of something.
6. Kudos: A category for highlighting someone’s work, or congratulating someone or something. It’s vital to keep in mind that, beyond the difficulties inherent to the work, there’s always room to recognize the effort of the team, the company, or a specific person.

Other Valuable Resources for Running Retrospectives

There are, of course, countless tools for running good retrospectives and staying focused on what matters. Here’s a list of useful tools and sites with examples of other activities you can run.

• Tasty Cupcakes — maybe not the best name for a website, but it’s a community that grew out of a presentation in Toronto in 2008 on agility.
• Fun Retrospectives
• Easy Retro

Common Mistakes When Implementing Agile Retrospectives

To wrap up, here are some of the most common mistakes and problems that tend to come up during retrospective meetings.

1. Forgetting the purpose of the meeting. The goal is to improve, and to do that, we need to discuss the deep issues, not just the surface-level symptoms. That’s why, within the meeting structure, it’s smart to set the objective during the “preparation” moment.
2. Making too many decisions. Decisions or action plans aren’t bad. But too many of them can lead to paralysis, or even chaos. Changes and improvement actions should be introduced gradually, to make sure the team moves through its own growth process instead of trying to take quantum leaps.
3. Not having the tools to drive discussion. This is a typical mistake for inexperienced facilitators — showing up to the meeting without enough preparation or clarity about which tools to use. Without tools, the discussion can end up thin or, worse, disorganized. A good facilitator never assumes success for any event or activity, and prepares to actively “carry” the team.

Share Your Experience

I’d love to hear about your experience with agile retrospective meetings. I’d love to know what’s worked for you and what hasn’t. For the best — or funniest — comments, I promise to send a digital gift.

Don’t stop running retrospectives, and be just as committed to them as you are to a planning session or a backlog refinement session. The success of truly agile teams comes from the fact that they never stop, and they always want to improve.