Tuesday, September 21, 2010

The manifesto for agile game development

The Agile Manifesto contains four values and twelve principles for "Agile Software Development".  It's simple yet powerful and still applies nearly 10 years later.

I've modified them slightly to better fit game development.
We are uncovering better ways of developing games by doing it and helping others do it. Through this work we have come to value:
  • Individuals and interactions over process and tools
  • Working game over comprehensive design documentation
  • Publisher collaboration over milestone negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

The principles behind the Agile Manifesto:

  • Highest priority is to satisfy the customer through early & continuous delivery of valuable software, assets and gameplay.
  • Welcome changing requirements, even late in development. Agile processes harness change for the developer's competitive advantage. 
  • Deliver working gameplay frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people & developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient & effective way of conveying info within a dev team is face-to-face conversation.
  • A working game is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors and developers should be able to maintain a constant pace indefinitely.
  • Continuous attention to balanced artistic quality, technical excellence and good design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done—is essential.
  • The best architectures, budgets, assets, requirements, and designs emerge from self organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


DE said...

Misisng a bullet point to get 12 principles :-)

This looks to be a useful specialization of agile. Congrats.

"Working game" obviously is shorthand for "working gameplay". Unlike "software" the term "game" implies completeness.

"Publisher" is an interesting term to use given the increasing methods of self-publishing.

The original "Responding to change" was heavily geared towards the idea of changing business conditions. For games, we are talking about changing hardware norms, responding to conventional publisher beliefs or purely local changes with storyboading. These are all considerable, but are not quite the same flavour as the original statement.

By "business people" I assume you mean stakeholders. As a developer, I would have little interest in meeting random business people.

"Build projects around motivated individual" - there is something missing there. It doesn't quite capture the idea that certain teams produce great games.

Clinton Keith said...

Hi DE,

Thanks for the feedback. The missing bullet point has been found and returned to its rightful owner.

Working game includes gameplay and other necessary things such as budgets and performance. One of the greatest failures you'll see in games is following the plan that says "everything will run at 30 fps" and only getting 15. Nobody cares about gameplay at 15 fps!

Publisher can include both 3rd party and 1st party. If you "self publish" on the iPhone or XBLA, etc there is often a 1st party publisher involved. The original manifesto said "contract negotiation" and you could argue that not all products have contracts. Perhaps "sponsors" would be better, but "publishers" is more universally understood.

"Responding to change over following a plan" applied to games, is mainly about responding to emergent design change as you "find the fun". Story-boarding isn't as emergent in games as it is in movies.

As a developer, have you never spoken with license holders, marketing or sales people AND studio stakeholders (business people)? Aren't these the people have huge impact often late in a project?

Agree on the "build projects..." feedback. Must think about that one more...


DE said...

I may be being too British with the "business people" thing.

A lot of people involved in "the business" have roles not directly involved in software development. Exactly what they are doing somewhat depends on the company.

I would expect marketing and community guys to be "chickens" in the daily standups, but probably not finance.

But ultimately the statement "Business people & developers" seems to suggest that developers are inherently not involved in the business, when they are at the heart of it.

Again, this may read differently to you.

I quite like "finding the fun over following a plan". Though how this relates to the development of Duke Nukem Forever, I'm not sure..

Clinton Keith said...

Stakeholders does sound better than business people, but isn't as inclusive. I'd like to find a better term.

There's all sorts of people who aren't stakeholders that we need to work with, such as license holder approval that are getting flat fees. I'd like to capture them as well, but would prefer another term.

Clinton Keith said...

Also DE, I wasn't sure about your last comment.

Did you think Duke Nukem Forever:
a) followed the fun too much
b) didn't follow a plan
c) followed too many frequently changing plans from a stakeholder in charge

We Scrum trainers use a phrase for a agile project without an effective product owner: "an iterative and incremental death march".

DE said...

Yes, incremental death march.

From what I hear about the original Duke Nukem Forever project, they suffered from vision expansion - in short their definition of "done" wasn't tight enough to ever stop. They always moved "done" over the horizon.

Perhaps at least one or more stakeholders was not able to step off the wheel with a version that they wanted to release.

The fun was followed, but no stakeholder(s) called time coherently.

Clinton Keith said...


The fundamental problem with AAA (disc based, single release) games is that there is a minimum marketable feature set that has to be shipped and a constantly shifting technical window. I think we'll see more games like DNF, whose MMFS bar (being a sequel to hit game) and dev timeline constantly stay beyond the technical horizon.

Surge said...

Lots of good information here. Very helpful in organizing things, thanks you for the post.