How do I make sure my retros don't become bitch sessions?

Dan Dan the Scrum Master man strikes again!

First off, you should celebrate the fact that you’ve created a safe enough space for a bitch session.  I’ll take a bitch session any day over an everything’s fine session.  Remember, the job of a Scrum Master is to create the container; the team creates the content.  You did not create the underlying issues the team is complaining about, unless they are complaining about you, which is entirely possible but I have a hunch is not the situation you are dealing with.  If that is going on, celebrate twice because not only does your team feel safe, they feel safe enough around you to complain about you.

When I hold retrospectives, my number one priority is creating the safety for team members to share openly and honestly with one another.  To do this, I employ set the stage type activities and pay close attention to my body language and the manner in which I am participating throughout the meeting. 

Contrary to popular belief, a Scrum Master does not solve problems.  A Scrum Master’s job is to connect those who have problems with those who have the solutions.  The best way that I know how to do that is to get those two parties into a room with one another and ensure the room is safe enough for them to communicate effectively.  Then, those parties can gain a shared understanding of what the problem is and converge on a mutually agreeable solution.  I am not involved in any part of the process other than getting the two sides into a room together and ensuring the room is safe.

If your retros are prone to becoming bitch sessions, odds are you are starting to feel that you are falling short as a Scrum Master or that you are doing something wrong.  Let me remind you – you should celebrate because you’ve actually already done the most difficult part.  The fact that the team feels comfortable being that honest is a huge win.  You are 99% there.  All that is missing is the final (easy) step of converting your retro into tangible actions.  Esther Derby’s book, Agile Retrospectives: Making Good Teams Great, provides an airtight framework for doing just that.  I use her suggested structure every time: Set the Stage, Gather Data, Generate Insights, Decide What to Do, Close.  I also highly recommend https://retromat.org for planning your next retro.  I steal my retro ideas straight off of there all the time.

Some other suggestions I have for retros:

• Steer the discussion when appropriate back to the sphere of control of those in the room.  If the person who needs to change something is not in the room, you might as well be complaining about the weather.  There’s nothing we can do about that.  What we maybe can do is for someone in the room to talk to someone not in the room after the meeting, but even that is not all that effective.  If enough people go talk to that person one at a time after the meeting, though, that can be effective because that person will probably start to realize there’s a problem that he/she has control over solving.  Still, though, the best thing you can do is focus on what the people in the room can do.  Unfortunately, not everyone is in the room but that’s life.  Unfortunately, not all of us are billionaires either.  We could go on and on about what’s missing in our lives but let’s focus on what we have.

• Continue to bring people back to the reality of the situation.  We have a limited time period to converse.  The retro is not going to last forever.  I like to make comments along the lines of “…it’s 11:23, just want to be mindful of the time.  Do we want to continue this discussion or are there more pressing issues we need to cover?”

• Play a game with yourself where you try and talk as little as possible.  Be open to what happens.  By not stepping in, you show the team that you trust them as mature adults to solve their problems.  Your job was just to get the parties into a room together.  Once the retro begins, you’ve done your job.

• Let the team own the enforcement of any agreements that come out of a retro.  Show them that you trust them by not bothering them about why they are not following through on what they said they would.  You can’t stop a freight train: if there is a real problem, they will bring it up again at the next retro.  Trust the team.

Scrum masters (myself included) feel a lot of unnecessary stress around retros because we think it is our time to shine and we worry that we won’t live up to our lofty expectations of ourselves.  So, I leave you with this parting thought: how you are in a retro or any meeting for that matter speaks far louder than anything you do.