Demonstrating Risk, Stability, and Testing

Learning Through Games

UPDATED: Kim Engle pointed out I'd forgotten to include a timeframe to run this. Depending on amount of laughter and discussion this can take between 30 - 45 minutes.

Many coaches use the Jenga game to help illustrate the importance of testing early and often. It’s a fun activity that demonstrates the concepts in a light-hearted but eminently clear way.
I’ve wanted a similar approach to help drive home the idea of stability, risk, and how testing helps mitigate those issues. I also wanted a clear expression of the always-present constraint of time. Moreover, I want to explicitly demonstrate that stable components don’t need anywhere near the amount of testing as less stable components.
I came up with the following approach several months ago, and it’s been very effective the three or four times I’ve run it so far.

Overview

The general idea is to build a structure of a specific minimum height in a constrained amount of time. Attendees are given different materials each iteration with the same height and time constraints. The different materials inject stability issues, making it harder to meet the minimum height requirement within the time constraint. This tends to be a lot of fun, because as with the Jenga game there can be a lot of crashing as structures fall apart.
I’ll start the exercise talking about value and risk—two things I continually hammer home during my coaching sessions—and talk about how this exercise is a tradeoff of value and risk. I don’t specifically call out stability during my explanations. I like that come to the forefront as the game unfolds. Your mileage may vary.

Rock, Dice, Marbles Game

(Apologies to Rock, Scissors, Paper.)

The Goal

Illustrate the interaction of risk, stability, value, and how testing comes in to play helping stabilize things and mitigate risk.
Materials required:

• One set of dice per team – nine to 12 dice
• One small rock per team. Rock should be somewhat die-sized and roughly square. You don’t want them too flat—part of the point is the rocks being unstable…
• Two marbles per team
• One small blob of putty, PlayDo, or otherwise squishy stuff. This blob should be fairly small. It’s meant to illustrate testing, a constrained resource.
  
  Setup:
• Break up your group in to teams. Keep teams under six if possible. Three to five per team seems to work best.
• Give each team one set of dice. Keep the other materials hidden.

Timeframe: Allow 30 - 45 minutes for this.

Iteration One

Rules for I1:

• Must build a tower at least eight dice high. I’ll also often use the sides of my Moleskein as a measure instead of just saying “Eight dice” or whatever.
• Time limit of 90 seconds

Running I1
Explain the rules, then start the timer and have teams build their towers.
When the timer finishes you’ll have some successful teams and some who had trouble with falling towers.
Discussions
This is the first place to start discussing the main point: stability. The structure’s a bit wobbly, even when using dice. Sometimes teams will use interesting approaches to building. Use opportunities as they arise to discuss how different approaches help mitigate instability, risk, etc.

Iteration 2

Distribute a rock to each team. This is generally met with some groans and pained laughter. Play that up! The game’s meant to be fun in addition to educational!
Rules for I2
* Must start tower from scratch. No building on top of existing ones!
* Must build a tower the same height as I1
* The rock must be used as part of the tower. It must contribute to the tower’s height, meaning you can’t just set it off to the side of the tower. It has to have something on it, or be on top of something else.
(I’ve had some creative attempts to get around the intent of this. Testers. Go figure. Again, use this as an opportunity to inject some humor as you describe the rule and ask the teams to honor the intent of it!)
Running I2
Same as before: Start from scratch, 90 seconds, fire the teams off and see what happens!
Discussions
More instability, this time in a big way. I’ve had some teams build smaller towers that included the rock. This is actually a great discussion point: those teams shipped some value! That’s not a bad thing—it offers a great opportunity to discuss value versus risk trade offs!
Look at people who succeeded in any fashion and talk about how they managed their risk/stability.
Now carry the discussions over to software delivery. Make a connection that the stability in this game is a metaphor for different components/systems we work with.

Iteration 3

Pass out two marbles to each team. Yet another opportunity for injecting some serious humor. “Oh no! You’re giving us another rock???” “No! I’d never do anything so mean! Here, have marbles.”
Rules for I3
Same height and time constraints. Start from scratch. Rock and one marble must add to the height of the tower.
One critical modification here: The stakeholder must have a tower at the minimum height. A shorter tower will not deliver him the business value he needs.
Running I3
Same as before. There should be a nice amount of crashes, laughter, and muttering.
Discussion
Huge stability issues. Connect back to software: stable components and systems. Less stable or newer components which haven’t been used for as long. Brand new systems, or ones written very, very badly.

Iteration 4

Now distribute out the small ball of clay/putty. Talk about stabilizing as you’re doing it. Don’t tell teams how to use the clay.
Rules for I4
Start from scratch, same height, 90 seconds. Rocks and marbles must contribute to height.
Running I4
Same as before. Start it off, let it roll.
Discussions
Talk over how teams used clay for stability. I’ve seen a wide range of uses: dots between dice, nothing on dice, big blobs on the marbles, etc. One team made a large pancake of clay and wrapped their rock and die in it—what a great metaphor to tie directly to software wrappers around unstable components!
If the teams haven’t made the connection of clay == testing, help guide them along that. Now’s the time to really head off down the road of “You have 35 - 40 hours a week to apply all your testing expertise. Where are you and your team going to focus? What’s the scary unstable stuff? Where’s the high-risk stuff?”
This is also the spot in this exercise where I really hit home on careful thinking around test coverage, regression, and dear God PLEASE STOP TESTING ALL THE THIRD PARTY TOOLS YOU HAVEN’T CUSTOMIZED.

Finishing Up

You should definitely poll your attendees to see what they got out of this. I always get some neat feedback, and it’s important to validate the attendees got some glimpse of the goal of the exercise.

Note on Licensing of this Exercise

I invented it, I’m licensing it.
Here’s my terms: Use this as much as you want, whenever you want, wherever you want. Pass the concept on to others as often as you want. The sole term in this license is if we are ever in the same place at the same time you must buy me a [drink] and share your experience with the game I mean exercise. Let me know if it worked, and how you’ve changed it.
Awful terms. I get it.
[drink]: Coffee, soda, or beer. Scotch is best; however, I’m happy with anything as long as you share your experience!