Game Development In a Post-Agile World 149
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."
Re:Many games developers ? (Score:2, Informative)
Re:I am a game developer. (Score:2, Informative)
We use these terms because it's very long winded to spell out what we mean in much the same way that we say wi-fi when talking about a wireless system for transmitting data between general purpose computing devices.
Re:methodology for noobs (Score:4, Informative)
I question whether you really get Agile, either. Yes, the requirements for the entire project are not given up-front. But the requirements for each sprint are.
Working without requirements is crazy and is guaranteed to destroy your sanity. Without requirements, you cannot estimate anything and you never know when you are done.
Yes, requirements can change in Agile, but never in the middle of a sprint. If the boss wants to send it back because it's the wrong shade of blue (despite that being the shade they picked) they will know exactly what it will cost them to change the color, and they'll get to decide exactly what sprint you'll do it in.
Excellent article against Agile (Score:3, Informative)
Good Agile, Bad Agile [blogspot.com] 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.
Re:Conclusions (Score:3, Informative)
I've used scrum for over a year now, so my opinion is colored by that. It's my opinion that scrum works quite well in terms of productivity but it has two major problems. It takes most the fun out of development and turns IT work into a daily grind of task processing fed from an infinite treadmill. The second is it kills inventiveness.
Why do I say that? Well, scrum prioritizes tasks by importance and not by tasks you're interested in working on. On teams I was on the task priority was simplistic and based on three things: 1) the seniority and level of the requestor, 2) the number of systems impacted by the bug, and lastly 3) the nature of a feature enhancement. #1 is usually turns out to be a waste of time (I call it the boss tax.) #2 is usually very hard and quite monotonous. #3 is the source of fun tasks. Since operations work always ends up trumping enhancement work, feature requests get pushed into the future so you're always chasing the day when you actually get to do interesting work. It doesn't come often.
Scrum is a team collaboration effort so stories added to the board must be justified. It's not enough to justify a task with "...because I want to work on it and I have cool ideas to try out..." or "the code base needs refactoring and I have some ideas how to craft it better". It will be summarily rejected by your teammates because they will chant "we must stick to the priorities". That is the precise moment when scrum kills invention.
Sometimes we need a mental Scoobie snack and need to work on interesting things in order to prevent burn out. I don't think it's to the team's advantage to ignore that. All the great ideas were developed by those interested in the particular problem and many were developed by those who momentarily ignored their peers and the bureaucratic system of control.
What I described is classic thread starvation problem due to a simplistic scheduler implementation. We have 3 threads but each is given different priority. In our example, it's thread 3 that never gets CPU time. The way you break free to give yourself time to innovate is to ignore the system and show your work after your prototype is complete. This may mean locking yourself away for a few days until your work is done. It may mean getting a negative review or worse getting fired. If the system of managing software development penalizes you for developing innovation, then the system is the problem.
As I said earlier scrum works well but only when metered and executed properly but who pulls that off? For example the schedule must allocate time between sprints for the sprints to be effective. The in-between time is critical for performing non-scheduled activities. Of course that lasts until a manager sees the schedule and says "hey why is there all this idle time between sprints?" which inevitably results with the "brilliant" observation that butting sprints against each other will "boost productivity". Sprints are a great idea so why not make every day a sprint day right?
Over the year we got a lot done so on paper we were very effective and productive, but it came with a cost--never ending recruitment and over taxed, under staffed teams. In the last 18 months my team has experienced 50% turnover. One teammate moved to another team and 2 others left the company. From what I can gather the story was the same during the previous 18 month block of time. You have to understand this is a big deal because in this company 100 resumes results in 1 phone screen; 100 phone screens result in 1 offer. It will take 6 to 9 months to replace the missing three so the remaining 3 teammates are facing those months of supporting 3 very large complex systems while simultaneously trying to do new development while on pager duty. For one of those 3 systems no one understands it because it requires specific technology experience and the 2 domain experts left. When the new hires come on of course there will more time wasted on training.
Re:Not sure how Agile helps game development (Score:3, Informative)
Look. Anybody with a brain knows that many agile practices don't apply to certain kinds of projects. That's just common sense. I've been in this business long enough to have seen a parade of silver bullet methodologies go by. All of them worked for people who had the development experience, business awareness, and common sense to know when to bend the rules or ignore them. Likewise none of them would take a person incapable of delivering a project and fix that.
"Agile" is a marketing term, and like most marketing terms it's a lie. Agile works best in those places that left without guidance would try to be too agile for their own good. The places where management, if you let them, will barge in twice a day with a new direction. Now if you know developers, you know they have good days and bad days, and if you want to get anything out of them you've got to give them a long enough stretch in one direction so that they can catch the wind in their sails. So you take down a few books from your shelf, and you say, "This is the latest thing. It's *agile development*."
Immediately management gets it. It's about getting more done faster. What you don't tell them is that it's about keeping them out of your team's hair long enough to get *anything* done.
Now if you can define a good set of requirements and keep the goalposts from moving for longer periods, that's even better. Thirty days is a reasonable compromise for a sprint. You want to measure progress in a detailed way at least that often anyway, and it provides ample time to get identifiable bits done and to even try and discard a few creative approaches. But there's nothing magically necessary about changing priorities every thirty days. If you can reasonably keep them constant for six months, that'd be even better. But in *some* kinds of development that's not possible.
When you are building software to support business functions, priorities shift based on the response to competition, assumptions in the business plan that don't pan out etc. Even the software itself changes the requirements environment. I've been in situations where I know that the organization needs B, but they can't *see* that need until they've seen A first. So the quintessentially agile part of "agile" is really indispensable on these kinds of "dynamic requirements" jobs. The rest of it (unit testing etc.) is just motherhood and apple pie engineering.
Now as far as the game industry is concerned, everything I've heard about it makes it sound like a horror show. I attribute this to two things. First it is attractive to young folks enamored of the romance of creating the kind of games they love. In other words people easy to exploit. The other factor is bravado and immaturity of the company management. In time as the people in the industry mature, maybe things will change. But "methodology" isn't going to solve the problem of self-deluded and exploitative management.