[Agile Games] Jenga Builders

Summary

The core idea of this game is to have teams build wooden structures with jenga sticks. The game is played by rounds, where each round is supposed to deliver an Agile lesson. In the context of this post, attendees can expect to learn about the darkness principle, quick feedback and communication, and being adaptive to change.

Each round after the first is essentially optional, the host can choose to add/remove rounds depends on available time. The host is also welcomed to pick, or customize her own round to deliver the desired lesson.

Team size

Minimum 4, ideally not more than 6.

Timing 

20 - 60 minutes depending on team size and number of rounds.

Materials:

• A deck of Jenga
• Photos of pre-designed structures, 3 x no. of team / round
• A whiteboard to record scores

Instructions

This game will be run over several rounds, with each round introducing a new concept.

Setup

• Split up the group into team of at least 4, and ideally not more than 6.
• Choose one person from each team to be the Analyst. The Analyst knows the core of the structure, but not which colors to be used. The Analyst is not allowed to touch Jenga sticks.
• Choose one person from each team to be the Designer. The Designer knows the required colors for a specific part of the structure. The Design is also not allowed to touch Jenga sticks.
• Choose one person from each team to be the Tester. The Tester knows the whole structure, but can only answer questions and is not allowed to give instructions or touch Jenga sticks. 
• The rest of each team will play Developers. Developers are the only ones who can actually use Jenga sticks and build stuff.

• The Analyst is given a photo of the structure needed to be built. The color of the sticks in this photo does not matter, in practice, team can use whatever colors available.
• The Designer is given another photo of a part of the structure needed to be built. The color of the sticks in this photo is crucial. The part must be a component of the final structure, with the exact color depicted in the photo.
• The Analyst and Design have to combine their knowledge of the system and convey that to the Developers, who build stuff.
• The Tester is given the photo of the final structure and has the right to accept or reject the work of the team.
• The initial flow is that The Analyst and The Designer will discuss and agree on the structure, convey the idea to The Developers and finally the work is given to The Tester to accept or reject.
• No one is allowed to show her photo to others.

Round 1:

This round teaches The Darkness Principle.

Each element in the system is ignorant of the behavior of the system as a whole, it responds only to information that is available to it locally. This point is vitally important. If each element 'knew' what was happening to the system as a whole, all of the complexity would have to be present in that element.

After the team has formed and roles assigned, give the below photos to relevant team members. And the game begins!

Analyst #1

Designer #1

Tester #1

After all the teams have completed their structure, ask questions on what happened, what went well, and what went wrong.

Learning:

What we learn from The Darkness Principle is that nobody on a team has a complete picture of all that's happening in the entire team. Each team member can only have an incomplete mental model of the whole project. That is why they have to plan and decide together.

Round 2:

This round teaches Quick Feedback and Communication.

Give the below photos to relevant team members.

Analyst #2

Designer #2

Tester #2

The trick here is that there are many different possible outcomes from the photos given to The Analyst and The Designer. Only The Tester knows the correct one. But he is at the bottom of the chain. 

After all the teams have completed their structure, ask questions on what happened, what went well, and what went wrong. And if they want to make any change to the work flow.

Learning:

The work will be carried on in usual manner, then given to The Tester to be rejected. We should note half the amount of work was wasted, and that the position of The Tester isn't optimized for quick feedback loop.

Round 3:

This round teaches Being Adaptive To Change.

Give the below photos to relevant team members.

Analyst #3.1

Designer #3.1

Tester #3.1

The trick here is that the outcome is almost possible to do. (At least for me, I had to put a finger on top of the whole thing to prevent it from falling apart.)

Somewhere half way, when the teams keep failing to build the structure, hand out this second set of photos.

Analyst #3.2

Designer #3.2

Tester #3.2

This time, the structure should be possible. (I managed to make that.)

After all the teams have completed their structure, ask the same retrospective questions.

Learning:

What we learn from this is that goal and target are not always rigid, and in order to deliver, sometimes, reasonable compromises are needed.

Round 4:

Freestyle. This round is for the team to summary what they have learned in previous round and as a whole, feel good about the learning curve. "Finally, a proper sprint!"

Analyst #4

Designer #4

Tester #4

All structure photos can be found here https://www.dropbox.com/s/np96ltzrdznpmxc/JengaBuilders.zip?dl=0

Observations

The game had its first debut at Silicon Straits 18th Feb 2016. Below are the points I observed from that first try.

• As suggested by The Darkness Principle, the key to win this game is communication, communication, and communication. A good team did a lot more talking than their lesser counterparts. Members in a good team were more willing to listen to each other and showed less tendency to suppress minority's ideas. The existence of an alpha role was subtle. All are desirable behaviours for brainstorming sections. The good team also utilized the role of Tester better (raise more questions and shorter feedback circle). 
• Whereas in the bad team, where The Analyst and The Designer had troubles expressing their vision, the team stumbled trying to get the sub-components right, left alone combining them together. With bad vision, the team fought for an alpha role, a process in which team members just went ahead trying to prove them right, spent less time listen to each other, and suppress more "silly" ideas (unfortunately, a few of them were really good). And in general, the bad team were more distant to leadership (members with photos) and treated them as checkpoints, rather than equal collaborators. 
• The gap of speed between a good team and a bad team can be quite big, up to 100% (my subjective observation). This had a couple of by-effects. The good team had way too much free time. The bad team is demoralised. It was suggested to have not 01 host for the entire game but 01 host for each team, constantly checking with each other and dropping hints to keep teams on pace.
• Can consider switching roles between rounds, so that people can try different positions, have time to slow down themselves and do internal retrospective.
• Stronger emphasis on mini retrospective meetings. The debut was run with participants all standing. While this was good for the game play and team dynamics, it thwarted the necessary pause to retrospect what happened, what went well and bad, any improvement to make.
• At some point, The Testers would try to manage the whole project, because they have the complete view of the structure. But as they aren't allowed to give instructions, team needed to have good strategy to query the correct requirements. So far, none of the teams spent time on improving the art of asking questions.