Teams That Blow Apart

Have you ever had an Agile team just explode in front of your face to the sound of laughter and shouts of “Let’s do that again!”? No? Well, then you’ve never tried my new favorite team training game/tool, Keep Talking and Nobody Explodes. I initially ran across this game through my involvement with the Oculus Rift virtual reality headset, and was very excited to see it come out for the Windows PC platform. While gameplay with the Rift will add intensity and depth, the real lessons for Agile teams still come through beautifully with the PC version. Laptop or desktop is fine, it plays well on either.

The game itself is simple, and like all good games it is highly unpredictable in actual play. The goal is, as a team, to defuse a virtual bomb. Sounds Agile, right? Trust me, it is! It can be played with 2 or more people and seems to work best with 5-7 total. One person is in charge of doing the actual defusing of the device on the screen, while the rest of the team consults a printed manual with the instructions. The defuser isn’t allowed to see the manual, and the person/group with the manual cannot see the screen with the device. Everything has to be communicated. Starting to sound like Agile yet? Think of a Product Owner and User Stories that communicate the vision of the feature. We all know how well that goes with new teams, right?

1_KeepTalking_Gameplay 2_KeepTalking_ManualSpread

There are time limits (can you say Scrum?), and you only get a certain number of mistakes before you go BOOM (iterative learning). Of course, just like in real life, pressures mount and there are distractions. Every time you make a mistake, the game reacts and does things to increase the adrenaline – flashing lights, sounds, etc. The effect is profound.

The manual contains all you need to know to successfully defuse the device. (Sounds a lot like a requirements document to me.) Sadly, it is compact, yet complex and it’s a real job to get all that good information into a form that makes sense to those reading it, and then get that information to the defuser.

So what lessons come out of the experience? Here are a few that have been mentioned by players in after-action retrospectives.

  • Co-location is really important. To attempt the game over the phone or by instant messaging or other low-bandwidth channel would make the task far more difficult.
  • Common terminology is key to crisp and concise communication. Give teams time to talk about how they will improve their gameplay and you’ll see this come out. Consider this as a venue for introducing other team communication skills such as The Core Protocols.
  • Teams will often talk all at once and listening goes by the boards. Teams that learn how to listen improve quickly.
  • Listening won’t help unless there is clear communication in both directions. Stating problems calmly, clearly, and succinctly pays dividends.
  • Long standing teams will play better. The first couple of rounds are disjointed and communication suffers. Some teams will improve very quickly, others will need more time to figure out what needs to be done better. Teams that have experience will know each others’ style and strengths and weaknesses.
  • Single piece flow – Overloading the defuser with commands is counterproductive. It becomes quickly apparent that a one-thing-at-a-time approach works best. This can be used to introduce or reinforce lean concepts.
  • Prioritization – some modules on the device need to be prioritized due to their nature. Teams must take some time initially to determine if any of these priority items exist and then treat them accordingly.
  • The user experience for the team members using the documentation highlights the need for sufficient, but not overburdening documentation. One alternative gameplay would be to let the teams re-write the defusing manual so it would be less opaque. Is a manual even the correct form? Is there some better way? Use multiple manuals so each player has one?
  • Teams will often self-organize into generalizing specialists. One person per page of the defusing manual. However, high-functioning teams will dive in and help immediately, especially when they see the “expert” is floundering. Over time, expertise becomes shared.
  • Have two teams play. One simply observes the other team and takes notes on the good and bad patterns they see.
  • Teams might film themselves and review their own behaviors in a retrospective. When you are head-down in the game, it’s very difficult to be objective and observe the interpersonal dynamics.

Do I recommend this game as a team building tool? Absolutely! Many Agile concepts are hidden in the gameplay and can be used as jumping off points for discussion or further team improvement items. Don’t forget to have management play too!  Find it at  Have a look at the game in action!


Thoughts From The Agile Trenches

Sometimes you just have to write it down. There is no cookie-cutter approach to Agile; every situation is different. The act of “writing it down” can often unjam a stuck brain or give a new direction to investigate. Try to explain it to your grandmother and see what assumptions you’ve been making.