This activity illustrates the importance of clear technical communication across different teams. It also emphasizes the point that it is often difficult to separate different activities of a software process (requirements engineering, design, implementation, and testing) into independent and separate stages. The waterfall software process is used as a foundation for this activity, in which the deliverables of each process activity are handed off down the chain of teams. As the deliverables generated by each activity move from one team to the next, some of the information will be lost or misinterpreted, resulting in the final product that is likely to deviate from the initial requirements.
As a result of completing this activity, students will be able to:
- Understand the importance of clear communication across every activity of a software process;
- Clearly communicate technical information throughout a software process.
- Basic familiarity with a plan-driven software process (waterfall) and its fundamental activities.
Up to 50 minutes.
Number of participants
This activity requires a minimum of four teams, each consisting of at least two students (overall, this activity requires a minimum of eight people). The optimal size of each team is 3-4 students.
Each teams needs a separate working space (a medium table), preferably with chairs.
Materials and supplies
- This activity requires one large LEGO set for each 4-5 teams. Suitable sets include LEGO Classic boxes, such as LEGO Classic Large Creative Brick Box 10698.
- Handouts for each step: one set per team (see below).
Scenario of the activity
- Introduction: 5 minutes
- Briefly review the waterfall software process and its basic activities: requirements, design, implementation, and testing. This activity will use waterfall to build a house out of LEGO bricks.
- Explain that each team will receive slightly different initial requirement specifications. Each team will focus on one process activity at a time, complete a worksheet, and then pass their results/deliverables to the next team. No team will be able to see the initial requirements after the first step of the activity. It is the intention of this game that the product will inevitably deviate from the initial requirements as the deliverables of each activity move from one team to another, and the information is lost in the process.
- Teams may not communicate with each other during any of the activity steps described below, except during debriefing.
- Step 1 - Requirements: 7 minutes
- Each team receives a handout with a set of Initial Requirements to build a house (see Handouts). Each set of requirements is slightly different. These requirements may be missing some pieces of information, but are not contradictory.
- Distribute Requirements Worksheets (see Handouts) to each team.
- Remind the teams to write the Product ID (from the Initial Requirements they received) on their Requirements Worksheets.
- Each team needs to fix the requirements by adding missing information and organize their set of requirements as an itemized list. The result must represent a complete set of requirements for building a LEGO house.
- When done:
- Instructor collects the sheets with initial requirements from each team.
- Each team passes their Requirements Worksheets to the next team. Each time one team passes something to another team, this flow of deliverables should always go in the same direction. Product IDs will help track each product (house) as it progresses from one team to another.
- Each team receives a Requirements Worksheet from another team.
- Distribute Design Worksheets (see Handouts) to each team.
- Remind the teams to write the Product ID (from the Requirements Worksheet they received) on their Design Worksheets.
- Each team needs to draw a sketch of the house using the information on the Requirements Worksheet they received. The sketch should include some dimensions/proportions, as necessary. The sketch must not contain any text, but it's OK to use numbers.
- Remind students to be mindful about the number of LEGO bricks that will eventually be needed to build the house they are now designing.
- When done:
- Instructor collects the Requirements Worksheets from each team.
- Each team passes their Design Worksheets to the next team.
- Each team receives a Design Worksheet from another team.
- Distribute Implementation Worksheets (see Handouts) to each team.
- Remind the teams to write the Product ID (from the Design Worksheet they received) on their Implementation Worksheets.
- Each team needs to build a house out of LEGO bricks based on the sketches and the dimensions specified on the Design Worksheets they received.
- Remind students to follow any dimensions/proportions listed on the Design Worksheet and to be conservative about the number of LEGO bricks used to build the house.
- When done:
- Instructor collects the Design Worksheets from each team.
- Each team passes their Implementation Worksheets and the house they build to the next team. During this step, teams will use the Implementation Worksheet only for tracking the Product ID.
- Each team receives an Implementation Worksheet along with the corresponding LEGO house from another team.
- Distribute Verification Worksheets (see Handouts) to each team.
- Distribute the original Initial Requirements corresponding to the Product ID listed on the Implementation Worksheet received by each team.
- Remind the teams to write the Product ID (from the Implementation Worksheet they received) on their Verification Worksheet.
- Each team needs to verify how well each house meets the original requirements listed on the Initial Requirements. Any inconsistencies/discrepancies/omissions must be noted on the Verification Worksheet.
- Ask each team how many inconsistencies they noted on their Verification Worksheet.
- Ask the team with the highest number of notes to discuss what they found. Trace these inconsistencies backwards through the chain of teams that worked on the house with the corresponding Product ID. Where did these inconsistencies originate?
- Ask all teams to discuss possible root causes for the inconsistencies discovered during the verification step. Do they have anything in common?
A consensus is very likely to emerge that the root cause was in lack of clarity, ambiguity, or omissions in the information passed from one team to another.
- Ask all teams how could we improve the process? How can we ensure that the house meets the initial requirements?
- Teams must be able to communicate without any impediments, without losing much of the information in the process.
- Each step of the software process--requirements, design, implementation, validation--should be performed by the same team to better facilitate creation and transfer of knowledge about the product.
- Implicit assumptions should be stated explicitly at the Requirements step of the activity.
- No problems were revealed until the last step, which is inherent to the waterfall process.
- Be clear about the initial requirements. It may be necessary to remind that each team is working on designing and building a house, but each set of requirements is slightly different.
- Teams will likely attempt to ask each other questions. No discussions across teams should be allowed. Various worksheets will serve as the only acceptable communication channel.
- It may be handy to have some colored pens and/or pencils available at the instructor's desk. Some product requirements may refer to different colored LEGO bricks, but the design step prohibits using any words on the worksheet. Students may want to use the colored writing implements to draw instead of writing color names.
- Remind the teams about remaining time. It is important that each team completes their component within the allotted time.
Notes on scaling up/down
This activity can be easily scaled up by adding extra teams. The game design ensures that each team will participate in each process activity. The game design also ensures that each team will see a product stemming from a different set of initial requirements, as long as there is at least four different sets of requirements and they are distributed in a sequence. For example, if there are eight teams labeled A through H and five sets of initial requirements numbered 1 through 5, the initial assignment of requirements to teams may look like this: A-1, B-2, C-3, D-4, E-5, F-1, G-2, H-3.