Agile developers essentially say: We will give you a plan based on what we know today; we will adapt the plan to meet your most critical objective; we will adapt the project and our plans as we both move forward and learn new information; we expect you to understand what you are asking for—that flexibility to adapt to changing business conditions and absolute conformance to original plans are incompatible objectives.
Many traditional planners don’t understand a key concept—you can’t “plan” away uncertainty. Plans are based on what we know at a given point in time. Uncertainty is another way of expressing what we don’t know—about the ends or the means.
For most uncertainties (lack of knowledge) the only way to reduce the uncertainty and gain knowledge is to execute—to do something, to build something, to simulate something—and then get feedback.
Many project management approaches appear to be “plan, plan, plan-do.” Agile approaches are “plan-do-adapt,” “plan-do-adapt.”
Throughout a project, the team is generating new capabilities in the product. They are also generating new knowledge—about the product, the technologies in use, and themselves as a team.
If I were to define a failed project, one of my criteria would certainly be “a project on which no one came up with any better ideas than what was on the initial list of requirements.”
Obviously, though, we can rarely wait twenty years for a system, and so we engage teams. A team of thirty may spend a year (thirty person-years) developing what a lone programmer could have done in twenty. The development cost goes up, but the value of having the application nineteen years earlier justifies the increased cost.
Far too often a plan is reduced to a single date, and all of the assumptions and expectations that led to that date are forgotten.