Agile Survival Guide: Retrospective Safety

I’m considering a series called “Agile Survival Guide”, designed to muse on / attempt to tackle some common things I’ve seen happen on projects that are attempting to embrace an agile mindset but are maybe falling a little bit short.

“I feel like we’re not having real retros.”

I’ve heard this more than a few times over the years and I’ve dealt with it in a few different ways, and seen some tips from others.

The goal of a retrospective, broadly speaking, is for the team (the entire team) to reflect on their current process and approaches as a whole to see what they could do better.

Issues I’ve seen come up:

• Team members who happen to be on the client side are there and this makes people feel like they can’t admit what’s wrong, even though you’re all on one team.
• Outside stakeholders from the team are present and the team feels the need to put their best foot forward.
• Someone’s big personality sucks the oxygen out of the room, leaving others feeling like they have little room to speak up (NOTE: I am sometimes this person; it is something I always try to keep in check).

Some Lessons Learned Toward Better Retrospectives

In the past, I’ve had success with some of the techniques below, none of which originated with me but which I feel you may benefit from, dear reader.

• Reinforce the goals of a retrospective. At the beginning of a retrospective, remind everyone that they are there to come together as a team to explore their delivery process and find things they might want to try in order to improve. Remind team members that in this setting, it’s OK to say when you’ve screwed up, because it’s a blame-free zone and the goal is to make the overall system better.
• Repeat the prime directive: For a little bit at least, it’s helpful to repeat the prime directive of retrospectives: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
• Do a safety check. Prior to a retro beginning, ask each team member to write a sticky note on a likert scale (strongly disagree - strongly agree, 1-5) for the phrase “I feel comfortable safe sharing issues and my suggestions for improving the team”. Look at the results at the start of the meeting. If there are any lower scores, acknowledge them and acknowledge that this process may be difficult for some, and reinforce that the goal is to allow everything to contribute their thoughts to the team. If the entire team scores low or there are many unsafe opinions, cancel the retro – you’re not there for a dog & pony show. If people don’t feel like they can contribute, ask them to see you to discuss, or set up an anonymous feedback form to solicit why.
• Lead by example. Is there something that you feel you could have done better or could have gone well? If you’re not fully in a facilitation role, consider leading with those topics if others seem hesitant, especially if it’s a critical piece of self-reflection. This can help the entire team ease up.
• Ask some stakeholders to step aside (at least for now). If a client is a stakeholder in the project, and their presence reduces the effectiveness of the retro, it may be worth having a conversation with that stakeholder. If they’re not a part of the team’s delivery, it may help to make the point that retros are generally reserved for the team so that they can talk about their weaknesses openly in order to improve. If the stakeholder tends to bulldoze discussion, it may be worth noting that allowing the team to improve themselves is going to pay a lot of dividends. I have had success asking for these folks to “give it a little time” and drop out of the meetings for a few weeks. In return, I promise to surface the details of the discussion and any key points I think they need to be made aware of (since the team is generally summarizing this stuff anyway). Most folks end up being happy to skip the meeting, and after the team builds up some confidence & trust, we may even be able to add them back in.
• Keep retrospectives interesting! Sometimes teams really find a groove with a format for discussion or things evolve in a certain way; that’s fine. However, there are a lot of ways to keep retrospectives fresh, which might help loosen people up to share a little bit more. Here’s a huge list of fun retrospectives with various goals. When I first saw some of these I thought it was overboard. But one of my favorites quickly became the sail boat retrospective, because it allowed the team to discuss so many aspects of where we were headed.
• Embrace a “share, then discuss” approach: Sometimes, when discussing topics, particularly contentious ones, the loud folks weigh in first and the discussion goes off the rails. Meanwhile, people who have valuable perspectives or who may feel disconnected have to fight their way in. If instead a discussion starts first by all attendees sharing their perspectives (should they choose to do so), everyone has had a chance to speak, and ideas and consensus begin to form among the team. This may require some time-boxing, but is a really helpful way to get the full spectrum of feeling and help others be heard. This enforces the concept of equal voice, which lends people to feel safer in sharing their opinions / observations, knowing they won’t be rejected outright.
• Vegas Rules. While I may surface a summary of what actions the team intends to take or any major risks, retrospective discussions should generally adhere to “Vegas Rules” (what happens in vegas, stays in vegas) unless the entire team feels comfortable sharing more. This is another way for folks to know that they can speak freely in a meeting, and the team doesn’t have to worry about any dirty laundry being aired that led to their decisions.

What are your Tips?

Have you heard a phrase similar to the above? Do you have an additional factor that causes this problem, or an additional solution you’ve tried with success? I’d love to hear it in the comments!