Game Development In a Post-Agile World

An anonymous reader writes "Many games developers have been pursuing agile development, and we are now beginning to witness the debris and chaos it has caused. While there have been some successes, there have also been many casualties. As the industry at large is moving away from the phantasmagoria of Agile, Gwaredd Mountain, Technical Director at Climax Studios, looks at Post-Agile and what this might mean for the games industry."

Comments

Re:Conclusions

[FooAtWFU]

My company started as a dinky little post-dotcom-startup, doing certain agile practices (extreme programming with a little bit of scrum), and it's since been bought out and now sells quality software to big enterprise customers tens of thousands to millions of dollars. As with any development methodology, it's got its ups and its downs, and depending on how you're trying to actually operate as a business, you'll need to make adaptations; moreover, it helps a lot if you actually employ intelligent people who know what they're doing.

Yes, maybe the Agile hype is a bit much, but so is the anti-Agile-hype hype. It's actually a good idea to start with simple things that work and are easy to code (so you can start making money today) instead of waiting forever building the Perfect System. The key is to manage the transition to more complicated things in an effective manner (so you can keep making money tomorrow). You start by thinking in the back of your mind about how you can make things easier to transition to the Perfect System in the future. That's probably the main tricky part.

Re:Not sure how Agile helps game development

[Hurricane78]

Nope. Waterfall is literally impossible on any real game project.
They are waayyy too huge.

What you would want, is the spiral model. Not exactly as in the book, but with the basic ideas.
At least it does good here. Jesse Schell also recommends it, for obvious reasons. And according to him, it’s what is used for all projects that big, that actually finish. ;)

Re:Not sure how Agile helps game development

[hackerjoe]

It's easy to lose track of the fact that good software is written by good teams.

I've worked on a couple of game teams that used scrum, and I'm kind of with you in that I don't think it made a whole lot of sense. However, nobody on our teams believed scrum precluded longer-term waterfall-style planning -- so we did that too, we just used scrum for the week-to-week divvying up the work. My impression is that a functional, experienced team can make something workable out of pretty much any process, we certainly did.

Those were traditional fire-and-forget commercial titles, though. Scrum makes a lot more sense for a long-life-cycle online game where you're adding features on a regular basis for 5 years post-launch. This is actually very similar to the context where (I understand) scrum is usually employed: internal information systems that see regular revisions for years after they're put in service.

Agile without user feedback!???

[Aceticon]

The essential philosophy of Agile is that development should be done in tight cycles were small self-contained features are designed and implemented, followed by user feedback while planning for the next cycle.

This process is intended to cope with a couple of problems from the old waterfall model, such as:

• End users of a system have needs but they don't know them fully and correctly up-front, so a fully defined requirements document is impossible. Tight cycles of feature-development-user-feedback facilitate user discovery of requirements and allow for small adjustments based on user feedback.
• It avoids the "As soon as we give the requirements to the IT guys we stop hearing from them for a year while all they tell us is that 'they're working on it'" problem. The end users of the system being developed become part of the development process in an Agile process - that brings all sorts of benefits like keeping them happy and getting quick feedback on potential problems.
• The planning stage before each cycle helps with prunning of low-value-high-cost features. By having the user-stakeholder choose the priority of the features to implement in each cycle, the important features will not be left behind just because they didn't look important to the developers

All that this has in common is the existence of end-users (which can be other systems, if your system does not have an UI), which have roughly defined needs (typically a business process) which the software being built will address.

Now look at games:

• The real end-users (gamers) need entertainment. They don't have a pre-existent process which the game would automate to achieve that - in fact some of the best entertainement comes from games that do things no games ever done before.
• "Having fun" is an emotional state which depends on many things that are difficult to pin-down and that even change over time and depend on the user's mind-set: a way to make users achive it cannot be discovered as part of small interactive development loops
• There is no typical end user that can act as a representative of the other users. In fact a successfull game aims to entertain as many sorts of users as possible and as cannot be tunned to the wishes of only some users
• Games are often one-pass entertainment: you play it once and then you never play it again. This means that any users trying the game in between the tight development cycles of Agile would quickly become useless as test-subjects (as boredom overwelmed fun)
• The programming part of a game is often the least important bit of it. In fact in most modern games the code just powers the rules engines (for the mechanics of the games) and the graphics engine (that gives shape to the game world and displays the artwork) and is at it's best when it's not noticed.

So games don't usually fit in the (software development context) pattern for using Agile development methodologies wholesale.

At best, some games might have a creative person behind it with a vision which can serve as the user-stakeholder, but even then often the "vision" is vague and can change a lot over time (a "vision" is much less prone to a continuously-improving discovery process than a "business process" - in fact if the person with the "vision" is not methodical, you end up with a process where a cycle is just as likelly to take the software closer to the "vision" as it is to take it further way from it).

To repeat the often heard (but seldom heeded) motto: "There is no silver bullet!"