It’s Not a Game, It’s an Experience
In part one of this series, I made the case that people behave based on their beliefs, which are products of their experiences. Therefore, it follows that we can help people change by giving them new experiences. Sometimes, new experiences can be prohibitively difficult, as we saw in the case of the snake phobic who would not initially go into a room with a snake at all. We see a similar dynamic in many large organizations where frequently we can’t get people to risk new behaviors on high stakes work at first, thereby preventing them from building the necessary experiences to embrace a change.

We can escape this catch twenty-two by using games. Properly designed, they offer us a low stakes and fun way to engage with people and help them create their own experiences so that they are comfortable enough to put new behaviors into practice. From this perspective, when we develop a game for a training exercise or similar activity, we need to pay close attention to the experience it is going to create. This experience is going to be the primary value delivered to participants. Let’s take a closer look at some guidelines you can use when planning to incorporate a game into your own sessions.

Have a Hands-on Activity
Regardless of the precise mechanics of your game, it should have a very hands-on and tactile component. People can be folding paper, building objects using LEGOs, rolling dice, or doing some sort of activity that is engaging and enjoyable. A growing body of research shows that getting people to engage with a problem with a physical medium engages the motor cortex, allowing someone to process an idea with multiple parts of the brain, more than if someone were to think about the problem alone. By processing the same idea through different mediums, individuals are more likely to produce insights and solve problems. Logistically, this will also help you ensure everyone is involved, as the physical activity reduces people’s disengaging and sitting off to the side while others take on the challenge.

Frame the Game with a Story
People think and communicate in stories, and good games should play to this. The point of your game isn’t so much to fold origami hats and boats, rather, the point of the game is to run your business in the boat-and hat-folding market in order to run the most efficient operation. You are the ambitious new manager there to help the team achieve breakthrough performance. This may sound silly, but that is the point. A game’s key element is that it be a fun and engaging experience. Looking back to our survey of psychological characteristics impacting people’s ability to change, putting people into a happy state will go a long way towards opening them up to receive new ideas.

My colleague Mike Dwyer developed a game to demonstrate the mechanics of Scrum. He created a back-story and a company called “Marble Movers,” and the point of the game was to build ramps for marbles. My favorite recollection was that in his training deck, when he got to the marble movers game, the formatting changed, as if he were presenting on behalf of this fictitious company. There was a corporate logo, and he even regaled the audience with tales of the company’s past achievements to create a history and engage people in the upcoming challenges they would face.

The way you frame a game can also enable you to use it in different ways. One of my favorite examples of this is the coin-flip game. The game is fairly straightforward: A chain of people must process twenty coins by flipping each one from heads to tails or tails to heads. They start using a batch of twenty and slowly decrease the batch size. All the while, efficiency experts are measuring each person’s individual performance. What we generally see is that while individual times degrade as people work for a longer periods across multiple small batches, the cycle time for the entire system improves. We’ve used this game as a powerful experience for managers, who get to play the workers who see their individual times decrease. We emphasize the value of individual contribution by rewarding the top performers in the early rounds, and later threatening to fire them when their performance drops. We talked to the managers measuring the time of each person and discussed what they planned to do with the “low performers,” as well as how those people felt about the entire situation. They had a powerful experience where they could see the old system of performance management punish them for improving the overall system instead of their functional area. This type of powerful experience frequently requires a clear measurement of progress, as I will describe in this article.

Have a Clear Score
People can organize towards action and get better insights if there is a clear goal that everyone can understand and measure against. In the case of the coin flip game, there were clear measures of the cycle time on individuals as well as the entire system. This offered meaningful and objective feedback on how long it took them to complete the work. It also provided a clear incentive: Go as fast as you can. Scores may be counts, such as when teams are trying to produce something in a game like the paper airplane factory or bottleneck game. In fact, these games add another dimension where they ask teams to predict what their throughput will be, and then try to meet it. This introduces an additional goal of being able to predict throughput. Especially if you are playing multiple rounds, people should clearly understand the goal and receive feedback as they go.

