Creating Agile Games for Coaches & Consultants

Yesterday Chris and Elisabeth Hendrickson led a day-long dress rehearsal for a class called Creating Agile Games for Coaches & Consultants. The idea for the course grew out of various experiences: Chris has led sessions on Agile learning games at several conferences, and they've always been hugely successful, and Elisabeth has taught learning games, and held "game days" for coaches at her Quality Tree Software offices in Pleasanton. She's also done a lot of work deconstructing games, and building a set of principles and processes for how to create or adapt them to target specific learning objectives, as well as amassing an amazing array of boards, markers, spinners, dice and the like.

The day began when David Chilcott walked into the room and wrote on a flip chart: "Do not think that you will necessarily be aware of your own enlightenment." Which proved true more than once.

At the beginning of the session, one of our 14 testers asked, "How would you like to receive feedback, in the moment, after the fact, verbally, in writing?" To which we said, "Yes, please." I mostly lurked throughout the day, taking copious notes so that we might capture the goodness and update our program and class materials for when we offer the class fer real in Portland on May 1st.

To kick things off, Chris and Elisabeth discussed various game elements like chance, choice, turns, roles, winning, etc., and how to select elements to match different learning objectives. Then they laid out a basic set of steps and broke everyone into teams. Most of the day was spent devising games, while Chris and Elisabeth floated from group to group, jiggling them when they got stuck somewhere, but trying to stay out of the way of the creative process. Some phases ran long, and others we didn't get to, and we learned a lot from that about how better to calibrate the day.

We've always found dress rehearsals immensely helpful in developing classes, and this time was no exception.The opportunity to have an iteration 0 helped us immensely in shaping the future class. Going in, Chris and I were a bit worried that we didn't have enough structure mapped out, while Elisabeth, who has taught a similar class before, was more sanguine. We were wrong and she was right; starting with the minimum necessary framework was absolutely the right approach. I commented to Chris as we were packing out, "We learned where we needed more and where we needed less, and with more structure and planning--we would have learned where we needed more and where we needed less."

The same pattern emerged in the four groups collaborating on building learning games: The more talking a group engaged in, the less progress they made. The groups that shifted to a trial and error approach and started playing and iterating made more progress sooner. A group working on a game illustrating the value of TDD got bogged down in too much up-front planning. Rob Myers, a well-known TDD advocate, summed it up neatly, observing dryly, "We've spent half the day to arrive at the realization that test-driven development works!"

Over the years, I've grown to take more pleasure in being proven wrong more than I do in being right, as it means I've learned something new. I think Agile values and practices speak to me because they encourage that mindset, and I observed the same at work in the group of stellar minds who honored us with their presence.

Jeffrey Fredrick observed that learning games are quite fundamentally different from recreational games, which are most often about winning and losing.

Jeff McKenna remarked that it was hard to remember to think like a participant and not like a coach, but that one had to step out of the coaching role and think like a player in order to do the work of designing a game. He also questioned the term "game," suggesting that much of what was being created could better be described as "simulations," which speaks to Jeff's point about the characteristics of learning game objectives.

Three of the four teams ended with finished games: a poker-based card game, a game with dice and story cards, and a kinesthetic game where people went on a kind of treasure hunt for balloons. The fourth group worked on a complex game-in-progress Cesar Idrovo brought with him to the workshop, and they had some good ahas around that. Some groups built their success slowly and steadily, while others made progress in big, sudden leaps.

In all, the level of engagement was extraordinarily high, which is remarkable considering that game design appears to be composed of 90% frustration and 10% exhileration. "You need to bring in lunch when you run this workshop instead of having a break," Steve Bockman said, "We just wanted to keep working on our game without disruption."

Many thanks to everyone else who turned up, including Mack Adams, Daniel Bols, Peter Dean, Don DeCosta, Rich Gierak, Ed Kraay, Craig Sakowitz and Joanna Zweig.

We've turned on registration for the May 1st workshop in Portland. And ff all goes well with Chris and Elisabeth's submission, you'll be able to catch an abbreviated three hour version at Agile 2009.

Comments

[Siraj]

Hi Hillary -

Good post and I will also email you a couple of our Games.

I can understand the comment re Games vs Simulation. Let me try using the term "simulation" here and see if the message comes across clearly.

The reason I need this clarity is because I use the word "Games" for another concept of learning human behaviour (as described by Eric Berne).

More when we meet. best wishes to Chris!

[Chris Sims]

Thanks Siraj!

Keep the couragile strong!