Slashdot Mirror
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."
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.
The World Wide Web is dying. Soon, we shall have only the Internet.
That should be pretty much method-independent.
The Tao of math: The numbers you can count are not the real numbers.
[For fun: Read it, as if Ricky Gervais were saying it.* ;]
You know when your boss caught on to a new buzzsomething, storms into your room, and wants to play thought-experiments with him on what to change? Restructure the whole company? Because, oh god, it’s so great. He just loves it. With glowing eyes..., like a child. And you hate to tell him, that everything he just told you, and everything you have “planned” in the last 3 hours (of “water-cooler talk”, mind you) ...is a steaming pile of bollocks. ;)
“Agile” is such a thing.
You know he loves it. But he’s got no fuckin’ clue what he’s talking about.
“Yeah boss. Mmm-hmm. Great idea. Love it.... Say, you did hear that at the golf court, didn’t you?”
The thing is... everybody... and I mean every real software developer and project manager... knew that it could. not. work. ...you little fucker?”
We were just sitting there, thinking to ourselves: “You have finally found something that’s even more unrealistic than the “plan everything, then GO!” waterfall model, haven’t you,
Did you know that the spiral model... was invented over twenty years ago? Yeah. That’s how long you and I were sitting there, in our stinky cubicles... printing out everything remotely resembling fliers, and... casually placing them near your boss’s room, so he miight pick one up, and you would not have to beat him with that fuckin cluestick in your most beautiful algorithmic fashion, until he looks like a real flame-grilled burger king burger!
(Thankfully, not all of the industry is that bad. Most game development studios, from what I have heard, are actually implementing the spiral model in a very successful way. As am I. But it didn’t help you much when you were working at EA now did it? ;) ;)
___
* Please, if you want to rip me apart for not getting British English right, write me a e-mail in my native language and regional dialect... south-western Luxemburgish. You know, the one with the “fro”, not the “fra”.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
"Agile" methodologies are most appropriate when the project consists of a large number of loosely coupled user-oriented features with no major architectural or technical innovations. Like PHP-based web sites. Or, in fact, much programming which involves using an existing "framework". Someone else has already figured out what the different parts of the system need to say to each other and roughly how they will say it. Development is mostly filling in the blanks.
Trying to use "agile" on a hard, tightly-coupled problem with no predefined structural framework, like an optimizing compiler or a database engine, is likely to result in a disaster.
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.
It's interesting to note that movie-making has become very much a waterfall model business. A few decades ago, moviemaking was much more "agile", and most directors came from a theatrical background. For a theatrical director, there's a debugging phase involving actors on a bare stage, and the content may change considerably during development. Big-budget moviemaking today involves going from script to storyboard to previsualization (making a low-end animated version as a planning tool) to production. That's very much a waterfall process.
Game development has lagged terribly behind traditional / non game programming industries in terms of its development practices. And the most recent projects I have worked on were using a Scrum / Agile hybrid. I will admit to not knowing exactly which is which. But the great thing that Agile/Scrum did was to put in place a process where every time someone asked for a feature change, it would be reflected on the development schedule. I have worked on projects where there was at best a vague checklist of what still needed to be done with no info on how long it was expected to take. In my experience, most milestone crunch work is due to people realizing too late that something that should be in the milestone was not going to get done in time.
The problem with any development practice is that if taken too far, it will cause more problems then it solves. You should not have to write a formal task card up, and put it on the board for trivial tasks. And if you break things down too much, you end up losing sight of the bigger picture.
I do not care what process you use to get things done. As long as someone on the project (probably the project lead), is keeping track of the following:
- Break down the project into smaller tasks: This makes it at least possible to assign responsibility for specific things to specific people.
- Task / Feature prioritization: When it comes time to make cuts, knowing what things are important is highly useful.
- Task interdependency: You want to schedule your work load to make sure no one gets stuck waiting for something else, and it helps to have a list of alternate tasks you can move onto when you do get road blocked.
- Making sure things are done mostly on time: It is never a good thing to only realize that a task is not going to be done on time 2 days before it needs to be done. If something is taking too long, you should know before hand
- Making sure new features are checked against the schedule: No one wants to have a project become late because someone decided to add new features half way through the project but did not add time to it.
If you can track these things intelligently you can avoid the worst bits of milestone specific crunch. No process will prevent a deathmarch, or magically squeeze out an extra 6 months of effective development time. But it will avoid the nastiest surprises, and help create a realistic prediction of what a given development team can produce in a given time frame.
END COMMUNICATION
Well, I usually test before I implement. Far fewer failures that way. Just a single "file not found."
The Tao of math: The numbers you can count are not the real numbers.
Do people in management at large corporations actually talk like this?
No, the programmers do.
Agile is all about breaking the project down into small, more-or-less self-contained (sets of) features, and getting the users involved in the process. The aim is the same, to go from a set of requirements to a finished product, but it's supposed to be more flexible, more able to cope with changes along the way, etc (hence, "agile").
It differs from the traditional waterfall method in that it allows for coding of one (set of) requirement(s) to start, while the next set is being specced out; it also allows (in fact, requires) that testing of the last set of delivered functionality is performed while the current set is being developed. Thus it runs several separate workstreams in parallel. If that testing reveals any bugs that need to be fixed now, then the fixes can be worked into the next sprint as required (which yes, may well push features out, either to a later date or completely out of the project).
Agile suits some projects better than others, some customers better than others, and some project teams better than others. When it works well, it can work really well; similarly when it's poorly managed or people have unrealistic expectations, it can crash and burn like any other method. (And similarly, of course, other methods of running software projects can work very well too - use the right tool for the right job...)
It's official. Most of you are morons.
The problem is not in "Agile" methodology.
The problem is in "Mongolian Clusterfuck" methodology, called "Agile" by managers who think "Mongolian Clusterfuck" isn't catchy enough.
Agile sets short reachable targets, and reiterates and modifies them upon reaching them. The cycle is 2-4 weeks.
Mongolian Clusterfuck is similar, but the cycle is 2-4 hours and the targets that haven't been reached are abandonned half-finished.
Agile has specs that accept modifications when the customer requests them. Mongolian Clusterfuck has specs that change every time your boss stops by.
Agile has daily meetings of what problems to solve and how. Mongolian Clusterfuck is "this is broken, leave whatever you're doing and fix it now."
Agile has one clear set of goals of a golden middle between performance, stability, portability, cost, time and maintainablity. Mongolian Clusterfuck has two. Simultaneously.
Game development is exceptionally prone to Mongolian Clusterfuck methodology. And then people who never knew Agile think it sucks bad.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2