Sunday, August 24, 2008

Agile values - Responding to change over following a plan

“Plans are nothing. Planning is everything” - General Eisenhower.

When the allies stormed the beaches of Normandy in 1944, they had a very detailed plan of attack. This plan led to their assumed victory over Germany before Christmas of that year. That plan was doomed from the start. How could it be otherwise? How could a plan for hundreds of thousands of soldiers, millions of pounds of supplies and thousands of missions all work out according to a plan on paper? Eisenhower knew it wouldn’t. That’s why there were always contingencies. That’s why the allies were always adjusting the plan based on the reality of the emerging battles.

Agile project management follows similar reasoning. A popular misconception about agile is that it doesn’t allow for plans. This isn’t true. Agile focuses on the activity of planning rather than focusing on a fixed plan. A certain amount of knowledge about any project is going to be well known. Just as the allies knew the location of the beaches they were going to land on, a game development project will begin with quite a bit of knowledge about the genre and market targets for the game to be developed. It is necessary to plan for these things and to share that plan. The problem occurs when the planning goes too far. I’ve seen a game design document for a fantasy shooter game that had the bullet count for each of the clip types of every weapon. How can we know how many bullets per clip we should have in a game? Why do we need to plan for that detail before we have the knowledge of what we need? This is an example of the source of problems that detailed plans can create. If the team sticks to the detailed plan, then it won’t be the best game possible. Great game emerge.

The agile approach is to plan for what is known and to execute against what is not known iteratively. In other words, agile is focused on gaining knowledge. If we don’t know how many bullets in a clip or what type of weapons will be the most fun, we don’t try to plan away that uncertainty on paper. We address it head on by building weapons early and learning what is best.

Many elements of a plan are assumptions. We assume the things that we put into a game design document are going to contribute to a hit game. Some of these assumptions are correct, some are not. By implementing and testing these assumptions, we change some of them. We then alter the plan to create a better game.


Mark said...

I don't entirely agree that detail should be just "left out" of design documents and "discovered" as you go. Sometimes, there are details that can be very *very* important to underlying technology. I do agree that things like how many bullets per clip should be *open* to change but that doesn't mean you can't put a "first guess" in the design doc. Maybe I'm unique among programmers but when I see "fuzzy" phrases like, "energy weapons should have some ammo in each clip" that stresses me out. "Some" ammo? How much? 10? 50? 10,000? 30,000,000? While programming I'm thinking about other things, like what kind of variable should I use to store this value. An ammo value of 10 or 10,000,000 can make a big difference.

I agree, don't stick to the plan just for the sake of sticking to the plan. But don't avoid even *trying* to plan those things out in the first place.

Clinton Keith said...

You raise some great points that I should clarify. I entirely agree that you shouldn't begin coding anything without requirements!

Documents aren't meant to replace conversation, but they often do. They are poor at communicating intent as well. Take the example of the clip. A designer might well guess that 50 is a good starting place and want to try that first. How does that get communicated in a document as a vague idea? Also, is the designer able to think over every possible requirement in the document up front? What about the ideas that he wants to discard?

The agile approach is to address the detail as "late as you responsibly can". This could take the form of a user story written in the release planning or even a conversation before the Sprint started.

Conversation is the key. Documents should not replace conversation. They should be a placeholder for future conversation in areas where there is uncertainty or change.

I know leaving uncertainty out concerns programmers that want to create architecture. This is where we could talk about XP. XP supports the creation of code that is easily changed as you discover value. Many programmers demand detail, even wrong detail, to code and they write code which is expensive to change. XP addresses this.