John Heintz, from Gist Labs, has just released his Agile Airplane Game at http://gistlabs.com/article/377/agile-airplane-game.
It is a game in which multiple teams have to coordinate to fold certain quantities of different airplanes that meet certain acceptance criteria (like being able to fly 🙂 ). John has made a nice matrix on what aspects of agile are covered by this game:
I have not been able to test this game myself, but I am planning on doing it soon.
I usually play it with two to three teams. In my opinion it’s very helpful to have more than one team, because mostly the first insight the teams are generating is the fact that they have to deliver as company not as a single team.
Does anyone have any suggestions how many teams work fine (two, three, four)? Having four teams with a big starting budget makes it easier to produce the planes in time than only one team.
I have not the chance to test it with different teams.
Hello Everyone!
Thanks for the interest in my teams version of the Agile Airplane game.
I’ve updated my website (but the link above still works) and fixed all the links, sorry about the trouble!!
Jim: Thanks for playing, and excellent conclusions. Those are exactly the conversations I wanted to evoke.
I’ll watch this space for comments, but feel free to contact me at john at gistlabs . com as well.
Cheers,
John
Simon.. Thanks for bringing up the missing links, but as I stated in the blog I am not the author of the game. I just referenced something I found on the web.
I have tried to let John know that his links are missing though. I also looked through my download history to see if I had them for you, but I am afraid I don’t have them anymore.
Anyone else who can help out Simon?
Game looks very interesting but none of the Dropbox links work, so I can’t get the PDFs.
Can this be fixed so I can try this game out ?
Regards,
Simon
Love the paper airplane game! It can also be infinitely modified to teach a variety of concepts. I first played it in my manufacturing days (long before the Agile manifesto was written). It was used to teach us about theory of constraints, continuous flow and self-organizing teams. Many years later, I used it to teach Agile concepts but modified it to include concepts on communication – each team received the instructions a different way – demonstrated, diagrams, and written instructions (no diagrams).
Each time, there was one unexpected outcome – the tester(s) had a sore arm the next day from throwing so many paper airplanes!
Used this today with a group of 28. EXCELLENT OUTCOME! Gave me lots of common ground to discuss all sorts of things, including risk management, cross-training, how work is prioritized, how changes in the market affect prioritization, and (MOST IMPORTANTLY) why Scrum teams need to keep a product-view (instead of a team-view) toward producing the product. My teams today learned a lot about having to work together to get the right outcomes.