From a brief study of the game industry, I might list a few impediments to
"agile" software development. Whereas this essay will define "agile" as
"good", we should not make the mistake to think that any agile "best
practice" must slavishly mirror into game development. Achieving the results
shown by "agile" development in other industries - reduced odds of failure,
accurate schedule estimates, and absurdly low defect rates - will require
adjusting the practices to fit game programming topologies.

    Planning Game, Early Delivery
With a few exceptions, the game industry could not sustain Early Delivery.
Games are entertainment, and changing levels every few months would destroy
the tenuous addictions that designers so carefully foster. The game industry
has more in common with the motion picture industry than the other sectors
of programming. A game starts as a pitch, very similar to a screenplay
pitch, and ends with a rollout. If the game succeeds it funds its studio's
failures. Like a screenplay, a big game design, up front, must pitch a known
genre to a very clearly defined demographic. That helps a studio's successes
exceed its failures. This practice excuses each game's development from much
internal risk management. A successful game generates enough cheddar to fund
rewriting the next game's engine. (A studio simultaneously shipping two
games generates trade literature headlines.)

Frequent, regular internal releases have many more benefits than merely
preparing for frequent delivery. Frequent releases depend on a steady stream
of feature requests, where each feature can cover any subset of database,
middleware, engine, logic, art (assets), and front-end. Sorting these
requests in order of business value has a powerful effect on design, because
the high-priority items get tested, reviewed, integrated, and reinforced the
most during the remaining development. However...

    Continuous Integration, Daily Deployment, Frequent Releases
Game development works with very large teams, split by function into groups
with similar abilities. The business world, working on projects requiring a
narrower range of abilities, has learned to avoid this tactic, and to
colocate very small teams of diverse abilities. Splitting teams by function
requires goal donors (designers and technical leaders) to split feature
requests by function, not by business value. So these forces, coupled with
the incredibly high volume of data born in each game title, powerfully
dis-integrates production, making continuous integration much more difficult
than it could be. A game's source code and data file can take several
computer-hours to rebuild.

So these forces, in turn, inspire game developers to re-invent a practice
that business programmers are learning to avoid - rampant code branching. A
game team might have a mini-branch for the sound guys, a mini-branch for the
AI guys, etc. The cost of re-integrating each teams' new outputs, to finally
create the integrated feature the designer requested, delays the most
important feedback. Designers should review the effect of each request, on
all game aspects, as soon as possible to permit that review to accurately
and usefully drive the new requests.

    Pair Programming, Shared Code Ownership
The game industry is widely reputed to program game engines using only the
worst practices of both Waterfall and Code-and-Fix. Designers request engine
abilities far in advance of reviewing the levels that exploit them.
Engineers perform Big Design Up Front to the best of their abilities. When
any Waterfall system runs off the end of its planned design, developers are
forced to switch to Code-and-Fix. Those of us experienced with the long-term
results of Waterfall have all seen projects with many clever designs, many
over-designed parts, and many parts riddled with spaghetti, cross-patches,
and horrid cruft.

I lack the tact that other agilistas exercise daily when I admit that game
development attracts and retains programmers with ... special skills. Pride
of code ownership must preceed the all-night coding sessions that keep such
code afloat. Game developers learn their systems very well, and the industry
relies on their experience shipping games to request them to ship again,
with a slightly better engine each time. Within these mega-iterations,
source code loses many opportunities for collaboration to force in new
flexibilities. "We can't do X until Q completes Y" is a common impediment.

    Test-Driven Development, Customer Tests
Over time, game projects grow a huge "decompression debt" of easily-fixed
bugs. Shipping a game requires an early feature-freeze and then a very long
party to stomp insects. However, within the many layers that make up a game
are many latent tests, and an extraordinarily huge number of side-effects
that could easily become "characterization tests". But only pure TDD from
scratch can beat legacy test retrofits. Pure TDD will generate full-feature
test fixtures capable of testing arbitrarily complex aspects of play that
entry-level testers could only dream of.

And all games have a scripting layer of some kind. The Lua language is the
leading candidate for this role. And the great irony of game development is
this: Most business projects don't have a scripting layer, and have Onsite
Customers who should not write source code. Agile development relies on
Customer Tests, written by customers, to constrain each feature they
request. Game projects, by contrast, require designers to author Lua scripts
to add the hooks and triggers to each level. So game projects have Onsite
Customers who can write scripting code, and game projects also have the
scripting layer for them to write with. To close this gap, game projects
need only require designers to author the tests for each high-level feature
they request. And game projects must tune their scripting layers to make
these techniques easy and robust.

    A Prescription
Start a game small, not super-big. Maybe start with a designer, two engine
guys, and two asset guys. They finish a level, incrementally adding
challenges, and maintaining a zero-tolerance for bugs. They measure their
velocity, and their gold-owner adds resources until the velocity levels off.
The game remains playable and deliverable at all times. It might not have
all its levels and its resolution cinematics, but it will have zero bugs and
all playability features for the levels it grows.

This recommendation turns traditional development side-ways. The storyboard
becomes the schedule, not the bottleneck, and levels not yet completed are
the ones most easy to change. Shortening the feedback between feature
requests and results, by any means necessary, will lead to agility for the
game industry.

--
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces