Managing risk: The creative gamble

[This feature was published in the August 2013 edition of Develop magazine, which is available through your browser and on iPad.]

Here’s a nightmare: Build the best team you can, work hard for two straight years, release a well-crafted game – and watch it fail in the market.

Here’s the crazy thing: We work in an industry where that nightmare comes true somewhere every day.

Surprisingly, we don’t talk about this very often. Even those of us who carry ‘business responsibility’ over our games seem to avoid the topic. There’s valuable discussion of development processes or leadership strategies, but little time is spent on how to deal with the great volatility of our products. Often, you’ll get the impression that we’re improving at releasing games on time – but not at ensuring their success.

Can it be that this is because what is at the heart of a successful game is radically different from what makes or breaks other software?

For a long time, our project management has looked to IT for its cues, and what we learned from there has enhanced our way of making games. Still, I would argue that there are limits; challenges we have to face that other software managers will never see. Most of them start with two words: game design.

THE SMALL DIFFERENCE

Games try to entertain. This sets us apart from traditional software, like eshops. It also means that we run the same risk as any movie or novel: Our audience might just not find the game appealing. Researchers call this ‘creative risk’.

As managers, we usually think of risks as threats to be minimised, or, in the worst case, mitigated. One has to wonder: Is the same possible for the risk of people not having fun?

Fundamentally, a big part of what makes something entertaining is down to curiosity. We like new things. This will be news to nobody – pretty much every game tries to offer some degree of novelty to its players. We search, we build, we advertise fresh new features, whether in an experimental title, or a sequel.

ON GREAT GAMBLES

There’s a problem, of course: What may seem original to me, can feel trite to you. Even individually, it can be very difficult to predict whether a game will meet our tastes before we try it. For a whole audience, it becomes effectively incalculable. Just consider how often century-old Hollywood gets it wrong.

Intuitively, this means that it’s a bad idea to take a lot of creative risks. After all, if we release a product that’s different from anything that’s come before, there’s a good chance it’ll miss everyone’s tastes, right?

True, but our players still really like new stuff. Games like Portal or Wii Sports show that if you take the risk, and manage to connect to your audience, the reaction can be tremendous. Creative risk is speculative – its outcomes can be negative or positive.

Of course, it is possible to build an entertaining game around a relatively conservative concept. Take StarCraft II, a careful extension of a well proven game. Then again, take the guitar game genre. There, we have a group of very well executed titles that got too conservative – and saw their audience move on. Taking no creative risks is a risk, too.

In the end, no matter what kind of game you build and how well you build it, all you get is a roll of the dice. The game’s USPs, the very things that can make it succeed, will carry the greatest, most central risks. Accordingly, there’s nothing we should take more seriously in our plans.

DOES IT WORK?

Obviously, if we want to help our game designers deal with risky features, we should help evaluate them. Just as obviously, it’s a good idea to make these features testable as quickly as possible.

The good news here is that every discipline involved in the creation of games has found its own ways of quickly prototyping and testing ideas. Based on those, it seems pretty easy to set up whole test plans. Say, you start out by testing a paper draft of a new feature, graduate to UI mock-ups, logic prototypes, and eventually release a fleshed-out version on a beta server. Such plans are hugely attractive. They reassure the team and stakeholders. Also, they don’t work.

Partially, it’s down to time. Way too often does a team invest into elaborate tests, only to discover that there’s no room to fix what is broken.

Things can get even worse, though: User tests, by their very nature, produce messy data. It’s easy to come to rivaling interpretations, and thus solutions. If a major stakeholder subscribes to such a differing view, the game designers may quickly lose control over their own concept.

THE LIMITS OF AGILE

To avoid all this, it seems sensible to integrate large-scale prototyping more tightly into the development process. To my surprise, when I began consulting Agile experts on this, they told me it was a bad idea.

We all know the basic artifacts of Scrum and XP. You’ve got a backlog, with the most important stuff up top. You’ve got a sprint, during which a certain amount of stuff is supposed to get done. You’ve got a working increment, which grows sprint by sprint.

What a lot of us miss is that, as far as ‘traditional’ Agile is concerned, that’s it. No milestones, no gates. After the first few weeks, the most important stuff is in. Then, with every sprint, the team will be able to release something better.

Following that logic, it’s a waste to spend a sprint building a prototype that may get discarded or even lead to a rework of stuff that’s already done. Setting up whole plans full of that? That’s missing the point.

For B2B application development, the environment Agile was built for, that’s true. There, it is possible to ensure that what is at the top of the backlog is also the most valuable for the user. In games dev, that’s the very thing we often can’t be sure about.

THE ROOT CAUSE

What this means is that to accommodate the creative risks of our games, we must tailor our processes in ways unique to our field. We don’t know whether our most central features are valuable to the player. We only hope so.

To me, those features – and the degree to which they are proven – should drive a project. At the root, this means accepting that each of them will be reworked many times. In my experience, one shouldn’t plan with less than 60 per cent of feature-specific contingency here.

More challenging: We have to acknowledge that there will be controversy. Here, it can help to have the game designers prepare while they are defining the features in the first place. Ask them to name ways by which to tell that the feature doesn’t work. It provides the designers with a degree of ownership over the tests, and sets a reliable yardstick for any discussion.

Finally, we have to give our stakeholders a fair chance to take influence. For this, it’s sensible to set milestones after major tests. There, you will have learned something important about your project. Thus, if necessary, it’s the ideal time to discuss changes – whether that means budget extensions, scope adjustments, or the dreaded cancellation.

That’s another thing we don’t talk about. But if we take creative risk seriously, it’s a step we should always consider. It’s always possible that what sounded fun on paper doesn’t really work out. Pressing on nonetheless – now that’s inexcusable.

www.innogames.com