Agile Jenga (Understanding the Value of Building Quality In)

Recently I facilitated Agile Jenga at the meeting I run in the local DC area, DC Scrum User Group (DCSUG). I am not the originator of this game but I have spelled it out a little more. A link to the original version is below.

Overview

This is a great game (aka Experiential Learning Exercise) to help understand why it is critical to bring product testing early into the development. I have found that it can help many, including management, to buy into the idea of test-driven development and the importance of building quality into the product under development.

Materials

• Jenga Blocks, numbered 1-36 (write the numbers on the ends of the blocks)
• Rules
• Rulers (optional)
• Random number generator (optional)
• Name tags for the roles (optional)
• Timer
• Flip chart (to place bug numbers on)
• Sticky notes
• Sharpies

Rules

There will be 3 rounds. Requirements remain the same, the only difference in each round is how soon/how often we get to “test” the structure. For each round, a new set of 4 random numbers between 1 – 36 will be written down as “bugs” to be fixed. Each round will begin with the developer building the structure to the requirements, with the tester providing feedback based on the rules of the round. The tower needs to be at least 4 length-wise Jenga blocks tall.

Recommendation: Try to switch the roles that people typically play (ex. have a tester play the developer role and a developer play the tester role). This will allow each person to gain some insight into the other roles on the project.

• Round 1: The tester is only allowed to “verify” the built structure only after the entire structure is built. Testers removes the bugs/blocks identified by the facilitator.
• Round 2: Separate blocks into groups of 12 (1-12, 13-24, 25-36). In this round the tester is allowed to remove the problem blocks after every 12 blocks are put in. So, the tester gets 3 opportunities to give feedback.
• Round 3: The tester is allowed to work with the developer as he/she is building the structure and is allowed to point out problem blocks (bugs) right away. The facilitator will provide each tester with the numbers for each bug/block before the round begins.

Preparation

• Place Jenga blocks on each table
• Hang flip chart for bugs
• Identify the bug numbers for each round and hide them

Variations

In order to show the benefits of performance testing along the way, you could add a requirement of the structure needing to support something like a book.  In Round 1, the structure does not try to support the book until it is complete.  In Round 2, they can try after 9 blocks, and in Round 3 they can try whenever they want.

In order to show the benefits of challenging assumptions and understanding requirements, once the structure is complete, “perform a UAT” and submit a defect that what the developer defined as a “level” is different than your definition.  This will require either: 1 – No changes are made and the business does not get what they want or 2 – Significant changes may need to be made to meet the needs of the business.

Debrief Points

• Reduce feedback loop
  • The earlier the tester gets on board, the faster you will receive feedback.
  • The point here is to reduce the feedback loop between development and testing. The biggest problem seen in lot of organizations is the attitude of the developers and testers in working together.
  • Tester and developer when working together, deliver high quality software with less rework. The first case depicts phased approach where testing happens after the software is built. If the bugs found are more fundamental (like blocks in the first level), the project will be delayed more as rework is necessary.
  • In the second case, feedback is faster. Developer could correct the code early and there is less risk than the Option 1.
  • In the third case, the tester is helping the developer avoid putting the bugs in real-time. This is possible when tests are written before code is developed. Getting to this level is what a team should strive for.

• Bugs can be hard to find
  • Since the numbers are only on 2 sides of the block, depending on how the developer builds the structure, it may be difficult to find bugs, adding more time to the bug finding process.  In this case we know there are 4 bugs, but if the team did not know how many bugs there were, it could cause the team to miss them.  If the developers figured this out, they may make sure that the numbers can be seen as they build.  This is analogous to having proper logging and alerting in place so that bugs can easily be found/corrected.

• Less rework
  • The later you test, the more rework you have if bugs are found, which will make the project late.

• Fail fast
  • The aim of agile testing is not to detect bugs but to identify and prevent them from ever getting in.

Some ideas/thoughts to expand on these concepts:

• As the developer is developing, see if they are developing the structure in components/modules. If so, it should be easier to adjust the structure as entire components can be moved, rather than having to adjust block by block.
• When we played, I was the tester and in round 2 I missed identifying a bug.  This was not intentional, but shows that bugs can be missed and the impact of that in later “rounds”.
• The initial requirements are ambiguous (ex. what is meant by a level).  It would be good to question/clarify those up front.  Otherwise, we may get to the end of the build and realize we misunderstood the requirements.
• Defect Density (defects / lines of code changed) was the same between each phase (3 bugs / 36 blocks).  What was different was the speed at which we found the bug.  It was much more beneficial to find the bug fast (Round 3) compared to at the end (Round 1), even though the defect density was the same.  To take it further, even if there were twice as many defects in Round 3, they would’ve still be found faster and produced a better product than Round 1.
• An interesting idea: Mix the bugs back into the blocks.  This would represent a bug that reoccurred, which can happen in development.
• As rounds go on, it seems that the designs for the structure become simpler.  This tends to happen because the developer realizes that the simpler the design, the easier to fix when a bug occurs.  So we want to use the simplest design possible to satisfy the requirements.
• Teams tend to notice that the speed of each round increases.  So Round 3 is faster than Round 2 which is faster than Round 1.

Links

• http://tom-sylvester.com/lean-agile/simple-game-to-demonstrate-agile-concepts-test-small-test-often-jenga/
• http://nandalankalapalli.wordpress.com/2011/09/15/game-test-small-test-often/

Script

1. Before starting
   1. Lay out the room to allow enough space
   2. Hang flip chart (for placing bug numbers)
   3. Create rules and post it
   4. Write down 4 bug numbers for each round on post its
2. Go over rules
   1. 3 rounds (3 minutes (1st), 1 min per iteration (2nd), 3 minutes (3rd))
   2. When a bug is identified, it is removed and not put back in
   3. Structure must be 4 length-wise jenga blocks tall
3. Break the room up into teams of 5-7 people
4. Get volunteers for different roles (hand out name tags for each role):
   1. Developers, BA, UX, Design, etc…
   2. Testers (only pull bugs/blocks)
5. Create 4 random numbers for the round and put them in your pocket
6. Start round 1 for 3 minutes
   1. When time is up, announce bugs for round 1 and post them on the flip chart
   2. Observe how many structures fell and the challenges the teams had
   3. Have the teams knock down the structure if it is still standing
7. Have teams separate the blocks into groups of 12 (1-12, 13-24, 25-36)
8. Start round 2 iteration 1 for 1 minute
   1. When time is up, announce bug(s) (between 1-12)
   2. Start round 2 iteration 2 for 1 minute
   3. When time is up, announce bug(s) (between 13-24)
   4. Start round 2 iteration 3 for 1 minute
   5. When time is up, announce bug(s) (between 25-36)
   6. Observe how many structures fell and the challenges the teams had
9. Have the teams knock down the structure if it is still standing
10. Quietly let the testers know what number blocks are for round 3
11. Start round 3 for 3 minutes
    1. Tester will identify the bug before it is placed on the structure and left out
12. Debrief

Example