Search

Categories

Agile Game Development: Does it really work?

I was reading this article? Agile Game Development: Dealing with Chaos in the Real World. Unfortunately it’s a set of powerpoint slides instead of an actual talk or article so a ton of details are missing. Even reading all the books on the reading list at the end won’t answer most questions because the questions we want answered are about game development and those books generally about business custom solution development.

I’ve read a little about Agile Development and Scrum and both of them sound very cool. I like the ideas of the short (15 mins or less) morning meetings where everyone says if they met their goal for the previous day and makes the promises today of what they will get done. Also the 30 day goals sound cool too. But that still brings up a host of issues.

Randomly off the top of my head:

  • In the daily short meetings, would it not be in most people’s interest to make the weakest promise possible? How is this over come or is it a real issue? Maybe people jump to the challenge.
  • What does TDD stand for?
  • Pair programming. This is one of those huge leaps of faith. I’m sure those doing pair programming “get it” but as someone that hasn’t done it my experience so far has basically been “hire good people and you’ll get good code”. I can’t imagine any of the teams I’ve been on so far would have worked better or been as efficient with pair programming. Maybe my teams were special? Or, am I just deluding myself?
  • Unit testing. I’ve seen lots of reference to always debugging your code, putting in lots of asserts etc and I do some of this. But at the same time bugs have never been that big of an issue on any teams I’ve worked on. Sure there’s a large list of bugs to fix come alpha or beta but it’s always been factored into the schedule, be at beta 1-2 months before shipping and we’ve always managed to get the bugs out. Have we just been lucky? Is 50% to 70% of my code being tests and therefore 50% to 70% of my time going to writing tests vs moving ahead going to really end up being more productive?

    Of course maybe I already write some of those tests. Certainly in the past there has been some not insignificant amount of work at making what I do visual for debugging and all that visualness get’s removed for shipping. (showing collisions or A.I. paths or what areas a character is looking at, etc. etc.)

  • Can I even do pair programming? For some reason, part of my personality, I can’t type when someone is watching me. Maybe if I did it everyday for several hours a day I’d get used to it. For any of the people that have tried pair programming, did any of them have this problem? Did they over come it? It’s like I probably type 80-120 words a minute when no one is watching but I type like 20 when someone is.
  • How about getting used to people’s style? For me, when I’ve watched over someone else’s shoulder it’s come to the point where I just don’t look until they are done typing because at each moment my mind expects them to type what I would type the way I would type it and it makes me nuts to watch them do it a different way. To give an example from car driving, when I drive I generally drive pretty conscientiously. A specific example is when I’m a mile or so from the off ramp I need to take on a freeway I’ll get in the lane I need to be in. I have another friend what pretty much always waits until the absolute last second to make that lane change to the point where he’s actually missed stops a few times. When I’m in the car with him, once we’ve passed the point where I would have gotten into the correct lane I start getting fidgitty wondering when he’s going to get to it. My solution has been to just close my eyes and let him take care of it. We get there one way or another and I get less stress. Well, watching someone else type code stresses me out about the same way. Once it’s done it’s no problem to look at it but watching them drive makes me nuts.
  • I’d really like to see if not a detailed plan a detailed history of what happened during an Agile project. Maybe even down to the minutes for a few daily meetings. What was the goal setting meeting like? Are there any classes that teach this stuff I can attend that actually give experience participating vs just reading about it? Are there any classes that deal with GAME development and not the typical unrelated to games programmer only business app development?
  • I’m skeptical as well. Those books and ideas are written for custom business solution development which is the #1 type of development. Most of the time the ideas in those kinds of books are not applicable to games. Making a game is rarely about meeting a functional spec. It’s about making something that is fun and visually appealing, two things you can’t put in a spec. Agile’s fast, short sub-goals sound like they’d be closer to game development than most advice from those kinds of books but then again. Maybe they aren’t

    Or, maybe there are two distinct parts to game development. Let’s call them pre-production and production. Does Agile work for pre-production? Coming up with ideas, testing new tech, trying out game play ideas etc or does it just work on production?

  • Does Agile development actually meet deadlines? I’m probably remembering poorly but I thought I read somewhere that Agile development is not about actually meeting deadlines. It’s about realizing there is no deadline, only changing specs and feature creep and so instead of setting a real deadline you just try in each sprint to meet a particular smaller goal in an organized way and believing that by doing so you’ll get closer to getting everything done faster than if you didn’t do it this way. As well, you’ll be able to respond to changing conditions. That might work in custom business apps since the business is already functioning without your app so if you are late a month or more people just won’t be as efficient as you had hoped but they can still keep doing business the way they’ve been doing it. Not meeting your deadline in games means missing Christmas, missing your Adverising schedule, missing your E3 demo etc.

    Anyway, I really would like to try it. It actually sounds like it could be fun in that it sounds like it would be easier to feel like you actually accomplished your goals since they are short term instead of always feeling that maybe we’ll miss the deadline that’s 6-18 months off. That in itself would be a huge plus to just feel less pressure and be able to concentrate on smaller things.

    • Mike
      TDD

      Sorry to bump an ancient post, but in case you never found out:

      TDD = Technical Design Document

    • Don
      Test-Driven Development

      TDD = Technical Design Document may well be true, but it’s just acronym overload.

      In the context of Agile software development, TDD means Test-Driven Development. See Kent Beck’s book by that title.

    • JaredQuinert
      The games shops I worked at were somewhat agile (before big-A Agile)…

      Good games development feels quite agile.  The product evolves iteratively, builds are frequent.  The uncertainty of knowing exactly what will make a succesful consumer product means that prescriptive/predictive methods are not usually the best idea.  I don’t think there is a huge mismatch between the agile values and the way in which I have experienced games are developed.

      I’m sure it can be applied, but be aware that agile is not just extreme programming.  Think about what problems you have, and how you might work together as a team to deliver software more effectively.  Decide whether the agile values work for you.  If so, look at the various agile methods and their practices, then see if any of those practices might solve a problem that your team has.

    • Rory

      TDD actually stands for Test Driven Development. It’s a technique for developing code where you write tests first, then write the minimum code needed to make the tests pass. Sounds like hell at first, but it can be incredibly useful. Check out the GDC talks this year for Noel talking specifically about TDD