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."
The key to successful development is the "Sally Jesse" method: Lose the zeroes, hire some heroes.
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.
When I think of game development, I think of milestones. I think of (relatively) set targets. This is more true for console games than PC game, but lately when I think of games I think console first.
Iterative style development? Maybe that might work for an MMO where the customers don't mind being permanent beta testers. The gap in QA between professional and game software development already feels pretty vast, but add to that yet another style that promotes a more aggressive, less strict regimen of development just sounds like a recipe of disaster.
I'm not sure when Agile became the silver bullet buzzword for programming. I have participated in it, attended Ken Schwaber's talks on managing scrums. I can see its positives and negatives, and it's difficult for me to see how game software development could benefit from being agile unless you're coming up with the next big project with a bunch of friends in your 'garage'. Designing your own game engine and concepts from the ground up where nearly every member of your team is a software architect level and the lightweight methods help. Otherwise if you're a code jockey working on a pre-existing engine then project management and deadlines are likely more effective.
And try pairing up agile software development with offshoring. It reminds me of the old "don't do drugs" commercials with the eggs.
*holds up an egg* this is your software development
*cracks egg* this is going agile
*opens egg over stove* this is agile offshoring
*ignores the fact that there is no pan to catch the egg* any questions?
Funny name. Smart guy.
[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
Many games developers have been pursuing agile development
Who ?
What the hell is he talking about?
Agile? Scrum? Waterfall? Sprints?
What do those words even mean? This article seems like it's written in some kind of alien language. And these charts look completely worthless.
Do people in management at large corporations actually talk like this? Do they actually think charts like this somehow help them run the company better? Ugh.
That's news to me. I don't know anything about the gaming industry or their development process (though in some cases it seems to be "work your devs to the bone, and then go bankrupt"). But I can assure you that agile methodologies are alive and well in the corner of the industry in which I work (e-commerce).
But Agile is a broad term, encompassing many different ideas. Do you mean specifically XP? Scrum? Agile design? I would say elements of all of these things continue to thrive, while in my experience none of them exist in their pure theoretical form (which is appropriate, because it wouldn't be very "agile" to be dogmatic about process).
While I can't imagine a game being released in an iterative fashion (aside from bug fixes and the occasional add-on content), I can imagine an agile, iterative model being used in-house, at least for some parts. I mean, do you really want to risk having nothing to show for your work for 6 or more months? Surely something could be "released" (in-house) for downstream dependencies to start work, and some basic feedback to feed into your development.
Who knows, as I say, I don't have any experience with game development itself. But the risk one faces with too long of an iteration is arriving at your iteration end-point way behind schedule, behind in technology, and with components that may work great in a design made a year ago, but can no longer fulfill the new requirements that have cropped up.
Did TFA have "Mary had a little lamb" in the middle of it? Nobody knows, and nobody ever will. Bonus points for unfalsifiable assertions in the first paragraph.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I don't know what anything in this thread means.
...but I like games.
Software development is still a craft.. more than art, but way less than engineering..
until we have tools to make software in a consistent, reproductible way, we can't apply engineering tecniques to software development
until then, we have to treat it as a craft.
we have to focus on communication of processes between people
the main problem today in software development is communication.
with the client, between developers, with management.
we have to develop tools to help the client communicate better the expectations. tools to help the developers communicate to the management how long it will take to do what. and to help management communicate to the client what will really be done, and how much it will cost, and how long it will take
that ...
As the industry at large is moving away from the phantasmagoria of Agile
I guess calling Agile a silver bullet and/or calling it a hype or anti hype is just a thing of the media. As a Software Developer you are used to at least know the best tool for your job and the best language for your job (albeit some reasons may prevent you from using them). The same should be true for software project management methods.
Keep in mind that perhaps 50% of all software development houses have no method at all but just do it with more or less success. That often is topped by neither having a version control system nor having an issue tracker. Project management is done with Excel Sheets, which are mailed around and edited/annotated by multiple persons.
Calling Agile "failing" is in my eyes a clear sign that you have no clue about it.
Every single thing that is stated as best practice in TDD, XP or Scrum is a very good thing to do in your process, regardless wether you follow any of those methods strict or prefer a more traditional approach.
Most people calling Agile fail either have (as I stated above) no process at all, never tried it, or already do do a lot of the core practices like nightly builds and continuos integration etc.
This said: no one ever claimed that a good running traditional process which is already yielding high quality result would be even better if run Agile. However everyone who has no process, everyone who has quality problems, everyone who has tracking, budget delivery time problems, those have a much easier term in adopting some agile process and a much easier introduction and adoption of tools instead of one who switches to RUP or similar heavy weight processes.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
...if the programmers started eating less, exercising and losing weight they could be back on the track to being agile?
When noobs don't know what to do and can't define the problem they break out the Agile card.
Problem is managers and CEOs lap up the Agile mantra especially when from a slick salesman. Agile sounds sexy. Waterfall methodology is what stale dinosaurs use.
In post Patriot Act America, the library books scan you.
Maybe not so related to the story, but anyway:
Game developers typically use C or C++ (at least the ones that create processing heavy 3D games), and it doesn't help that the open source frameworks for unit testing in C++ are not too great. The problem is that there are about 40 of them (see http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B), many developers spreading their talent over their own creation instead of working together on something good. We use UnitTest++ at work, and it hurts to see that the mailinglist is about dead, with interesting proposals getting no answer, and no updates since 2008. GTest seems better, but we can't switch just like that.
Contrast this to Java, where you basically have JUnit and TestNG in healthy competition.
There are commercial options, like UquoniTest (see http://www.q-mentum.com/uquonitest.php) which has great features, but I'd rather wait until they're compatible with UnitTest++ (as they promise on their blog), and Cantata++ (see http://www.ipl.com/products/tools/pt400.uk.php) which has code coverage.
Microsoft has published empirical data that shows that the process overhead for TDD increases the development effort by 15% - 35%
I have to say I'm amazed at how many idiots there are here. Has anyone on here really implemented or participated in a well-run agile process? Yes I said process because that's what it is.
The article comes across as thoughtful and presenting a well formulated view but completely misses some of the fundamental tenets of the agile manifesto. For example, valuing interactions over process does not mean you create a chaotic, wild-west environment. It simply means you do not rely on process to strictly guide you but expect people to talk through problems and quickly identify solutions rather than apply process for the sake of process.
An agile development environment, whether Scrum, XP, or a customized hybrid approach (truly taking agile concept to heart) creates a repeatable framework for delivering quality results quickly. A good agile environment will have a cadence that let's developers focus on technical solutions. It give managers a consistent window to see how work is progressing, to ensure requirements are met, and to quickly and easily adjust based on review, feedback, testing, etc.
I'd also point out that the writer of the article said the following in his article, very clearly NOT stating that agile was the cause of the problem:
Developing software is hard and developing games is particularly tough. We only have to look at the software development landscape to see the rotting corpses of failed projects as evidence of this fact."
The key responsibility of management is to help prioritize what gets developed when. If you don't capture and prioritize the development of fundamental systems (read: game play mechanics and physics) early on then this sounds to me like piss-poor management. You let high-risk items sit until late in the process. The more tightly coupled various elements are, the more critical the prioritization process.
I've actually heard some state that "it should not be a random walk". No shit? Thanks brainiac. Anyone that thinks that is what an agile process entails has no idea how to manage. Now please step aside so the team can work on incrementally delivering on the long-term product strategy and goals I've prioritized and roughly mapped-out (with their help).
Oh, did I mention I come at this from slightly outside the development team in a product manager role? And it STILL makes sense to me and helps me be more effective in my role.
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:
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:
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!"
Agile does not seem like a very good choice for game development (with a few exceptions).
A better methodology for game development would be rapid application development, because:
You want to make a model of the system before implementing it.
You want to make prototypes.
You are not planning on "maintaining" the system for years to come, you want it to be done relatively fast.
Almost none of the benefits of agile apply to game development unless its some kind of constantly running, constantly changing MMO.
Other good methodologies:
* Contract Driven Development
* Model Driven Development
I can see some form of structure is useful, but people seem to always get carried away with it, which sets of a cascade of bad things.
Things take longer -> enthusiasm drops away -> it becomes just a job -> people lose interest in talking and reading about the technology -> their learning slows or even stops.
I believe process and structures should be applied very very carefully, and more often than not, sparingly. I believe chaos, common sense and "yeh that works for us" can combine to come up with simple processes and structures that work best. I don't doubt things can be learnt from other processes, but it is a slippery slope to walk on.
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
I stopped RTFB'ing when I read the word "orientated."
His choice of words betray his place in the hifalutin versus technical continuum.
Oh crap I said "continuum", I'm turning into one of them droids! I'm meltiiiiiiiiiing...
Pet peeve: Profane people propagating perfunctory pedantry.
Good Agile, Bad Agile by Steve Yegge at Google is an excellent article on the pros and (mostly) cons of Agile development.
Personally my single biggest problem with Agile is that it specifically de-emphases code ownership (mental ownership, not economic). In my experience as a developer, the only way you get people to go the extra mile on a project (working nights, weekends, whenever and whatever it takes) is when they feel like that code is theirs.
The other big problem I have is that whenever I see someone talking about Agile development it always feels like they're trying to sell me Amway products. It has the same, almost proselytizing tone that a Born-Again preacher takes when they're holding out the money-jar.
"I am not a partisan of either camp. I am only interested in results and do not have the time or inclination to advocate a particular point of view."
;)
Great, another swing voter
Every year at GDC they have more and more Agile workshops. Seems like every studio I know is using scrum. I don't see any indication that agile is going away at all. Certainly there are agile projects that have failed, as have waterfall projects. But it really sounds like the author had some bad experiences with bad project management, and decided to blame the entire Agile methodology for it.
From what I've seen, game projects involve milestone deliverables based on the publisher requirements and events like GDC or Leipzeig. Within those milestone timelines, they use agile methods to adapt to changes and keep on schedule.
How cool is that: a whole article of which I didn't understand one word because I thought it was about making games for people who are not so agile anymore as they used to be, so they need games that rely on wit and intelligence rather than fast reactions.
-- Cheers!
I'd recommend Agile to http://en.wikipedia.org/wiki/Fixed_price projects.
I'd like to buy homeland for our 10 million people. http://twitter.com/mahadiga