Lessons from a Paper Bridge

Yesterday, TSOT engaged in a company-wide exercise which was supposed to teach us about teamwork and blitz planning. In the process, we got a couple of lessons that could be applied to the process of building software.

The Assignment

The people participating in the exercise were divided into three teams of four people. The assignment was to build a bridge across which a ball about the size and weight of a plum could be rolled.

The specs for the bridge were:

• It had to be free-standing; we were not allowed to secure it to anything
• It had to have a minimum span of 4 feet (about 1.2 metres)
• While travelling across the bridge, the ball’s minimum height off the ground cannot be less than 2 feet (about .6 metres)

The items with which each team was allowed to construct the bridge were:

• 8 sheets of easel pad paper (each sheet is about 36″ by 24″)
• 4 plastic beer cups
• 4 thick paper plates
• 1 roll of masking tape

We were given ten minutes to come up with a construction plan and twenty minutes to construct the bridge. We were given a stack of 3″ by 5″ index cards for writing out our plan. Each team had to pick a team leader, who would direct the activities and make notes of the plan on the card.

The Outcome

I’ll cut to the chase: the team I was on, Team 2, won. Not only did we build a bridge that met all the criteria, but we finished its construction in 10 minutes and had enough time to hang out in the lounge while the other teams kept working. Here’s the bridge that our team built:

Our team’s bridge.

Another team, Team 1, took all the allotted time. Their bridge met the “freestanding” and “4 foot span” criteria, but didn’t meet the “ball must be 2 feet off the ground throughout its travel across the bridge” criterion. Here’s the bridge they built:

Team 1’s bridge.

The last team, Team 3, weren’t able to complete their bridge in time.

The Design

The bridge we built, viewed from another angle.

The span of the bridge was made with 4 sheets of easel paper: 2 rolls, each one a 2-ply roll of paper, which were then joined together with a one-foot overlap in the middle for extra strength. The design was unconventional, but there wasn’t any rule that the bridge couldn’t be a covered bridge.

The pillars of the bridge were each made with a 2-ply roll of easel paper, with a plastic beer cup at the top and base. For extra stability, we attached one paper plate to the bottom of one pillar and two paper plates to the bottom of the other pillar. This gave the span a slight slope to ensure that the ball would travel from one end of the bridge to the other (there was no requirement that it had to be a two-way bridge).

The span design was my idea, so I was assigned to build it with the assistance of the team leader. The other two members designed and built the pillars. The pillars were mostly identical, so the guys building them consulted with each other throughout the building process.

Although we were given scissors, our design didn’t require any cutting. I’m certain that this cut down on the construction time significantly.

The Lessons

Our bridge, viewed from one end.

The exercise demonstrated the expected points about teamwork (a good leader, clear communication between team members and cooperation) and blitz planning (a simple plan, an iterative approach and adapting to real-world feedback). It also yielded some unexpected lessons about design:

• Build the simplest thing that could possibly work. It’s an oft-repeated mantra in Agile Development, but it’s something that programmers sometimes forget — probably because we often erroneously equate “simple” with “stupid”.
• Go with the strengths of the material you’re given. The other teams built structures that took their inspiration from real-world bridges. This might be a good approach if the materials we were given were popsicle sticks, but since we were working with mostly paper and specific height and span requirements, we decided that a tubular design would be the best approach. It offered the advantages of strength and ease of construction.
• The corollary from the previous point is that the solution may look different from what you might expect. With the two previous points and the time constraints in mind, explore the possibilities.

Although the exercise is now over, we’re keeping our bridge around as a little reminder of the design lessons we learned — we plan to use them in building our software.