While at CAST last summer, one of my goals was to get ideas about how to get non-testers more interested in testing early. One woman (I think her name was Mel or Meg) suggested Agile Testing Jenga as an activity she often ran with teams that might help. There are a lot of posts online describing variations of it, but according to Lisa Crispin it originated with Nanda Lankalapalli at least as far back as 2011. Last month I facilitated a game with my department’s QA group and a friend of mine did the same with her team this week. This post describes some of my experiences with it and the insights that our teams got from it.
Equipment
Since I knew I was going to play this game with a group of up to a dozen, I needed multiple sets of equipment. Luckily my local dollar store had off-brand Jenga sets for $3 each so I was able to get a bunch quite cheaply.
I split the blocks into thirds and dyed each set a different colour using dyes intended for making tie-dye T-shirts, then numbered them from 1 to 42 so each sequential third was the same colour (the first 14 bricks all red, etc). I only numbered two sides of each block and changed where the numbers were located to make them a bit trickier to identify, but kept each set identical.
Finally, I printed a series of cards numbered from 1-42 and put them in cheap card sleeves matching the colour of that number’s block, with regular playing cards behind to make them a bit easier to shuffle. I happened to already own card sleeves in the right colours, but you could easily replace this with any other method of generating random numbers.
All told, this activity cost me about $12 and an afternoon of crafting.
Playing the game: Round One
As people came into the room, I asked them to split up into groups and nominate one person in their group to be the “tester”. While people arrived, I wrote the following on the board:
REQUIREMENTS
1. Use all the blocks
2. Must be at least 3 levels tall
3. Must not have any bugs
Then I told them what we were going to do: You’re all developers, and your project is to build a tower out of this set of blocks. Those are the requirements on the board. When you’re done, the tester in your group is going to inspect your tower and remove any bugs they find. After the bugs are removed, you must make sure your tower still meets the requirements.
People immediately asked for clarification on what I meant by a “level”, and we settled on the interpretation that the tower needed to have three layers of vertical blocks. In retrospect, I should have been more strict that each layer of vertical blocks needed to be separated by horizontal blocks, since I ended up with contraptions like this:
I also should have been strict about building only one tower, rather than two towers very close to each other.
I deliberately did not tell them, somewhat nefariously, how the tester was going to identify bugs, or even what bugs would be. I just gave each team their pile of blocks, started a timer and told them to start building.
At the same time the developers started building, I asked the testers to come over. From my deck of cards, I had them each pull 2 cards from each colour, effectively giving them each 6 random numbers, and explained how bugs worked:
“When your team is done building their tower, you find the blocks that match the numbers on your cards, and remove them from the tower. Yes, you might have to move other blocks to find the ones with your number. Yes, the tower might fall, but then it’s up to the developers to fix it so that they still meet the requirements.”
I know it was breaking the analogy somewhat, but I made clear that only the testers could remove blocks from the tower. Originally this was just for entertainment value (and it worked very well for that) but it ended up providing a neat insight later.
It took about 8 to 10 minutes for teams to finish their first round at the tower. The highlight for me was as soon as the first tester starting looking closely at her team’s tower, one of the developers exclaimed “I don’t have a good feeling about this!” One team had particularly bad luck of need to tear down almost their entire tower just to find one buggy block.
After the round, we had a mini debrief where I asked several questions:
- What went well? (Great, until the tester showed up)
- How did it feel to have the testers removing bugs? (Not good!)
- Will you change your strategy for the next round? (That brings us to…)
Rounds Two and Three
In the second and third rounds of the game, the rules change. In round 2, the developers are told to first use only red blocks, then have the tester remove the red bugs. Then they can add white blocks and have the white bugs removed, and finally blue blocks. In round 3, the tester can remove bugs at any time.
Importantly, the requirements and the number of bugs—two of each colour—are the same as the first round. The only thing that changes is when bugs are removed.
All the cards were shuffled and redrawn, so the teams still wouldn’t know which blocks were buggy until the tester removed them. In addition to changing how they tested, I noticed the teams also changed their building strategy. Both teams made an effort to place the blocks so that the number was always visible, effectively making their towers more “testable”. There was also some effort to make the towers more resilient to having blocks removed, although this is hard to do perfectly while still reaching 3 levels tall. I suspect both of these changes were encouraged by the fact that the testers were pulling the blocks out themselves rather than letting the developers do it.
Final debrief
After each round, I did a debrief again, adding a question about how the experience compared to the previous round and what they thought made each round better than the last.
Unsurprisingly, the time to finish was shorter each round. We went from about 10 minutes in the first round to about 1 minute in the last round. Part of that was because they were just more familiar with constructing the tower, of course. There’s also an element of the developers starting to understand how testers find the bugs—making their towers more testable by making it easier for testers to check each block for a bug—and designing in safer ways. Fewer “tower crashing” bugs means less rework.
I was most interested in whether they connected the dots between this exercise and how they test on their own teams. During the game, as soon as I described the rule change for round 2, someone immediately said “Oh, it’s like sprints!” But for round 3, even in the debrief, nobody made a similar leap to a way of working they were familiar with. I think this illustrated that the group wasn’t as used to techniques like pair programming or testing early. Nonetheless, they spontaneously adopted those sorts of activities while building their third tower without realizing it. Both teams read out numbers as they added each brick to the tower, for example, which to me looked a lot like inviting testers to give feedback on designs before writing any code. This was true agile testing in practice!
One of the participants later borrowed the Jenga sets to run it with her own development team, including their product owner and team lead, to rave reviews. Especially after the third round, they started asking themselves what was holding them back from testing like that every day. So even though playing with blocks seems so simple, it still sparked some important conversations about how to change their mindset.
Bonus round
Time permitting, I added two suggestions for a bonus round:
- Ask “What would you change to make testing even better for a fourth round?” and try it.
- Make the requirements more difficult: more levels, two towers, etc.
For the second team that did the activity, I think their time was better spent discussing how to change their real-life strategy to test more like the third round. For the first group, though, I mentioned that I regretted not making the “3 levels” definition more stringent, so we decided to repeat the rules of round 3 with tougher requirements: the tower had to be 3 levels of alternative vertical and horizontal blocks. Despite forcing a more fragile structure that took more effort to build, the time to a finished bug-free product was still less than even the second round. This really just helped sell how useful rethinking how we test can be.
Thanks again to Mel (or Meg—sorry) for telling me about the game in the first place, the several bloggers who posted their version of the instructions, and Nanda Lankalapalli for coming up with it.
Leave a Reply