It’s critical to have a clearly thought out measure or goal, and the constraints you impose can profoundly impact how the game is played. For example, the coin flip game inherently creates tension between individual performance as well as system wide performance. The point of this game is to give people an experience where they can see how a focus on individual performance can conflict with system-wide performance. If we only measure time through the system, we would not see that. Similarly, the bottleneck game measures the business results of a factory line which is measured in completed boats and hats less the cost of the supplies, in the case of this game that is pieces of paper used. In order to be successful, teams must not only produce a lot, but they must be careful to limit inventory to manager their costs. If there were no such penalty for used paper, we would see very different behaviors, such as overloading the system with inventory. Interestingly, this offers another way to unveil a game, by making progressively more difficult goals for successive rounds of play. Progressive complexity also helps guard against the challenge of overwhelming people with too many rules and challenges at once  Let’s take a look at how it can be applied here.

Complexity Can Kill
If the goal of our game is to create a meaningful experience, then we want to ensure it is accurate and realistic, right? This is a line of thinking I have followed to ruin on several occasions. When building a simulation, I often have this vision that someone is going to get up and say to me, “Ah ha! That is not how software development works; you’ve made it too simple and this exercise is therefore invalid.”

Thankfully, I have yet to encounter someone like this. I have, however, built games that were so complex, people were not able to make sense of them. Some were so bogged down with learning the rules, that their experience became one of trying to decipher the game. When you design a game, you are a victim of the curse of expertise. Your familiarity with the domain and the game structure might make it appear incredibly simple to you, so much so that you may want to add more rules and complexity. Rather than add more rules, designs should be open in play, allowing an interesting array of divergent outcomes. In this context, an open game is one for which there is not a predetermined outcome or a single path everyone must follow. Closed games like these are similar to brain teasers where we must find the one path. In my experience, when people going through an exercise to gain experience encounter a game that is too closed, they may feel like they are being manipulated.

The first way to address this challenge is to test a new game in order to get a get good feel for whether you’ve set the right level of complexity. Different people playing the same game should end up with different approaches, experiences, and outcomes. My experience has been that we will almost always err on the side of excessive complexity. Therefore, the second way to address this challenge is to use progressive complexity when playing a game. Those of you who play video games will recognize this pattern immediately, as it is how most games unfold. When you start, you have very limited capabilities and the challenges are commensurately easy. As the game progresses, you gain more ability and the challenges increase proportionally. Especially if a game has multiple rounds of play; you can easily introduce a simple version and then progressively ratchet up the difficulty with new rules, more constraints, or other impositions upon participants. This also gives the facilitator the flexibility to adjust the game based on the audience. If you begin with a simple set of rules and people are confused or struggling, you don’t need to introduce anything else. Conversely, if participants eat it up and don’t feel challenged, you may be justified in increasing the additional rules and guidelines. Increasing difficulty can provide another data point for the debrief as you can discuss how people responded under the different levels of the challenge.

Plan Time for a Meaningful Debrief
I once helped train someone to teach a class I had developed, and one day I was in the back of the room watching him go through what was meant to be his polished solo performance. We had discussed all the slides, exercises, and common questions. The class began with the spec writing game, which the trainer executed quite well. The game wrapped up and people were beginning to chat with one another, It looked like they were about to engage in a meaningful discussion of what just happened in the game. One person raised her hand and asked what the point of the game was. The instructor simply responded, “Oh it was just an ice breaker.”

The energy was immediately sucked out of the room. Conversations died, and I could see the looks on several people’s faces change from curiosity to annoyance. A potentially profound experience was just dismissed as an idle way to get people talking and interacting. I always knew how important debriefs were, but that fumbled response made it crystal clear to me that the debrief is the single most important part of a good game. As such, you need to allocate sufficient time for people to both make meaning out of their experience as well as share vicarious experiences with each other. Let’s look at an example.

