Have you ever tried to make a complicated meal without a recipe? If you’re not culinarily inclined, it can be risky. Recipes can be an amateur cook’s best friend because they’re tested and proven.
To solve a complex problem, you want to steer clear of anti-patterns, which are essentially documented recipes for failure. Paying attention to anti-patterns means you get the advantage of learning from others’ mistakes.
When it comes to retrospectives, there are some tactics or “recipes” that have proven to be flops. Thanks to past experience, we know which unhelpful solutions to avoid, allowing teams to bypass problematic situations and keep the focus on continuous learning and improvement.
Here are five agile retrospective anti-patterns and what to do if you find your team dealing with them.
1. The unstructured retro
The scenario
These are the retrospective meetings without clearly defined stages, where the goal of the meeting gets lost, and the team’s discussion veers off topic without arriving at clear action items.
Just as you probably wouldn’t set out on a road trip without a map, you wouldn’t enter into a retrospective without a plan. Retrospectives shouldn’t be so rigid that they don’t allow for free discussion, but each stage in the meeting should lead the team closer to action.
How to fix it
Especially for distributed teams, the right tool can provide needed structure and keep the team focused on the end goal: action items.
“I do find having a tool indispensable,” says Melaina Oak, scrum master at a large nonprofit focused on conservation. Oak has a fully distributed team and has tried a number of online tools for conducting retrospectives. “It really helps having something that moves you through the stages, from welcome and why, to discussing, to voting.”
Using Retrium allows Oak’s team to focus only on the stage at hand, preventing team members from skipping ahead to voting before the rest of the group is done generating ideas.
2. The complaining retro
The scenario
In these retros, too much time is spent complaining, blaming or finger-pointing.
When emotions are running high or projects become stressful, it can be easier for teams to focus on the negative.
Complaining in meetings actually inhibits the generation of ideas, one study found.
And complaints can be a slippery slope. Research shows that one person’s complaining can create a cognitive burden on others in the conversation, starting a domino effect because the listeners want to reduce that cognitive burden by complaining themselves.
How to fix it
Let’s start with what doesn’t work: When complaints arise, simply forbidding people from complaining or telling them to “think positive” doesn’t do much, studies show.
Researchers found that leaders were able to prevent complaining behavior in team meetings by making sure teams felt like procedures were fair and issues were dealt with equally. In retrospectives, this means striving for equal input from team members and clearly communicating standards and expectations.
If the complaints focus on external factors outside the team, Oak says it’s important to bring the team back to “what can we do, what can we influence, what do we just have to accept?”
“I’m not a big fan of just accepting things, so I say let’s try to influence the problem first,” she says. “But it's good to recognize sometimes that you just have to accept this is how something is.”
Accepting what the team can’t change (for now) can move the discussion away from complaints and refocus it on what the team can influence in the near future. After all, Scrum is often described as the art of the possible. Bring your team back to what's possible.
As for blaming or finger-pointing, try pair programming or assigning code buddies to allow for more empathy within a team. Help build relationships by rotating the pairs. Then, when issues arise, it’s a pair sharing an experience rather one person against the rest of the team.
3. The manager's retro
The scenario
In this situation, a manager or supervisor turns the retrospective into an opportunity to micro-manage the team.
These can be tricky situations that are often delicate and context-sensitive, and it takes a strong Scrum master to feel comfortable enough to be honest about a situation like this.
Certainly, there are teams who invite the boss to retrospectives, and things go really well because there is a culture of trust. The team can still do what they need to do — focus on improvement — with the boss in the room.
But a when a manager becomes a roadblock to progress, you need a way to tactfully address the situation so your team can get back to focusing on themselves. “Your team’s retro is for your team, not anyone else,” Oak says.
How to fix it
Here, a good understanding of office politics and knowing how to have difficult conversations if you want to approach the manager in question. Focus your conversation on the shared goal of continuous learning and rapid improvement. What’s good for the team is good for the manager.
If that’s not an option, you could try calling an ad-hoc retro — without being subversive — so you have space to talk privately. Or you could break out into smaller pairs for shorter, more informal retrospectives. In that case, the manager might feel like they don’t need to be involved.
One issue Oak has run into in past organizations is leadership wanting all the details from a retrospective shared with the rest of the organization.
“We managed to coach leadership around to the idea that if the team comes up with something that can help other teams, let them share it, but don’t force them to share. You'll just waste time coming up with things that are politically safe to share.”
4. The "didn't we already talk about this?" retro
The scenario
With these retrospectives, the same issues or topics keep coming up, and it starts to feel like nothing ever changes.
When retrospectives start feeling like Groundhog Day, it's a sign that you’re not moving the needle forward. It might be because your team is overwhelmed, tasks aren’t clear or actionable enough, or it could be due to external factors you have less control over.
How to fix it
When Oak’s team experienced this, she looked at data from past retrospectives to spot patterns.
“I went probably through six months of our most recent retros and built a spreadsheet of what our top ‘went-wells’ were, our top ‘didn’t-go-wells,’ and what we had done based on those,” she says.
She was able to spot the items that came up again and again but within the context of everything else. “Here we see this pattern, but hey look, we also talked about how we wanted to do more code reviews, and we took some actions toward that.”
Seeing the bigger picture can help provide good perspective for you and your team. Maybe they haven’t moved the needle on one item, but they have made good progress on many others.
If you suspect the issue might be that your team is overwhelmed, try ending your next retrospective with just one action item rather than a long list. Commit to fixing that one thing as a team. Once you do, the team will feel accomplished thanks to a “quick win,” and you can build up to checking off more action items.
5. The "because Agile says so" retro
The scenario
In this case, the team is just having a retrospective because Agile or Scrum says so. No one on the team is tuned into the retro, and instead, they’re distracted, on their phones or not fully participating.
When you have consultants or outsourced teams, this can be an issue. Contractually, they may be obligated to fulfill certain requirements to get paid. This can also happen for in-house teams, too, and a lot of times it’s connected to the “didn’t we already talk about this” retro. If you don’t see retros leading to change, it’s time to re-evaluate.
“One of the common pitfalls is when teams are eager to run retrospectives just for the sake of running retrospectives,” writes Olga Kouzina, author of “Retrospectives, Part 2: In a Sentimental Mood.”
“They know that if they are supposed to be Agile, they need to do retrospectives,” Kouzina says. “But it’s not as simple as following a guideline. The need has to come from within. The team has to develop this intrinsic feeling of power to solve their problems and – even more important – to accept the responsibility.”
How to fix it
At this point, some teams might just give up and stop doing retrospectives, but that’s not the answer because it will just set the team back further in terms of making positive improvements.
Instead, try to re-engage the team by experimenting with your retros, suggests Rini van Solingen in his post, “How to improve your Sprint Retrospective meeting?”. Try varying retro formats or locations to shake up retrospectives. If your retro is co-located, try standing instead of sitting around a table.
Oak has tried shortening her team’s retros to 45 minutes and is now thinking of going back to an hour because she realized the team really needed that extra time to discuss action items.
Have your team explore the root causes of why retros aren’t effective. What impediments can they identify? This might be another chance to do an analysis like Oak talked about above, looking at the past few months of retros and identifying good and bad patterns.
***
Good retrospectives aren’t a piece of cake, but with the right recipes, you can avoid dangerous anti-patterns and keep your team’s attention on identifying improvements and working toward positive change.
Ready to take your retrospectives to the next level? Try Retrium.
Photo credit: Bethany Legg; Domino by Bro. Jeffrey Pioquinto, SJ; Ben Rosett