In my last post, I talked about the ways in which serious games can fill a significant hole in Agile practices. Let’s turn that around and see how Agile can help serious games.
Before we can get into the meat of that topic, it’s important to be clear about which serious games we’re going to be discussing. There’s a wide variety of game-like activities used for reasons other than entertainment (education, ideation, market research, etc. etc.), and not all of them can benefit from serious games equally, or even in the same ways. For our purposes, we’ll be focusing on three types:
- Software-based serious games in general. This is a pretty broad category, encompassing everything from marketing games like IBM’s CityOne to educational games like the HelpMeSee cataract surgery simulator, from online versions of simulation games like Buy A Feature to advocacy games like Narcoguerra. As long as these games are software-based, it’s worth considering Agile as a development methodology for building these games.
- Simulations and wargames. Whether the medium for simulating future events, such as another Arab-Israeli war, is software or a board game, these games try to model the complexities of the real world. The people who design these games have to make critical choices about which aspects of the real world to model, and how the model works. For example, a business wargame that seeks to identify future competitive threats has to be complex enough to capture the essential details, but not so complex that no one can actually play it.
- Large-scale innovation games. Many organizations, from city governments to corporations, run serious games involving dozens or hundreds of participants to generate ideas, understand customer needs, gain insights into new markets, and prioritize work items. When scope expands to this size, the project logistics can grow unwieldy, and organizers can lose sight of the ultimate goals of the exercise.
From those descriptions, you’ve probably already guessed at some of the ways in which Agile can help these efforts. In addition, there are less obvious applications of Agile practices that are equally important.
Software-based serious games need better user experiences
Undoubtedly, many teams building software-based serious games can benefit from Agile, because they face the same challenges as teams developing and delivering other kinds of software. Complexity, the bugbear of many software teams, wreaks havoc with schedules, quality, and other important measures of success, whether the final product is a game like Democracy 3, or a browser-based image editor like PicMonkey.
On the surface, serious games also face the same user experience challenges as other software products. How do we make it easy for the user to figure out how to perform specific tasks? Do we have an application flow that matches their expectations? Is the look and feel appealing, or are users wincing whenever they look at it?
Serious games have one additional user experience requirement that other applications don’t: a very specific outcome. For example, an educational game that attempts to teach high school physics must be engaging enough to hold the attention of twitchy teenagers. It also needs, at the end of the day, to teach physics. The mechanics of the game must keep players playing and ensure they absorb the curriculum.
Unfortunately, educational game designers sometimes assume that their games provide an effective or even superior way to communicate important lessons, without real evidence that they do. Just because the medium is a game doesn’t make it automatically engaging or educational. The game designer must do a significant amount of “playtesting” to ensure that it meets its goals.
The short iterations of Agile, each ending with a working piece of the game, and punctuated with moments when you can collect feedback on the game. Do players understand this animation of an inclined plane? Does the flow of the game space out information enough so that the player doesn’t get overwhelmed? Incrementally testing these individual pieces of the game is vastly preferable to testing the entire game at the end of the development cycle.
Simulations and wargames need greater clarity about the minimum viable product
Jose Luis Borges wrote a famous short story, “On Exactitude In Science,” about the absurdity of creating a map of the world at a one-to-one scale. Certainly you can increase the accuracy of the map this way, but a map that’s as big as the world itself is worthless.
Unfortunately, many designers of simulations make exactly this mistake. If you build a simulation of financial markets so
that you can test ways to prevent another global meltdown, you might include thousands of variables, such as the pressures to show quarterly profits, the specific regulations that govern national markets, accounting standards, CEO bonus plans…Eventually, you could imagine creating a model that depicts the behavior of individual employees in Bank Of America, Schwab, and other firms.
Obviously, this level of detail is unnecessary. But which variables do you leave out of the equation?
Essentially, this question is asking what the minimum viable product is. When the game designers don’t know the answer, they take a kitchen-sink approach to developing their product. They throw in anything that might be important, since they don’t know what actually is important.
Agile doesn’t provide a magic formula for determining the minimum viable product, but it does improve the odds. With every iteration, there is an opportunity to test the hypothesis about the minimum viable product, and make adjustments when the results turn out to be wrong. To return to our financial simulation, the game designers might believe that, once a firm’s portfolio of financial products reaches a particular size and complexity, risk is unmanageable. That’s a testable proposition that, if correct, might help the designers omit other sources of risk from the model.
The game might take an hour to play, but the project takes a lot longer
Large-scale serious games can produce amazing results, faster and more inexpensively than traditional methods. (For an example, listen to this podcast interview with the Chief Gaming Officer of Conteneo.) However, the bigger the project, the greater probability that something will go wrong, not just during the game itself, but before and after it.
The timeline for any serious game used in this fashion includes a lot of preparation before the game itself, and a substantial amount of follow-up afterwards. US military wargames, designed to generate new strategies and put them to the test, provide a salient example. Before bringing together dozens of civilian and military participants in a wargame about a clash over Taiwan, the organizers must do a lot of research, and they need to do no small amount of playtesting to ensure that the game is battle-ready. After the game, the organizers need to communicate the results to interested parties, and they also need to help the people crafting real strategies for this scenario incorporate the lessons learned into their plans.
This kind of multi-phased project is very familiar to Agile practitioners. Each phase is, essentially, a single “release” in a larger roadmap. The before, during, and after phases each have specific deliverables. Breaking down, in Agile fashion, the steps needed to prepare for the game make the sizable work more manageable, and gives the team an easier way to deal with changes to the game. For example, you never know when “the customer” might change the game at the last minute. (“Let’s assume that Japan and Korea are sitting on the sidelines during this crisis, instead of being active participants…”)
Without effective follow-up, all the effort that went into the large-scale serious game might come to nothing. For example, if the goal of the game is to discover the real opportunities for a company’s product and services across many regional and national markets, the game might as well not have happened if the marketing and sales departments don’t get a thorough debriefing on the results of the game. Often people may want to ignore the results of the game, as they would any information that might challenge their current strategy. Therefore, “follow-up” may involve a lot more than just presenting a final report on the results of the game.
Insert obligatory caveat about Agile here
Agile is not for everyone in software development, so the same principle must be true when using Agile to design and run serious games. However, the burden of proof should be on the side of not using Agile. Serious games involve a lot of uncertainties, such as whether the game design will produce the desired results. Agile works best when navigating through a sea of uncertainties, so it deserves as much consideration as, say, whether to use the Unity engine as the platform for the next educational game.