Why Your Developers Hate Retrospectives (And How To Get Them To Fall In Love Again)

The way some developers feel about sitting through a retrospective is the same way most cats feel about sitting in water — they’d really rather not.

As far as some developers are concerned, retrospectives…

⏰ Are often seen as a waste of time

😴 Can be boring

🗣️ Often lack participation

👎 Rarely result in positive change

This mindset can lead to lackluster efforts from the team and can result in a downward spiral of low productivity and motivation. It is possible, however, to reverse that cycle and make retrospectives a key part of your team’s success.

From insights to improvements, developers can benefit greatly from successful retrospectives — after all, it’s developers who created them in the first place. So, when and how does the love start to fade?

The Beginning of Retrospective Reluctance

For some developers, the beginning of the end may have started with a series of bad facilitators and a few repetitive, surface-level conversations about how the recent sprint went and how processes could be improved. For others, the demise may have started with questions answered with silence and awkward sighs.

Mike Cohn from Mountain Goat Software shares some common reasons that he’s heard directly from developers as an attempt to avoid retrospectives post sprint. Reasons include: the team doesn’t need them, retrospectives are too boring, the team is too busy, and the team just doesn’t like them.

The culprit? Retrospectives that are poorly facilitated.

From the perspective of the developer, poorly facilitated retrospectives aren’t just boring but can be a waste of time and kind of a buzzkill to creativity, especially when a developer is heads down in code. Developers are under a lot of pressure to constantly innovate, but then are pulled from this concentration to sit through a retrospective. Normally, the opportunity to reflect and expand on the work done thus far while taking a step back to view the bigger picture would be a good thing. However, when they lack quality facilitation, retrospectives can do more harm than good. What would’ve been a chance for developers to speak up and honestly about the successes and pitfalls of a project can become another task to check off their long list of to do’s.

But having one bad cup of coffee doesn’t mean all coffee should be avoided from this point forward.

In fact, receiving a great cup of joe from someone who knows their way around a french press is an entirely different experience that some may even describe as “life-changing”.

Until tasting the potential and the benefits that quality coffee has to offer, it’s easy to see it as a potential waste of time. It’s time that developers are introduced to good coffee, err… retrospectives.

The Benefits Of Well-Facilitated Retrospectives

To repeat the same process but still expect change to occur is both unproductive and just plain silly. Which, in a sense, are the solutions that software developers were pondering when they came up with the agile concept — reflection, adaptation, and most importantly, improvement.

Not only can retrospectives be helpful on a larger scale relating to company growth, but they are also helpful to each individual employee, as they create a safe space for valid feedback and provide a sense of empowerment. Agile puts power in the hands of the team as they work to solve their own problems and create solutions for the team, by the team.

Quality retrospectives can often double as morale boosters, giving a team of developers a chance to express that they value one-another, naturally strengthen bonds, and create a better work culture. An article recently shared by Forbes showed that employees react more to a sense of purpose than just pay when it comes to productivity in the workplace.

To those who argue that retrospectives are a waste of time, you may want to sit down for this one… While retrospectives take time to complete, they’re actually more of a time-saver than they are wasters.

How?

By allowing for continuous improvement — a long-term investment in the team. Teams are able to learn from mistakes and work together to discuss ideas and topics that wouldn’t have otherwise organically surfaced, which saves time and money.

According to a study by Comparative Agility, higher performing teams consistently indicated higher scores regarding their retrospectives than their average peers. In other words, there is a positive correlation between teams that report their retrospectives are effective, and those who perform well on key business outcomes related to speed, quality improvement and customer satisfaction (the composite metric).

They can show in their data that teams that do well on business outcomes, also tend to report they are doing retrospectives more effectively than their average peers. It is therefore a good idea to take retrospectives seriously – teams that do indicate they perform better than their peers.

The plots below show the difference in “contribution margin” of Pearson Correlation coefficients between high performing teams and “average” (all) teams. The “bluer” and narrower the dot, the stronger the correlation between a given attribute and our outcome composite metric (which was self-reported.)

