Manager In A Strange Land: How Much Planning?

(For anyone awaiting my article on "Drag" and wondering why I took the time to write this instead...this is actually an article I wrote a while ago and never got around to posting.)

"A good plan, violently executed now, is better than a perfect plan next week." - Patton

“Plans are worthless, planning is indispensable.” — Eisenhower

Are these two quotes contradictory?  Eisenhower seems to want to continue planning (even though he knows he'll throw that plan away later) whereas Patton wants to quit planning today and do something.  When you think about the quotes long enough they become tautological.  "We should plan until our plan is good enough."  Duh.  But how long does it take to get to a good enough plan?  How do we recognize a good enough plan?  To be more precise, where's the crossover?  How do you know if that extra hour spent planning is going to save you an hour down the road?

Back in the waterfall days, we'd spend the first milestone on "the plan" - and the outcome of that would be the rest of our milestones.  (And we thought we had it good because it meant we didn't have to actually do anything real for the first milestone.)  It was actually pretty easy to justify this to the publisher.  (And it didn't seem to matter if it was a nine month project or an eighteen month one--never tried it for a twenty-four month or longer project--you'd get that first month to plan.)  Some of the least succesful projects I've worked on resulted from this:  Draconus and a Nascar racing game that never saw the light of day, to name two.  So, from my anecdotal evidence, a month of planning without coding is the wrong amount. 

Did we need more or less? 