A common game I use in classes today is the marshmallow challenge, a game where teams work for twenty minutes to build a freestanding structure out of tape, uncooked pasta, and string in order to hold a single campfire marshmallow as high off the ground as possible. Going back to our earlier criteria, this has a clear measure—the height of the marshmallow off the ground, which we can use to evaluate performance and draw conclusions. It also has a fairly straightforward set of rules. While the game takes less than half an hour to setup and execute, the debrief may run for just as long, if not longer. You can get powerful insights simply by asking participants to surface their thinking as they went through the exercise. Did they have a clear strategy? Did they change directions? What was their approach? We can then evaluate this against the participants’ empirical performance, which was how high the marshmallow was suspended by the structure.

While this exercise may sound inefficient to do with each individual group, the point is to help build vicarious experiences. Because the marshmallow challenge is a very open game, each team may have a different strategy for how it used its time and resources with differing levels of success. By opening the dialogue to all teams, people are able to gain not only their own experience, but the vicarious experiences of those around them. For even more impact, you may want to talk about what happened to past participants; include pictures, if you can, so that people can see how their experience was similar or not to that of others. Remember, people only change behaviors when they have new experiences that adjust their mental models. A good debrief is critical to being able to apply meaning to an experience so that it can be used by people afterwards. As a general rule, I assume that for every minute of playtime in a game, I allocate one minute for debriefing. You may not want to use all the time at the end, and if you have a game consisting of multiple rounds of play, you may want to debrief after each round.

Limitations of Games
As games and gaming grow in popularity, some people within the agile community are already pointing at games as a universal cure for all challenges. We should be very clear that there are limitations to using games as a training or coaching instrument. First, while games are valuable, they don’t stand on their own without proper support. People are not able to apply the concepts a game is meant to illustrate until they are educated about those concepts. Because of this, games must be complimented with the appropriate training for people to learn those skills. As I mentioned earlier, without clear debriefs and session design, the best game can fall flat on its face.

We must acknowledge that these games are inherent simplifications of reality and are only approximations, and we should focus on what we are trying to achieve from them. In the case of this article, I’ve discussed using games to produce experiences that help reinforce new behaviors. As such, the games will not be perfect approximations and are limited to vicarious or simulated experiences. Just like how Dr. Bandura enabled his snake-phobic patients to actually walk into the room, if we are using games to introduce new behaviors, participants will need to be eased into opportunities to try these new behaviors. In reality, this needs to occur shortly after trying them in a game or they risk forgetting the experience before they have an opportunity to really incorporate it into how they operate.

Games are a powerful tool in any coach, trainer, or consultant’s toolbox and we should look at them as one component of a series of complimentary activities, including instructional training, coaching, and other activities necessary to help people gain new skills and put them into practice. Thankfully, with the growing popularity of using games within the agile software development field, we see a number of games fully documented, play tested, and available with instructions online. As you look to incorporate games into your own training or coaching activities, you may want to simply start with games already defined and figure out how you can implement them using some of the guidelines outlined in this article. Happy gaming!

[Brian is one of the co-chairs of the Agile Games Conference being held this year April 19-21 (www.AgileGames2012.com).]

Resources
[1] David Rock, Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long (New York: HarperCollins, 2009), 205.

[2] Barbara Fredrickson, “What Good Are Positive Emotions?” Review of General Psychology 1998 Vol. 2 No. 3: 300-319.

[3] Rock, 158.

[4] Kerry Patterson et al, Influence (New York: McGraw-Hill, 2008), 47.

[5] Jacqueline Lloyd Smith, Team Work: Hand-On Minds-Engaged, 2009 http://www.strategicplay.ca/upload/documents/team-work-hands-on-minds-engaged.doc

About the Author
Brian Bozzuto is an Associate Agile Coach and ScrumMaster with BigVisible. With an extensive background in large financial service companies, he has worked as a developer, analyst, project manager, and coach. He has a broad range of experience using various frameworks including Scrum, Six Sigma, and CMM and is a Certified Scrum Master and Project Management Professional. Brian has worked on numerous large integration projects involving enterprise portals and other web technologies. He has worked, in various roles, at Fidelity Investments, Investor's Bank & Trust, Bank of America, and Fleet Bank.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview