Developers Hate Your Retros

Here’s a secret you didn’t know: Developers hate your retros. Not all developers and hopefully not all of your retros, but at some point, a developer has sat in one of your meetings and thought “this retro sucks”. You might wonder if this is a problem, but at the heart of agile lies one key concept, continuous improvement.

John Samuelson

October 19, 2021
6 mins

If you don’t engage your development team in the right way, a way that will allow an effortless flow of information in a non-judgemental environment, your teams will stagnate, your delivery will flatline and you will be an agile team in name only.

It’s the same format every time

One sure-fire reason that developers hate your retros is when they are exactly the same every time.

Sure, we all have the best intentions to create beautifully bespoke, gamified and tailored retro formats, but when you’ve been in back to back meetings all week, with no time to prepare and your retro meeting is about to begin, you turn to your favourite format hoping that no one notices.  For many people it’s “Went well, needs improvement, actions”, but you will know your own natural preference.  

The mode average for delivery cycles is 2 weeks, so after a year your team may have sat through 26 retros all of the same format. Familiarity can breed contempt and asking the same questions, in the same way, can often lead to the same answers.  

Repeating the same format can often lead to so-called “pat on the back” retros or “nothing” retros where people turn up, go through the motions, point out a few things that went well and then get back to coding.

What can I do?

The most comprehensive retros operate on a continuous basis, allowing thoughts to be captured throughout the delivery period, rather than everyone scrambling to remember something meaningful in the first 5 minutes of the meeting (and inevitably, important action points being lost as a result).  

In order to do this, create your next retro board immediately after the conclusion of the previous meeting. This gives you a great opportunity to choose a fresh new format to keep the team engaged and so you will be prompted to choose a different format and keep things fresh.

Scatterspoke can help, with multiple different suggested formats available to use and the ability to create a custom approach depending on your team’s preference or the current operational needs and topics affecting the team.

The things they raise never get done

If developers hate your retros because “there’s no point in them” then this may very well be the underlying reason.

We go into retros with the ambition to change the world, but sometimes we leave with a deflating reminder of the hierarchical corporate structure we work in, having defeated brilliant ideas before the retro has even ended.  All too often we make a wish list of things that need to change but these things never get discussed any further than the retro they were raised in.  It doesn’t need to be like this.

It’s too easy to fall into the trap of implementing only the changes that are under your or the team’s control, whilst ignoring important changes outside of the remit of the team. As an example, you might successfully resolve an issue raised in your retro that “blocked items aren’t clearly highlighted” by implementing an extra column on the board but fail to address the flaky CI pipeline (which causes hours of delays every release) because it’s owned by the platform team.

What can I do?

Make sure that when items are raised, you ask open questions using the “T-E-D” mnemonic (Tell, Explain, Describe) such as “Tell me what we could do to resolve this” or  “Explain the steps that we could take to make this better”.  Make sure the actions are captured, but not only captured, make sure they exist somewhere they are likely to be progressed…

For items at the team level, consider adding them to your workflow tool as deliverables within the next sprint or delivery period, then the team will be looking at them every day. If an item needs resolving outside of the team, find out what the equivalent location is in the team where the work needs to be done.

If it is something that needs to be resolved at management level, consider creating a kanban board for your management team if one doesn’t exist, or a team impediments board where actions can be made transparent and assigned at the appropriate level.  This will allow the team to see that their improvement ideas are being taken seriously and also let them track the progress.

One popular new feature of Scatterspoke, Team Pulse, addresses a common “catch 22” situation by allowing common retro themes to be shared with the management team in an anonymised way, without breaking the safe space and confidential nature of the retrospective.

It’s the same people talking every time

Developers hate your retros when the same person dominates the meeting every time, raising only the issues that are important to them and proposing only their solutions.

It’s a commonly trotted out trope that “developers are introverts”, but many developers simply save their verbal contributions for the times when they think they will be most effective. If you’ve worked with many developers you will know that they commonly have strongly held opinions and often aren’t afraid to voice them.

It’s because of this propensity to have strong views that there can be occurrences where one voice becomes the most dominant in the room, but sometimes the best ideas come from the quietest voices.  If you’ve not noticed that the same person is repeatedly talking for most of the retro, chances are that person might be you!

What can I do?

Good facilitation can help resolve this issue. A great way to start a retro is to go around the table asking everyone what they would like to achieve from the meeting, or what they think the purpose of the retro should be. When people have spoken once in a meeting they tend to be more willing to speak again.

Try speaking to the people that tend to have the louder voices separately from the retro and ask them to support you in engaging the quieter members of the team. This will allow you to gain a more balanced set of views. You can use phrases such as “thanks for that input, does anyone else have anything to add to this?”

If you notice someone who rarely speaks, due to the small number of participants it’s perfectly fine to address that person directly in the meeting to get their views. As developers learn their opinion is valued they will start to contribute more.


Keep an eye on the engagement levels in your retros to ensure that they haven’t stagnated. Remember that continuous improvement is a cornerstone of agile and that this should also apply to the retro itself.  Mix it up with different formats, involve everyone in the discussion and make sure those actions go to the right place and are tracked, visible and followed up on.  

If you do all these things you will be on the right track to engaging, meaningful and impactful retros.