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."

Conclusions

[triorph]

Is the current conclusion these days that agile doesn't work? Its been what I've always thought but I am wondering whether this article is stating it for a fact when most of the software engineering discipline still believes in it.

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.

Re:When to use "agile" methods.

[dcollins]

"A game can fall into either category. If the game requires new technology, especially something hard, (advanced AI, a new physics engine, a very large seamless world, etc.) a very front-end design-driven approach may be necessary. On the other hand, if most of the game consists of developing content for different areas of the game world, an "agile" methodology could work fine. Second Life is probably the most extreme example of this."

In my experience as a game developer (now 10 years ago), the situation would be exactly reversed. New technology requires rapid iteration from a lot of stakeholders, in a search to find something that is workable, balanced, fun, expandable, etc., which sounds "agile" to me. Established technology seems more like something you can give marching orders to the art department and have a fixed production schedule.

Examples: Two projects with new game engines being designed or evolved, programmer/designers were continually advancing or identifying features as unworkable, while some poor guy was trying to update a 100-page "design document", trying to record our feature set, being always hopelessly out-of-date, and to which none of the programmers paid any attention. Meanwhile, an intermediate add-on project adding no new programming (just new levels and art) became celebrated for having a well-established schedule up front, the tightest timeline, least expense, and best-looking art of any project at the company.

Re:Not sure how Agile helps game development

[Anonymous Coward]

That's because claiming the waterfall is flawed is easier than backing up the model the author is trying to sell.

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!"

Orientated.

[ericvids]

I stopped RTFB'ing when I read the word "orientated."

His choice of words betray his place in the hifalutin versus technical [askoxford.com] continuum.

Oh crap I said "continuum", I'm turning into one of them droids! I'm meltiiiiiiiiiing...

Re:Was it ever Agile?

[fusiongyro]

Everyone who is annoyed at this article seems to be claiming that the author hasn't experienced agile as it should be practiced.

I have some experience with another methodology, cleanroom software development. The idea behind is, you make a detailed specification, you implement all the code with copious annotations, explaining each line of code. Then you have a big code review, in which each line of code is viewed and the engineers all agree that it correctly implements exactly the specification of the line above it, and that each specification performs part of the overall goal of the program.

After you do all that, you compile and run the program for the first time, and start counting how many bugs you have.

The interesting thing is that cleanroom has been proven many times to produce an order of magnitude fewer bugs. Looking at the method, it's hard to imagine how it couldn't. It has a reputation for making the maintenance phase much lighter, because there are so few problems. Yet, when most people hear about the method, their reaction is revulsion at the overhead and the perceived costs (though in practice, it's been shown that the up-front cost may be higher, the overall cost of the project usually is lower.) Why could this be?

Perhaps these different methods exist because people are different and groups have different priorities. For many people, high turnaround is more important than the lowest bug count, and thus, they choose agile. I tried it and I found it was a poor fit for me. The other partners in my company couldn't stop telling the clients that we used this method, but we never found a client proactive enough to actually make it work. They were shitty clients, sure, but they were the ones we had.

Agile belongs to the class of things which can be disliked for what it is, even by people who know what it is supposed to be like.