What is a retrospective anti pattern?
An anti pattern is any habit or system that causes more harm than good. When it comes to retrospectives, and sprint reviews there are some tactics 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 Scrum Master Anti-patterns that we are constantly seeing in retrospectives and what to do if you find yourself dealing with them over several sprints.
These are the retrospective meetings without clearly defined stages, techniques, or processes. These are the retros where the goal of the meeting gets lost, and the discussion veers off-topic into pointless interactions 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 with each stage in the meeting, the facilitator should lead the team closer to action.
Especially for distributed teams, the right tool can provide the needed structure and keep everyone 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 to have 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 members from skipping ahead to voting before the rest of the group is done generating ideas. And by the end of the retro, the team has focused on the best action-items for success for the upcoming sprint.
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 development team, starting a domino effect because the listeners want to reduce that cognitive burden by complaining themselves.
Getting into this anti-pattern also establishes the expectation that retrospectives are a time purely, for complaining. This means you can easily fall into that mindset for weeks on end.
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 meetings by making sure everyone felt like procedures were fair and issues were dealt with equally. In retrospectives, this means striving for equal input from 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 or insights rather than one person against the rest of the team.
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.
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.”
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.
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 session 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.
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.”
At this point, everyone 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 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.
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.
.png){kind=small}
