Agile game dev (1/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part I - Problem and solution

Read the series: 1/5, 2/5, 3/5, 4/5, and 5/5.

Problems

In the 70s, arcade hardware was expensive, so developers iterated on the software and shipped when high quality. In the 80s, hardware became cheaper, so everyone could ship games without too much investment. Quality consequently decreased. But as games increased in complexity, teams started to require specialists (artists, composers, network engineers), and the software costs exploded. This led to the hit-or-miss strategy: invest only a few man-years in developing a game, ship, and hope for success. Hopefully, one hit would pay for many failures.
Problem #1: the number of man-years (and costs) to make AAA games doubles every 5 years, but the market isn't growing as fast. Moreover, only 25% of the revenues will go to the developer; the rest goes in distribution, marketing, publishing, and licensing fees.
Problem #2: only 20% of games released generate profits, so risk-averse publishers prefer sequels of existing IPs than risky innovation. Yet it is innovation that drives the game industry.

You can only know if your game is fun by play-testing it. Since design, art, and tech requirements emerge as the game is developed and play-tested, waterfall is not appropriate, and maintaining a detailed documentation too time-consuming.
Problem #3: how do stakeholders (developers, publisher, IP owner, studio management, etc.) communicate?

Traditional game development is made of 4 steps: concept, pre-production (aka pre-prod), production, and post-production. Of particular interest are pre-prod and prod. Pre-prod is exploratory, and aims at figuring out the basic mechanics for the game to be fun. Pre-prod can follow a kill-gate model, where several prototypes are started to explore ideas in parallel, and the least promising are "killed" every few months. In production, levels and assets are mass-produced.
Problem #4: how to predict the schedule, budget, and amount of new content to produce from the basics found in pre-prod? Moreover, milestones defined in contracts with publishers prevent developers from adding good features at the last moment, and prevent publishers to ask for new features too. How to accommodate everyone?

Introducing agile game development

Agile is not a silver bullet. It only makes the development process transparent: problems will become obvious, but they still have to be solved. Agile aims at improving communication between the stakeholders: publisher, developers, IP owner, studio management, and so on.

Sprints: Agile game development is iterative. At the lowest level of granularity, an inter-disciplinary team of developers designs, implements, and polishes features during iterations of 2-4 weeks called sprints.

User stories are the agile way to present features so that they communicate value/fun to the stakeholders. For example: "As a player, I want to see enemies react when shot."

Releases: At the highest level of granularity, releases of the game are delivered every 4-8 sprints (2-4 months). Releases focus on major goals such as "online gameplay".

Backlogs: Communication within the team happens through a sprint backlog, and between the team and the stakeholders through a product backlog. User stories are moved up or down the backlogs by the product owner, representing the stakeholders in the studio.