Yesterday I had the great pleasure of speaking to two undergrad business classes at the University of Virginia’s McIntire School of Commerce. The students are primarily accounting and finance majors, with a few engineering majors thrown in for good measure. I provided an overview of Agile methods to the class, and we did an exercise to help demonstrate some of the concepts.
After a very quick definition of agile, we jumped right into a paper hat and boat folding game, known as “the bottleneck game.” Pascal Van Cauwenberghe and Portia Tung provide excellent pre-made materials for this game, using the title “I’m not a bottleneck! I’m a free man!” You can download the materials in several languages at http://www.agilecoach.net/coach-tools/bottleneck-game/.
The exercise is a multi round game illustrating lean principles, where the teams continually improve their ability to fold paper hats and boats according to some set specifications. There are seven roles: customer requirements, analyst, design, programmer, interface design, tester, and customer acceptance. Each role has very specific instructions that they have to follow, and inevitably the programmer will become a bottleneck in the first round of work.
In today’s classes, I only had about 75 minutes total, so we just did round one of the game. Because the audience was business undergraduate students, most of them don’t have much real world experience yet, and even less exposure to real world IT projects. In most trainings, when you talk about the perils of waterfall projects an audience of seasoned professionals will nod their head and know exactly what you mean.
But in this case they don’t all have that life experience yet, and so the first round of this game was a very useful way to give the students a sense of the different roles in typical software projects, and the types of challenges commonly encountered.
Not only was the programmer the bottleneck in all teams, but we also ran into similar problems of understanding the requirements (ie, boat folding instructions), learning curves, idle time for the testing team, and not discovering defects until late in the process.
After the exercise, I talked more about the general agile principles, and gave them a very high level view of agile and scrum methods. Throughout we were able to reference the observations they made in the bottleneck game, and that seemed to really help the learning.
At the end we had more Q&A and they asked some excellent questions. They asked about contract models, getting customer involvement, documentation, and more. The whole session was a lot of fun! Thanks to Pascal and Portia for providing such excellent materials and instructions that made this exercise very easy for me to lead. Thanks also to Professor Gigi Kelly for the opportunity to discuss agile with her classes!
