Posted by Tom Grant on March 16, 2011
As readers of this blog know, I have a keen interest in serious games. Among other virtues, they provide a way to deal with tough circumstances by changing the way team members interact. In an upcoming research document on the subject, I relate the story of a development team that had to rewrite a creaky old application from scratch. Which features did the team need to re-implement right away? By running a serious game with the stakeholders, the team pinpointed which features were essential and why.
Serious games have plenty of other uses. For example, I've seen lightweight role-playing exercises used to help develop personas and user stories. Heavyweight simulations have helped managers and executives grapple with some of the toughest decisions. Games can help with estimation (Planning Poker), road maps (Prune The Product Tree), and team dynamics (Speedboat). Serious games often incorporate crowdsourcing, sometimes to scale efforts that might otherwise be difficult for teams to do alone, and other times to elicit information that people might otherwise be unable or unwilling to provide. Serious games have applications beyond application development, beyond even product development, beyond even some interesting marketing use cases. If a serious game can help a city government work more closely with community members to address a budget crisis, it should have plenty of applicability in other settings, too. The educational uses are a whole other chapter in the history of serious games, with decades of successful experience in military training, career development in the private sector, and, of course, educational institutions like primary schools and universities.
As enthusiastic as I am about serious games, I'm not yet sold on a wholly different trend: gameification. It's easy to confuse the two, since their names both include the word "game." However, serious games and gameification attempt to address different problems in very different ways.
As in the case of the team that needed to rebuild its application from scratch, a serious game provides a way to step outside of the normal work setting, with the intent of generating outcomes you don't normally get from typical planning exercises, requirements collection, brainstorming sessions, and other familiar techniques. Serious games may become a regular activity, as in the case of the ubiquitous "build the best robot" competitions, designed to inspire and test innovations in robotics. But even in these cases, the serious game doesn't replace daily work with games.
In contrast, gameification is, as the name implies, about turning regular activities into games. For example, Jane McGonigal's book, Reality Is Broken, starts with the following proposition:
- Since the launch of World Of Warcraft, players have clocked more than 50 billion hours of time playing this online game.
- People play World Of Warcraft because, for whatever reason, they find it rewarding, despite the lack of tangible, real-world benefits of playing it. (Unless, of course, you count the people working in the underground economy of "gold farming"for massively multiplayer online games.)
- Therefore, if you could somehow recreate the experience of playing World Of Warcraft at work, you'd increase their motivation on the job. In other words, if businesses could capture even a fraction of those 50 billion hours playing World Of Warcraft, they'd be very happy with the increased productivity.
To be fair, gameification advocates cite other potential benefits. However, motivation seems to be the one that they frequently cite first, in contexts as varied as employee productivity, customer loyalty, and lead generation. Dangle badges, achievements, and other shiny gewgaws in front of many people, and that may be enough for them to get motivated to do things they might otherwise find uninteresting. Add a game layer on top of some activity, such as learning how to use Microsoft Office, and you push all the right buttons of a generation of people who have grown up with video games.
While this technique may work some of the time, we hardly have all the data we need to jump to any bold conclusions about gameification. Who knows, maybe we'll all be doing game-like activities at work in the near future. On application development and delivery teams, we'll get power-ups when we check in code without issues. We'll earn merit badges when people give high marks to an application's user experience. When we double the number of automated tests, we'll "level up" enough to qualify for membership in the Guild Of Puissant Quality Professionals.
Or, we might resent the intrusion of games into our work lives. Here are some reasons to be a wee bit skeptical about gameification:
- Not everyone loves games. As with any human activity, such as social media behaviors, games don't appeal to everyone. Not everyone is a blogger, but some people love blogging. Not everyone loves Facebook games, but some people spend a lot of time playing Farmville and Mafia Wars. Even software developers, a population where you're likely to find more gamers on average than the general population, do not universally love Halo, World Of Warcraft, Carcassone, Dungeons & Dragons, or other types of games.
- People already feel intrinsic motivation about their work, and games might just get in the way. Daniel Pink's book Drive has been successful because (1) a lot of us recognize how much we want to do a good job, without reference to other rewards, and (2) as managers, we have to cultivate this intrinsic motivation in our employees. Many developers already feel a great deal of intrinsic motivation, from the engineers who work late to make a key algorithm more elegant to those who spend time outside of work contributing to open source projects.
- Gameification might make "gaming the system" an even bigger problem. Development teams already measure the contributions of their members. Code quality, velocity, ability to work in multiple areas of the system, willingness to help other members of the team – these are just a few quantitative and qualitative yardsticks by which team members are already measured. Adding "gameified" rewards, such as badges (Continuous Integration Pro!) and achievements (90% Code Coverage!), only complicates the system of rewards. Anyone who has had to develop employee performance measurements, key performance indicators, and other work-related metrics can tell you that you can rapidly reach the point where additional metrics don't improve the team and frequently undermine its success.
- Some behaviors may be hard to encapsulate in a leader board. Many gameified rewards don't really fit the way teams work. Some developers, for example, might provide steady, reliable contributions. Teams need chickens as much as pigs, hedgehogs as much as foxes, and tortoises as much as hares. So what then is the point of putting every species of developer on the same leaderboard?
- Gameification might insult people instead of motivating them. Here's where serious games and gameification differ sharply. Because serious games might suggest, through a short-term exercise, how work might improve, it does not try to replace work. Gameification proposes a permanent introduction of game elements into work, in ways that many people might find obnoxious. Customer support technicians might see the replacement of a normal CRM system with a pirate game that works kinda like a CRM system as a clear sign that management doesn't take their work seriously on its own terms. Many people sent to mandatory management training offsites would rather spend two hours discussing challenges with their teams than baking a pie as a team-building exercise.
Gameification is still in its infancy, so it's entirely possible that we'll find ways of dealing with these problems. Over time, as people get acculturated to living in a gameified world, some of these problems may go away on their own. Certainly, there are situations in which gameification has been very effective. On the other hand, it's just as possible that intractable obstacles to "gameification" might limit its effectiveness in many situations and even threaten a backlash if organizations push gameification too hard.
[P.S. There's a lot of valuable insight in Alistair Cockburn's 1999 talk about software development as a cooperative game. I'm just not a fan of applying these insights too literally, in the way gameification tries to do.]