Introduction to the Agile Retrospective: the Why, the What, and the How
The retrospective can have many different names. We sometimes hear about 'Sprint Retrospective', 'iteration retrospective', 'team retrospective' or even 'Agile retrospective'.
All right, but what is it really about? What's the point of having retrospectives? What format should I use? How often should I do "retros" with my team? Does it work as well in a remote work context?
If you're asking yourself these questions… you've come to the right place. In this article, we will try to understand why retrospectives have become so popular. Then we will see how you could implement them into your team's routine. Let's go! 🚀
How is a retrospective different from a regular team meeting?
How often should we have retrospectives? What’s the ideal length?
Origins and popularization of the Agile retrospective
The year is 1997.
Radio stations repeatedly air Wannabe by the Spice Girls, while #TeamNotoriousBIG only swears by this hit called Hypnotize. Let's all meet halfway and treat ourselves to Daft Punk's title Around the world.
Alistair Cockburn, meanwhile, was probably quite busy that year.
In his book, Surviving Object-Oriented Projects, Cockburn informally described how working incrementally and regrouping after each increment could help project development.
In 2001, Cockburn further developed his concept and even gave the first name to this famous-to-come team meeting, 'reflection workshop.' In the process, he contributes to the Agile Manifesto's birth (of which he is a co-signatory). Here’s a key part of the Manifesto:
'At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.'
- Manifesto for Agile Software Development
From there, the Agile movement is put into motion for good.
Meet Norman L. Kerth, a former professor at the University of Portland and one of the pioneers of agility. Still in 2001, Norman made a significant contribution to the popularization of retrospectives with the publication of Project Retrospectives: A Handbook for Team Reviews.
Simultaneously, the adoption of Agile methods such as eXtreme Programming or Scrum is gaining in intensity. The retrospective is spreading and helps thousands of teams engage in a game of self-inspection and self-adaptation.
In 2006, Esther Derby and Diana Larsen joined in and published the excellent Agile Retrospectives: Making Good Teams Great. This book has been propelling the practice of retrospectives far beyond the boundaries of software engineering.
A simple definition of the Agile retrospective
Let's start from the beginning. The retrospective is first and foremost about the team, made for the team, led by the team. It takes the form of a short and frequent team meeting. We will come back to its duration and frequency later on.
Note: If you're new to Agile, and particularly to Scrum, make sure you understand the difference between a Review and a Retrospective.
The retrospective is about looking back on past events in the last iteration, learning from them, and then collectively building an action plan to drive rapid and continuous team improvement.
'A retrospective is a chance for a team to reflect and learn from the past within a structured meeting. The main aim is to inspect the situation and adapt to the reality.'
- Aino Vonge Corry, Retrospectives Antipatterns
Simply put, the purpose of retrospectives is to help teams improve continuously.
Traditionally, a retrospective would allow a team to reflect collectively on three key questions: 'What went well?', 'What didn't go so well?' 'How could we improve?'.
However, a retrospective is much richer than a simple answer to these questions. We'll explore several fun retrospective formats in a moment.
What kind of team should do Agile retrospectives?
(Very) short answer: all teams should frequently conduct retrospectives.
It doesn't matter what industry you’re in, and it doesn't matter what you're working on or what work methods you employ. You're a Product team? Good. A Marketing team? That also works perfectly. The retrospective exercise should take place systematically for any team willing to develop their full potential.
Do you run retros with Scrum? Or maybe you facilitate retrospectives with SAFe? Or does your team prefer Kanban? No matter the framework: as long as there’s a desire to improve as a team, there’s room for a retrospective.
It's not uncommon to hear that teams don't have time for retrospectives. Since a picture is worth a thousand words, this one pretty much sums up the philosophy behind retrospectives:
Besides, the level of maturity of a team should not affect the conduct of retrospectives.
'Retrospectives help teams - even great ones - keep improving.'
- Esther Derby & Diana Larsen, Agile Retrospectives - Making Good Teams Great
What are the benefits of Agile retrospectives?
So you think retrospectives are a waste of time? Think again. Since the team is very transparent during this exercise, its members can more easily discuss the challenges identified.
Let’s look at some of those benefits:
Creation of more frequent feedback loops within the team,
Enhanced collaboration, communication, trust and team spirit,
A stronger ability to identify how to improve our processes,
Improved team productivity,
A greater occurrence of lessons learned within the team,
An ability to prevent past mistakes from happening again,
Better anticipation of future problems.
How is an Agile retrospective different from a regular team meeting?
Agile retrospectives are different from traditional meetings because their goal is to focus on a specific project with the intentions of:
Putting the team at the center of the discussion. The aim is to improve the team and, as much as possible, how it can interact with the elements surrounding it,
Giving voice to all team members,
Taking stock of what went well and not so well,
Building an action plan together with the objective of rapidly improving the functioning of the team on one or more identified action point(s).
Who should facilitate the Agile retrospective?
First of all, a team member should certainly take responsibility for hosting a retrospective. However, you might wonder who should have this responsibility, and the answer is… it depends.
Of course, a Scrum team will first and foremost rely on their Scrum Master and may request their help in facilitating retrospectives. An Agile Coach also has the experience and skills to perform this facilitation work.
However, in their effort to become self-organized, many Agile teams operate a continuous rotation when it comes to designating the next retrospective facilitator.
Thus, each member of the team will have the opportunity to design and facilitate their retrospective. This technique will provide the team with renewed activity choices and help avoid falling into a boring routine.
What are we talking about in an Agile retrospective?
The Scrum Guide introduces the concept of the Sprint Retrospective as follows:
'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 regards to individuals, interactions, processes, tools and their Definition of Done.'
- Scrum Guide, 2020 edition
Here, we can note that the topics addressed during a retrospective are very diverse and continuously linked to the team.
In the case of our online retrospective platform designed for distributed Agile teams, we have identified 10 core team dimensions and offer them across our ready-to-use retrospective templates.
These dimensions typically correspond to the main topics covered in retrospectives, although this list is obviously not exhaustive:
Mission: we are all aligned with the company's goals. Therefore, we know what to do as a team to achieve our objectives and deliver value.
Ownership: our team works autonomously and can make decisions on its own. Our ownership is easily identifiable from inside and outside the team.
Value: the value we create for both the business and our users is easily identifiable, measurable, and deliverable.
Speed: we can deliver quality value while respecting delivery dates. The team is working at a healthy and maintainable pace.
Process: our processes are rightfully designed and help us deliver value. We do not feel slowed down or blocked because of them.
Roles: the roles and responsibilities of each team member are clear to everyone. All the skills necessary for the success of the team are present.
Collaboration: the collaboration is omnipresent and respectful. It manifests itself in constant and high-quality communication.
Resources: we have access to all the material resources and support we need to accomplish our mission.
Fun: our team atmosphere is enjoyable and pleasant. Each member likes working as a team.
Learning: team members keep developing their skills through repeated learnings, cycle after cycle.
How often should we have Agile retrospectives? What’s the ideal length?
Your team should hold retrospectives frequently so that they see a sustainable impact on productivity and team growth.
We generally hold a retrospective at the end of each Sprint for a Scrum team, once every two weeks on average. Thus, the group quickly reassesses the impact of the action items it took on in the last retrospective.
Retrospectives are not meant to be meetings that go on forever. In fact, just two 90-minute retrospectives a month can give a team more than enough time to optimize their efficiency.
Here is another valuable clarification from the Scrum Guide : 'The Sprint Retrospective [...] is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.'
In short, there is no particular constraint apart from favoring relatively short meetings and making retrospectives frequent.
What is an action plan, and how do you build it?
As stated before, the purpose of a retrospective is to help the team improve very quickly.
To do this, the team builds an action plan during the retrospective, consisting of one or more action items. There are endless examples of action elements as there can be so many topics covered in a retrospective.
Three major tips to help you build an effective action plan:
Make sure that the chosen action items are SMART (Specific, Measurable, Achievable, Relevant, Time-oriented),
Don't commit to too many action items at once. Remember that the point of an action plan is to see a rapid and distinct improvement in the team by the next cycle.
It is best to avoid assigning an action item to more than one person at the same time as this would most likely weaken the notion of accountability within the team. While multiple people can work together to accomplish an action item, we recommend that you only name one person responsible for it - as a messenger role towards the action item's progression.
Would it be possible to have examples of Agile retrospective formats, please?
Of course, thank you for asking!
For the sake of brevity and efficiency, let's focus on examples of virtual retrospective activities - which can, however, easily be conducted in the office as well.
This format is one of the easiest to understand and use when starting out with the practice of Agile retrospectives.
The team generates ideas and groups them in a three-column table: 'Keep' for things you would like to keep, 'Drop' for those you would like to give up, and 'Start' for those you want to try in the next iteration / project.
2/ The 4Ls
The Ls stand for: liked, learned, lacked, and longed for.
Known for its great simplicity, the 4Ls has quickly become a classic retrospective format. We recommend using this activity to highlight both the positive and negative aspects of a project or an iteration.
Note that many Scrum Masters select this facilitation technique for recurring retrospectives as well.
This activity focuses on the positive aspects of your team’s experiences.
Combine the Team spirit responses with the comments from Ideas to determine which actions your team members want to take.
With the help of the Three Little Pigs fable, frame a discussion that highlights the processes that need to be improved, while celebrating what’s going well.
Three columns illustrate this very original retrospective model:
The house of bricks (the strong and durable elements),
The house of sticks (the solid pieces that can be improved),
The house of straw (all the things that can collapse at any time).
We’re picking a completely different example this time.
Designed to invite team members to express themselves on a given set of themes, the Team Radar visually represents the team's strengths and weaknesses.
Remember the list of the 10 team dimensions mentioned above? You could use them on your radar to deliver a real-time snapshot of your team's health. This way, each team member would rate all of the dimensions with a score from 1 to 5 and then share their comments to give more context to their score choice.
---
Note that you can try these 5 retrospective activities for free on Neatro.
How to run an Agile retrospective?
Now that we've covered the retrospective basics, it's time for you to prepare for your next team retrospective!
We recently wrote a remote retrospective guide with plenty of tips for preparing and running your online retrospectives. Special mention to our article on the best retrospective check-in activities.
And if you're looking for tools to help you embrace a culture of continuous improvement, check out our guide to the best tools for Agile teams or our top 10 of the best free retrospective tools.
🎁 Bonus! A moment of philosophy: can we really speak of an 'Agile' retrospective?
This section should please connoisseurs. 🤓
In the term 'Agile retrospective,' we tend to focus on both the ceremony (the retrospective) and agility in its broad sense, don't we?
The very nature of a retrospective is fundamentally Agile, so why would we mind insisting on its Agile aspect? With this being said, can’t we see a pleonasm here?
As opposed to traditional project management methods (e.g. the Waterfall framework), Agile methods advocate adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change. Thank you Wikipedia. Thus, the retrospective is a direct means to articulate the values of the Agile Manifesto.
Also, to our knowledge, there is no 'waterfall retrospective' out there. Instead of solely using traditional methods like the aforementioned Waterfall framework, we find teams that combine a traditional project management methodology with a particular Agile practice.
But maybe 'the truth is out there", as special agent Fox Mulder would say.
Putting an emphasis on the Agile aspect of retrospectives might catch the attention of teams that do not claim to be Agile. Those teams might simply want to explore new practices to gain immediate benefits. Can we blame a team that cares about its continuous improvement and is willing to incorporate an Agile retrospective ritual into its non-Agile routine?
So, what do we think of this 'Agile retrospective' thing? Is it the right formula? Or is it yet another shot from a group of Agilists wannabes?
The concept of Agile retrospectives can be approached from many different angles. However, we can all agree on one thing: team retrospectives help any team improve quickly.
Errr, did we just mention wannabe? WAIT! ARE WE BACK IN THE NINETIES AGAIN?