The blame game: retrospective anti-patterns
We all know that we’re not supposed to blame individuals during retrospectives, but…you know…sometimes when bad things happen there’s clearly someone at fault, right?
Maybe a team member bypassed code review to merge in a controversial change, which ended up causing downtime and a hasty rollback.
Or perhaps someone rushed through a schema migration, resulting in a late night spent restoring corrupted data.
Or maybe a team member got stuck on a problem and spent half the sprint at the bottom of a rabbit hole instead of asking for help, until it was too late and the team missed their sprint goal. And so on.
Whatever the cause, the result is always the same: as soon as the topic comes up during the retrospective, everyone’s head swivels simultaneously to stare down the instigator of the team’s misery.
How do you keep things on-track, avoid personal attacks and defensiveness, and most importantly, how do you ensure your team comes out of the session with an actionable plan to improve things together?
The perfect blend: one part collective (team) ownership, two parts curiosity
The key to winning The Blame Game is for your team to take collective ownership of the problem, and to be curious about the perspectives and circumstances surrounding the incident.
There are many different ways you can facilitate this during your team’s retrospectives. Below are a few examples of approaches that I’ve used.
There are no people problems, only process problems
No-one is the villain of their own story. Sure, maybe someone made a mistake that negatively impacted the team, but in the moment they genuinely thought they were doing the right thing. They were just missing a key piece of information or a critical step in the process that would have helped them to make a different decision.
Shift the focus of discussion away from the person and towards identifying what that missing piece could be:
“Where did our process fail? How can we make it more robust without slowing us down?”
“What knowledge could have helped us to make different decisions? How do we make that information more accessible?”
Software development is a team sport
A high-performing team doesn’t require every member to be a superhero. Rather, a high-performing team has learned how to work together to create something that is greater than the sum of its parts. When a member of the team makes a mistake, the team must collectively own that mistake, so that they can learn how to be even more effective together in the future.
Try nudging the conversation towards fostering more collaborative ways of working:
“As a team, how can we support each other better, so that no-one ends up in that situation again?”
“What would have been a better outcome, and how could we have worked together to help bring that about?”
If you have a team charter or working agreement, this is a chance to reaffirm (or revise) your team’s ways of working
Many teams have a team charter or working agreement…filed away somewhere in the company intranet, untouched and un-viewed since the day it was created.
Retrospectives are a great way to keep this part of your team culture relevant:
“This sounds similar to something we talked about when we last iterated on our team charter. Did we miss an opportunity here to help each other to stay true to our shared values?”
“I don’t think anything like this came up during our last working agreement session. Maybe this is an opportunity to schedule some time to draft the next iteration?”
Avoid the temptation to make amendments to the team charter or working agreement during the retrospective. These sessions require a different mindset, and you don’t want recent events to bias the outcome. Instead agree to scheduling a session to work on the team charter and then move on to the next topic.
Keep cultivating curiosity and co-operation
The common through-line for resolving team conflicts during retrospectives is collective ownership and curiosity.
As the team manager, in rare cases you may have to step in to address performance or certain interpersonal issues. The remaining 99% of the time, however, you’ll affect more lasting positive change by:
Helping your team members accept collective (team) ownership of each problem, and
Facilitating curiosity to explore different perspectives of problems and potential solutions.
Remember: retrospectives are about the future, not the past.
In the meantime, we’re not yet done with retrospective anti-patterns! I’ll be back in a few weeks to explore The Shouting Match and how to make sure everyone on your team has an opportunity to make their voice heard.