Scrum … and Production, Pre-Production in games

So, here’s a question for Agile developers: when you’re using Scrum as your development process, and your game is in pre-production, at what point do you move to Production? And, more importantly, how can you tell (that you’ve moved)? Is Scrum in fact a permanent Pre-Production, right up until the moment you launch? And if that’s the case, how do you explain THAT to your publisher?

Traditional process

There are three stages: Concept, Pre-Production, and Production. Every game goes through those processes in that order. Typically the number of staff working on the project (and hence the amount of money being spent – and the risk being taken on!) goes up by a large factor from stage to stage.

Rather than bore you senseless here if you already know all this, I’ve written up a slightly more detailed explanation of games production stages and how they relate to each other. If you aren’t familiar with those stages, read that instead.

What is Pre-Production, anyway?

Well, as one of my colleagues, Mark, put it: the whole idea of a Pre-Production/Production split is merely an artifact of the developer/publisher split in responsibility, funding, project ownership, etc. It’s there because the developers can’t answer most of the questions until they’ve actually written most of the game, but the publishers are desperate to “reduce risks” by “eliminating unknowns”.

I did a quick google to see what other people have said about pre-prod for games, and one of the first hits included the quote “PreProduction has become the most important phase of the development cycle”. Actually, I think (like Mark) that Pre-Production has always been the most important phase, as far as the developers are concerned, although usually it’s never allowed to last long enough to be that important in the overall project. Despite being usually much shorter than Production, with much smaller resource (many fewer staff, etc), arguably it’s where the true art and craft of making fun games happens. Everything that follows is an attempt to fit the square peg of game development into a round hole, to curtail changes, to control spending arbitrarily, and to fulfil the vision that’s created during pre-production without allowing for the possibility of the team changing their mind on what’s going to make the game fun, or a success.

…which coincidentally brings us full circle, as this is one of the biggest reasons that game developers are trying to adopt Scrum in the first place. Scrum promises a large amount of “changing your mind” whilst keeping budgets and spending very efficient – even, magically, promising even tighter levels of control of the spend whilst granting much much more freedom of creativity. Yeah, you can have your cake and eat it! (unless the cake is a lie)

What about the movie industry?

Well, yeah, because the term “pre-production” comes from there first. I guess – just a wild guess here – that it got imported to the games industry by EA, probably around the time they imported the job title “Producer” to mean, a la movie-parlance, someone who combines organizational and creative responsibilities (a merged lead designer/project manager).

“In digital video, photography, television and film, pre-production refers to the tasks that must be completed or executed before filming or shooting begins. This includes tasks such as hiring actors or models, building sets, budgeting, planning, scheduling, renting equipment and tests, to name a few of the many pre-production tasks.”

Here’s the problem: whereas a movie starts with a FULLY WRITTEN script, the game design for a game is never complete until the day you ship. That means that where a movie has the luxury of looking at the script on day 1, and starting to do things like “building sets”, the game equivalent can only be guessed at for the majority of the project lifetime. Pre-production, in a movie industry sense, is impossible and nonsensical for the majority of computer games development. (leaving aside the exceptions of the few games, such as the infamously sequel-tastic EA Sports titles, where the game design doesn’t change and has very little innovative or new added during the course of the project. For anyone not in the industry, FYI: those are rare in the overall constellation of games developed each year).

Scrum and the effect on game production

With a Scrum project, you are ready to *ship* the product every single month (or fortnight, or even week, depending upon your sprint length). If you start by using Scrum at the concept stage, as we have for some of our projects, then … how do you decide when to transition to pre-production? And, more importantly, when to transition to Production?

