A Quick Tutorial for Improving Your Retrospectives

Anthony Mersino June 17, 2021

I spoke recently on the topic of retrospectives and continuous improvement. I have written no fewer than 10 articles on the topic of retrospectives. IMHO, the retrospective is one of the most important meetings in the Scrum Framework. Sadly, it is also the agile technique that is most frequently butchered by hacks.

I know, I know, that sounds like hyperbole. And perhaps my own experience is jaded from working with so many brand new Scrum Masters who may or may not have had much training in the role. (Unskilled Scrum Masters is another topic we can rant on in a separate post!)

In any case, I put together this quick tutorial for those who are interested in improving their retrospectives. Good retrospectives will build team morale and esprit de corps, improve trust and engagement, yield better quality improvement actions and boost continuous improvement.

Books on the Retrospective

For those of you who still read books, there are two great books on retrospectives. The first is Norm Kerth’s 2001 book, Project Retrospectives; a Handbook for Team Reviews. Written prior to the creation of the Agile Manifesto, Kerth’s book focuses on conducting project retrospectives in a traditional project environment. The focus here is the project mentality and learning lessons that can be applied to future projects.

I’ve conducted a number of these retrospectives for traditional projects. We used to call them lessons learned or post mortem sessions. And while they can provide insights, I don’t recommend them. Not because of Norm of course, but because the lessons learned from one project are rarely harvested and applied to the next project. I have written about why these efforts are mostly wasted in this LinkedIn article, Lessons Learned for Traditional Projects are Still a Waste of Time.

There are a few main reasons why conducting retrospectives for traditional projects is a waste of time.

1. Timing – Most traditional projects take 6 months or more to complete. Participants come on and off the project and in some cases leave the organization entirely before the post-mortem. And those that are available to participate may not remember anything more than the most recent experience with the project.
2. Accessibility – When you conduct lessons learned, where do you put the results? The PMBOK says you should post the lessons learned in the “corporate knowledge base”. When you are starting a new project, do you go back to that corporate knowledge base to cull through all the projects and see what might apply to the next project? No of course you don’t. That is why I recommend you would be better off to toss those lessons learned in the trash instead, as shown below.
3. Applicability – Even if you overcome the timing and accessibility challenges, the challenge you will likely face is the applicability of the lessons learned from project A to the next project, project B. Remember that by definition, projects are unique and temporary. The chances of the lessons learned from project A being applicable to project B are slim. The lessons may be valuable to a single project manager who takes what she learns from Project A and applies it to Project B. But no one else cares. No one else is going to be scouring the company interweb for applicable lessons learned. It would be a waste of time.

The most beneficial thing I’ve found from Kerth’s book is the Prime Directive. We’ve mentioned it before in other posts but it bears repeating here.

I first learned to use Norm Kerth’s Prime Directive to set the tone for my retrospectives when I was just starting as a Scrum Master. I still find it helpful and use it often.

Agile Retrospectives by Esther Derby and Diana Larsen

Norm’s book is great. A more applicable text for those using iteration-based agile development is Agile Retrospectives, by Esther Derby and Diana Larsen. This book is chock full of tips and techniques and it is an indispensable guide for those responsible for facilitating retrospectives.

Just one example of the value in this book is what I have come to call the 5-minute rule. The idea is that if people don’t participate within the first 5 minutes of the retrospective, they feel it is OK not to participate for the rest of the meeting.

When someone doesn’t speak at the beginning of the retrospective, that person has tacit permission to remain silent for the rest of the session.

— Esther Derby and Diana Larsen Agile Retrospectives: Making Good Teams Great

Another example of value from the book and one that I think is worth exploring is the idea that retrospectives in agile follow a pattern or set of steps. Leveraging these steps will help you to create better outcomes from your retrospectives and improve continuously. Here are the five stages from Derby and Larsen:

1. Set the Stage
2. Gather data
3. Generate insights
4. Decide what to do
5. Close the retrospective

In the sections that follow, I’ll explore the five stages of the retrospective and the common mistakes people make in leading them.

