Wrong.net

“Plans are nothing.  Planning is everything.” - Dwight D. Eisenhower

One of the common criticisms I see of any kind of agile development (note: agile with a little a, not a capital A) is that people seem to believe that agile development means that you don’t plan, don’t design, and don’t document.

In my opinion, this couldn’t be further from the truth.

In fact, I’d go so far as to say that agile development involves more planning, more design, and more useful documentation than other methodologies.  The key difference is when you do the planning, to what extent, and what information you derive from it.

I’ve worked on projects that planned to the extreme.  There was a gantt chart which specified what you would be doing at 2pm on Thursday.  Now, that’s somewhat okay, except that the Thursday in question was two years into the future.

Let’s come up with a hypothetical example.  Let’s say you’re going to start a brand new Generic Fantasy MMO from scratch.  Do you just start diving in and writing code and making art?  I’d hope not, and I doubt anybody with a brain would suggest that.

You start with planning.  You know you’re going to need art, some levels, some amount of design documentation, and code.

You’ll know you’ll need some areas for people to walk around and swing their swords.  How many?  Well, that’s a function of how large they are, but we’ll say 100 distinct “areas,” where each area is more-or-less self contained.  How will we make them?  In Max or Maya?  A custom tool?  Who will make them?  If designers are doing the layout flow, we probably don’t want to have them use Max, so we’ll need a custom tool.  How will that tool work?  Will it plug together pieces Lego-style?  While it give more freedom, and then allow artists to perform a beautification pass?  How many levels will be inside vs. outside, and how does that impact what tools are needed?  What are the plans for future expansion after release?

Once we have some of these answers, we can start putting together a plan.  Let’s say we want a 50/50 mix of outdoors and indoor areas, so we’ll need relatively strong tools for both.  We want designers to do at least initial layout, and we’re pretty sure we can use a “Lego-brick” approach.  We’ll still need artists to create the bricks.  But, we can start using this knowledge to make a plan for what resource we’ll need, when we’ll need them, and how we can go about putting this thing together.  In this case, we’ll probably need at least one programmer pretty quick, with at least some art time not too long after that to create some sample “bricks” (once we get past the programmer art stage).  We can make a rough guess as to when at least some functionality will be done, and start making sure we have more level designers and artists for when that happens.

And the plan will be wrong.  Period, end of story, no matter what.  Your estimates will be off.  Things will change, your knowledge of the problem will increase, and you will have to adapt.

So, in that case, what’s the point of planning?  In this case, the simple act of planning gave us a good amount of the information that we needed at that moment to make the decisions we needed to, and could make, right then.  It gave us enough information to start making staffing decisions, and helped us define the scope of what we were doing.  It made sure that we thought the problem of “how do we make levels” through, and didn’t miss any major pieces of that particular puzzle.

We didn’t try to nail down too many specific details.  We didn’t say exactly what each dungeon should be, or how we were connecting areas, or anything at all of that nature.  Those are details that are unimportant at this time.  They don’t impact a single thing that we’d do for the next month or so.  So, instead of wasting time arguing about them now, do another planning session in a month (or 2-3 weeks, or whenever), revise the plan as your knowledge has increased, and work from there.

People using agile development (I refuse to use “agile” as a noun or to capitalize it) do plan.  They plan a lot.  They just see the value of planning in the information that comes out of the exercise, not the specific set of dates and requirements.

This seems directly counter to what I’ve seen in BDUF-type organizations.  Plans, in those orgs, tend to focus excessively on the detail level, and actually focus less on the high-level decisions.  In my experience, those are the wrong things to worry about at the beginning of any project.  They’re almost always easy to change, require knowledge you don’t have anyway, and subject to iteration.  Yet, somehow, I see planning documents that focus extensively on these minor details, and merely imply the larger decisions via these details.