The successful projects (these projects were only qualified successes, to be sure - I've only worked on one project that was an unqualified success - hit time, budget, scope, and 90%+ on gamerankings) I've worked on had a lot less.  Typically we couldn't wait to get started coding, and documents were often an afterthought to either explain what we'd already done or talk about where we'd go from there.

In *Agile Software Development With Scrum* they talk about how Scrum can be seen as a Kuhnian phenomenon.  I haven't the foggiest what they're talking about, but I do have a very vague, layman's knowledge of the Hegelian dialectic.  (Recently refreshed from watching the movie *Half Nelson*.)

People typically think of agile and Scrum as being the antithesis of Waterfall.  I disagree.  Rather, Waterfall is the antithesis of "dive in and code".  The thesis:  we should dive in there and start coding!  The antithesis:  we should plan every detail - we need to gather requirements and model in UML and flow charts and write all of our header files before we write the actual .c files and blah blah blah.  Synthesis:  Scrum - we should spend *two days* (one day on the project, one day on the first iteration) planning the project.  From then on, we should spend one or two days planning for each eighteen - nineteen coding.  (And on a project with more than ten people, we should spend one day planning the macroproject and then each subteam should spend a day on their dish.)  And we may want to stop and do a little side-planning here or there along the way - we'll see.  A plan, as far as Scrum is concerned, is a list of requirements with somewhere from a sentence to a paragraph describing each one - they fit on file cards.  Accompanied by wild-ass-guesses for how long each of these things are going to take.  And we'll probably forget a bunch, and that's okay.

Compared to some projects that consider themselves agile, that's actually a lot of planning.  To be honest, that is more planning than has gone into some of my "successful" projects.  Maybe those successful projects could have been even more successful.

It looks like Clinton Keith wants more planning these days.  What he proposes isn't a Gantt chart per se but it's damn close. I'm not crazy about Gantt charts. (Check it out; I spelled it right this time.) It looks to me like he's feeling the pull to Plan More.

And speaking of arguing for More Planning, we have Joel Spolsky. 

But I'm going to put my foot down and say, "No.  Enough planning."  I think Clinton's hearing the siren song of the Gantt chart because game development projects always suck, and you look for causes, and one cause, if you're not doing much planning, might be "we're not planning enough." Post hoc ergo propter hoc. But like Ken Schwaber says, you quickly hit very diminishing returns when you spend more time scheduling/planning - and we should just accept that we're going to be wildly inaccurate and get on with it.

As for Joel Spolsky, maybe spending two months designing makes sense for products like FogBugz and CityDesk...because iterating with on-paper design with those projects actually might make the designs better.  But, since games are more complex systems, and systems are notoriously unpredictable even to the seasoned designer, if you spend two months designing your game while I spend one day designing out of every ten coding, my final design is going to be six iterations better than my first design but your final design - well, it's practically a coin toss whether it's going to be better or worse than your first design.

Let's take some of the games I've worked on...

Die By The Sword - very little planning, though what first got me onboard with the project was seeing a map they'd made on paper for one of the combat arenas; back then I was sick of the cowboy mentality and wanted to see more BDUF;  of course, we rebooted the project partway through and turned it from a fighting game to an explore-a-dungeon-beating-things-up-along-the-way game, and that arena got thrown out.  In a way, though, we stumbled upon Cerny's method - taking almost a year to make that awesome first level, our "prototype / vertical-slice" - and doing lots of kleenex testing on the way there.  It slipped twice but was a great game.  (Sure, only 75 on gamerankings, but I'm convinced it would be higher if gamerankings existed when we shipped.  5 stars in Next Gen, for example!)

Draconus - Draconus was the closest I've come in my career to doing full waterfall.  We had a giant whiteboard in Pete's room with our UML diagrams.  We had big design documents that we argued about in long meetings.  We did research on state-of-the-art approaches before writing our highly abstract code.  Also one of the most troubled games of my career - the original publisher dropped it and another publisher picked it up but only wanted to give us nine months to finish - cancel the network play and the this and the that and the other thing, but do it for the Dreamcast instead of the PC.  All that BDUF thrown out. We were six months late, and only got 70 on gamerankings.

So, for Spider-Man 1, we backflipped.  Just get in there and make some levels, damn it!  More planning would have helped.

Spider-Man 2 had almost the right amount.  Could have used just a tad more.  In the beginning, we'd spend mornings designing while we spent afternoons coding - but it wasn't long before we were sketching a level on a napkin and then spending a month or two of implementation to make it as good as we could.  20 page design doc;  continually evolving table of what all the controls on the gamepad did;  map of the city...

And Spider-Man 3 I think had too much, though that's supposition because I wasn't around for most of the project.  Although it wasn't even close to full waterfall, in the early days we did a sort of waterfall with the individual levels - first described in text by the designer and then isometric concept art made by the concept artist and then a meeting in front of a lot of people where the designer presents and defends the design - and we'd typically find that the level they drew on paper was the level that got made and it would get kinda stuck that way.  One of the reasons we were doing more planning was because a cross-studio Activision consultant came by with the level design docs from Infinity Ward and said, "Look, here's how our best studio makes their game.  Why don't you do it like this?"  So we did.  Later I mentioned that we borrowed the "Infinity Ward method" to one of the Infinity Ward guys and he said, yeah, they don't do it that way anymore, because the junior designers would would keep making crappy levels and then the senior designers would ask why they weren't fun and the junior designers would say they just implemented what was in the doc.  (This was a couple years ago, so I don't know what Infinity Ward does now or did for CoD4.)

That's a key thing with game levels - you don't know how fun they are until you build them.  And if you make your sketch too detailed, if you make it more of a blueprint than a sketch, people are going to model that detail right into the level and there's going to be resistance to changing it later.

So - how much planning?  Here's what I think:

Small team, downloadable game, no need to hit a specific ship date:  almost none.

Console action game:  20-page design doc;  story outline first - script and game evolve simultaneously;  levels sketched (but not blueprinted!) right before they're built.  In the early days, split your time between planning and implementing.  In the later days, fall back to one day of planning for every ten - twenty implementing.

RPG:  more, but I don't know how much more, because I haven't made one since 1993.

MMORPG:  still more, but again I don't know.  Damion Schubert's the guy to go to for this.

Comments

[Peter Bessman]

This a pretty chaotic post, in the sense that it lacks a coherent, take-away message of "this is the one thing you need to do." Which leads me to believe it's probably right (or less wrong than average). Obligatory Fred Brooks quote: "there is no silver bullet."

My team is firmly in the "almost no planning required" category, which means we're a small, broke startup. While that's traditionally thought of as a curse, given how much established companies seem to struggle with the nightmare of managing big projects, perhaps there's also a blessing in there somewhere.

[Jare]

The more you can iterate, the less you need to plan. Conversely, the less you can iterate, the more you need to plan. You need at least enough planning to have some breakdown of production areas, estimations of resources and costs, and a good idea of the dependencies.

All of those will help you figure out your balance of plan / iteration in different areas. For example, you will rely on iteration for things like player control, and you will need some hard plans for voiceover recording or outsourced art.

[Pag]

Don't you need planning for the higher level ideas though? Iterations work great for low-level features that can be implemented and tweaked relatively easily: controls, enemy AI, etc. But you can't really iterate on high-level concepts. Sid Meier's dinosaurs game died after a while and as I understand it, they still weren't sure if the game would be turn-based or real-time -- that can't have helped production.

Basically, how do you balance the need for a clear overarching vision and the need for flexibility during development?

[Clinton Keith]

Hi Jamie,

Good post.

Actually I wasn't proposing more planning outside of the sprint, but more coordination of hand-offs within a sprint.

Scrum practices were developed for groups of programmers (with an occasionally UI artist), so it's not surprising that there is some weakness in the Sprint planning when you have 2 designers, 3 artists and a few programmers making up a feature team.

Also, note that this burndown was proposed and tried by our team alone. As it turns out, we abandoned this practice in favor of having weekly reviews during the sprint, within the team, where we could deal with all the dependencies. Much better solution.

Gantt charts are evil for long term planning!

Cheers,
Clint

[Merus]

To be fair to Spolsky, he recognises that some of his advice doesn't apply to games - he mentions somewhere that games don't usually get the luxury of a throwaway version 1, which changes the assumptions enough about design that his advice doesn't really apply. Games almost certainly need to iterate more than regular software - but at the same time there's some really expensive asset requirements that it doesn't make sense to iterate on, so clearly there's some sort of forward planning that needs to go on.

[TimL]

Lots in here to take in so I'll only point out one small takeaway that I think is a wonderful point that needs to be made more often. "Agile is not the antithesis of Waterfall." I'm personally tired of people seeing Agile as the silver bullet (and hero to Waterfall's villain) of the day (in whatever literal form they mean it to be in: i.e. specifically SCRUM, etc.). There is so much more to it than just abandoning the "old way" of Waterfall and adopting Agile as the solution. As much as I am a defender of an Agile mentality I always hesitate when getting into the ring for it because Waterfall still has it's place. Thanks for going out on a limb on that one Jamie.