Welcome! I’m glad you’re here. In this first part of The Ultimate Guide to Agile Retrospectives, you’ll learn the basics of the retrospective. Ready? Let’s go 🚀
- The Basics
- What is a retrospective?
- What is the value of a retrospective?
- What is the relationship between agile and retrospectives?
- What is the difference between retrospectives and postmortems?
- What mindset is required to run a successful retrospective?
- Who should participate in a retrospective?
- Do I need a retrospective facilitator?
- Who should facilitate the retrospective?
- What process should I follow?
- How does the retrospective fit into an agile iteration?
- How long should a retrospective take?
- When and how often should I run a retrospective?
- Outcomes and Follow Through
What is a retrospective?
The retrospective is an opportunity for your team to reflect on what has occurred and to construct ways to become better going forward.
In other words, retrospectives are a chance for your team to inspect how it works and to adapt going forward. Most retrospectives focus on discovering answers to three questions:
- What is working well? 💯
- What is not working well? 😒
- What should we change? 🤔
Retrospectives enable Actionable Team Learning. By Learning, I mean that the retrospective must lead to the acquisition of new knowledge or skills. By Team Learning, I mean that the learning must be for the whole team and not isolated to an individual. And by Actionable Team Learning, I mean that the knowledge or skills that the team has acquired must have the potential to lead to change.
Any meeting that satisfies those three criteria is a retrospective. In practice, most teams use the retrospective as an opportunity to identify issues and to come up with ideas on how to remediate them.
What is the value of a retrospective?
Retrospectives give your team a chance to learn from their mistakes and to improve over time. Albert Einstein himself understood why it’s important to run retrospectives! (Though he almost certainly wouldn’t have used the term. 😋) According to Einstein:
“The definition of insanity is doing the same thing over and over again, but expecting different results.
Retrospectives give you and your team the chance to stop doing things that aren’t working, and to start doing things that do work instead.
In the preface to their book Agile Retrospectives: Making Good Teams Great, retrospective experts Diana Larsen and Esther Derby identify 6 benefits to retrospectives:
- Improved Productivity
- Improved Capability
- Improved Quality
- Increased Capacity
- Increased Empowerment
- Increased Enjoyment
Don’t expect to realize all of these benefits, every single time. Change is hard. But over time, if you commit to running retrospectives regularly, you will start to see improvements in many (if not all) of them. 💪
What is the relationship between agile and retrospectives?
Most people associate retrospectives with the agile movement. That’s because the most popular approach to agile — Scrum — explicitly incorporates retrospectives into its process. If you don’t know what I’m talking about, then let’s get you up to speed real quick.
According to the Agile Alliance, agile is “the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.”
In other words, agile is all about continuous improvement. That’s it. Really!
Underpinning the entire agile movement is the Agile Manifesto. And the twelfth and final principle behind the Agile Manifesto is:
While this principle doesn’t explicitly mention the word “retrospective”, it does implicitly describe the need for them. Think about it: the phrase “at regular intervals, the team reflects on how to become more effective” basically describes retrospectives in a nutshell. A rose by any other name would smell as sweet. 🌹
Since retrospectives are at the very core of agility, it doesn’t matter what agile framework (like Scrum or XP) you are using. Retrospectives should be a part of your process.
What is the difference between retrospectives and postmortems?
TLDR: Post mortems are usually run at the end of a long project. Retrospectives are run regularly.
One of the biggest differences between postmortems and retrospectives is that whereas postmortems lead to a set of Lessons Learned, retrospectives tend to lead to the creation of Action Items. While the difference between Lessons Learned and Action Items might sound like semantics, it’s actually much more profound. Since postmortems are run at the end of a project, most Lessons Learned are filed away in a desk somewhere never to be looked at again. 😰 In contrast, Action Items are intended to be acted on immediately.
Another big difference between postmortems and retrospectives is that retrospectives are intended to help you improve while your project is still in progress. Postmortems, on the other hand, only help you learn after the project is done (hence the term postmortem, which literally means “after death 💀”!)
Don’t miss any updates!
Signup to be notified whenever we update the Retrospectives Academy.
What mindset is required to run a successful retrospective?
Many facilitators will open their retrospectives by reading the Retrospective Prime Directive. The Retrospective Prime Directive is designed to ensure that the team has a positive mindset coming into the retrospective. It reads:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”Norm Kerth, Project Retrospectives: A Handbook for Team Review
I’ve found that the Prime Directive is most useful for:
- teams that tend to blame, insult, and criticize during their retrospectives, and
- retrospectives that will be focusing on a particularly tricky, difficult, or tense period of time.
So, how do you use the Prime Directive in practice? There are any number of ways. My favorite is to begin the retrospective with an open space. Remove the conference table! Place some chairs in a circle in the middle of the room and stand in the center of the circle. As people arrive, invite them to sit in a chair. To open the retro, slowly walk around the circle while reciting the Prime Directive. Make sure you make eye contact with each person, and look for a nonverbal signs of commitment. For example, you might notice someone nodding their head. Others might give you a smile. Small acts like these help the team establish a more mindful, positive atmosphere for the retro.
Your team wants to skip the retrospective?
Since retrospectives involve asking “how can we improve as a team?“, they can be highly sensitive meetings that require psychological safety. It’s therefore important to invite only the right people to the retrospective each and every time.
Who should participate in a retrospective?
It might sound trite, but by default … The Team should participate. Of course, who constitutes The Team will mean different things to different people in different contexts.
If you are using the Scrum, The Scrum Guide is very clear about who to invite to your retrospective:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
And who is on the Scrum Team? There are three types of team members:
- The Product Owner
- The Development Team
- The Scrum Master
So, if you follow Scrum, it seems pretty straightforward! Just invite the PO, the development team, and the Scrum Master.
But … is it always so simple? 🤔
Not in my experience. Here’s why. If the goal of the retrospective is to construct better ways of working, then the people who should attend the retrospective are … the people who will help you construct better ways of working. Period.
Sometimes that might mean inviting your manager. Sometimes that might mean inviting someone who is not on your team, but who is closely involved in the work you are currently doing. Other times, it might make sense to intentionally hold a cross-team retrospective in order to focus on organizational impediments.
The point is — use your brain. 🧠 You should be confident in your ability to figure out who should be invited on a case by case basis. Just think ahead of time about the issues at hand and invite the people who need to be there in order to give your team the best chance to improve. 💡📈
Do I need a retrospective facilitator?
Almost certainly. That’s because retrospectives are in a special class of meetings that rely on “participatory group learning”. The difficulty with participatory group learning is that most groups have no idea how to problem solve collectively. Many of us are good at problem solving individually. But when we’re in a group setting, divergent opinions and personalities can make shared learning and decision making difficult.
That’s where facilitation comes in. According to Sam Kaner, author of The Facilitator’s Guide to Participatory Decision-Making, facilitators have four responsibilities:
1. Encourage full participation
Facilitators help foster a respectful and safe environment in order to invite everyone on the team to contribute their ideas.
2. Promote mutual understanding
Facilitators help the group understand each other so that they can achieve shared learning.
3. Foster inclusive solutions
Facilitators help the group find solutions that take into account divergent opinions and perspectives.
4. Cultivate shared responsibility
Facilitators help empower the group to take ownership over the outcomes of the meeting.
It’s rare that a team of diverse individuals can achieve Actionable Team Learning in a retrospective without a skilled facilitator who helps guide them along the way.
Who should facilitate the retrospective?
In most cases, your Scrum Master or Agile Coach will volunteer to facilitate retrospectives. That’s because, as servant leaders, these individuals are primarily focused on enabling the team succeed, and retrospective facilitation fits into that role.
But can others facilitate your retrospective? Absolutely! And I recommend it for a number of reasons.
First, rotating the role of the facilitator helps build empathy within your team for just how difficult facilitation truly is. This is especially helpful if someone on your team questions the value you bring to the table as the facilitator. 😬
Second, each person who facilitates the retrospective can bring in fresh ideas on how to keep it fun and engaging. Other people on your team might have unique ideas on how to run different types of retrospectives that you’ve never thought of! 💡
And third, it is very difficult to both be the facilitator and a participant in the same meeting. Some might say it’s a fool’s errand. By rotating the role of the facilitator, you give everyone an opportunity to fully contribute to the conversation (including yourself!). 😊
Never run a retrospective before?
So what actually happens in a well-facilitated retrospective? Certainly people don’t just sit down and five minutes later agree on a solution to a problem. So how does it actually work?
What process should I follow?
If you’ve ever seen an agile team at work, you’ve probably been exposed to a lot of sticky notes 😁 And retrospectives are no different! Many retrospectives look something like this:
What’s actually happening here? The team is using a facilitation technique called 4Ls (“Liked, Lacked, Longed For, Learned”). This was just one part of their retrospective that helped this team Gather Data.
In fact, many good retrospective facilitators follow the five-stage approach that Diana Larsen and Esther Derby outlined in their book Agile Retrospectives: Making Good Teams Great:
1. Set The Stage
Help the team focus on the retrospective and creates a safe and respectful environment.
2. Gather Data
Create a shared understanding of what happened in the latest iteration.
3. Generate Insights
Identify issues, conditions, and patterns in the data that can help identify root causes.
4. Decide What To Do
Figure out what to do to attempt to improve going forward.
5. Close the Retrospective
Summarize the results of the retrospective and get feedback to improve the retrospective next time.
There are tens if not hundreds of variations on how to properly facilitate each of these five phases of the retrospective (Set The Stage, Gather Data, Generate Insights, Decide What to Do, and Close the Retrospective). Two good resource for these techniques are Retromat and this Trello board.
How does the retrospective fit into an agile iteration?
If you are using Scrum, most retrospectives are run at the end of every sprint. The output of a retrospective is one or more Action Items. These Action Items are then “fed” into the following iteration, during which time the team will try to improve how it does its work, based on the findings from the previous retrospective.
How long should a retrospective take?
That depends on the type of retrospective you are running, and on whom you ask 😇
Some suggest a formula: thirty minutes for each week in your iteration (so, thirty minute retrospectives for a one week sprint, one hour retrospectives for a two week sprint, and so on).
The Scrum Guide says that sprint retrospectives should last no more than three hours for a one month sprint, and indicates that the shorter the sprint, the shorter the retrospective.
Here’s my practical advice: realize that when you first start out facilitating retrospectives, you won’t know the right length of time because there’s no single right answer 🤫. Just pick some length of time (one hour is a good starting place) and try it out. See if it feels too short or too long. Inspect and adapt. Be comfortable with experimentation.
As you gain confidence and experience with retrospectives, you will be able to better determine the appropriate duration of your retrospective. In Agile Retrospectives: Making Good Teams Great, Diana Larsen and Esther Derby identify four factors that can influence the appropriate amount of time:
- The length of your iteration
- The complexity of the situation
- The number of people on the team
- The level of “conflict or controversy” on the team
When and how often should I run a retrospective?
Different teams run retrospectives at different times. If you are following the Scrum framework, it’s pretty simple: just run a retrospective at the end of every sprint.
If you are following Kanban, it’s a bit more complex. Since retrospectives are not formally part of the Kanban flow, it’s up to you to figure out the best time to retrospect. According to shmula.com, there are three times you might run a Kanban retrospective:
- At regular intervals
- Whenever there is an issue that a single person can’t solve on their own
- Based on the “Kanban Pull System”
Regardless of which framework you follow (or none at all), it’s important to realize that you can run a retrospective at any time. There’s no rule that you have to wait for your next regularly scheduled retrospective (don’t tell the process or framework overlords 🤫)! Especially if an issue or impediment is slowing the team down, consider retrospecting now. By stopping the work and retrospecting, you’ll be able to experiment with actions and improvements that can make the rest of your iteration more productive and end up saving you time.
Outcomes and Follow Through
The difficult thing about retrospectives is that your job is not done when the retrospective is over. In many ways, the hardest part has just begun. Since the purpose of the retrospective is to “construct ways to improve going forward”, if you never act on what you’ve learned in the retrospective, you’re probably just wasting your time 😒.
What is the outcome of a retrospective?
Remember, the purpose of a retrospective is Actionable Team Learning. It’s not enough just to talk. You have to talk with a purpose.
Sometimes it’s useful for a team to run a retrospective that isn’t focused on fixing something but instead focused on simply growing closer to one another. For example, a newly formed team might find it helpful to hold a retrospective that is focused exclusively on the positive (for example, they might paint a picture of what success looks like down the road). At the end of a retro like this, the team simply feels closer and more trusting of one another. And that’s a great outcome! 🤗
But in most cases, a retrospective should lead to one or more Action Items. An Action Item is “a discrete task to be accomplished by the team”.
How can I ensure follow-through on my Action Items?
Identifying problems is easy. Finding potential solutions to those problems is hard. Actually changing is even harder. Those pesky human beings naturally resist change. 🤖
Unfortunately, it’s impossible to ensure follow-through. But you can increase the odds that follow-through will occur. Here’s how.
1. Write your Action Items down! 📝
Too many teams complain about what’s broken, discuss ways to fix them, but never record their solutions down. Don’t fall into that trap.
2. Remember to be SMART 👌
I’ve seen Action Items that read like this: “Talk more with the Product Owner” That’s not good enough. Make sure your Action Items are SMART:
3. Follow the energy 💥
If no one on your team is excited about the Action Item, the odds of it actually getting done are slim to none. So instead of “committing” to Action Items for which there is little interest, commit to the Action Items for which there is palpable energy in the room.
4. Tackle one thing at a time ✔️
It’s unlikely that your team will be able to change more than one thing at a time. So, don’t try. Instead, focus on a single Action Item at a time. Don’t try to bite off more than you can chew.
Where should I record my Action Items?
The Scrum Guide instructs us to include “at least one high priority process improvement” item in your Sprint Backlog every sprint. There are two advantages to this. First, it’s harder to forget about Retrospective Action Items when they are recorded “inline” with the rest of your work. And second, because it encourages you to leave enough time during your sprint to work on the Action Items. 💡
Other teams prefer to maintain a Retrospective Improvement Board, Kanban style. Like all Kanban Boards, the Retrospective Board would have three columns: To Do, Doing, Done. Whenever your team commits to an Action Item, put it in the To Do column. As you start work on it, move it to the Doing column. When you’ve completed an Action Item, move it to the Done column. Wayne Grant has a writeup about this approach.
How should I handle impediments that are outside of my team’s control?
At some point your team will identify impediments during the retrospective that are outside its control. This is true regardless of company size! At a small startup, it might be budget 💰. At a large enterprise, it might be company policy 📄. And so on.
So what then? What should you do? 🤔
My first recommendation is to focus the team on what is under its control. Lots more is under your control than you might imagine!
Beyond that, simply recording down the impediments that are outside the team’s control can help. One way to do this is to use a Circles and Soup diagram:
If you categorize your impediments in a diagram like this, they become easy to refer to. You can even hang a big poster board in your Team Room that includes a always-up-to-date Circles and Soup diagram. This serves as a reminder to the team of what it can and cannot control.
Finally, remember that it is a lot easier to complain about issues you can’t control than fix the issues you can. Focus on what you can control instead of what you can’t.