Every year, serious games have made a larger appearance at the Agile Alliance’s yearly conference. For instance, a few years ago, one session featured a game that simulated the collaboration between UX professionals and an Agile team. Other sessions demonstrated how to use serious games to improve the dialogue between Agile teams and their customers. If you know me, you’re already aware that I have a special interest in this topic, in part because, as it says in my LinkedIn profile, one of my professional missions is to make serious games wildly successful, not just in software development, but in lots of settings that desperately need the typical rules of conduct disrupted.
This year was a breakthrough year for serious games at the Agile Alliance conferences. The conspicuous start was Luke Hohmann’s keynote, which talked about serious games not just in software development, but in those other settings that I just mentioned. The San Jose budget game was the centerpiece, but by no means the only example of serious games helping reach important outcomes that the typical rules weren’t producing. (Bias alert: Luke is a friend, and one of his slides featured the work that my wife and her colleague are doing to apply serious games to psychotherapy.)
Serious games had a much bigger presence at the Agile 2015 conference than just the keynote, however. I attended several sessions that included games. Some of these sessions announced, in the program, that they would include games. Others featured games as a pleasant surprise. The second keynote also featured games, which I had not expected (and I don’t believe there was any collusion between the two keynote speakers, or the conference organizers, to have game-heavy keynotes). I also found a very receptive audience for demonstrating two of my own games that I brought to the conference, Dice Of Debt, which shows the high value of preventing technical debt, and Design Factory, which gives player the opportunity to pursue different Agile portfolio management strategies.
The games at this year’s Agile conference fell into three use cases (there are others):
- Education. Some games help drive home important lessons about Agile and software innovation. For example, the Product Owner Value Game illustrated the difference between effort, as expressed in estimates, and value, which prioritization normally expresses.
- Insight. Other games help us understand our customers better, giving them the opportunity to reveal themselves in ways that the typical Very Serious Conversation in a conference room often can’t achieve. Games like Product Box, for example, help get to a possible definition of the minimum viable product in less than an hour, instead of days of head-scratching.
- Simulation. Another category of games help people play out options to see what the possible outcomes might be, before performing expensive experiments in real life. Dice Of Debt, for example, shows how destructive the focus on getting as many story points stuffed into the next sprint can be, when the cost is often growing technical debt that reduces long-term value. It’s important to give people the opportunity to play out different strategies, not only to see the results of their own choices, but also to work within the confines of their own situation. For example, if you can’t get your organization’s support for every technical debt-reducing measure, is it better to push for one big measure early, or apply some lighter-weight techniques as you go?
There are plenty of other uses for serious games, but these are most of the typical ones in software development. (The one I didn’t see very much was games as a tool for making better decisions, in the fashion that Planning Poker re-shapes estimation for the better.) The conference, therefore, did a good job of representing how Agile teams can and do use serious games.
The conference also illustrated some important points about how to properly use serious games, sometimes intentionally, other times not.
- Pick the right game for the task at hand. As I’ve said, there are a lot of different types of games, each suited to address a particular kind of challenge. While Product Box is great for getting customer insights, for example, it’s not as good at teaching Agile principles. Interestingly, the use of game-like rewards (scores, badges, etc.) in work, a.k.a. gamification, was completely absent from this year’s Agile conference. While it has its uses, gamification doesn’t fit the typical session at an Agile conference, which is, “How do we get intrinsically motivated software professionals working better together?”
- Prepare, prepare, prepare. The best game sessions I saw were the ones in which the speakers had practiced the game in advance and put some serious thought into how to run the game successfully. Unfortunately, there was also at least one negative example, a large, complex game which had no facilitators to help players at each table. The result was a confused, frustrating experience.
- Prune and playtest. One of the main reasons why games work well is their limited duration. As mentioned earlier, you can get a lot out of a quick exercise like Product Box, and you can get people to play it if you keep it short. Therefore, you have to prune the game mechanics down to their essentials, with nothing extra that doesn’t add to the game experience. You then playtest to see if the game creates the experience you had hoped to engineer. The best sessions (like this one) cleaved closely to that fundamental rule of game design, showing clear signs of pruning, or playtesting, or both.
Serious games were not the only high point of the conference, but the prevalence of serious games at this year’s conference was a landmark for games designers, practitioners, advocates, and players like me. Now, back to designing a game for a client…