[If you've discovered the value of Scrum agile development while making your game, expert Clinton Keith outlines Lean and Kanban, two ways you can be agile during all phases of the game development process.]
Many games teams that adopt Scrum quickly discover its value.
The improved velocity of introducing value, or fun, to the game at a regular
iterative pace shows where the project is heading and allows the team and
customers to react by improving the game frequently. However teams find that
when they enter production, the value of Scrum diminishes.
Many teams abandon some Scrum practices late in a project's life
cycle and return to more traditional waterfall practices. They call this
approach "a blend of Scrum and Waterfall". This article explains
the reasoning behind this and introduces the concepts of Lean Production and
Kanban as an alternative to adopting waterfall practices.
Lean and Kanban can answer the issues with Scrum that many teams
face, but they don't require the team to abandon agile methods. These
practices are based on real world production experiences which showed a 56%
improvement in the cost of level production.
In most agile projects outside the game industry, there are no
phases of development. There are no concept phases, pre-production phases or
production phases. These projects start with releases, and every release
delivers a version of the product to customers. Think of applications like
Firefox that release a new version every month or so. Most games have a
single release that requires years to achieve.
Eliminating phases is a big benefit of agile; waterfall phases
such as the testing phase force the critical activity of testing to be
postponed to the end of the project, where fixing bugs is the most costly.
Planning phases at the start of projects attempt to create detailed knowledge
about what features will be fun and the work associated in creating them.
Unfortunately the best knowledge comes from execution, which is why highly
detailed pre-planning fails.
For many games however, there is still a need to have phases
within the game. There are two major reasons for this:
There
is a minimum bar to the content being delivered regardless of the quality. Sixty-dollar
games must deliver eight to 12 hours of gameplay. This represents the major
portion of the cost of development and occurs after the gameplay mechanic is
discovered. This requires a pre-production phase to
discover fun and a production
phase to mass-produce the assets for the eight to 12 hour
experience.
Publishers
have a portfolio-driven market model. This constrains the goals of the games
that they fund. In order to gain publisher approval (which includes marketing
and often franchise/IP owner approval), developers need to create a detailed
concept treatment during a concept phase at the start
of a project. Developers are then unable to stray too far from this vision
throughout the project.
Pre-production allows more freedom to iterate on ideas and
explore possibilities. During production, we are creating thousands of assets
that depend on what we have discovered during pre-production. These assets
create a cost barrier to change during production.
For example, consider a team in production on a platformer genre
game. Platformer games (such as Nintendo's Mario series) challenge the player to develop skills to navigate
treacherous environments. The production team will create hundreds of assets
that depend on character movement metrics such as "how high the
character can jump" or "the minimum height that the player can crawl
under". Production assets depend on these metrics.
If these metrics are changed in the midst of production, it can
wreak havoc. For example, if a designer changes the jump height of the
character, hundreds of ledges or barriers would have to be changed. This can
create a great deal of wasted effort during the most expensive phase of
development.
It's critical to discover and lock those metrics during
pre-production. This doesn't mean that we can't be agile during production.
How we are agile does change. Instead of using an iterative and incremental
process such as scrum, a more incremental process such as Lean is more
applicable.
Sprints and Production
Asset
creation is deterministic and sequential work that does not fit the Sprint
iteration cycle very well. If we think about production as a factory assembly
line, then the two to four week iteration cycle doesn't make as much sense.
Factories don't empty the assembly line every four weeks and determine what
to build next.
Assembly lines have things rolling off much more frequently
and require incremental improvements instantaneously. The rate that completed
assets roll off the line becomes the new heartbeat of the production team.