Because Scrum, as far as I can see, is granting the development team an infinitely-long Concept stage (or, at the very least, an infinite Pre-Produtction stage): at every moment they are free to take any part of the product and throw it away and replace it with something better. One of the great mantras of Production is “thou shalt not throw anything away … unless there’s no way the game can ship with it in current state (and that usually doesn’t apply until you’re really close to shipping”. I’m not saying that’s a mantra anyone chose, I’m observing that de facto it seems to be how publishers and producers end up handling the Production phase. Maybe I’ve just seen a lot of bad examples – but I think not. I think this is an inevitable side-effect of the “avoid risk and avoid extra expense” strategy that the publishers have chosen as the purpose of Production.

So … if you’re permanently in pre-prod, how do you decide when to go to the publisher’s GreenLight committee (or whatever your publisher calls their equivalent)?

It occurred to me that the answer, with any publisher that understands Scrum, is: You don’t. They come to you.

The Power of … Scrum

Every time you finish a sprint, the publisher should have at least one representative turning up to the review meeting to see what’s happening and what’s been changed/completed/added/removed.

They should also be making a judgement every single sprint of: as a publisher, do WE want to “move this ahead” into pre-production, or from pre-production into production.

This is one of the explicit aims of Scrum, to give the person who’s commissioned the project (i.e. the publisher, who’s paying for all this development!) the ability to make extremely well-informed decisions about the project at any point. They are informed and empowered. So, they need to take that power and that information and decide for themselves what to do.

Fundamentally, the decision was never in the hands of the developer, and with Scrum, I think that maybe it doesn’t need to be something the developer is even all that aware of any more. Old-style, you have to explicitly make a special final build for the end of Pre-Production – but with Scrum, you’re doing that all the time anyway.

I could be completely wrong, of course…

I see this as one of the interesting unanswered questions with Scrum for games dev, of which there are many, all in the area of “Ok, sure, we can all see how it fits in with day-to-day development – but how the heck does it affect the traditional developer/publisher relationship, and how does it alter the traditional processes that exist in that area?”. Scrum, in its mainstream incarnation, doesn’t deal with a developer/publisher relationship – no surprise, really, because almost no other software development industry has such an odd dynamic as its centra driving force.

But what the heck. Here’s my stab in the dark at this small part of it. I’d love to know what you think.


6 Replies to “Scrum … and Production, Pre-Production in games”

  1. As a data point for the semantics of pre-production: we use pre-production to prototype design concepts and technology ideas, with the understanding that these don’t become working parts of our game. One of the ways we ensure that prototype code doesn’t get morphed into shipping code by an overly aggressive production schedule (or publisher) is by doing prototyping in languages that allow rapid development, but aren’t necessarily suitable for shipping.

    Pre-production for large projects seems to be typically trending in the 12-24 month time frame. One of the largest factors I see as a distinction between pre-production and full production is the funding model, with the latter being almost exclusively publisher supplied, and the former between a combination of self-funding and investor driven.

  2. “we use pre-production to prototype design concepts and technology ideas, with the understanding that these don’t become working parts of our game”

    Have you tried using Scrum? I’d be interested to know how you see this prototyping relating to Scrum. We do something very similar, a pre-pre-production :), to do ultra throw-away prototyping, but that was started before scrum, and integrating it into Scrum (getting prototypes to move from this incubation stage to a scrum pre-prod stage) is something I don’t fully understand.

  3. We use agile methods, not “Agile” (note the proper name case). We employ some of the concepts from Scrum, but any Scrum advocate would tell you we’re not using Scrum. And this varies from project to project, depending on the whims of the leads.

    Some of the most useful aspects of Scrum I’ve found for pre-production are 2-week sprints with runnable (demonstrable) deliverables, daily stand-ups, and a feature backlog. We don’t use burn-down charts; I usually put the sprint goals on a whiteboard in the stand-up area and keep it updated continuously so anyone and everyone can see what we have completed and what needs to be done to meet our sprint goals.

  4. Here is a free ebook I found. Here’s a quote from the website:

    “This book aims to give you a head start by providing a detailed down-to-earth account of how one Swedish company implemented Scrum and XP with a team of approximately 40 people and how they continuously improved their process over a year’s time.”

  5. Just one comment about the movie industry – you’re NOT correct in your assumption that the script finalizes everything that will happen on set. There’s a ton of movies who are famously written (and re-written) on set, e.g. Casablanca.

    More importantly, however, a lot of directors feel that the movie actually happens during editing. Walter Murch had to re-cut The English Patient countless times over the course of a year in order to make the time transitions to work.

    So it’s a lot closer than you think. Editing is a lot like beta …

    Funny thing is you don’t get to do a Director’s Cut of a game. Never.

  6. A great read Adam,
    It’s really interesting to look at all the different industries and areas that modern game development has inherited from.
    To date some of the best development methodologies in use stem from Agile (among other things), and as Peter acknowledged, are heavily augmented with what actually works within individual game developments.
    Perhaps one day we will be able to formalise some of these processes as a basis for evolving our practices.

    -Keep up the good work!

Comments are closed.