Distributed Team Retrospective: Communication, Collaboration, Empathy and Explosions

A tool for distributed team retrospectivesNot too long ago I came across a post by fellow Scrum Master, Josh Briggs, about a great experiment he conducted with his team: Keep Collaborating and Nobody Explodes. I’ve taken it and scaled it as a retrospective technique for use as remote or distributed team retrospective for 50 to 60 participants.

Consequently I’m helping teams uncover ways to improve their effectiveness at delivering value as well as learning how to not blowing each other up 🙂

The Big Idea Behind this Distributed Team Retrospective

Teams often experience a breakdown in communication. Sometimes it will be around requirements, or expectations, or priorities.

The issue can be manifested by a lack of connection between Dev-Team members, or between the Dev-Team and the Product Owner. Or between Product and Design. Or any other role combination…

Other elements that contribute to difficulties in collaboration and delivery of value include component silos, and specialization.

All of the above can be particularly pronounced with virtual teams.

Important keys for solving for these problems include:

  • Communication
  • Collaboration
  • Empathy

The following exercise, suitable for both a collocated as well as a distributed team retrospective, explores the impact of these elements. As a result, teams uncover ways to continuously improve their effectiveness at deliverying real business value. It’s also a whole lot of fun!

Supplies Needed for Remote / Distributed Team Retrospective

1) A really good video conferencing solution with break out rooms

Personally I like zoom.us. Zoom has greatVoIP and the ability to split people out into break out rooms (manually or automatically/randomly)

Using a tool like Zoom, the host can message all rooms,  can choose to split the participants into these separate sessions automatically or manually, and switch between sessions at any time, and more. It’s an awesome tool, especially for distributed team retrospectives.

Remote team retrospectives2) Licenses for Keep Talking and Nobody Explodes

Keep Talking and Nobody Explodes is puzzle game that is incredible at revealing how shared vocabulary, collaboration over specialization, and repetition makes for a high performing team. You’ll need one $15 license per group. Groups of 5 ± 2 work well. And you can get a bulk ten pack at a discount: $135 and use that for distributed teams.

Invest $3 / person for a 90 min experiment to improve collaboration, communication & empathy! Click To Tweet

The Role Playing Scenario

Each group will be in their own break out room, sharing video/audio.

Distributed team retrospective technique

One teammate (the “Defuser”) will install the Keep Talking app on their local Windows or Mac laptop.  Once the game is running, the Defuser will be playing the role of a person trapped in a virtual room with a ticking time bomb that they must disarm.

The other players on the team, the “Experts,” are given a PDF bomb defusal manual. They must decipher information in order to give instructions on how to deactivate the bomb.

But there’s a catch: the experts aren’t allowed to see the bomb, only the defuser can, and the defuser can’t see the manual.

Oh, and the team has only have 5 minutes. And one mistake too many and things go boom!

Game play for this distributed team retrospective starts with a relatively simple bomb composed of three different modules. Each round will have a different set of modules. With each successful disarming, the team can advance to more complex devices.

Distributed Team Retrospective: Communication, Collaboration, Empathy and Explosions Click To Tweet

Key Metrics

With multiple groups playing, ask each group to give themselves a team name, and to keep track of a few key metrics.

The number of:

  • Bomb explosions due to time out
  • Explosions due to too many mistakes (strikes)
  • Number of successful defusings

Debrief of Puzzle Solving Experiments

After half a dozen rounds, about 30-45 minutes, the teams will have discovered quite a few things. Ask each team to pause 5 minutes and do a short brainstorming, noting what helped them solve the puzzles, as well as what hindered their success.

And then bring everyone together to share and discuss their learnings.

Typical items that bubble up are listed below.

What Helps?

What Hinders?

  • Collaborating all on the same module at the same time
  • Solving for the difficult module first
  • Using predictive information
  • Listening clearly, w confirmation
  • Understanding overall structure
  • Providing clear, detailed, explicit instructions
  • Providing enough nuance, enough details
  • Having a shared vocabulary
  • Using established patterns and sequences
  • Doing the familiar first
  • Moving on when stuck, or yolo’ing it
  • Having a clear game plan at the start
  • Practice, repetition
  • Familiarity with “code base” (i.e., the modules)
  • External interference (interruptions)
  • Creating silos or specialization (this is MY module; that one is YOURS)
  • Not understanding documentation (no time in advance to read the manual, yet forced right into using it.) i.e., insufficient grooming /planning
  • Not having time to onboard / learn the game
  • Ambiguous / poor communication between team members
  • Lack of shared terminology
  • Having new problems all the time / changing conditions
  • Stress / time pressure
  • Lack of upfront planning
  • Assuming other people had the same knowledge as you…
  • Too many “architects” / cooks directing the recipe

Key Take-Aways

Each of the retrospective items are easily connected to “the day job” scenario of software development teams: solving complex puzzles within a time-box.

Teams become aware of the value of the practices they use, or should be using: team agreements, definition of ready, grooming. Game play also exposes issues around dysfunctional styles of behavior and communication.

If you have more time, you can introduce other elements:

  • If you really want to torture your teammates, allow slack only communications… see the impact of spoken vs written communication.
  • Split up and randomly reform the teams after each 5 minute round.

The latter helps explore the impact of persistent team membership versus feature teams.

I think you’ll find that persistent team membership:

  • Enables faster creation of a shared vocabulary
  • Creates rapid fail/learn cycles that lead to quicker process improvements
  • Overall promotes collaboration

And all of the above leads to higher levels of performance – what more can you ask for from a distributed team retrospective?

Take This Distributed Team Retrospective for a Spin

What do you say? Will you keep collaborating or will you explode? I look forward to hearing your experiences using this idea for either colocated or distributed team retrospectives.

Remote and distributed team retrospectives

2 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top