.png){kind=icon}
Table of contents
Imagine you’ve facilitated the most energizing, engaging, and fun retrospective ever. Congrats! 👏
There’s only one problem: the hardest part of the retrospective is still to come. 🤯
Now that the retro is over, you’ve got to actually improve something based on what you’ve learned!
And unfortunately for us, change is hard.
So that’s the bad news.
What’s the good news?
The good news is that you can follow a simple three-step process to dramatically increase the odds your retrospectives will lead to genuine improvements.
And here it is:
In this chapter, we’ll dive into the Choose-Create-Discuss steps in detail so that you have a framework for ensuring your team follows up on Action Items in your next retrospective.
But we’re getting ahead of ourselves.
Look at the google search trends for the terms “fun retrospectives” and “Retrospective Action Items.” Which one has higher search volume?
"Fun retrospectives" by far!
You don't need to analyze the data deeply to understand something profound: people are far more interested in how to have fun retros than they are in retro Action Items.
This is a big problem.
Let me be clear: there's nothing wrong with having fun in your retrospectives. All else being equal, we'd prefer to have more fun! 😍
The problem isn't the fun itself. It's that, for many of us, having fun in your retrospective has replaced actual changing and improving as our primary goal.
Let's look at the data.
We asked over 275 members of the agile community how they manage their post-retrospective follow-up. While 97% of respondents created Action Items, only 12% indicated they always assign deadlines to Action Items. Why is this significant? Because without a deadline, there is no timeline for follow-through.
So if you feel your retros aren't leading to real change, stop focusing so much on having fun and start focusing on increasing the odds of follow-through.
Let me be super clear just to be sure we're on the same page: The game or activity you use in your retrospective doesn't matter as much as the change that happens after the retro is over.
If that resonates with you, here’s what you should do:
So, how do we increase the likelihood of follow-through and change?
Let’s take a closer look at the three-steps that will help your team follow-through on Action Items. Remember we need to:
Ready to dive in? Cool. Let’s go.
Want to know when the next chapter is available? Sign up below to be among the first to receive each chapter.
Choosing the right action is more complicated than it might seem.
The mistake I see teams make time and again is that they are too quick to agree to an Action Item.
Here’s what I mean.
At the start of a retrospective, the facilitator holds space for the team to brainstorm various issues they want to discuss. During this time, the team keeps an open mind and tries to generate as many ideas as possible. Nothing is off the table!
Great! Next, the team will converge on the impediment they feel is most important to discuss (for example, using dot voting). During this time, the team should think critically and try to narrow the ideas to one or two that require more focus and attention.
This diverge and then converge pattern enables teams to collectively brainstorm in an effective manner.
Tip: There are some cases in which talking about many different impediments in your retrospective makes sense. But in general, you should try to have a deep conversation about a single topic, rather than shallow conversations about many topics.
Now here comes the mistake that many teams make. Once the team has converged on a topic of discussion, they skip right to coming up with an Action Item:
By going directly from converging on an impediment to agreeing on an Action Item, the team doesn’t have a chance to openly brainstorm potential Action Items in the same way they brainstormed potential impediments. That’s the problem. (I talk about this in more detail in Chapter 2.)
Think about this again, because it’s important.
At the start of the retro, you hold space for the team to brainstorm freely. Why? Because you want to ensure everyone in the room has the chance to add their ideas before thinking critically about determining the most important one to discuss.
Similarly, when trying to come up with an Action Item, it’s vital to ensure everyone in the room can brainstorm candidate Action Items before committing to one.
Many teams skip this step, and by doing so, the odds are very high that you will end up working on a suboptimal action. (It will likely be the action the most outgoing person on the team wants!)
Instead, after identifying an impediment, you want to hold space for the team to diverge and brainstorm again before finally converging on and committing to an Action Item.
Here’s what that looks like:
(As an aside, this is called the Double Diamond approach to brainstorming. You can read more about it in this excellent post from SEEK.)
Ok, so now we have a theoretical approach to improving our Action Item selection. But how do we converge on a single action item in practice?
There are lots of ways to converge on an Action Item. But my favorite is...
...to pick the Action Item with the highest Expected Value, or EV for short.
Expected Value!? Apologies if I’ve brought up bad memories of high school statistics!
Fortunately, calculating the EV(action item) is much easier than you’d expect.
The EV(action item) is simply a function of:
Its IMPACT
Your CONFIDENCE in the action’s impact
How much CONTROL you have over making the change
The amount of EFFORT the action will take
The team’s ENERGY level for working on the action
Or, for the math people out there,
EV(action item) = f(impact * confidence * control * effort * energy)
To calculate the EV formula, we need to translate these concepts into numbers.
So how does this work in practice?
Let’s walk through an example.
Imagine your team has converged on “too many bugs in our product releases” as the impediment to focus on.
Next, imagine your team diverged again and identified the two most promising candidate Action Items to fix the problem:
Note: in practice, you should generate far more candidate Action Items. This is an illustrative example.
To figure out which Action Item to work on, the team should go through each one and collectively determine the expected value.
For example:
Great! But what does the number 2,500 mean?
Absolutely nothing! At least, nothing on its own. The number 2,500 is only interesting relative to the other potential Action Items. So, let’s look at the next Action Item:
It’s possible because the team doesn’t have the energy to work on it. Maybe because there’s a lack of interest, or maybe it’s because there’s a lack of time or resources to make it happen. Whatever the case, if there’s no energy to work on setting up a CI/CD server, it won’t happen! And therefore, its Expected Value (EV) is zero.
And that means the choice between these two Action Items is easy. We’ll work on the first one: Take on less work each sprint.
Bonus Tip #1:
The first time you use this approach to picking an Action Item, it's entirely possible your team will get hung up on the details. For example, there might be a big debate on an Action Item's impact. Will it have a High impact? Or a Medium impact? And what do those terms mean, exactly?
Actually, they don’t mean much. They are relative ratings. What’s important is that they are correct relative to each other.
Bonus Tip #2:
Don't get stuck debating these ratings for hours on end. Why? Because no rule says you must pick the Action Item with the highest Expected Value. Expected Value should be used as a guide, nothing more.
Bonus Tip #3:
In general, the outcome of this exercise should be a commitment from the team to work on a SINGLE Action Item coming out of your retrospective. One! Not two. Not three. One.
Why? Because change isn't easy, and by trying to change too much at once, you lower the odds that any change will happen.
Of course, there are times when going broad instead of deep makes sense.
For example, if there is a lack of consensus on what topic to discuss, then it's possible that talking about more than one topic (and therefore creating more than one Action Item) might make sense.
Similarly, if the topic being discussed only impacts part of the team, you should also consider committing to more than one Action Item.
One way to help narrow the focus of your discussion is to use the 80/20 rule, which states that, for many events, roughly 80% of the effects come from 20% of the causes. For example, if 90% of dot votes are on one topic during your retrospective, that's a great topic to explore together during the discussion phase.
But, if your notes are more distributed and you lack consensus, the group should go broad with their discussion to avoid minimizing voices on the team. More distributed votes suggest that a deep conversation on one topic does not make sense because no single topic impacts the whole team; going deep in the retro is a waste of time because it doesn't apply to them.
Instead, refocus the team on what matters and capture this in your retro:
ACTION ITEM: Book a follow up meeting and move on to the next topic in the voting.
In summary, you should only go deep on one Action Item if:
And on the other hand, you should keep your conversation broad and assign Action Items to discuss topics deeper with a smaller group if:
Bonus Tip #4:
If you follow the Double Diamond approach, you should end up with a lot of candidate Action Items (far more than the two in this illustrative example). In this case, calculating the Expected Value for each Action Item would be far too time-consuming. This is why in practice, most teams end up filtering the list before calculating the Expected Value.
Here’s how that works. Start the filtering process by removing any candidate Action Item from the list that the team does not have any energy on. Why? Because these Action Items will end up with an Expected Value of zero anyway. So there’s no point in discussing the other ratings.
If you need to filter further, pick another component of Expected Value. For example, you could remove any Action Item that is out of the team’s control.
Or you can filter by the impact of the Action Item by plotting each Action Item on a 2x2 grid similar to the one here:
Once you look at the Impact of each Action Item - how much will this change how and what we do? - To what degree the Action Item is in our control, select the topics in the upper right.
And so on.
Once you have a more manageable list, proceed with the EV calculation.
Try Retrium. It guides you through the retrospective process
Start today for free!Now that your team has picked the right Action Item to work on, it's time to move on to writing it down.
Let's return to our Action Item, "Take on less work each sprint." It turns out this is horribly written! Why? Imagine, in two weeks, you look back to see how the Action Item turned out. Here are two questions you might ask:
Let's start with the first one. Remember, the Action Item is "take on less work each sprint." How will you know if you made that change? What does "less work" actually mean? Is it fewer story points? Is it fewer user stories? Or something else entirely?
And even if the team agrees on a definition of "less work," how much less are we talking about? One person might imagine a slight reduction in work, while another might imagine a significant reduction.
And the second question, "did the change have the expected impact?" is even harder to answer. The Action Item did not include anything about the expected impact. So how will the team judge its effectiveness?
That's why it's crucial to write down your Action Items deliberately. There are lots of ways of doing this. Let's start with an approach you likely will have heard of before: SMART.
SMART stands for:
In other words, when you write down your Action Item, you should check to ensure it meets those criteria.
Let’s try rewriting the Action Item, “Take on less work each sprint,” in a SMART way:
In our next sprint planning meeting, we will accept three backlog items into our sprint backlog.
Now, the Action Item is:
The SMART mnemonic is not the only approach to writing high-quality Action Items. There are many alternatives. Here are just a few:
It’s enough to make anyone’s head spin! Here’s my practical suggestion: pick one of these approaches and see how it works for you. If it works well, great! If not, try another one.
Speaking of Experiments
Another way to write down Action Items is to rewrite them as hypotheses and experiments. By definition, hypotheses and experiments are based on the Scientific Method, which requires us to make verifiable predictions.
The advantage of this approach is it requires us to write down our actions in a specific and measurable way.
Here is a template you can use to write your actions as hypotheses and experiments:
We hypothesize by <implementing this change>
We will <solve this problem>
Which will have <these benefits>
As measured by <this measurement>
Try Retrium. It guides you through the retrospective process
Start today for free!
So, you now have your Action Item written down. But you’re not done yet. Who is responsible for working on the Action Item? By default, the team is collectively responsible. However, that leads to the tragedy of the commons, in which “individual users, acting independently according to their self-interest, behave contrary to the common good of all users.” In other words, team ownership leads to a lack of follow-through since everyone assumes someone else will take responsibility.
That’s why having a single individual take responsibility for the Action Item is a good idea.
I call this job the Action Item Ambassador (some prefer Action Item Shepherd). Note that I intentionally am not calling it the Action Item Owner. That’s because this person doesn’t own the Action Item; the team does. Instead, the Action Item Ambassador guides and reminds the team of its commitments.
You can think of the Action Item Ambassador as the Scrum Master of the Action Item. It’s about servant leadership, not ownership.
Bonus Tip: Make sure you ask for a volunteer to be the Action Item Ambassador. This should not be an assigned position. Someone should be eager to volunteer as long as you picked an Action Item that the team has the energy to work on (see the section above on how to do this).
The Action Item Ambassador’s job is to help the team work on the change during the sprint. How do they actually do that in practice?
First, the Ambassador should remind the team to make the Action Item highly visible throughout the sprint. Why? Because the more visible something is, the more the team will remember to work on it. Things that are not immediately visible tend to be forgotten.
Here are a few ways you might do that.
1. Place the Action Item in the Sprint Backlog
One way you can increase the visibility of your Action Item is to place it into the Sprint Backlog itself. That is the recommendation of the Official Scrum Guide.
“To ensure continuous improvement, [The Sprint Backlog] includes at least one high-priority process improvement identified in the previous Retrospective meeting.”
Source: https://www.scrumguides.org/scrum-guide.html#events-retro
This approach works exceptionally well when the Action Item takes some sustained effort throughout the sprint.
For example, if the Action Item is “Research how to set up a Continuous Integration server,” the act of researching will take time away from working on other Product Backlog items. As a result, it makes sense to consider the time and effort it will take to work on the Action Item together with other Product Backlog items.
2. Create a Kaizen or Kanban Improvement Board
As you might know, a Kanban Board is a board with three swim lanes (or columns) that looks like this:
Many teams use Kanban Boards to track their product work, but you can also use them to track your improvements coming out of retrospectives.
Hang this Improvements Board somewhere in your team room or use one of your online tools - think #ActionItems Slack channels- to keep the status highly visible to the team. Whenever the team commits to an Action Item at the end of a retrospective, the Ambassador should put it in the To Do column.
One reason this is such a powerful technique is that it makes the Action Item highly visible and makes the team's progress (or lack thereof) visible on the Action Item.
For example, if the sprint is nearly over and the Action Item is still in the To Do column, that will be blatantly obvious to everyone on the team that there has been no progress toward improvement.
3. Monitor and physically record your progress
If you use the Improvements Board technique above, you'll quickly be able to see whether the Action Item is being worked on. But once the Action Item is in the Doing column, there's no way of checking how the progress is going.
That's where creating a big, physical visualization of your progress comes in handy. According to the American Psychological Association:
"If you are trying to achieve a goal, the more often you monitor your progress, the greater the likelihood that you will succeed...Your chances of success are even more likely if you report your progress publicly or physically record it."
Here’s an example.
Imagine your Action Item: "Talk to the Product Owner at least twice a day." How might you create a visualization of your progress?
One way is to create a board where each column represents a day of the week, and every time someone talks with the Product Owner, they put a simple check mark underneath that day.
Something like this:
Imagine it is Wednesday, and you look up from your laptop and see the Big Visualization above. What could you instantly notice? That the team failed on the Action Item on Tuesday.
At first, creating visualizations of your progress can be difficult. But in my experience, the progress on almost any Action Item can be translated into a visualization. And if you can’t, it’s likely because the Action Item isn’t written in a SMART way.
4. Talk about your Action Item progress during the Daily Standup
Now that you have a big visualization of your progress discussing how it’s going throughout the sprint is essential.
My favorite way of doing this is during the Daily Scrum, during which each member of the team responds to three questions:
The Action Item Ambassador should remind everyone to discuss progress on the Product Backlog during this meeting and progress on the Retrospective Action Item. The same three questions apply here, too.
5. Talk about your Retrospective during the Sprint Review
At the end of each sprint, your team will hold a Sprint Review with stakeholders. This time is a great opportunity to discuss your retrospective improvements with people outside the team. In fact, according to the Official Scrum Guide, during the Sprint Review:
“The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved.”
https://www.scrumguides.org/scrum-guide.html#events-review
According to Maarten Dalmijn, Senior Product Owner at BESTSELLER:
“In my experience, by sharing some of the challenges with your stakeholders, sometimes you can rally them on your side to help fix those problems for you. Especially if they are organisational in nature and delay delivery of something valuable, they care about. It can create a sense of urgency to finally fix nagging issues that have been slowing you down for ages. You can use it to your advantage to realize organisational changes.”
One caveat is to make sure the team is comfortable talking about these issues with stakeholders outside the team. Remember: psychological safety comes first.
6. Talk about your Action Item progress in the next Retrospective
If you are still struggling with follow-through, it can be helpful to run the next retrospective on this topic in particular. Why is the team struggling with its Action Items? What can we do differently next time?
Remember that the success of your retrospective isn’t measured when the retrospective is over. Changing and improving is hard work! But you can try to narrow your focus and efforts with the three-step process we talked about here:
Great question. We'll be talking about psychological safety and the role it plays in building a productive team in the next chapter. Stay tuned!
Want to know when the next chapter is available? Sign up below to be among the first to receive each chapter.
What is psychological safety for teams? and how do you know if your team has psychological safety?
.png){kind=small}
