I have to admit that when I first started hearing about Extreme Programming and Agile methodologies, I was pretty skeptical. Another software fad that will come and go, I thought. What first started to open up my mind was a conversation that I had with a young developer a number of years ago. I was interviewing him for a position and he was talking about Extreme Programming and I was thinking “Yeah. OK.” Then he said that without Extreme Programming he didn’t think he would still want to be doing development because Extreme Programming had made software development fun again. And that’s when I stopped and thought to myself, “Well, yeah, you know – it should be fun. It’s supposed to be fun.”
And by fun, I don’t mean “drinking beer and playing foosball” fun (not that there’s anything wrong with that). I mean software development fun – the reason that most of us got involved in this profession in the first place. The fun of knowing that the application you developed is absolutely right – it solves the problem perfectly – the users want it now – and your code is absolutely beautiful. The pain of tracking down some obscure bug and the total joy of finding it. The fun of working in a team and arguing and bouncing ideas off each other and learning from each other – that kind of fun. So while I don’t by any stretch of the imagination believe that Agile development practices are perfect or totally mature or fit the needs of every development challenge, the idea that fun is somehow part of the equation of creating great software, somehow strikes me as being very true.
So it made sense to me that at the Agile Alliance 2009 Conference, I found there was a growing focus on games as a way of teaching Agile concepts. I went to two game-oriented sessions, both by Portia Tung and Pascal Van Cauwenberghe. The first session was titled “The Bottleneck Game: Discover ToC, Agile, Lean and Real Options by Playing” and involved optimizing a production line for creating paper boats and paper hats. (My job was to make the 1st fold and draw a line down the middle.) The second session was titled “The Business Value Game: Transform How You Prioritise Projects and Stories.” This session focused on prioritizing stories by business value for iteration and release planning. The material was presented by having all participants engage in a pretty elaborate card game. Later, I went to a ThoughtWorks open house and one of the ThoughtWorks “stations” featured an Agile board game that they had created. At the conference, there were sessions on the “Kanban Game,” “The Distributed Agile Game,” “Agile Cross-Culture with Games,” etc. There was even a session on “Creating Agile Simulations and Games for Coaches and Consultants” by Elisabeth Hendrikson and Chris Sims (which I wanted to attend but had a conflict with another session).
So are games popular for teaching just because they’re fun, or is there something more? In his Agile Alliance keynote, Alistair Cockburn talked about software development as being a “Collaborative Game.” He went on to say that games have positions, moves, and strategies. Maybe one of the reasons that games are a good teaching tool is that the game creator is forced to explicitly abstract out and communicate (via the rules of the game) these positions, moves, and strategies. In a game, implicit mechanisms are made explicit to the players and these mechanisms are experienced in the course of playing, rather than simply being read (in an article or book) or heard (in a tutorial or webinar).
It looks like games are becoming a big part of Agile training. Sounds like fun.
