Being Agile when Designing and Playing Agile Games

July 30th, 2010 By Ellen Gottesdiener

In my Stickyminds.com column “Playing at Work: Agile Games Deliver Value” I share game ideas and experiences – the benefits games can provide, selecting an appropriate game, facilitating a game, and designing a winning game.

Designing and Facilitating Agile Games

When writing the column I got to thinking how agile principles could provide a basis for good game design and facilitation. I reflected on a recent experience I had at Deep Agile 2010: Empowering Teams with Agile Games. Working in a small group we created a new game, tested it, and retrospected both the game and our design process in less than half a day. We consciously (and some times unconsciously!) were being agile! (To see and learn more about our game, read Michael Sahota’s summary at The Backlog Is in the Eye of the Beholder.)

Games and The Agile Manifesto

To clearly communicate the agile-ness of our work and what we learned I did a quick mapping to the Manifesto for Agile Software Development.

Manifesto for Agile Software Development	Agile Game Design & Play
Individuals and interactions over processes and tools	Keep it simple: make sure the game is simple to play, and don’t get caught up in the game mechanics or use complicated, expensive game pieces. Provide ample time for players to interact and learn together.
Working software over comprehensive documentation	Provide simple player directions — concise, clear, and (ideally) not in writing.
Customer collaboration over contract negotiation	Require teamwork to reach the objective. Include chances for the players to reflect and debrief.
Responding to change over following a plan	Permit adaptations and iterations to the game. Include time to play the game again so that players can apply their adaptations. Encourage teams to consider how they can adapt their learning to their work.

Then I mapped to the Twelve Principles of Agile Software:

Principles of Agile Software	Agile Game Design & Play
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software	Be sure your game answers the question, “Why would I want to spend time playing it?” The game should include a few compelling, narrowly defined objectives that make players eager to play or curious about participating. Include kinesthetic activities (grouping, sorting, drawing, cutting) that use tactile elements (game pieces, boards, cards, balloons)
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	Initially deliver a lightweight version of the game. Get player feedback, and improve the game as needed. Keep your game materials simple and cheap. Investing in high-fidelity game materials will slow you down initially and discourage changes based on player feedback.
Simplicity – the art of maximizing the amount of work not done – is essential.	Incorporate a few low-fidelity, inexpensive, readily available game components. Use a simple metaphor or symbol to help players see the problem or need. For example, Speed Boat [7] helps customers elicit product problems by having them identify impediments (anchors) that hold back or slow down the boat (product).

What’s your experience with designing and facilitating agile games? Do you have other agile dimensions to add to these mappings? How are you “being agile” with agile games?

Resources

See Reference at the bottom of my article: “Playing at Work: Agile Games Deliver Value”

Product Agility

A blog about agile product discovery and delivery,
collaboration, and continual improvement