Whoever claims that work has no room for play or play might not be a form of work may not know about the serious purpose of agile games. You can learn from games, use them to instigate change, innovate, and make product decisions. This week's column explores how Mary Gorman selects, plays, and designs games. Mary explains how games improve collaboration, deepen learning, and help teams focus on value delivery.
Imagine blowing up balloons to discover how to work with your customer to improve the quality of the product you're building. Recently, I led an agile team in doing just that-by playing 99 Test Balloons.  In this game the players are told to draw faces on the balloons. Only afterward do they learn about strict size and shape requirements for the facial features. During the first round of play, the room usually is strewn with rejected balloons.
And so it happened with the group I was helping. When I gave these players a chance to improve, they quickly adapted and delivered much better results. During the post-game retrospective, my team members smiled and shook their heads, remembering how many times in the past they had experienced similar challenges with acceptance criteria. They started planning how to adjust their project work to sharply reduce the number of errors found during testing.
Winning at Work
Playing a game gives people an opportunity to actively participate in unleashing creativity and generating new ideas. Think about it: You do your best work when you're in a creative environment and in "flow."  Moreover, we often learn best when we do, observe, discuss, and reflect on the outcomes of the experience. 
By any definition, an agile game is simple, adaptable, and quick to play. In the agile software development community, an agile game is also collaborative and provides value-it has a serious purpose. It can teach a specific agile concept leading to improved performance, as in 99 Test Balloons, or it can enable collaboratively exploring business needs, such as identifying new product concepts or prioritizing a project portfolio. 
Put simply, teaching games help make your learning stick, and doing-work games help you accomplish business goals.
What's Your Game?
How do you select an appropriate game? Start with the problem, challenge, or opportunity your team is facing. Here are three examples.
When a team needs to learn what drives customers to purchase a product, I often select the Product Box,  a fast-paced, doing-work game. Ideally, key customers are invited to play. (When that is not possible, team members act as surrogate customers.) In the first part of the game, the players use cardboard to build a product box that expresses the features and benefits that would compel them to buy the product. Then, each player "sells" his box to the other players.
This game gets people motivated and uncovers diverse-and sometimes conflicting-views of the product's features.
Suppose a team is considering using pair programming. The team could benefit from experiencing two people working together to build a product. As a trainer, I select PairDraw,  a teaching game. In the game's debrief, the players reflect on the experience of creating their own individual drawings in contrast to jointly creating a drawing. They talk about the impact of their pairing on the result and whether they were more creative when working together. The ultimate goal is to consider how they can use the game's results to help them prepare for effective pair programming.
For a team that needs to identify constraints and learn how to improve delivery, the Bottleneck Game  can be valuable. Pascal Van Cauwenberghe, a co-creator of the game, described an integration test/release team pressured to complete its work faster by the accelerating pace of delivery from agile development teams. Members of the teams joined to play the game. "By trying out systems thinking and the Theory of Constraints, the players understood the importance of seeing and optimizing the whole," Van Cauwenberghe says. The game debrief helped the team see that the test/release process was the bottleneck in the system. Everyone pitched in to apply the game's lessons. Van Cauwenberghe adds, "The release after the Bottleneck Game went a lot smoother than usual. It took the test/release team several days less than usual to deploy the release, without having to do any overtime." 
Running the Play?
A successful game often requires a game facilitator. When I serve in that role, I make sure to:
- Schedule sufficient time in an adequate space and prepare game materials
- Clearly communicate directions
- Always run a debrief after the game, allowing the players to reflect on the experience and see how it relates to their work
As with any type of facilitation, you need to stay neutral to the play while being available to serve the game's purpose and participants.
Design to Win
How do you create an effective game? There were lots of great ideas at the recent Deep Agile 2010: Empowering Teams with Agile Games conference.  In the session "Game Development," Mike McCullough and Don McGreal shared their experiences in designing games and coached small groups in creating new games. I joined a group that wanted to design and test games to explore backlog challenges.
During our Open Space time  my group created a new game, tested it, and retrospected both the game and our design process. Michael Sahota, the session conveyer, kept us focused with his energy and enthusiasm. Read Michael's post, "The Backlog Is in the Eye of the Beholder,"  for details about our process and findings. You can also grab the materials to play the game yourself. Below are some of the key lessons we learned.
Designing the game:
- Clearly define the objectives and limit them to three or fewer.
- Start with a small set of players-no more than twelve.
- Leave wiggle room; expect the game to evolve.
- Test as you go, refining and refactoring along the way.
- Act as a deep observer during the tests. Watch players adapt and extend the game in different directions. They may experience deeper learning beyond your original intentions.
- Retrospect the test with the players, looking for ways to fine-tune the game.
I also find it helpful when designing a game to employ a number of principles that are congruent with agile software development and principles-whether or not I am designing a game intended for use in an agile software environment. See my blog post "Being Agile When Designing and Playing Agile Games."
If you need creative ways to do work, or if your team can benefit from deep learning, play a game! Check out the references and resources at the end of this article. You'll find plenty of playing options that can deliver value to your team. What's your next move?
My thanks go to Lisa Crispin, Ellen Gottesdiener, Luke Hohmann, Michael McCullough, Michael Sahota, Sivasailam Thiagarajan, Portia Tung, Pascal Van Cauwenberghe, and Bill Wake for their helpful review of this column.
 99 Test Balloons
 More on Flow
 Kolb, D. A. (1984). Experiential learning: Experience as the source of learning and development. New Jersey: Prentice-Hall.
 Innovation® Games
 Product Box
 Bottleneck Game
 Pascal Van Cauwenberghe, personal communication, 3 July 2010.
 Deep Agile 2010: Empowering Teams with Agile Games
 Open Space and Opening Space for Passion, Energy, and Learning Part II
 The Backlog Is in the Eye of the Beholder