Table of contents
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:
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.
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:
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:
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. 💪
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:
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
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.
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 💀”!)
Want to know when the next chapter is available? Sign up below to be among the first to receive each chapter.
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.
The Retrospective Prime Directive is:
"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.”
I’ve found that the Retrospective Prime Directive is most useful for:
So, how do you use the Retrospective 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 Retrospective 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.
Use Retrium to make your retrospectives easy and fun.
Start today for free!
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.
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:
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. 💡📈
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 of 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.
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 to 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!). 😊
Try Retrium. It guides you through the retrospective process
Start today for free!
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?
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:
Help the team focus on the retrospective and creates a safe and respectful environment.
Create a shared understanding of what happened in the latest iteration.
Identify issues, conditions, and patterns in the data that can help identify root causes.
Figure out what to do to attempt to improve going forward.
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 resources for these techniques are Retromat and this Trello board.
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.
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:
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:
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.
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. 😒
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.”
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:
Specific
Measurable
Achievable
Relevant
Time-bound
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.
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.
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 the 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 an 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.
Want to know when the next chapter is available? Sign up below to be among the first to receive each chapter.
Congrats on completing Retrospectives 101! 👏 Now that you have a basic understanding of the retrospective, it’s time to learn more about the 5 phased structure of a successful retro.
Let’s Do this!
.png){kind=small}
.png){kind=icon}