Why Developers Hate Retrospectives

How many times have you heard one of the following questions?

• Could we skip the retro this week?
• What about doing the retro every second or third Sprint?
• Could we postpone our retro?
• What’s the benefit of retros?
• I’ve got a lot to do. Would it be okay if I don’t attend the retro today?

I bet you’ve stumbled upon some of these questions if you’ve worked with Scrum teams. They often come from developers because they usually hate Sprint Retrospectives.

Developers search for excuses to skip retros when they see it as a waste of time.

Over the last few years, I identified four common patterns contributing to developers’ attitudes towards retrospectives, and I’d like to share them with you. Also, I will give you some hints on how to get developers interested in retrospectives.

#1 Mechanical Retro

How does your Sprint retrospective run? Please, don’t tell me you always use the same dynamic. When I first learned about Scrum, I had a hybrid scrum role, Product Owner and Scrum Master (which I don’t recommend, but it’s another story). I was inexperienced and got to know the following:

Retrospectives are used to evaluate what worked and didn’t and then discuss upcoming risks and opportunities. 

Well, I moderated several retrospectives with the same questions always. In the beginning, everyone was eager to answer such questions, but after three times, our retros became monotonous. It was mechanical; we had no surprise, everyone knew how our session would be, and nobody was eager to attend it any longer.

Mechanical retrospectives drain the team’s energy. Ensure you vary your sessions and keep a surprising element.

#2 External Factors

What do you do with your discoveries from the retrospectives? Ideally, you take actions that improve your scenario and strengthen your team. However, this is tricky because you may discover something and be powerless to solve it. This will create frustration if the same topic pops up every Sprint Retrospective.

Let me give you one example. For five retros in a roll, the team brought up the same topic, “DevOps is blocking us from shipping our features.” The problem is that DevOps was a separate team; in other words, it was outside our circle of control. We could have an influence but could not guarantee the change we wanted. The team was tired of this situation and disengaged from our retros.

During your retrospectives, be aware of your circle of influence and define actions where you have control. You will need a different strategy to deal with items outside your circle of control.

By defining actions inside your circle of control, you give the team the power to become a stronger team every Sprint.

#3 Low Energy

Is the Sprint Retrospective “distracting” the team from getting their work done? If so, you can expect the event to have a low energy level and therefore be disengaging. It’s the meeting everyone wants to run away from.

I’ve identified some reasons that contribute to low energy during retros:

• Overloaded Sprint: The team has more on their plate than they can sustainably handle, and the retro gets in the way.
• Bad Experiences: Last retros contributed to bad moments with the team. Either the moderation failed, or team members lost eye-level contact with each other.
• Parallel Activities: Everyone is present in the retrospective and doing another activity simultaneously, yet nobody provides feedback.
• Camera Turned Off: Remote team members turn their cameras off for any reason, creating distance from the other participants.

When you face any of the above points, the energy will be low, and team members will stop caring about retros. The good news is that such issues are in your circle of control, and you can change them.

#4 Nobody Cares About Actions

The output of great retrospectives is sound actions. The team knows how the agreed actions help them become a better team. Sounds obvious, but it’s easy to mess around with activities.

Some questions for you: 

• How many action items do you define per retrospective?
• How often do you conclude all actions during the upcoming Sprint?
• How do you navigate the actions during your retrospective?

A flawed approach would be defining actions and ignoring them during the Sprint. Another common anti-pattern is to flood the team with actions and not take the first step to act in any of them. Also, teams often define actions poorly and forget why they created them in the first place.

Actions are vital for retrospectives. Ensure you create compelling ones, leave space during the Sprint to address them, and navigate during each retrospective.

Until you evaluate the results of your actions, teams will continuously perceive retrospectives as a waste of time.

Outstanding Retrospectives

Retrospectives don’t have to be a time-waster. You can design it for success, but you need to have the right ingredients available for a good recipe. Here are the key ones:

• Sprints are well-balanced, and teams don’t have to work until the last minute to get their work done.
• Sprints have space to address actions derived from retrospectives.
• You’ve got an excellent facilitator to engage participants during retrospectives.
• You have access to multiple retrospectives dynamics.
• Remote team members keep their cameras on.
• Everyone respects the time and does not do any parallel activity during retrospectives.
• Build expectations by creating a recurrent activity that team members look forward to. Help them have fun with it. You can gamify your retros, for example, the meme of the week or any other fun and engaging exercise.

Considering you have these aspects in place, having sound retrospectives becomes simple. I like having the following structure:

• Warm-Up: Take a moment to help the team arrive at the session. You can be creative; use a short game, a quiz, or anything they can have fun with will do the job. This should take 5 to 10 minutes.
• Tune In: Give everyone a chance to share how they come into the session. Ensure you vary from retro to retro. I like asking the team to describe the previous Sprint with an image, a song, or three words, and sometimes asking them to rate the last Sprint in a matrix with collaboration and results. The tune should take from 10 to 15 minutes.
• Navigate on Actions: Evaluate how the team addressed the actions. Keep this part simple. It’s essential to agree on what’s done, in progress, and obsolete. This part should take from 5 to 10 minutes.
• Discovery: The fourth part is the moment to be creative and use different dynamics. You can use simple things like what to keep, improve, start, and drop. Or you can be as creative as you want; it’s the moment to engage with the team and identify opportunities to become a stronger team. This is the core of your session, and it should take a minimum of 30 minutes.
• Create Actions: As you discovered how the Sprint went from the lenses of everyone, it’s time to agree on what to address. Ensure you don’t overwhelm the team, take from one to three actions; that’s enough to ensure progress. Ensure you give proper time for this part; generally, 15 minutes will do.
• Tune Out: After defining the actions, take a moment to let the team close the Sprint. Take at least 10 minutes for this part. You should also vary during this part. Some examples are Kudos cards, confidence level for upcoming Sprint, rate of the value created during the session, etc.

Within the new normal, you can benefit from digital tools like GoRetro. It will speed up your preparation and ensure you benefit from updated and engaging boards.

Final Thoughts

Developers don’t hate retrospectives; they hate BAD retrospectives. Nobody enjoys doing something that they don’t see value in. Whenever you realize developers are giving excuses for not attending retros, it’s a sign you have a problem, and you need to address it. As Stephen Covey said: 

“First seek to understand, then to be understood.”

Retrospectives can be engaging and outstanding if you:

• Have the right tools for it.
• Take adequate time to prepare.
• Ensure actions are created and navigated.
• Facilitate mindfully and engage the team.