Slashdot Mirror
Using Agile Methodologies To Make Games?
simoniker writes "Using Agile methodologies for programming is a concept that's been around for a while now, but some firms are now applying the concept to video game development." There has been a lot of talk lately about what the 'next big thing' in development will be. Could this be it? Or is this just another step along the way? From the article: "Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives."
And so started a cycle of hatred towards methodologies about how to be productive in application development.
To me, the wild wild web is still here. I still get my kicks from coding without set in stone documentation and I still hate schedules.
I've always had the view that every project was a wild animal. Worse yet, it's a wild animal in sheep's clothing. And you approach the sheep with a shepherd's hook. When the veil is lifted and you see man eating marsupial with alligator teeth and a scorpion's tail, you have no choice but to throw the shepherd's hook at them and give it all you've got.
And this is how I approach managing a development project. You remember prior projects and throw together a bag of tools that have worked before and then you set to taming the beast. If you tell yourself "Waterfall works every time" then you're just going to find yourself with a shepherd's hook facing a lion or a bear.
Instead, you learn to adapt to every situation and that's the important thing. The rules are few and loose. The customer has the power to destroy everything and you have to deal with it. The best development is done on the fly with just enough documentation to convey the big idea of what's going on and keep everyone on that page. Given real life schedules and timed deadlines, there is such a thing as too much documentation.
Agile development is better in that it allows you more play and doesn't inhibit spur of the moment innovation. I think some of my most demoralizing moments have been when I realized some great new possibility for a project only to have my manager tell me that so much documentation would have to change that "maybe we'll put that in next year's scope." I find this to be ridiculous.
What was happening was people were starting to assume that waterfall was the silver bullet for project management. "What kind of project is it?" "I don't care, we're using the waterfall." And the big problem is that the waterfall is only considered 'adaptable' if you're ok with reworking everything from step one. Is this really necessary for every project though?
Another new thing we have these days is a "framework" that fits a specific type of problem well. You can throw these together on the fly and have very little documentation because the framework provides a well known implementation strategy (see Spring's MVC).
It is my opinion that using an incremental deliverable approach with frequent customer meetings and executive power at any point in the project is the most successful strategy. The "rules" you have to adhere to are up to you and should be purely a case by case basis.
Why do we constantly look for the "next big thing" when the "big thing" is simply experience?
My work here is dung.
because of the iterative process of Scrum and the short work cycles of Sprints, redirecting a project rarely results in large volumes of wasted work.
... cause that last pair of words ... wasted work ... seems to hit my teams especially hard quite often right now. We'll finish LARGE tasks, perhaps bundle multiple items together into one large release (cause this is how management wants it) ... and by the time it gets to UAT testing many development hours have been spent ... and then the UAT tester will turn around and say ... nope ... don't need/want that ... and thus all those development hours are wasted. I'd love to get a workflow like SCRUM implemented in my workplace.
I like this
I doubt it. Smart dev teams have been using iterative development cycles and keeping their code tidy since a long time before anyone coined the buzzphrase "agile" (or using SillyCapitalLetters and calling things "extreme", or any of the other hype we've put up with lately).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
"creating prioritized vertical slices that iterate on the most critical elements and features"
Can someone tell me what this means?
Computers are useless. They can only give you answers.
-- Pablo Picasso
Agile development with C++? Sure, it can be done. But one of the nice features of that language is its ability to model the application domain using Classes, Objects, Inheritance. If you don't take the time to model the problem correctly, you can painfully pay for it later on. Sometimes you get faster development times if you actually take a day or a week and model your problem so that it captures the essense of what you are trying to solve using objects, etc.
An iterative approach where you use a greedy method of implementing each new feature as quickly as possible with little insight into the overall system may or may not produce optimal results. It can lead to lots of spaghetti code. Or maybe not. Certainly in my career that approach sometimes *has* led to cleverer solutions as I was forced to think up the best, simplest way to imlement them. But often it can lead to massive amounts of spaghetti code that doesn't make much sense or capture any insights into the problem.
Working at a major game company, here's what happened when someone here raised XP:
The guy who suggested it, "It's an itterative development model. We identify core features, develop those features, refine those features with the customer, then add the next layer, repeating as we go. We gain much better code as every component meets the customer's need as it is developed, challenging the customer to think about it in context, and allowing us to add additional itterations if needed."
Management, "So, we can identify additional features throughout development?"
"Absolutely. You just have to assign additional resources (time/people) to account for those extra features. But, by identifying them as they come up, you end up with a much better system that really does everything right."
Over the next few months, features kept getting added, developers dutifully updated schedules. All was happy. Followed by...
Management, "This was supposed to ship before thanksgiving. It's now slated to ship in the new year. We'll entirely miss the holiday season."
Rapidly realizing his mistake for suggesting it guy, "Yes. But you kept coming up with new features. And they are great new features. Think how much better the product is for it."
"If we miss the holiday season market, we lose money. This has to ship 'on time'."
"But on time is a function of how much you add. We're developing everything to schedule. You've just increased the features so increased the schedule."
"The schedule can't move."
"So you'll have to lose some of the remaining itteration milestones. You'll have to drop features."
"But we like all the features we've come up with."
"But adding features adds time. You've known that since the beginning."
"We've known this has to ship for the holiday season and you promised us we could have extra features. You're just going to have to work more overtime. Fortunately you're overtime exempt so that won't cost us anything to get this project back on schedule."
"It is on schedule. You just changed the schedule by adding features that were identified along the way."
"You told us your wonderful "XP" model would let us do that. We gave you the chance to try this new method under the understanding we got these benefits."
"And you do."
"Good. Then make your schedule."
"We are mak-"
"No arguments. This discussion is over. You promised you could deliver the extra features. You're now behind schedule for the holiday season. You're just going to have to crunch. End of discussion."
Yeah, thanks XP.
Never, ever, raise exciting new methodologies to management. They will hear all of the advantages and expect every last one of them as though it was the perfect implementation of the method whilst completely failing to hear (and certainly refusing to act on or implement if they do hear) any of the trade-offs that have to be made to enable those gains.
Tragically, I couldn't RTFA because of th excessive market speak.
In order to energize the evolution of computer games we need to synergize on the vertical slies... WTF?
I guess people forgot to mention that writing computer games rates up there with writing operating systems in complexity...
Yes Francis, the world has gone crazy.
30 days is fast? I wish I had 30 whole days to do my projects!
I love iterative development, but scrum didn't impress me much when I was involved with it. Perhaps that was just due to the management that implemented it. We went from logging bugs and tasks in bugzilla to writing them on index cards (do I really need to point out to computer people how stupid that is?), and trying to plan projects on these obscure, poorly implemented planning tools.
Iterative development is great, but scrum strikes me as nothing more than another useless management fad.
This is just an issue with management, though. A good manager will trust his engineers (or fire them and replace them with trustworthy alternatives). The manager's job is to set the direction of the project, get the engineers what they need to steer in that direction, and then get out of the way as much as possible and as quickly as possible.
It's staggering how many managers don't realise this, and hamstring their dev teams with their personal, half-baked, technically-incompetent ideas and/or with excessive procedures and beaucratic reporting because the manager "has to know what's going on". Of course he does, up to a point, but what exactly is he going to do if a developer does tell him that a bug fix was delayed by a day because {$TECHNOBABBLE}? If he's not going to act on some information, he doesn't need to know it, and requiring developers to take time out of their day to "keep the manager in the loop" more than necessary just disrupts development.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I have been developing products for a long time (decades if you must know). For what it's worth, it is my experience that the people on the team have by far the biggest impact on product quality, timeliness, and all those other goodness measures. I believe that the methodology is almost immaterial. Good engineers will instinctively use the appropriate process for the problem at hand. Now, this doesn't necessarily scale to very large projects, which is why I am a firm believer in loose coupling. As soon as practical, decompose the big project in to a collection of loosely coupled smaller projects and then put in place the teams (unfettered by process dogma) to develop the pieces. Ahh, you ask, but what process do you use to decompose the system? See my earlier comment - choose a small team of very good engineers and have them do it. Don't tell them how -- they already know that. Trust people, not process. Ironically there is one process that I believe is critical to every organization's success, and it probably the least-studied, least-optimized, least-formalized process every company has ... and that process is the interview process. Clearly if I am going to trust my people to do the right things and make the right choices, I had better hire the right people. Anyhow, that's about $0.93 more than my $0.02 so I'll step down off my soapbox now.
The more you regulate a company, the worse its products become.
The problem using any software development methodology which requires user feedback for new product development is that you don't actually have any users - best you can get is a marketoid and those change their minds every 5 minutes.
./ for the last couple of years, the main process problem with game development seems to be that a lot of the control over the final product lies with Marketing, and worse, Marketing is in a different company altogether (the producer) than game development - so even with good managers on the software development side (already unlikelly) it's difficult to control the the flow of wacky ideas "that just have to be included in the game" coming from the marketoids - thus requirements creep is rife, which almost guarantees that long hours and death marches are standard.
You see, the closest you have for a user of a new game is a gamer and those can't really help you refine your requirements 'cause all they want from a game is to be entertained and they don't really know beforehand how a new, entertaining, game will look like - "having fun" is hardly an easy to define business process.
Maybe some sort of mixed approach where you have a game designer with an overall view of the game concept and a generic pool of gamers to check out the "fun factor" during game development. Might work well for games with an "exploration" component (for example RPGs) for which you can design the early levels, "test" them with some gamers and then use the result to fine tune those levels and later ones. Still, i doubt it can be usefull in game genres such as RTS and Sims.
More in general, and judging from the posts i've been seing in
Which can never be done reliably for non-trivial projects with the tools and techniques we have available today, regardless of what anyone trying to sell you their book says. No-one has yet shown how to beat picking two of cheap, fast and good.
Which is a much higher level than the sort of day-to-day project stuff we're talking about here.
It doesn't, in this context. Again, no executive of a large company should routinely be involved in the day-to-day progress of minor projects by a particular dev team. That's not their job, and it's the worst kind of micromanagement.
It also means you need metrics worth something, which random estimates for project timescales based on the inadequate information that was available six months earlier most certainly are not.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Seems like the whole idea the article suggests is a pipedream. So their great and new idea is to complete the most important features immediately, then refine them. Well that is all great, but what about the fact that a game usually isn't remotely playable until it is 90% done, no matter which pieces you work on or do in what order.
This reminds me of something I just read about how episodic content will never work, as making episode 1 requires 95% of the work of the entire game.
Show me raw, tangible statistics pitting Agile methodologies against other more traditional approaches, like "waterfall". I'd like to see a whole range of games (or other applications), developed using various methodologies and scored based on parameters like: shipped on time, end product quality, popularity, critical review scores, and, of course, amount of profit. This would be the only way to see how much "better" Agile is compared to other methodologies. Otherwise this is all just theory, speculation, and unadulterated opinion.
Despite what EULAs say, most software is sold, not licensed.
This is nothing new in game development, even at large companies. 'agile' (with a little A) has been used for at least a decade. You just can't possibly build a good game with the waterfall model and we've known that forever. I think it's a bit like every generation thinking they invented sex.
We use nightly builds (a single day without a working build is a huge hit). Getting the framework working so your designers and texturers (and gameplay folks) can start trying stuff in-engine, then fleshing out features. Midding sized time periods (2-4 weeks) between major builds. Unit testing. Though we have to bring in humans to really break it when it's all put together.
Now if you mean Agile with a capital A, then it's not the next big thing, it's just the same bullcrap it was when it was called eXXXtreme Programming. We like to write things down and design a lot of things up front, which clashes with Agile (and don't tell me it doesn't, even with the lip service) - you need at the very least a production bible for large project games to keep everyone together. Parts of the design will sometimes not survive actual implementation and will be tossed, but in general they keep things on track and usually only need some tweaking (everything gets tweaked during playtest time).
If you don't do this sort of thing you end up with http://en.wikipedia.org/wiki/Dungeon_Lords, which is what you get with a Agilely (with a capital A) developed game. It shipped only half complete with no internal cohesion at all and still isn't finished. But the great thing is that you can use your Methodology to justify it all.
As a programmer, I like RUP.
As a project lead, I like RUP.
It has aspects of Agile to it.
The important parts are:
Get the risky stuff addressed early. If DX9 doesn't support bi-pixar multi-shading like it says it does, then it is best to find out early rather than at the end.
Do the work in measurable chunks. That way you know in as little as a month if you are falling behind schedule.
Frequently interact with the users to make sure you are on course. This is the biggest problem with waterfall projects- working 6 months on something and it turns out you made a wrong turn on week 2. And I've seen other programmers do this again and again even with user interaction- they get an idea of what the program should be like in their head and turn off input from reality.
All the documents and crap bother me to and feel like useless makework. At least video game programmers do not have to deal with SOX compliance issues.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Scrum isn't a software engineering method. It is purely a project managment methodogy. That is one if the _key_ differences between Scum and other Agile methods.
They cause a huge mess in communication and a lot of grief for the developers. It also allows the designers to change their minds on a whim - which means that the project keeps stalling.
You're doing it wrong. If desingers don't like something, it gets left to a future sprint. Remove things from a sprint by all means. You can always use the freed up time for something, but don't change things. You do have to be a little pigheaded about the rules, whilst not being totally inflexible where the system is wrong which is a tricky balance but quite possible.
And when you've got a lot of people who need to keep working together, agile methods are useless. It's great for small groups (3-4 people), but don't bother if you've got 150 people, all with complex interdependencies.
You need to simplify the interdependencies, and split into teams of less than 10 people. If team A needs something from team B, then Team A's will have to do something else this sprint.