How many times have you found yourself engaged in a retrospective, wondering why do you lose all this time? How many times have you committed to action items that no one ever dealt with in any way? How many times have you caught your team or yourself discussing the same issues again and again thinking that this will not be the last time?
Retrospectives are very hard-to-drive meetings. The hurdles to overcome are countless. Team members that will not open up, team members that dominate the conversation, inability to identify root causes, lack of commitment to action items, frustration and politics, just to name a few. Sometimes the Jocker (Scrum Master) has to display a great arsenal to keep all of these under control and - above all - meaningful.
My intention in this blog post is to share part of the knowledge, experience and lessons learned by driving retrospectives. Despite mainly referring to people facilitating these sessions (Scrum Masters), I believe that all members of a scrum team could benefit by it. Throughout this post, I will be referring to sprint retrospectives, but these principles, more or less apply to all kinds of retrospectives (release retrospectives, departmental retrospectives etc).
# The Goal
Before we even begin talking about how to carry out successful retrospectives, let’s think for a moment why we have them in the first place. This meeting is a key part of the ever ending inspect and adapt loop. It’s the team’s official slot reserved for thinking what we did during the last sprint and how could we improve it.
Bear in mind that this is the last resort for improvement. The proper moment is any moment. As soon as we know that something could be improved, we should try to improve it right away. When you come across any pain point, don’t forget that the retrospective is now! However, this runs the great risk of never prioritizing and never doing it and therefore, the sprint retrospective is there to force us to work on these issues.
The goal of a retrospective is to produce action items
# Structure
One of the great pitfalls to be avoided is not preparing a retrospective before facilitating it. Structure and preparation are key to the success of the retrospective and there is a reason for it. Team members often get emotional or carried away when engaged in retrospective conversations (they are supposed to after all) and it can be very easy to lose sight of the goal and spend the session in a meaningless way.
Always make sure that you know exactly how the session unfolds relative to the schedule. Is it going too slow? Are we spending too much time on this topic? How far behind are we? Can we cover it and in which way? Always make sure that there is enough time to reach to action items.
In an ideal situation, a mature team should be able to walk into the retrospective and just share their thoughts, drive the discussion to conclusions and action items, commit on working on them and move on with the following sprint. However, since this is barely realistic, I always use exercises to put the team in the right context and help them focus on identifying strengths and weaknesses. An excellent source of exercises is retromat. In the vast majority of the retrospectives I have facilitated, I have broken the structure down to the following five sections.
# Set the stage
Usually, 5-10 minutes for a 90-minute retrospective, depending on the team size
Take the time to communicate the purpose of the session and the schedule. It may sound redundant, but it will help the team members orient themselves during the retrospective and focus on the task in hand for the following period of time.
Usually, I ask for a very brief check-in phrase or input (e.g. describe the previous sprint in 3 words). Simplistic as it may sound, keep in mind that there may be people in the room that are hard to open up. As Scrum Masters, we should always make sure that every team member feels comfortable to speak and is engaged in the team exercise. This is what I focus on during this short phase. Get everyone onboard for what’s about to follow.
# Gather data
Usually, 20-25 minutes for a 90-minute retrospective, depending on the team size
This is the time to identify what went wrong (or could just be improved) and what did the team do well (this is also very important).
Use an exercise that focuses on plain facts. Ask for both negative and positive facts. As it is important to amend any problematic areas, it is equally important to preserve the good habits. Preferably, before discussing, allow the team some time to silently think and jot down a few things on sticky notes, in order to avoid affecting each other’s thought in this part. If necessary, you may feed the team by mentioning one or two defective ares that you recognized during the sprint, prior to the exercise, to get them going and accelerate results, but be very careful not to guide them.
This is an extremely important step, as it will feed the rest of the retrospective with data. If the team fails to come up with the right issues here, it is almost inevitable that the real issues will remain untouched, no matter how great the effort in the rest of the session.
# Generate insights
Usually, 20-25 minutes for a 90-minute retrospective, depending on the team size
Having identified the major pain points in the previous step, it’s time to address them. The point of this step is to come up with potential solutions to these pain points, but do not neglect to preserve the good habits as well.
Pick an exercise to help the team interpret the data gathered from the previous step and come up with action items to both address the problems and preserve the good habits. Usually, I avoid a lot of conversation and interaction up to this point to keep the process of gathering the data impartial, but this is the point to allow collaboration to kick in (e.g. working in pairs or have a lot of conversation). Make sure the team members are interacting in a productive way. If the items from the previous step are too many, ask the team to prioritize them and work the list top to bottom until the allocated time (or the list) runs out. Ideally, by the end of this step a list with ideas (solutions to problems, things to start/stop/continue doing etc) is composed and lies visible to the team (e.g. sticky notes on the wall, whiteboard etc).
Always keep in mind that this is the very heart of the retrospective. Tension may be caused, strong arguments may take place. This is healthy and desired, but always make sure that the situation is under control and is actually going somewhere. As a Scrum Master, make sure that personal attacks are avoided, only productive arguments are hold and the team mainly deals with items that is actually empowered to change.
# Decide what to do
Usually, 20-25 minutes for a 90-minute retrospective, depending on the team size
Presumably, most of the hard work is over. A list of action items is in the team’s hands. What is left is to decide on a reasonable amount of action items to work on the upcoming sprint.
In this step, I always like using exercises that foster collaboration (and conversation) and create clear, unambiguous results. For instance, an impediments cup facilitates prioritizing action items, creating a clear result and engage in discussion while doing so.
Basically, this is a matter of prioritization. All action items are useful, but the team has to commit to a reasonable number of them. This depends on a lot of factors (size of the team, difficulty of the action item, sprint length etc). Make sure that the decisions are taken collaboratively (but not chase after consent, as it can kill the retrospective) and the reasons for them are clear to the team. Additionally, be very careful not to use a process that creates winners and losers, as this can hurt morale.
# Close the retrospective
Usually, 5-10 minutes for a 90-minute retrospective, depending on the team size
This step can be used to both get feedback on the retrospective and close the session in a light tone. It’s very likely that as problems surfaced, people opened up, things got tense and there were disagreements. This was very desired indeed, but as the session draws to a close, the point is to leave all these behind, keep all the hard work and close in a good mood in order to begin the next sprint.
Any very brief exercise will do for this part. Just make sure that as you achieve the above-mentioned goal, you’re not tiring an already exhausted team. Preferably, choose a fun and invigorating exercise.
# SMART action items
Perhaps the biggest pitfall for a retrospective is to come up with action items that are not SMART. There is a huge difference between action items and wishful thinking. For instance, consider the following two outcomes of a team’s retrospective:
Improve collective ownership of the code.
No self merges. All code will be reviewed by at least one more engineer before being merged. Bob will monitor it and in the next retrospective will let us know if we succeeded or not.
Do you see the difference? For an action item to be meaningful, it has to be:
- Specific
- Measurable
- Agreed upon
- Realistic
- Trackable
# Dealing with silent team members
Getting people to open up can be one of the trickiest tasks for a Scrum Master, but it constitutes a key ingredient for a fruitful retrospective. People may be quiet due to their personality or because they choose to remain silent for their own purposes. Both cases are difficult to handle, but each requires a different approach.
When dealing with team members that are shy or not very outgoing, remember to work hard with them while setting the stage. Before leaving this step, make sure that they have shared something with the group. This will make them feel more engaged and will increase the probability that they will share more during the retrospective. If necessary, during the retrospective, explicitly ask them to comment on a topic, especially if you know that they have an opinion on the matter, but they are obviously reluctant to share it.
When people remain silent driven by politics, the spectrum of options is considerably narrowed down. What I feel is useful is to state once again that the purpose of this session is to improve as a team and in order to do so, sincere input and respect by everyone is a prerequisite. However, an individual who chooses to play his own game most likely will not change his path by such a speech. I would also suggest to drive the rest of the team to open her up.
# Dealing with team members that dominate the conversation
On the other hand, having a team member that simply dominates all conversation is a definite disaster for the outcome of the retrospective. A team member may do so either wittingly or unwittingly. In any case, find a suitable point in her speech and interrupt her. Make sure you are very polite, but firmly explain that this session cannot work like this and the team will lose sight of the goal in this manner. Strive to achieve that discussion is as evenly as possible distributed throughout the group and all have a fair chance of expressing themselves.
This is not an easy situation to be in. No matter how polite you are, chances are that the person you interrupt will feel offended (even if she doesn’t show it), but do not yield to this thought. In the past, I have driven retrospectives that suffered for this exact reason, because I never summoned up the courage to interrupt this person. Hopefully, I’ve learned from my mistakes.
# Keep the conversation productive
The moment the conversation is derailed, the retrospective is immediately jeopardized. Having team members aimlessly discussing instead of trying to reach to the root cause of problems and solve them can be a disaster. Personal attacks and conflicts can cause this. Make sure that you are very strict on this and put the team back on track as soon as you realize it. Additionally, discussing on items that are out of the team’s reach can also kill the retrospective. Make sure that you spend no time on such topics.
A team that tends to frequently focus on items outside of its power is in danger of essentially wasting retrospective after retrospective dealing with issues that they will never be able to solve. Also, as they are convinced that an external factor is slowing them down, they run the risk of lowering their own morale and start feeling underprivileged. Kill this as soon as you notice it. No matter how disastrous these external factors are, this is the time to focus on improving the internal team functioning. An excellent exercise to help you with this is Circles & Soup.
# Avoid creating a routine
As soon as retrospective starts feeling like a routine, do something to disrupt this. During this session, we want team members to be creative and think outside of the box. A routine is the worst enemy of this.
Always strive to keep the team energized and keep the blood flowing. Use exercises that require standing up and walking in the room. Keep it playful. If possible, change the room or the time the retrospective takes place. Whatever you do, do not create a routine.
# Conclusion
Driving a retrospective is a very tricky business. However, retrospectives are key to the healthy functioning of an Agile team. Make sure to prepare beforehand and constantly keep in mind that the team should be after SMART action items. Don’t let it be derailed and the hard work is definitely going to pay off. Finally, never forget. The retrospective is now.
P.S. Feel free to share your thoughts or comment on mine. As always, I would very much love a nice, productive conversation on the topic.