Action Focused Retrospectives

What are action focused retrospectives

Action focused retrospectives are a way for your team to reflect on your past cycle of work, discuss what you’ve learned, identify specific action items to pursue, and follow through on those action items.

Action focused retrospectives typically follow the following structure (from Agile Retrospectives by Esther Derby and Diana Larsen):

Set the stage
Gather data
Generate insights
Decide what to do
Wrap Up

When to use action focused retrospectives

It’s a healthy practice for your team to pause periodically, reflect on your work and determine opportunities for improvement or experiments you want to try.

If your team works in an iterative fashion (such as sprints using the Scrum framework) the usual timing is at the end of each cycle (sprint).

If your team works in a flow fashion (for example, Kanban) it’s helpful to have a regularly recurring checkpoint to reflect and adapt. The regular recurrence may be every week or two depending on how fast-paced your team’s environment is.

Why use action focused retrospectives

Retrospectives are an important activity for your team to explicitly practice continuous improvement. Without a clearly defined reflection point, your team may fall into a pattern where you continue to work in the same fashion, continue to run into the same obstacles, and never learn from your experiences to improve your work moving forward.

Failure to use retrospectives prevents your team from having explicit approaches to clearing obstacles, identifying opportunities for improvement, and identifying experiments to try out new approaches.

You want to use an action focused approach to retrospectives to ensure that your retrospective discussions generate action and follow up rather than just being a forum for your team to air their gripes.

How to do action focused retrospectives

Set the Stage

Gather the team together and remind everyone that the purpose of the retrospective is to reflect on the past week(s), discuss what happened and what you can learn from that, and determine specific action(s) for moving forward.

It’s also good to remind everyone of the Retrospective Prime Directive from Norm Kerth (Project Retrospectives: A Handbook for Team Review):

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.

Another good thing to do at this point is to review any action items that were established at the previous retrospectives and discuss what happened with that action item. This is a good way to ensure follow up occurs on past action items and provides a nice transition from set the stage into gather data.

Gather Data

Ask team members to individually write thoughts on sticky notes about the past sprint or week(s) based on a set of topics. One thought per sticky note, as many sticky notes as they want.

There are a variety of sets of topics that teams can use including:

Good, Bad, Meh
Start, Stop, Continue
What went well, what did we learn, what should we do differently, what still puzzles us

There’s no magic between one set of topics and another. Find one that works for your team and run with it. You may find that you need to change up the topics if the team gets tired of a particular set of topics.

Once everyone identifies their items, ask them to put their sticky notes up on the whiteboard under the appropriate topic. Ask everyone on the team to do this at the same time so the source of specific notes is not immediately obvious. This should encourage your team members to be more forthcoming with their thoughts.

The resulting white board will look something like this:

Generate Insights

Affinity Grouping

Once everyone has put their thoughts up on the board ask your team to group the ideas into similar categories. Try to reach a point where there are no “orphan” sticky notes, meaning there are no single sticky notes on the board.

As the team groups the sticky notes, they should keep the notes under the same topic (all the sticky notes originally placed under “Good” should stay in “Good”)

This activity gives your team the chance to see all the ideas and also see their ideas in relation to the thoughts of others on the team.

After affinity grouping, the board may look like this.

Title the Affinity Groups

Once you have all the sticky notes in affinity groups, ask your team to suggest a title for each group. You can either have someone from the team do this as team does the affinity grouping, or you (as the facilitator) can quickly go group to group and ask what title they want.

If you take this approach, I’ve found it helpful to read the sticky notes in the group and then ask the team for title suggestions. You may find that you have to suggest titles.

Don’t spend too long identifying titles for each group, but make sure the team is aware of the general theme of each group and that you come up with a title that appropriately describes that theme.

Once you have titles, the board will look something like this:

Dot Voting

Next, ask your team to indicate which topics they would like to discuss in more detail by dot voting on the groups.

A good heuristic for determining the number of votes each person gets is to count the number of groups, divide by three and round up.

In this case, there are 7 groups so dividing by three and rounding up results in three votes per person. In this particular situation, there are 7 team members so there will be a total of 21 votes.

Each person can choose where to put their votes. They can put all of their votes on one group or spread them out to multiple votes.

The board may look like this as a result.

