I spoke recently on the topic of retrospectives and continuous improvement. Readers of this blog may recall that I have written no less than 10 articles on this site 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.
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.
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.
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:
In the sections that follow, I’ll explore the five stages of the retrospective and the common mistakes people make in leading them.
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.
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:
Try This Instead:
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.
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:
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:
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:
Try this Instead:
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:
Avoid this in the Deciding What to Do Stage:
Try This Instead:
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:
Try this instead:
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.