Your Retrospective Tutorial

So we have hired a volunteer to play the part of facilitator for a remote retrospective. She will take us through each of the 5 stages of the retrospective based on the book by Derby and Larsen. Her retrospective tutorial will show us first what not to do followed by what to do instead. Let’s dive in.

1. Setting the Stage

Setting the stage is all about creating an environment where people can share and learn from each other. Consider the following video example of things to avoid doing, followed by things to try doing when setting the stage for a retrospective. As you view the video, see if you can determine the points that the facilitator is making.

Here is what I noted from the video, based on each of these categories:

Avoid This in Setting the Stage:

• Arriving Late
• Blaming the last meeting for being late, rather than taking personal responsibility
• Negative language “Where things broke down”

Try This Instead:

• Welcome everyone
• Use a positive tone and energy
• Confirm who is in attendance
• Share the purpose of the retrospective
• Read Norm Kerth’s Prime Directive to create a sense of safety
• Ask for everyone to respond as a way to engage everyone in the first 5 minutes of the meeting

How did you do? Were you able to correctly identify what to do and what not to do? Let’s move on to the second stage of the Retrospective, Gathering Data.

2. Gathering Data

Gathering data is about collecting qualitative and quantitative data about the retrospective. Remember that we are using empiricism and data0-driven decision-making. So we want to be able to share the data within the team to help get everyone aligned.

(Note: For an in-depth look at the use of data-informed retrospectives, check out this article by Age of Product.)

Avoid This in the Gather Data Stage:

• Generalize – “I thought we all did pretty good”
• Vague and half-hearted invitation for team members to share

Try this Instead:

If you were meeting in person, a whiteboard, some sticky notes, and a handful of sharpies would be all the tools you needed for a retrospective. Today with remote teams, online tools are essential to support the retrospective. Avoid the tendency for one person to share their screen or take notes while everyone else is limited to just watching. (Or more likely, participants are multi-tasking because they are bored).

Instead, use online tools that allow everyone to participate and work in parallel. Here are some tools that you might find helpful:

• Miro – https://Miro.com and Mural – https://www.mural.com. Miro and Mural are popular whiteboarding tools. They will allow you to leverage most of the techniques you would use with a whiteboard in a room. (I have been told that Zoom has a built-in whiteboarding tool but I have not used it.)
• IdeaBoardz – https://ideaboardz.com – IdeaBoardz is a free online tool with several templates for retrospectives. Though free, I’ve experienced some performance issues.
• Parabol – https://www.parabol.co/ and Go Reflect – https://www.goreflect.com/. I’ve not personally used these tools but others have recommended them to me.
• Tasty Cupcakes – https://www.tastycupcakes.org/tag/retrospectives/. The Tasty Cupcakes site has a number of different ‘games’ or exercises teams can use to conduct their retrospectives. You will likely need to use one of the whiteboarding tools mentioned above to actually implement the game.

3. Generate Insights

In Generate Insights, the facilitator leads the team to go beneath surface symptoms and explore WHY things might be happening. From Derby and Larsen:

Lead the team to examine the conditions, interactions, and patterns that contributed to their success. Investigate breakdowns and deficiencies. Look for risks and unexpected events or outcomes. It’s easy for people to jump to solutions once problems emerge. First solutions may be correct, but often they’re not. The work of this phase is to consider additional possibilities, look at causes and effects, and think about them analytically. It’s also a time for the team to think together.

— Esther Derby and Diana Larsen Agile Retrospectives: Making Good Teams Great

Avoid This in the Generate Insights Stage:

• Poor facilitation style by biasing the team “I think we can all agree…”
• Blaming other teams for poor performance

Try this Instead:

• Encouraging the team to drill down on two events
• Reflecting back on what others said
• Going beneath the surface to identify root causes
• Inviting others to participate and share

4. Decide what to do

In deciding what to do, the facilitator leads the team to review all the options and make a decision on what to try to improve in the next sprint.

At this point, the team has a list of potential experiments and improvements. Now is the time to pick the top items (usually no more than one or two for an iteration) and plan what to do. Your primary job is to provide structure and guidance for your team to plan experiments and actions.

