Are your team retrospectives successful?

The retrospective is an opportunity for teams to inspect and adapt to change in order to improve. It is an ongoing process to which the team needs to commit.

With Agile retrospectives, the team drives their own actions - By Ben Linders

Does your team practice Scrum and do you regularly perform retrospectives? If the answer is yes then I would like to ask: Have you ever thought about the success rate of your retrospectives?

I recently asked myself this question. I am a Scrum Master, and if I have to rate my retrospectives, what would my success rate be?  60/40, 70/30, or 80/20? This ratio depends on so many factors and assumptions, such as: 

• Team engagement.
• The outcome of the retrospective.
• How the team felt about it.
• How well the team utilized the allotted time.
• How efficient was the retrospective activity?
• What decision did the team reach?
• What were the derived action items?
• Did the retrospective meet the team's expectations?
• Did the team feel heard and valued?
• Was the retrospective activity interesting?
• Did the team have enough opportunity to provide feedback?
• Was the previous feedback incorporated?
• Did the retrospective activity help the team uncover any potential problem?
• Did at least a single team member walk away having learned something from the retrospective?
• How did the team evaluate the implemented actions from previous retrospectives?

Some might even argue that a retrospective can never fail. It depends on different perspectives, assumptions, and personal opinions. Some might even insist that it cannot be termed as a failure, but rather as learning. I do not reject any of these opinions. There is no right or wrong answer, it’s just a question of interpretation, and the success ratio depends on your point of view. If the team members are sharing thoughts, worries, and opinions in a constructive manner, then it will be dubbed a success. If you are the type of person that thinks retrospectives can never fail, then the success ratio for you will be 100/0. 

I was inquisitive about this question and wanted to validate what my fellow Scrum Team community members think, so I posted a poll on LinkedIn. I couldn’t include 100/0 as one of the options because of the question limit imposed by LinkedIn. 

I discovered some interesting views from fellow Scrum masters which bring different perspectives and are quite interesting. Should we even measure retrospective success and failure? Or should it just be an open space to share thoughts, worries and opinions in a constructive manner?

Failure can also be perceived as improvements that failed to be implemented.

Along with the poll, I did connect with other Agile minds, and they asked a few related questions which I would like to address.

What do failed retrospective meetings look like?

 Everyone can have a different point of view about what retrospective failure looks like to them.

Example 1: Lack of participation or a small number of people controlling the conversion. This boils down to the Scrum values of courage and openness. If the team is not provided with a safe environment in which they can express themselves and have an open discussion, team members will usually refrain from participating or, in some cases, only a few dominant team members will lead the entire conversation. This can be restricting and misrepresenting of the team's voice.

How can you help a team caught in this circumstance loosen up and have more honest conversations? I normally begin with energizers and allow each person a fair amount of time to share their experiences. I strive to be open and honest about my own experiences. Leading by example is the most effective method of showing that you are willing to speak your mind and that you are creating a secure environment for your team to do so. 

Calling out the silent team members and specifically asking for comments or opinions can help get the conversation rolling. Make sure you're not pressuring or pushing your teammates too much. 

One-on-one conversations with team members help identify or uncover any potential obstacles that might prevent them from engaging.

Example 2: Blame games can have a damaging impact on team members and lead to a retrospective failure.

How do you get the team to recognize that the focus should be on the problem rather than the person? Shifting the emphasis away from a person and toward a problem might help the team provide constructive comments and find solutions and ways to improve the process. As a facilitator, ask the group to share what they would do differently in the future to avoid the problem. This will allow the team to concentrate on finding answers rather than argue about who is to blame. It's critical to recognize that a decision is made with the best of intentions and knowledge available at the time.

What will my retrospective success rate be?

I would say 80/20. Before exploring this topic, I would have settled for 60/40 or 70/30, but after speaking with other Scrum Team members, I realized that the retrospective was a success, even if it was a learning experience for me. Because the retrospective meeting can be considered a success even if just one person learned something from it.

What have I learned from retrospective meetings as a Scrum Master?

With years of experience, I have learned a lot as a Scrum Master, but retrospectives in particular taught me a few important things:

1. Time management is an act of balancing keeping track of time, while still giving the team ample opportunity to express. 
2. Invest in exploring new ways for the team to collaborate. Experiment with facilitation skills. 
3. Prepare beforehand for retrospective meetings, but be prepared and willing to alter the plan depending on the team's current state of mind, availability, or other such influencing factors.
4. Ask for feedback and do not just assume the team will volunteer it. Feedback always helps me get a clear indication of whether I need to change the course.

How do I plan for my retrospectives?

I always experiment with retrospective activities to make sure they contain a surprise element for the team. I do invest time in selecting the retrospective activity, but not all of the activities are a success. Even after putting time and effort into the thought process, some retrospectives will inevitably be dull, unengaging, or disconnected. Luckily, most retrospectives hit the right chord, are engaging, and the team feels connected. In short, the retrospective activity guides the team to uncover the potential problems.

I start my retrospective with a check-in activity, some simple energizers to help the team relax, open up. I provide the team with a space to express their emotions. This is followed by a segment for recognitions, retrospective activity, and ends with a feedback activity. I encourage the team to also bring forward their personal side, not just their professional identity. If I have 60 minutes to plan the retrospective, it will look something like this:

• Check-in activity - 10/15 min
• Team recognition - 10/15min
• Retrospective activity - 30/45 min
• Followed by feedback - 5 min

If you add up the times and err on the side of caution, you will have more than 60 minutes planned. I always set the team expectation on trying to timebox in order to help them stay focused, but at the same time, I also need to keep it free-flowing. The balancing act is really important here. Retrospectives should not be done under pressure; they have to be fun, interactive sessions that the team enjoys attending. I also document my retrospectives so that I can refer to them later. I find it amusing how much I have learned from my past experiences.

Who is responsible for the success of the retrospective?

Allow me to take some of the strain off the Scrum Master’s shoulders. They are just a person or a medium who does his or her best to support the activity and provide a platform and place for the team to work together to progress.

The retrospective’s success is the team’s responsibility, and each member must contribute to the success. A Scrum Master is the person who best facilitates the event, but he or she cannot be the only one who contributes to its success. The Scrum Master is responsible for coaching the team about the value and potential of retrospectives in order to benefit from them. 

I would like to engage with my readers to understand what their take on the success of retrospectives is. It will be interesting to have a conversation on this topic to explore more perspectives. I highly value retrospectives and truly believe in their potential to help a team improve, progress, and evolve.