If you can only have one meeting: make it an Agile Retrospective (and don’t screw it up).
20/09/24

If you can only do one Agile event: make it a retrospective.

I have said this sentence hundreds of times. For me, the most important event if you want to help a team improve is this: Agile retrospective.

Planning, daily, stand-up, … all the events proposed by Scrum can be very useful if we do them well, but before we go crazy introducing new meetings to the team:

Why don’t we do a retrospective to see if it makes sense for the rest of the events?

 

Origin Sprint retrospective

Retrospectives do NOT originate from the Agile Manifesto!

In classic project management there were meetings called “lessons learnt”. These meetings are held at the end of the projects and serve to take stock of how they have gone, identify strengths and areas of improvement for the execution of the following projects.

These meetings are very useful, but there is a but and that is that most of the times they were held with the next project started and some of the improvement actions could not be tested because we were already too advanced in a certain phase of the project.

The first time, where I hear the words “sprint retrospective” is in the Scrum guide where it is defined as:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with respect to people, interactions, processes, tools, and its Completion Definition. The elements inspected usually vary by scope of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team analyzes what went well during the Sprint, what problems were encountered, and how those problems were (or were not) resolved.

The Scrum Team identifies the most useful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They can even be added to the Sprint Backlog for the next Sprint.

The Sprint Retrospective concludes the Sprint. It is limited to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter in duration.

But remember, the Scrum guide is a guide not a dogma, so retrospectives may vary in time and form.

 

Purpose retrospective

This is the main thing to keep in mind:

why do we do the retrospective?

The Retrospective is the main continuous improvement event described within Scrum.

Although if you don’t work with Scrum the Retrospective cannot be missing in your team events.

Going back to the purpose, the agile retrospective aims for the team to improve: improve their efficiency, collaboration, value delivery, or whatever it is they need to improve.

 

Retrospective or Agile Retrospective or Sprint Retrospective

Is there a difference? Is it the same? Yes but No

I mean, in essence there should be no difference, but then why do we add Agile? Well, not for me, the fact of calling it Agile speaks more about the philosophy of the retrospective than about the retrospective itself. We want this event to be collaborative, everyone, ALL, attendees to participate freely in an environment of trust and that all their opinions are heard and considered equally.

And why?

Because it would not be the first time that in a retro (a.k.a. retrospective) comes a manager or leader or PO or Scrum master and tells the team a list of what they do wrong (yes, if he tells them they do it wrong) and the solutions to implement. And chim pum pum!

In my experience, this is NOT good for anything! And it is not Agile!

The idea of the sprint retrospective is simply in the case where the team works according to the Scrum framework and at the end of the iteration an “Agile retrospective” is conducted.

The 3 questions

There was a time, some of you may not remember because you are very young, when it was said that in the retrospective you had to answer 3 questions:

  • what have we done right?
  • What can be improved?
  • What actions will we take to improve?

Obviously these questions could be very useful if the purpose is clear, but they were removed from the Scrum guide because there was a clear case of Cargo Cult.

If you don’t know what Cargo Cult is and how it manifests itself in the Agile Retrospective, watch the video:

Retrospective Template

There are very good books on retrospectives that I suggest you read, but if you don’t have time and want the “recipe” I will tell you the five phases of the retrospective:

  1. Set the Stage: This initial phase focuses on creating a safe and comfortable environment for all participants. The goal is to make sure everyone is ready to participate openly and honestly. It may include a brief icebreaker activity or check-in to connect the team and focus them on the session.
  2. Gather Data: In this phase, information is gathered about what happened during the period under review. This may include facts, metrics, important events, and perceptions of team members. Common tools include timelines, lists of “what went well” and “what didn’t go so well,” and quantitative data analysis if available.
  3. Generate Insights: Once the data is available, the team digs deeper to identify patterns, root causes, and opportunities for improvement. Here they seek to understand not only what happened, but why it happened. Techniques such as the “5 whys” or fishbone diagrams can be useful.
  4. Decide What to Do: This phase focuses on turning insights into concrete actions. The team prioritizes the ideas and selects the actions to be implemented in the next cycle. The goal is to define clear, specific and achievable actions, with assigned responsible parties to ensure follow-up.
  5. Close the Retrospective: In this final phase, close the retrospective with a reflection on the session itself, to improve future retrospectives, and acknowledge the team’s efforts. It may include a quick evaluation of the retrospective (what worked well? what could be improved?) and a positive closing, such as a round of thank yous.

These phases help structure the retrospective to be effective and contribute to the continued growth of the team.

 

How to facilitate a retrospective

The key to facilitate is to follow the previous phases without being noticed, that’s all there is to it.

There are 3 things to keep in mind:

  • Control the times: people like to talk and be heard, and in a retro we have a lot of audience.
  • Everyone participates sincerely: watch out for those who are silent and say yes to everything, possibly you do not have a convinced person but one who does not care about what happens there.
  • Not only the Scrum Master speaks: the retro is your star event and you make it your moment. Sometimes because you like the setting, and sometimes, most of the time, because the rest of the team doesn’t even talk if you pay them.
  • Do not become a place to confess or to tell of your sorrows and hardships.

If you keep this in mind, you are likely to end up with a successful facilitation.

 

#NoRetrospective

This may be the first time you’ve heard this term, but it dates back to 2019 or earlier!

The idea of the NoRetrospective is not about not doing retrospectives. Otherwise what a mess!

The concept pursues the idea that in order for the team to think about how to improve, it is not necessary to wait for retrospectives, which hopefully will occur every 2 weeks.

With #NoRetrospective you don’t have to wait 2 weeks to improve.

The idea is that the team has the culture of continuous improvement so embedded in their behaviors that the moment an improvement opportunity is detected, if it makes sense, it is addressed. Without writing it down in a notebook and waiting for the sprint retrospective to comment on it.

 

Final: The key to a retro

In our trainings we talk about retrospectives (even in a single moment) we like to highlight the following:

  • Continuous improvement is cultural, you can make as many events as you want, but if it is not accompanied by improvement behaviors, it will not do you much good.
  • It is interesting to reflect on how we deal with error?
  • You can do something very simple with an outline similar to the 3 questions but in headline mode for reflection:
      • 1) that we have done/do well as a team
      • 2) areas of improvement we identified
      • 3) SMART improvement actions

And how will I know if the retrospective has been a success?

Autor

  • Víctor Fairén

    Socio fundador de SmartWay. Profesor Universidad de Agile & Kanban. Consultor en Lean Agile. Strategic Advisor Business Agility

    View all posts

Autor

  • Víctor Fairén

    Socio fundador de SmartWay. Profesor Universidad de Agile & Kanban. Consultor en Lean Agile. Strategic Advisor Business Agility

    View all posts