This activity introduces the concept of iterative development along with the concepts behind it. Most importantly, it illustrate that upfront large plans do not always work, while working using small iterations may yield better results. In particular, this activity is useful when introducing the concepts of agile development, describing scrum sprints, as well as product and sprint backlogs. This activity uses the game of Tetris as a foundation.
As a result of completing this activity, students will be able to:
- Understand the concepts of plan-driven and iterative development;
- Apply the concepts of iterative development in a team setting.
- Basic familiarity with the concept of software process.
Up to 30 minutes.
Number of participants
This activity works equally well for small and large groups. The game is played by pairs of teams, A and B. An ideal size of each team is 2-3 people, but there's no limita on the number of teams, as long as there is an even number of teams. This activity works better for larger groups that would allow to form at least 3-4 pairs of teams.
Each pair of teams needs a separate building space (a medium table), preferably with chairs.
Materials and supplies
- Each pair of teams needs a small baseplate. The preferred size is 8x16. It is important that each pair of teams has a baseplate of the same size.
- Each pair of teams will need a selection of of standard (2x2, 2x3, 2x4, up to 2x8, and 1x2, 1x3, 1x4, up to 1x8) bricks. Important: the longest brick must not be wider that the smaller dimension of the baseplate. For example, LEGO Classic Large Creative Brick Box 10698 includes enough bricks for about 5 pairs of teams using 8x16 baseplates.
- Wikipedia: Tetris
Scenario of the activity
- Introduction: 5 minutes
- Discuss the game of Tetris and explain the difference between the classical and our LEGO-based version.
- The baseplate serves as the "well," and the force of gravity pulls the bricks towards its "bottom" (one of the narrow sides).
- Each brick needs to be placed as if it fell towards the bottom of the well: either at the bottom, or immediately above another brick. No bricks can be placed completely or partially below another brick.
- Unlike the classical game, completed rows of bricks do not disappear--they stay in the well.
- The game is over when a brick cannot be placed completely on the baseplate.
- This round simulates plan-driven development. Team A formulates the plan; Team B follows the plan and is not allowed to deviate from it.
- Team A lays out all of the bricks randomly in a straight line forming a queue (the queue of bricks is "the big plan"); Team B cannot see the queue. Team A decides which end of the queue will be its "top". The queue should not contain two bricks of the same size next to each other. This makes the game more challenging.
- Play the game in one long sequence as follows:
- Team A gives one brick from the top of queue at a time to Team B.
- Team B places the brick on the baseplate following the rules described above.
- Repeat the previous two steps until the game is over and no more bricks can fit entirely on the baseboard.
- This round simulates an iterative process. Teams A and B switch roles: Team B has the bricks, while Team A builds.
- Team B's queue of bricks simulates the product backlog. Team A builds using the same rules as above.
- Since now everyone knows the purpose of the queue, ask Team B to be "as mean as possible" when constructing their queue.
- Play the game in small iterations/sprints as follows:
- Team B gives five bricks from the top of the queue to Team A. These five bricks simulate a sprint backlog.
- Team A decides in which sequence to place the bricks from their sprint backlog on the baseplate. Team A then places one brick at a time on the baseplate following the rules described above.
- Repeat the previous step until the game is over and no more bricks can fit entirely on the baseboard. Otherwise, Team A starts the next iteration/sprint by asking Team B for five more bricks.
- Compare the average score from round 1 and 2. Why is the score for round 2 score always higher (even though Team B was instructed to construct a "difficult" sequence?)
Plan-driven development does not give the teams any freedom to anticipate change, which may result in lack of efficiency (lower quality metric) and technical debt (uncovered areas scattered throughout the baseplate).
- How did the teams feel about the game play in the second round?
Teams always mention that the rules of the second round allowed them to better see the bigger picture and plan their work within the iteration yielding better results.
- What are the similarities between the second round and scrum?
- Team A = development team
- Team B = product owner
- Team B's queue = product backlog
- Five LEGO bricks that Team B gives to Team A = sprint backlog
- The period of time when Team A works with those five bricks = sprint
- Cumulative size of the five bricks = team velocity
- Neither rounds of the game are timed. We found that the game is dynamic enough so that the teams do not need any encouragement to work at a reasonably quick pace. We also found that timeboxing each round often leads to distorted quality metrics.
- We recommend using a broad selection of bricks mixing an approximately equal number of 1x bricks (1x1, 1x2, 1x3, etc) and 2x bricks (2x2, 2x3, 2x4, etc).
- Having too many 'standard' bricks (like 2x2 and 2x4) with a baseplate of standard even dimensions (such as 8x16) makes the game significantly less challenging.
- It may be preferable to pre-sort the bricks for each queue. This will save time and ensure that each pair of teams has just enough bricks. Alternatively, each Team A may be asked to pick bricks from a common pile prior to starting round 1. The instructor will need to visually inspect each team's selection to ensure that each team has enough bricks (while not taking too many) and that the bricks are of sufficiently diverse and correct sizes.
Notes on scaling up/down
This activity works best with larger groups for several reasons. It scales well: there can be any number of A+B teams playing in parallel. It doesn't require too many bricks per each pair of teams. Finally, a higher number of teams generate better quality metrics.