Forgot your password?
typodupeerror
Programming Games

Game Development In a Post-Agile World 149

Posted by Soulskill
from the slowly-but-surly dept.
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."
This discussion has been archived. No new comments can be posted.

Game Development In a Post-Agile World

Comments Filter:
  • Conclusions (Score:2, Interesting)

    by triorph (992939)
    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 (Score:5, Interesting)

      by FooAtWFU (699187) on Tuesday February 09, 2010 @02:57AM (#31069378) Homepage

      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:Conclusions (Score:4, Insightful)

        by maxwell demon (590494) on Tuesday February 09, 2010 @03:02AM (#31069396) Journal

        moreover, it helps a lot if you actually employ intelligent people who know what they're doing.

        That should be pretty much method-independent.

        • by Kjella (173770)

          That should be pretty much method-independent

          More intelligent and skilled people would always help, but I'm quite sure I'd run a project differently if I had an elite team vs a few skilled and many mediocre developers. The greater imbalance in the team, the less you can rely on "the team" working it out and the more you have to introduce structure like XP or test-driven development or waterfallish specs and designs made by the skilled people.

          • by Cryacin (657549)
            In my experience in corporate and small business software development, Agile vs Non-Agile is actually quite irrelevant. As long as there is a process in place, that is being adhered to and is the right horse for the right course, it works and works quite well.

            The problem is that in a lot of 2 bit organisations, unskilled Development Managers come along and cobble together a frankenstein process, and/or don't enforce it during the execution. What was once an Agile PROCESS, now becomes an AD-HOC MESS.

            When
        • Re:Conclusions (Score:4, Insightful)

          by DamonHD (794830) <d@hd.org> on Tuesday February 09, 2010 @04:42AM (#31069726) Homepage

          Well, no: a completely toxic process-driven scheme will drive away creative and intelligent engineers. So will a completely batty and air-headed and uncontrolled 'agile' scheme. Balance and common sense is vital.

          Rgds

          Damon

          • by Darinbob (1142669)
            If you've got balance and common sense, and intelligent engineers, then the methodology doesn't matter and may even be optional.
            • by DamonHD (794830)

              Agreed, or at least it may be informal.

              The most successful teams I've worked in have all been populated with individuals independently mentally committed to DoingTheRightThing(TM), and formal rules beyond versioned delivery of the end products were rarely needed.

              Rgds

              Damon

          • Someone needs to contact this guy and tell him that his emails are being posted on /.

        • by mcvos (645701)

          moreover, it helps a lot if you actually employ intelligent people who know what they're doing.

          That should be pretty much method-independent.

          It's not. Companies who have everything determined in rigid processes can get more useful out out of idiots than companies that still need to invent lots of things. Companies that have lots of stuff to figure out have a bigger need of smart people instead, and those are also more attractive to smart people, because they get the freedom to use their smarts.

          Some companies prefer cheap programmers over expensive ones.

      • by ultranova (717540)

        it helps a lot if you actually employ intelligent people who know what they're doing.

        But if you hire such people, you have to pay them. If you fire and replace them with the cheapest ones you can find, you can get a big fat bonus, cash in your options, and then blame any lack of quality on incompetent employees.

        I should had been a CEO :).

    • by 91degrees (207121)
      Well, most of the games industry is in love with Scrum. I have met Gwaredd though. He's one of the few people I've met who actually knows about design methdologies.
    • by alberion (1086629)

      Not necessarily,

      I have been working with Agile software development for 3 years now. Delivering working software every 2 or 3 weeks and never had a single day of delay or extra cost. Got extremely satisfied clients.

      Now, it is not a religion, it is not the only and best way to view software development. It is just one tool every project manager must have in his toolbox.

      Always think, does this software that I am building looks more like a building a bridge or like writing a book?

      If you are building a bridge

      • by mmkkbb (816035)

        I have no mod points, but I would like to comment here so I can bookmark this comment for later. That's a very nice simile that I am going to steal!

    • by Angostura (703910)

      I am wondering whether this article is stating it for a fact

      A question that will be answered if you ... read the article. Strangely enough the article sets out fairly clearly what the article sets out.

      Madness, I know.

      • by Miseph (979059)

        You almost had me going there... then I realized what you were really up to. Nobody reads the articles. Ever. You sir deserve to take home some gold at the Trollympics.

    • Re: (Score:3, Insightful)

      by mcvos (645701)

      TFA starts out sounding like idiot drivel with strong anti-agile prejudices caused by bad experiences with bas, expensive consultants. Later on it gets very informative, however. It's not the Agile doesn't work. It's that, depending on your situation, it might not work for you.

      Agile gives programmers freedom. If you've got good programmers, that's a good idea. If your programmers are crap, you're better off restricting their creativity. At least, that's the gist I'm getting from the first half of the articl

    • Agile programming as been around for decades .. someone just wrote a book about it and gave it a name and structure. Which of course, ruined it.
    • Re: (Score:3, Informative)

      by lena_10326 (1100441)

      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 o

      • by Cryacin (657549)
        You are so spot on with burnout.

        At my current company we allow for "just because" time. This can be up to 10% of a developer's time, but even that number is flexible. At the end of someone's "just because" time, the business provides constructive (read constructive) feedback as to whether that time was useful, and why/why not.

        We combat burnout, and we allow for each developer to get some gun slinging time, which is very important for creativity. At the end, they get feedback as to whether it was useful
  • by dhall (1252) on Tuesday February 09, 2010 @02:45AM (#31069340)

    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?

    • by sarahbau (692647)

      I agree. While I've never actually done (professional) game development, it seems like the waterfall model would make more sense for a game.

      • by Hurricane78 (562437) <deleted AT slashdot DOT org> on Tuesday February 09, 2010 @03:09AM (#31069414)

        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. ;)

      • by 91degrees (207121)
        The thing about games is that what looks good in the design doesn't always work in an actual game. You can't determine whether something is fun without creating a sample and playing it. Then you work out how to tweak it to make it work or make it better. You need an iterative approach.

        The "customers" in this case are the designers (and possibly the testers).
      • by MadKeithV (102058)

        it seems like the waterfall model would make more sense for a game.

        Come on people, stop quoting waterfall as a valid model for software development. Even in it's original introduction it was used as an example of a *flawed* model! [wikipedia.org]

        • Re: (Score:2, Interesting)

          by Anonymous Coward

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

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

            I hear you shouldn't chase them either.

    • by hackerjoe (159094) on Tuesday February 09, 2010 @03:39AM (#31069496)

      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.

      • That's how we use it.

        We have milestones up until release. Each milestone has some requirement of where the game will be at.
        We have half a dozen two-week "sprints" each milestone. Each sprint tends to include related work, but it's mainly just a handy way to divide up the time.
        Each sprint has big tasks ("stories" in the speak) in it (estimated in days), divided up between sprints at the start of each milestone and reorganised at each sprint if needed and agreed to.
        Each "story" is broken up into individual ta

    • It really depends on the game and the end goal in mind, and how you want to achieve getting there.

      I've just started this past week with my room mate the idea of a web based RPG. Think Dungeons and dragons with a Pokemon style interface. Anyways, for something like that, there are a lot of aspects to it, basically everything world of warcraft would have, minus the engine.

      So what I have in mind is a mostly agile development. It will initially be released as a stand alone combat system, you have your character

    • Re: (Score:3, Informative)

      by hey! (33014)

      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

      • Anybody with a brain knows that many agile practices don't apply to certain kinds of projects.

        But isn't it management that comes up with the development methods? I forsee issues here.

    • by ukyoCE (106879)

      Iterative style development? Maybe that might work for an MMO where the customers don't mind being permanent beta testers.

      MMOs are definitely a strong case for Agile. MMO worlds and features are always evolving. You can't waterfall a feature for a year, toss it out the door, and then ignore it when it's a flop with the users.

      Using an agile methodology doesn't mean your end-users are beta testers either. The point isn't to implement broken features and test+fix them later, it's to add and improve working features in a timely fashion. If a feature isn't ready for the deadline, you drop that feature and go ahead with your dea

  • by Hurricane78 (562437) <deleted AT slashdot DOT org> on Tuesday February 09, 2010 @03:04AM (#31069404)

    [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.
    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, ...you little fucker?”

    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”. ;)

  • by Animats (122034) on Tuesday February 09, 2010 @03:23AM (#31069448) Homepage

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

    • Re: (Score:3, Interesting)

      by dcollins (135727)

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

      • by hackerjoe (159094)

        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.

        This agrees with my (more recent) experience, but the fact is unless you have your own supply of cash to burn, your money source is going to want milestone deliveries, and probably will not tolerate

        • by Jellybob (597204)

          One of key principles of agile is that you always have deliverable software, which plays right into needing to deliver working software at certain milestones.

          A well run agile project will be delivering software every couple of weeks though, which also means that every couple of weeks you can hand something to the money men, and to play testers. They can then actually play the game, and pick up any major flaws much earlier in the process, making it feasible to actually do something about it.

          I don't know if t

          • by hackerjoe (159094)

            Unfortunately the "always have something deliverable" part is actually one of the least useful parts of Scrum for game development, in my experience.

            The concept is too vague. Any larger game has a quality bar for shipping -- there's no point if it's not at least so good. So saying "deliverable" actually ends up confusing the team; "not completely broken" is what you want to communicate, but the programmers should already be keeping the game runnable. If they weren't doing that, the designers and artists wou

    • by eulernet (1132389)

      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.

      Yes, you are right.
      When a sector becomes mature, a process can be defined.
      But this is because making a movie is very expensive, and much more than creating a video game.
      On the very few games costing more than 10 millions, there is a lot of procedures.

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

      Hum, as an ex-game programmer and a current agile developer, I have to say that you are wrong.

      Writing a game now requires using lots of frameworks (3D engine, controller input, and in some cases AI).

      Using frameworks has nothing to do with agile programming. Not

      • by mcvos (645701)

        Pair programming is the typical example that won't work in game programming.
        Why ? Simply because you cannot afford to write every line of code by two programmers when you write a game.

        Not every line of code, but for some lines it can make a lot of sense to write them in pairs.

    • by b4dc0d3r (1268512)

      Since you're going all general on us... A company I worked for used to tell its customers it was an "Agile" company. It announced "Agility Alliance" partners intended to speed time to market, and develop solutions quickly.

      Internally, a new development process was rolled out that everyone had to follow. It was classic Waterfall with everything renamed. Then they addressed the shortcomings of Waterfall by adding additional planning, documentation, gate reviews, and I forgot what else.

      We're agile, and we ju

    • by elrous0 (869638) *
      Sadly my less catchy "Let's just get together and build this motherfucker" design philosophy lacked the one-word or acronym-based approach needed to ever catch on as an industry buzzword.
    • "Or, in fact, much programming which involves using an existing "framework". "


      Ding ding. If you are using a existing framework, then getting 'experienced' folks (intelligent is subjective and misleading) will have the domain knowledge, hence design is a lower priority from requirements/user stories. And then an Agile process used as a guideline will work out fine as along as management does the due-diligence in planning and getting clear test/success cases from the dev teams.

      Of course all that can ea
  • by LordZardoz (155141) on Tuesday February 09, 2010 @03:30AM (#31069464)

    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 ?

    • Re: (Score:2, Informative)

      by 91degrees (207121)
      Kuju, EA, Ignition, High Moon, Creative Assembly. Probably a few others but the only games company I know that isn't explicitly is Climax.
  • 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 non
    • by 91degrees (207121)
      I can imagine an agile, iterative model being used in-house, at least for some parts.

      This is exactly how it works.
  • 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.

  • I don't know what anything in this thread means.

    ...but I like games.
    • Well, agile programming has done harm to the games industry, and therefore they are now looking for phlegmatic programmers.

    • It's a lot of project management nonsense. Basically, there are a few different ways to manage a software project. The idea is that much like building a house, you can assemble the house in many different ways, and some ways will produce a better house in less time.

      Personally, I think it's all just a bunch of crap. Any carpenter will tell you that you should assemble the walls before you put the roof on. Any programmer will tell you that you need a filesystem driver before you need a resource managem
      • Re: (Score:3, Insightful)

        by Yetihehe (971185)
        It's called Cowboy Coding [wikipedia.org]
        • I find it funny that many put down cowboy coding as an atrocity--worst of the worst sins, but how come many revenue positive startups are built on top of cowboy code? It's because it works if the developers are good and passionate, but if not the code churned out will be a mess of spaghetti. Corporate profitability is priority #1--not code quality. Code quality is probably #3 or #4 on the list.

          • Exactly. Everyone on our team is good at their job. No amount of "waterfall", "agile", or "spiral" is going to prevent bad code from being written by a bad programmer. Everyone has their own workflow, and their own way of thinking. Encouraging everyone to be their best is the way to go.

            The only time that quality is ever sacrificed is when fixing bugs close to a milestone. But as soon as the milestone is over, we generally get a chance to rip out our hacks and do it properly.

            Honestly, I think our
    • by trapnest (1608791)
      I am with this guy. Are you people even speaking english?
    • by RPoet (20693)

      You know, it's about leveraging the curation of your social graph in the hyperpersonal news-stream of the post-2.0 web. I think.

  • by angel'o'sphere (80593) on Tuesday February 09, 2010 @04:38AM (#31069712) Homepage Journal

    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

    • by wrook (134116)

      The problem is that "Agile" as a methodology means almost nothing. We value people over processes, etc, etc. It could be anything.

      I've worked on a couple of very successful XP style projects. One was so successful that it surpassed my wildest expectations. We had good people on the project, but it wasn't much different than other teams I've worked on before. The biggest difference was an interest in the XP practices and a consistent approach to applying them. The more we did it, the more we learned, a

    • Every single thing that is stated as best practice in TDD, XP or Scrum is a very good thing

      Is overcomplicating and mangling your code to conform to the limitations of your testing framework a very good thing?

      • by ukyoCE (106879)

        I assume you're referring to TDD? TDD can be done in many ways, and only the most extreme and (as you said) cumbersome involve testing frameworks or unit testing.

        I've found unit testing to be good for critical and complex back end components that are difficult to test from the front end. But to me, TDD can be as simple as "test each function as you write it to make sure it actually works". You can do it with print statements if you want, whatever works. As long as you don't get to 500,000 lines of code

        • I assume you're referring to TDD? TDD can be done in many ways, and only the most extreme and (as you said) cumbersome involve testing frameworks or unit testing.

          Well, I agree that it's not all there is to TDD, and that was kinda tongue in cheek. I disagree with your assessment of it as "extreme", however. It seems to me that the majority of TDD community are strong proponents of this approach.

          Actually, I don't mind either unit testing or mocking frameworks, the problem is that most existing ones are deficient in that you have to specifically tailor your classes (that is, your API) so that they can be mocked. Examples include no static, no final/sealed, and in C#, v

  • 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.
  • by Aceticon (140883) on Tuesday February 09, 2010 @06:15AM (#31070024)

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

  • 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 com
    • 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.

      IME, places that reject formal processes citing that kind of reason tend have worse results than the worst of the "slavish adherence to inappropriate process" places. Any process should be flexibly applied (generally; there are probably some areas where there are good re

  • Was it ever Agile? (Score:5, Insightful)

    by SharpFang (651121) on Tuesday February 09, 2010 @07:03AM (#31070254) Homepage Journal

    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.

    • Re: (Score:3, Interesting)

      by fusiongyro (55524)

      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

      • Re: (Score:3, Insightful)

        by SharpFang (651121)

        Right methodology for right use.

        Standard Waterfall for a clearly set goal with specific purpose and function, unlikely to evolve, well known and specified.

        Agile if you don't really know where you're going, trying various approaches to see which works, soft metrics like "it should be fun".

        Cleanroom for short code for known and unchangeable specification, where bugs are not acceptable.

        Waterfall is good for business apps. Cleanroom is great for embedded and mission-critical. Agile feels just like the right thi

        • by Deosyne (92713)

          I can't imagine any large scale game being designed by the programmers. That's what designers and producers do; programmers and artists then take the design and make it work on screen as close to the design as possible.

        • by fusiongyro (55524)

          "Waterfall" is a myth [sqablogs.com]. As this article shows, the actual methodology that created the myth was explicitly cyclic, taking a batch of requirements, specifying them, implementing them, testing them and repeating. "Waterfall" has only ever been a straw man to be attacked by agile proponents. It's easy to make people who have no methodology at all feel like they must have been doing waterfall all along, when they weren't.

          Agile might "feel" better for games, but when you have to produce a product that gets presse

  • Orientated. (Score:3, Interesting)

    by ericvids (227598) on Tuesday February 09, 2010 @09:16AM (#31070958)

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

    • by Chapter80 (926879)

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

      A friend of mine from Indiana spent a year in Japan. During the first 3 months, he felt very out of place. Then he got orientated.

  • by Civil_Disobedient (261825) on Tuesday February 09, 2010 @10:40AM (#31071842)

    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.

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

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

Some people have a great ambition: to build something that will last, at least until they've finished building it.

Working...