s part of the training and workshops I organised for the group projects I’m running this summer I decided to see how some of the ‘games’ would work in conveying agile prinicples to the students. I tried James Shores ‘Offing the Off-site Customer‘ and the ‘Lego XP Game‘ last week. Both went reasonably well I think.
On Monday I gave the students an overview of why they’d not be using the waterfall model for software development, and why we’d go for incremental and iterative development processes instead. In particular I explained why small we’d want to push decisions to as late as possible because of the cone of uncertainty, and therefore a user story on a post-it note would suffice to capture the essence of the need at the start, and you’d end up getting more details in a chat with the person later when you knew more about the product being developed. I also pointed out that waterfall assumes the product is being manufactured, when in fact, as agile assumes, software development is really, as Clark Ching points out nicely in Rolling Rocks Downhill, that it is product development: what is the best way to make this ‘new’ product or service? Software development is an exploration, and therefore change is the normal state of affairs, as nobody can know all of the requirements up front.
On Tuesday we looked at requirements gathering and user stories. This went well. We also used Shore’s game to highlight the relationship between the customer and the developer. In the first run of the game, where the developer and the customer are divided and the analyst conveys the information, some students started writing down descriptions of the diagram that was ‘the product’, and others only laterly, after suggestions, started going back and forth desciribing what was needed.
In the second version, when the developer can speak to the customer and the analyst at the same table, then this went much better and a few students even picked up the idea of developing ‘tools’ to establish right-angles and function as ‘rulers’. Very nice work by them.
On Wednesday we looked at estimating and planning following the ideas of Mike Cohn. This went well, and we followed it up with the Lego XP Game. This was delivered smoothly, and the students soon learned not to mess with the lego outside of the ‘build’ time, as my assistant and I had to destroy artifacts being built in the estimating and planning stages. Our explaination was that ‘oops, the customer didn’t like that version. A shame you wasted your time building something no one asked you for.’
The game follows a clear ‘estimate, plan, build, retrrospective’ phases and with the help of an online stopwatch worked well. In the second, and especially the third iteration of the project, the students knew what they were doing, and focused on the estimating and planning more appropriately.
We had seven teams of four, as we didn’t have enough lego for nine teams of three – the box of lego that would hold four/five? reams of paper was just enough. The more lego you have the more interesting and easier the tasks are to complete for the teams.
Using both games to reinforce the ideas covered in the lecture worked well I think, and I’ll run them again when we cover these topics again. It broke up the day well, so that it wasn’t just lectures and practicals, but also some relevant experience ‘doing’ what is needed so that the students understand ‘why’ the different steps are necessary. Both games were full of noise and excitement and did a good job of representing the ideas and processes of agile methods. If you’ve not tried them, then you should. You’ll find links to others if you google ‘agile games‘, or head to agile fun.