The team then uses these votes to determine the order in which you discuss items. In this case, the order of topics is:

Pipeline
Mob programming experiment
Short week
Refactoring
Met outcome early

For each topic your team discusses the story behind the group of sticky notes and why it is sitting in the particular topic.

These discussions give your team a chance to get a better understanding of the concerns the rest of the team has or the assumptions the rest of the team is making.

These discussions also tend to blur the lines between gathering insights and deciding what to do, as the discussions will often identify potential action items.

If you find that your team tends to linger on a particular issue preventing you from covering all the topics you want to discuss in the retrospective, you may want to time box the discussion. When you reach a limit for the amount of time you want to discuss an issue, you can choose to continue the discussion, identify action items for that issue, or just stop discussion of that issue.

For some discussions, you’ll want to clearly identify a specific action item, especially those that appear in the Bad column. In the example shown above, the team was having a bit of difficulty with their development pipeline, so the outcome of the discussion on that topic should identify some action steps they can take to resolve the pipeline issues.

For other discussions, you may discuss the results of an experiment that your team tried for the time period that the retrospective covered (the team in this running example tried mob programming in the previous sprint). In that case, your team may decide whether to continue the experiment, abandon the practice, or adopt the practice on an ongoing basis.

Finally, the intent of some discussions is just to comment on some good things that happened and give kudos to the team. Your team may also want to discuss what made that particular thing successful and identify what actions you can repeat in other situations.

Decide what to do

Identify specific actions that your team can take to benefit from or address the particular situation you are discussing. You certainly need to spend a little bit of time making sure the team has a shared understanding about the scenario and its consequences, but you want to drive toward identifying action items rather than just falling into an ongoing complaint session.

As the team identifies action items, make note of them (the best way to do that is to write them on the board near the sticky notes describing the particular situation).

As you near the end of your scheduled time for the retrospective, or if you have made it through all of the identified discussion topics, explicitly ask the team to select which action item they plan to tackle in the next sprint or week(s).

It’s best to focus on a very small number of action items – preferably one – to increase the chances that your team will actually finish that item. The more items your team tries to tackle, the bigger the chance the team does not accomplish any of the action items.

Once you’ve selected the action item, identify who will own making sure the action item is completed, by when (usually by the next retrospective) and criteria for knowing when the action item is successfully completed.

If you choose to tackle multiple action items, identify the same information for each action item.

Wrap Up

During this part of the retrospective, confirm that your team has a shared understanding about the action items coming out of the meeting.

Check if anyone has any comments about the process you used for the retrospective (a retrospective on the retrospective as it were).

You may also want to see if there were any specific topics that weren’t discussed that someone has a burning desire to bring up. Depending on the dynamics of the group you may need to be careful with this, but it can often help people to know there is always an opportunity to bring something up that they just thought of, or didn’t include in the initial data gathering.

Caveats and Considerations

You may decide to have each person read off their sticky notes as they put them up so that everyone hears every point. If some team members are reluctant to bring things up if they are directly associated with the idea, then it’s best to have everyone put their sticky notes up at the same time. If that concern is a factor, you have a significant team dynamics issue that you need to work through.

The definite advantage to having everyone put their sticky notes up at the same time is that it is faster than having each person read each sticky note. If you go the route of having everyone put their notes up at the same time, you’ll want to provide an opportunity for the team to read through all the notes. As noted above the affinity grouping exercise provides an opportunity for team members to view all the notes.

There are a variety of different approaches to set the stage, gather data, and generate insights provided in the book Agile Retrospectives Making Good Teams Great by Esther Derby and Diana Larsen. You may want to check those approaches out if your team is facing a particular situation or you’ve been using the approach described above for quite a bit of time and your retrospectives are starting to become monotonous.

You may want to focus discussions on specific categories of sticky notes topics. For example, in the case described in this post, you may ask the team to focus on the “Meh” and the “Bad” topics. This is a judgement call. There is some value in discussing the good things that happened, especially if there is the need to increase the frequency or intensity of a particular activity.

It may help to have someone from outside your team (such as a coach or an experienced facilitator from a different team) facilitate the retrospective. This allows everyone on the team to focus on the content of the retrospective and allows for an unbiased facilitator. This is not a requirement, but it may be handy to do on occasion to allow for a different perspective.