@hdietrich I have a wild and crazy idea for a distributed retro of 60 people.
1) Use https://zoom.us/ as the connection point.
Great VoIP and the ability to split people out into break out rooms (manually or automatically)
https://support.zoom.us/hc/en-us/articles/206476093-Getting-Started-with-Video-Breakout-Rooms
Can message all rooms as admin, call folks back into the main room etc. Awesome.
2) A Ten Pack of Keep Talking and Nobody Explodes
http://www.keeptalkinggame.com/bulk-purchase/index.html
A puzzle game that is incredible at revealing how shared vocabulary, collaboration over specialization, and repetition makes for high performing teams.
I’ve run this retro twice - once with 25, once with 35. With a second facilitator should be able to scale to 50.
Groups of 5 ± 2 work well.
Source of idea from Josh Briggs.
I’m working on a write up of my experiences so far with it; here are some notes:
The Big Idea
Have you ever felt a breakdown in communication around requirements?
Or maybe a lack of connection between Dev-Team members and the Product Owner? Or Product and Design? Or any other role combination…
What impact do component silos have on our ability to deliver value at the right pace? What impact does specialization versus collaboration have? How does previous experience affect things?
Important keys for solving for these problems include:
- Communication
- Collaboration
- Empathy
During this retrospective, we’ll explore the impact of these keys and discuss ways of increasing their use - continuously improving the effectiveness of our team work.
The Role Playing Scenario
One teammate (the “Defuser”) is trapped in a virtual room with a ticking time bomb they must defuse.
The other players on the team are the “Experts” who must give instructions to defuse the bomb, which they do by deciphering information found in a bomb defusal manual.
But there’s a catch: the experts can’t see the bomb, only the defuser can.
Oh, and the team has only have 5 minutes. And one mistake too many and things go boom!
Debrief
What helped to solve the puzzle?
- Collaborating all on the same module
- Solving for the difficult/unknowns first
- Using predictive information
- Being explicit
- Listening clearly
- Understanding structure
- Providing clear, detailed, explicit instructions
- Providing enough nuance, enough details
- Having a shared vocabulary
- Having patterns, sequences, repetition
- Doing the familiar first
- Moving on when stuck
- Having a clear game plan at the start
- Active listening
- Practice, repetition
- Familiarity with “code base” (i.e., the modules)
What hindered puzzle solving?
- External interference (interruptions)
- Creating silos or specialization (this is MY module that 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
- Ambiguous / poor communication between team members
- Lack of shared terminology
- Having new problems all the time / changing conditions
- Stress / Time pressure
- Lack of planning
- Assuming other people had the same knowledge as you…
- Too many “architects” / cooks directing the recipe
Key Take-Aways
Persistent team membership and repetition of game play:
- allowed teams to experiment quickly (silos vs collaboration)
- developed a shared vocabulary and a process unique to each team
- created rapid fail/learn cycles that promoted higher levels of performance