How To Rekindle The Developer-Retrospective Relationship

If teams groan at the prospect of entering another retrospective, it’s time to change the way those retrospectives are facilitated.

Run a Retrospective on Your Retrospectives

Development teams can have many positives to gain from retrospectives, but unfortunately this only holds true if the retrospective itself has something to give. If a retrospective isn’t working for the team, then it needs to be discussed. Think inception retrospective style — try running a retrospective on your retrospective.

By allowing the team to give their opinions on the facilitation and structure of their retrospectives, the power is put back in their hands. A great place to start running more quality retrospectives is by heading back to the basics with the 5 Phases of a Successful Retrospective:

Set the Stage: Give the team a chance to “check-in” before diving into the main topics. This helps team members get into a focused mindset and encourages participation.
Gather Feedback: By sharing and understanding feedback collected since the last retrospective, team members are more easily able to concretely view which processes are working and which ones aren’t.
Generate Insights: Once the feedback has been collected and analyzed, the team can collaboratively develop insights based on the information.
Decide What to Do: Now that all feedback has been collected, analyzed, and discussed, it’s time to come up with a plan for improvement. The team can use this step to consider what their goal is, which processes are helping them get there, and beyond that, what more can be done to reach that goal.
Close the Retrospective: It’s suggested to take one more opportunity to reflect on everything that’s been discussed, giving team members another chance to speak their truth.

Foster Psychological Safety

Great facilitators regularly check in on team members to get a sense of how they are feeling. If the facilitator senses that their team is holding back from speaking openly about their thoughts, it may be because they don’t feel safe enough to do so. By establishing early on that each team member’s opinions are valued and that nothing negative will come from expressing them, the team should feel more inclined to participate with honesty.

Mad-sad-glad is a great technique that only requires team members to assign an emotion with an occurrence during the sprint, to get an overall idea of what’s working well and what isn’t. This method is a great way to allow team members to think about their feelings as opposed to commenting on specific occurrences in a sprint, which may be intimidating for the more introverted members.

Liven Up Your Retrospective Routine

Games and ice-breakers are a great way to put the fun back in retrospectives and give team members an energy boost. Games can provide a sense of trust and communication, two things a retrospective struggles to be successful without.

Marie Prokopets, Co-founder of FYI, developed a list of 10 retrospective game ideas that will help shake up any retrospective. Some of these games include:

Back to Back: A game where team members sit on the floor (you guessed it!) back to back with their arms linked, and then try to stand up together. It’s harder than it sounds and forces team members to physically work together in order to complete a task.
One Word: An exercise where the facilitator reads a variety of topics, words, or specific occurrences related to the sprint, and each team member anonymously writes down one word that comes to mind. Everyone then reads their word out loud and then discusses, noting patterns and interesting thought-processes.
Two Truths And A Lie: This fun, lighthearted game is a great way to ease any potential tension and promote team bonding. In this game, each team member shares three facts about themselves, but only two of them are true. The team then has to guess which one is the lie. This can be a fun way to better get to know everyone on the team and share potential fun facts or stories with each other before diving into more serious matters.

Prove Value By Making Follow-Through A Priority

At the end of the day, the best way to encourage a developer to love retrospectives again is to help them see the value they hold. Developers can begin to look forward to each week’s retrospective, knowing there will be a new team challenge to tackle collaboratively and a chance to speak their minds.

Following-through on action items can be a great way to prove the effectiveness of each meeting and give team members a better sense of purpose.

To do this, it’s recommended to add the action plan from each retrospective to the top of a sprint backlog and begin each daily scrum discussing the progress of each action. Both of these practices can help keep action top-of-mind while encouraging their completion. Coupled with a retrospective routine, this method allows the team to think in the mindset of continuous improvement.

Before long, your developers will look forward to retrospectives, knowing they’re about to have a chance to input ideas, have their voices heard, build a stronger team, and see positive results. After all, that’s what a retrospective is for!

Next Up: To start on the journey of improving the trust levels among team members, take a read through How To Build Trust Outside Of Your Retrospectives.