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