This document describes an activity called TDD/Agile Jenga that is used to demonstrate the importance of early testing in the development process. The activity involves building a Jenga structure in three rounds with different testing approaches: Round 1 tests after completion, Round 2 tests periodically during construction, and Round 3 involves continuous testing. Participants provide feedback on how the activity illustrates that reducing the feedback loop between development and testing results in less rework and a faster ability to find and fix bugs. Debrief points emphasize starting testing earlier in the process to deliver higher quality software more quickly.

1. TDD / AGILE
JENGA
DMITRIY V. BLINOV
NOVEMBER 2017
SKILLSCUP.COM
DBLINOV.COM

2. TDD/AGILE JENGA
WHEN AND WHAT FOR?
▸ To help understand why it is critical to bring product
testing early into the development

3. TDD/AGILE JENGA
MATERIALS AND PREPARATION
Jenga Blocks, numbered 1-36 Write the numbers on the ends of the blocks
Find and book a room
Place Jenga blocks on each table
Rules (opt.) Create a flip-chart sheet or show the next slides
Empty flip-chart sheet for bugs (opt.) Hang it to place bug numbers on it
Random number generator (opt.)
Sticky notes
Randomly identify 4 bug numbers for rounds 1–3, write them
down on post-its, and hide them
Write down 4 bug numbers for each round on post its
Rulers (opt.)
Name tags for the roles (opt.) Developers, BA, UX, Design, etc. (builders) and Testers
Timer

4. TDD/AGILE JENGA
RULES
▸ 3 rounds, requirements remain the same. For each round:
▸ 3 minutes
▸ The developer builds the structure at least 5 length-wise blocks tall
▸ The tester provides feedback based on the rules of the round — when a bug is identified, it is
removed with one hand and not put back in
▸ The difference in each round:
▸ New set of 4 “bugs” to be fixed — random numbers between 1—36
▸ How soon/often we get to test the structure
▸ Recommendation:
Try to switch the roles that people typically play: have a tester play the developer role. This will
allow each person to gain some insight into the other roles

5. TDD/AGILE JENGA
ROUND 1
▸ 3 minutes: Developers build the entire structure of 36
blocks
▸ Only after the entire structure is built:
▸ Facilitator identifies the bugs (defect blocks)
▸ Testers are allowed to “verify” the structure —
remove the bugs

6. TDD/AGILE JENGA
ROUND 2
1. Group separates blocks into 3 groups of 12 (1–12, 13–24, 25–36)
2. 1 minute: Developers build a 1st 1/3 part of the structure (blocks 1–
12)
3. After 1/3 is built:
1. Facilitator identifies the bugs of the current dozen
2. Testers are allowed to remove the problem blocks after every 12
blocks are put in. So, testers get 3 opportunities to give a
feedback.
4. Goto step 2

7. TDD/AGILE JENGA
ROUND 3
▸ Facilitator provides testers with the numbers for each bug
before the round begins
▸ 3 minutes
▸ Testers are allowed:
▸ to work with developers as they are building the structure
▸ to point out problem blocks as soon as they see developers put them

8. TDD/AGILE JENGA
WHAT TO DO IN A ROOM?
Before start:
▸ Break the room up into teams of 5–7 people
▸ Get volunteers for different roles: Developers, BA, UX, Design, etc. — build. Testers — only pull bugs/blocks
▸ Hand out name tags for each role (opt.)
After each round:
▸ Count down how many blocks fell
▸ Observe the challenges the
teams have
▸ Have the teams knock down the
structure if it is still standing
Rounds:
1. When building time is up announce bugs for the round and post
them on the flip-chart
2. Before start have the teams separate the blocks into groups of 12
(1–12, 13–24, 25–36)
‣ When 1 minute is up announce bugs for the iteration and post
them on the flip-chart
3. Before start quietly let the testers know the defects numbers
‣ When a tester recognises the defect block, he/she tells about it
to the team

9. TDD/AGILE JENGA
DEBRIEF POINTS
▸ Reduce the feedback loop
▸ The earlier the tester gets on board, the faster you will receive feedback. Therefore, reduce the feedback loop between
development and testing.
▸ The biggest problem seen in lot of organisations is the attitude of the developers and testers working together, even though, this
allows to deliver high quality software with less rework.
▸ The 1st round depicts phased approach where testing happens after the Sw is built. If the bugs found are more fundamental (like
blocks in the 1st level), the project will be delayed more as rework is introduced.
▸ In the R2, feedback is faster. Developer could correct the code early and there is less risk than in the R1.
▸ In the R3, the tester is helping the developer avoid putting the bugs in real-time. Getting as close as possible 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, 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 to identify and prevent bugs as early as possible.

10. TDD/AGILE JENGA
DEBRIEF POINTS (2)
▸ After each point ask: How does this happen in real life?
▸ Only a part of the tower fell down — not entirely.
▸ I’ve noticed that you couldn’t found defects blocks.
▸ The tester has tried to replace defects blocks by himself.
▸ You’ve decided to put blocks consequently.
▸ Have the tower fell down entirely after the Round 1? And
after the Round 2?
▸ Feedback loop length
▸ Were the requirements met

11. TDD/AGILE JENGA
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.
▸ If a tester misses identifying a bug, it may show that bugs can be missed and the impact of that will be
seen in later “rounds”.
▸ In the beginning you may just say that “the structure should me 5 blocks tall”, omitting to mention “5
length-wise tall”. This would illustrate that the initial requirements are ambiguous. If a team doesn’t
clarify it up front, they may get to the end of the build and realise they misunderstood the
requirements.
▸ Even though, defect density is the same among rounds, the speed at which we found bugs is different.
▸ To take it further, even if there were twice as many defects in R3, they would have still be found
faster and produced a better product than in R1.
▸ As rounds go on, the designs for the structure become simpler. This happens because the developers
realise 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 R3 is faster than R2 which is faster than
R1.

12. TDD/AGILE JENGA
REFERENCES
▸ anAgileMind.net/2014/10/27/agile-jenga/
▸ Personal experience