The bridge exercise is a typical icebreaker for the first lesson of the course. It clears the fairway for the upcoming course ("breaks the ice") in several manners: It reduces social reservations by providing a problem that has to be solved together, it reduces the uncertainty for the course by giving a sense of achievement when the first problem of the course is solved and it introduces first terms and concepts of the course that can be experienced by practical work.

Question

The main stakeholders of this exercise are participants of software engineering
courses (novice as well as experts), but you can find managerial and communication
aspects as well (see Variants below).
The mission:
? The job for the team is to build a bridge connecting the two watersides of a
river.
Requirements:
? The bridge has to be self-supporting, so no pillars are allowed in the middle of
the bridge.
? Pedestrians shall be able to get onto the bridge from the level of the edge.
Of course there is no real river needed for this exercise, two tables that can be moved
around do the watersides for this exercise. The building material for the bridge is
plastic in form of toy Lego building bricks.
Implementation: For the solution of the problem the teams get
? 3 large buckets of Lego building bricks
? Two tables that can be placed in a way that there is up to 150 cm distance
between them (the width of the river)
Acceptance criteria:
? The bridge must span the gap for at least one minute.
? If more than one bridge passes this test, an additional stress test is performed:
One by one, individual Lego pieces are placed at the middle position of the
bridge. The bridge collapses under the biggest load - i.e. the largest numbers
of added Lego pieces - wins the competition.
Schedule:
? 30 minutes for planning and prototyping (Prototyping) and
? 5 minutes for the final build from scratch (Construction) .
The beginning and the end of the phases are being signalled by the instructor. At the
end of the prototyping phase all Lego parts have to be taken apart again.

After the construction phase is finished, each bridge built by a team is tested
according to the acceptance criteria.

Answer 1

Discussion of the solution space:
If the complete 150 cm shall be connected with the bridge, there is only one solution:
the lego pieces tilted, with the knobs on the side. If the Lego pieces are connected in
the "usual" way - with the knobs on the upper side - the connection between the parts
is not good enough to carry the load of the pieces.
The speciality of this exercise is, that the participants have to obtain this knowledge
while doing the design (unless they already know the „trick“). Usually they find this
only during the construction phase, often by accident. Unless they have this design
knowledge, the teams will attempt to build „very solid“ bridges and soon run out of
parts.
After the teams finsh the bridge exercise there is time for a summary for what has
been done. Now the course participants get to know first concepts of software
engineering and project management which can be referred to by discussing the just
finished exercise in terms of process and products (see the comments on this exercise
as well).
It is possible to introduce 2 variants, to make this exercise even more „software
engineering like“:
VARIANT V1: Change the Requirements in the middle of the prototyping phase
To show how the strong winds of change often blow in Software Engineering, the
requirements can be changed 10 minutes time before the planning phase ends - don't
tell from the beginning, that the width of the river will be 150 cm but something like
50 cm. With that you let them run in the wrong direction - the trick isn't needed for
such a small width. When you change the requirements (river is 150 cm broad instead
of 50 cm) the participants will have to rethink their strategy quickly and do a total
redesign of their work.
This variant is in particular good for „upper level“ courses, master or senior
development courses. Include their experience into the summary at the end of the
exercise. Mention scalability of systems (also compare this with the WASA (see
lectures slides in SPE).

VARIANT V2: Team Competition - Two teams in one room:
This variant is particularly useful for project managers working on distributed
projects, or even global software engineering projects.
If there are not enough rooms, let the two teams start and stop in the same room at the
same time. Although there is competition, the teams will do some type of
collaboration by observing the other team: If one team got the "trick", the other team
will follow immediatley.

How to determine the winner (can be done as part of the acceptance test):
- 10 Points when the bridge does not crash for one minute
- State that the average number of pieces is 60. A team gets 60 points if the bridge
has been constructed by the team. Points are added or subtracted, based on the
deviation from this goal (53 pieces: 7 pieces saved -> plus 7 points. 66 peaces : 4
additional pieces needed-> minus 4 points)
- Stress test points: Add additional pieces to the bridge during a „stress test“: One
point for each additional piece the bridge could „endure“ during the stress test without
breaking apart.
Include any team comments, observations and whatever else you see during the
sessions into a summary and deliver this summary at the end of the exercise or at the
beginning of the next lecture. Topics like nondisclosure and patents can be easily
added as discussion points as well as design re-use and design patterns (pattern for a
building unit, to be built in parallel by each team member used to speed up the
construction phase)