Simple Game to Demonstrate Agile Concepts: Test Small, Test Often (Jenga)

Description: The below game is a simple but powerful one that is used to show the benefit of tighter feedback loops that come from frameworks such as using agile.

Thanks to Nanda Lankalapalli for introducing this game to me.  The original description can be found on his blog.  I first played this game when I took a trip to Denver and visited ePlan Services.  The purpose of the trip was to meet Lisa Crispin (co-author of Agile Testing) and observe how her team implemented scrum.  During my 2-day visit, I was introduced to Nanda and we played this game.  Since then, I created my own Jenga set and introduce the game to most of the teams that want to start developing software more incrementally.

Materials:

• Subset of Jenga blocks, numbered 1-36
• At least 2 people (One person to play the developer, one person to play the tester)
• Random Number Generator (Optional) – You can use a generator like this one, or just pick some on your own.  Make sure the numbers are different for each round.

Requirements:

1.     Build a structure that is at least 3 stories or taller.

2.     Use all blocks.

Example:

How to Play:

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.

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 points out problem blocks (the number blocks that are bugs) and the developer needs to remove the bugs and still comply with the requirements.
• Round 2: In this round the tester is allowed to point out the problem blocks after every 9 blocks (1/4) are put in.  So, the tester gets 4 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 put out problem blocks (bugs) right away.

Learning Point:

Tester and developer when working together, deliver high quality software with less rework. The first case depicts water fall 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 introduced.

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, it is the most agile way and the tester is helping developer avoiding putting the bugs in. It may not be possible to reach this in software development. Getting as close as possible to this level of agility is what an agile team should try for.

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.

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 bug can be missed and the impact of that in later “rounds”.
• The initial requirements are ambiguious (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 (4 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 the blocks.  This would represent a bug that reoccured, which can happen in development.
• 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 they 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.
• 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.