— Esther Derby and Diana Larsen Agile Retrospectives: Making Good Teams Great

It is quite common for a team to identify several different opportunities for improvement, which is great. However, it is not a great idea to try to change too many things at once. That tends to backfire, overwhelm the team, and result in few or no improvements being made. To avoid that, the facilitator should coach the team to narrow their ideas down to just one or two action items.

Another common mistake is to identify changes that others need to do, rather than orienting to changes that are within the team’s power. A good facilitator will help teams to shift the focus from external action.

Consider a team struggling with getting outside stakeholders to provide detailed acceptance criteria. Which of these actions is more likely to be successful:

• Stakeholders need to provide detailed acceptance criteria prior to the start of the sprint.
• The team will schedule a working session with the stakeholder to gather detailed acceptance criteria prior to the sprint.

Avoid this in the Deciding What to Do Stage:

• Create 15 new action items all get added to a growing list of improvements
• Vague invitation to make actions a priority

Try This Instead:

• Narrow down the list of 15 which would be overwhelming. Instead, select just 1 or 2 actions that the team can improve.
• Use Dot Voting to let the team decide what is the best course of action. This is a form of participatory decision-making that helps the team get buy-in and take ownership for their improvements.

5. Close the Retrospective

Closing the retrospective is just as important as setting the stage at the beginning. I’ve seen too many facilitators punt at the end, run out of time, or rush out the door. This can be avoided with good planning and skillful facilitation.

End the retrospective decisively: don’t let people (and their energy) dribble away. Decide how to document the experience and plan for follow-up.

— Esther Derby and Diana Larsen Agile Retrospectives: Making Good Teams Great

Another key is to make sure that the facilitator is not the owner of the action items from the retrospective. Those actions should be generated by the team, voted on by the team, and then owned by the team afterward.

The learnings belong to the team, and team members: not the coach, not the team lead, and not you as the retrospective leader. The team needs to own them.

— Esther Derby and Diana Larsen Agile Retrospectives: Making Good Teams Great

Avoid this in the Close the Retrospective Stage:

• Rushing or panicking
• Running over the timebox / running out of time
• Let people go if they need to – should not be a partial team exercise
• Abruptly ending the meeting and rushing out the door

Try this instead:

• Thank everyone
• Mention the action items that everyone agreed to and add those to the task board
• Invite them to end on a positive note by showing appreciation to each other.
• Stay calm, cool, and collected. Be present.

Summing It Up – Use this Retrospective Tutorial to Improve

Of course, our facilitator did a great job of demonstrating both what not to do and what to do. These facilitation skills are essential to anyone conducting retrospectives. They can be learned and improved. New team facilitators should invest time in observing others as they conduct retrospectives and practicing. Yes, it is that important.

I also recommend that new facilitators plan their retros in advance. Otherwise, it is easy for the meeting to go off track or run late. In fact, advance preparation is essential.

I hope you found this helpful. Of course, it is based on the great thinking from Esther Derby and Diana Larsen and their wonderful book. I find that book indispensable and agree with Derby and Larsen that facilitator that apply these tips will help their teams to:

• Understand different points of view.
• Follow a natural order of thinking.
• Take a comprehensive view of the team’s current methods and practices.
• Allow the discussion to go where it needs to go, rather than predetermining the outcome.
• Leave the retrospective with concrete action and experiments for the next iteration.

— Esther Derby and Diana Larsen Agile Retrospectives: Making Good Teams Great

In addition to their great ideas, one thing that I have found helpful is to plan out my retrospectives in advance. In a previous blog post, I shared a planning worksheet that I have used for my retrospectives. I use the worksheet to map out each of the stages above, how much time I am going to use and what techniques. This allows me to stay focused and present during the retrospective. You can see that planning worksheet on the backside of this tip sheet: Retrospective Tip Sheet.

I hope this helps and I welcome your comments.

This article originally appeared here and has been republished with permission

Business & Finance Articles on Business 2 Community

(39)