Integrating Games to Change Behaviors, Part 2


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.

About the author

Brian  Bozzuto's picture Brian Bozzuto

Brian Bozzuto is a principal agile coach at BigVisible Solutions. With an extensive background in health insurance and financial service companies, his current focus is supporting teams as they adopt agile and lean practices and deal with the challenges of organizational change. Brian's passion is helping foster better relations between business and technology to achieve more response projects and better business results. He has a broad range of experience applying various process improvement frameworks including Scrum, Kanban, Lean, and Six Sigma in large organizations. Brian has been certified as a Project Management Professional and Certified Scrum Practitioner. He is one of the founding members of the PMI Agile Virtual Community of Practice and the creator of the annual Agile Games conference in Boston.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!