If you don’t engage your development team in a way that will allow effortless information flow 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 that 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 probably turn to your favourite format hoping that no one notices.
The mode average for delivery cycles is 2 weeks, so after a year your team may have sat through 26 identically formatted retros. 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 frequently 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.
If even some of this sounds familiar, you need to make changes.
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. When retro prep gets left to the last moment, important action points are lost.
To fix 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.
Scatterspoke can help, with multiple 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 to them”, this may very well be the underlying reason.
We go into retros with big ambitions, but sometimes leave with a deflating reminder of the hierarchical corporate structure we work in, having seen brilliant ideas die before the retro even ended. All too often, we bring up things that need to change never only to see those things never mentioned again.
It’s also too easy to fall into the trap of implementing only the changes that are under your or the team’s control while 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.
It doesn’t need to be like this.
What can I do?
To start, make sure that when items are raised, you ask open questions using the “T-E-D” mnemonic (Tell, Explain, Describe). For example, “Tell me what we could do to resolve this” or “Explain the steps that we could take to make this better”. Ensure the actions are not only captured, but exist somewhere they are likely to be acted on.
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 the equivalent location within the team that needs to get it done.
If it’s something that needs to be resolved at the management level, consider creating a kanban board for them if one doesn’t already exist. Or, you can try 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 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 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 common trope that “developers are introverts”, but many simply save their verbal contributions for the times when they think they will be most effective. If you actually work with developers, you’ll know that they commonly have strongly held opinions and often aren’t afraid to voice them.
Because of this, one voice can easily dominant the room, but sometimes the best ideas come from the quietest voices.
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 more active team members outside 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, it’s also 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.