Throwing paper airplanes to learn agile methods

My game programming class has started their final project, which is to be completed in two iterations. My intention was that they would deploy what they learned in the Advanced Programming prerequisite to develop good user stories and plans, but many of them asked specifically for some kind of lesson or activity to get a better understanding of agile methods in general and Scrum in particular. I spent some time yesterday searching for best practices here, but none of the canned exercises I could find satisfied my goals. I wanted something that would teach the basic structure of Scrum and include the use of a task tracking board. I ended up making some modifications to ideas I found online and deployed them in class today.

To start, I had them play this online Battleship game that is used by some trainers to get people—especially management—to understand the fundamentals of agile approaches. In the game, you can choose how many shots to take at a time before you get feedback about whether or not they hit. I had half the class work in a 40-shot increment and the other half work in 10 shots. As one would predict, the half with shorter increments had much higher scores than the others. Not only that, they were also done faster: the 40-shot students were among the last done because they had to be so judicious with their resources. I asked the class the difference between the two groups, and they correctly identified feedback as the key. I quickly explained how this is a decision we make when choosing, say, a waterfall-based or an agile methodology, and then we moved on.

I had them count off by fours to make four teams who don't normally work together, and I put each one in one of the "alleys" between tables in RB355. I drew a template task board, with columns for Story, Not Yet Started, In Progress, and Done, and had they copy these to their boards. I gave an overview of what would happen: a three-minute planning meeting that would generate tasks on sticky notes, followed by three three-minute "days" of a Sprint, followed by a review and retrospective meeting, and then another series just like that. They had seen some aspects of this before, so we were able to get right to work, and at this point, they were very curious about the activity we were going to do. I handed out their user stories, which are transcribed below, and after giving them about two minutes to read the sheet, we got into the planning meetings.

Product Backlog

Fleet
Build a fleet of at least four paper airplanes that satisfy the following criteria:

• A plane must be folded from 8.5”x5.5” paper only. No additional material may be added and no extra material may be removed.
• The nose of the plane must be blunted to avoid accidental injury.
• The plane must have crisp, clean folds. 
• A plane that satisfies the above conditions must bear all team members’ initials. This marks the plane as part of the fleet. Once initialed, a plane may not be removed from the fleet.\

Branding
Each team has its own name and logo.

• The logo must be publicly displayed by the team on their board.
• The public display must have each team member’s initials to indicate their approval.

Hangar
I have a hangar that indicates the starting position of my fleet. The hangar satisfies the following conditions.

• The hangar covers at least 11”x8.5” of the floor and be at least 1/2” off the ground.
• The hangar features the team’s logo.

Flight
Maximize the number of planes from the fleet that can touch the far wall while still in flight.

• The hangar is no more than two floor tiles from a wall.
• The plane thrower’s feet must not be more than two floor tiles from the wall.
• Sliding along the floor to the far wall does not satisfy the flight goal. The plane must strike the wall while still in the air.
• A plane that has met the goal is placed next to the hangar. No other planes may be next to the hangar.
• Earn points equal to the number of planes that pass the mark minus the number of planes in the fleet that do not.

This is a customization of the "agile paper plane game" that you can find in various places online, such as here. All versions of the game I came across shared the property that each member of the team had to make one fold in planes. I did not like that approach, since that's not generally how (my) agile teams work. They don't have every piece of work move through every person like an assembly line, but instead, they rely on clear communication of both serial and parallel work. I also took inspiration from Lego4Scrum, where the tasks look a lot more like real software development work. I don't have the budget to buy enough Lego kits and have them sent via expedited shipping, so I combined the two ideas.

I provided both whole and half sheets of paper for their use, as well as the sticky notes and, after they realized that some of the sticky notes were not very sticky, some adhesive tape. The students got right to work and stayed within the bounds of what activities belonged in which timeslice. They were clearly and intensely focused, which made it both rewarding when a plane soared straight to the far wall and comical when so many of them flipped and flitted about before nosediving into the ground.

I noticed as they worked that some teams were using 8.5"x11" sheets to fold their airplanes, but I didn't challenge them on it right away. Rather, at the end, I asked them to review the conditions of satisfaction and have a chance to come clean. One team had recognized at the end of the first sprint that they were in violation of the airplane acceptance rules—one of the emergent leaders pointed out that he only read "8.5x..." and assumed the rest would read "11" and not "5.5". They made tasks to deconstruct their hangar and planes and recreate them to satisfy the constraints and did so in the second sprint. Another team had not read the conditions carefully at all and only realized they were in paper size violation when the other team told their story.

I asked each team to share stories about what changed between the two Sprints, and the results were fascinating. One team discovered the value of cross-functional teams. In their first Sprint, they distributed tasks and as a result only had two different plane designs, neither of which were making it across the room; in the second Sprint, they all worked on each piece and made more progress. Another team pointed out that they jumped into the plane-folding task with gusto because they were excited about that, but that their excitement was not actually producing anything that satisfied the conditions. That team added a more explicit research step in the second Sprint, which helped them vary their designs and produce more useful planes. I pointed out that Scrum allows for "spikes" that are used for just such cases. I wish I had taken better notes, because the other two teams also made changes to their process in such a way that highlighted core agile practices and attitudes, but now I cannot remember them. It's like I tell my students regularly: "I will remember this" is the primary fallacy we tell ourselves.

At the end, I asked them to share their insights about what they learned from the exercise that could be applied to their final projects, and the results of this were excellent as well. Topics that were brought up include the importance of making estimates (and in particular, of making them large enough), giving adequate time to planning, articulating tasks in a clear and measurable fashion, and keeping everyone aware of your progress on your tasks.

I was really surprised by how well the exercise went, perhaps in part because it's so unlike the kinds of things I normally do in class. I generally prefer to do and reflect on authentic work rather than small simulations or throwaway work, but here I think it let the students focus on the process rather than the minutiae of programming. I was really impressed by their reflections on the process and its implications for their project. My own professional preparation with agile software development methods allowed me to hear their stories and contextualize them within more general principles and rules.

There were a few things that I would change for next time. It wasn't clear to me that having a "Stories" task on the board mattered at all, or that anyone used it the way I intended. The exercise would  have been fine without it. A couple parts of the handout can be clarified. I had two students come up to me with what I would call "pointy" planes and asked if they were "blunt enough." I started telling them to use their eyes to measure bluntness: if it fits in your eyeball, it's too sharp. This was maybe a bit challenging to interpret, so maybe another measurement of bluntness is appropriate. In my description of the hangar, I meant that it should have a volume of at least 11"x8.5"x0.5" and be sitting on the ground, and I should have just said it that way. Instead, I worded it as 1/2" off the ground, which some students interpreted as elevated, like on a chair or table. One team was also unclear about whether it was the front or the back of the hangar that should be within two tiles of the wall, although this was also the team that tried throwing their planes at the near wall instead of the far wall, so I think this was an intentional trying to game the system and not an honest mistake. (We did not come back to the point that this one group tried to interpret the rules in their favor rather than seek confirmation or favor value for the customer.) Almost every team ended up having one person write each other team members' initials on their planes and logo, rather than what I intended, which was that each person inspect the work and then initial it. I can make that more clear.

That's the story of my game programming class today, finished writing just in time to go to my next class of the day. As always, please feel free to leave a comment about your experience with agile training games or ask about the activities of the day. I expect I will reuse the exercise again in a future course.