This content is syndicated from Jim Highsmith by Jim Highsmith. To view the original post in full, click here.
To a manager’s question, “How much will project Zebra cost?” The comment, “I don’t know,” is usually an unacceptable (but often the best) response. A more specific answer such as, “Well, somewhere between $2 and $6 million dollars would be rejected in many, if not most, organizations. The project manager who says, “Project Zebra will cost $3.2468 million dollars,” will be hailed as “with it.” Now, everyone knows down deep that this figure is fantasy, but they are comfortable with it because they know 1) there is an off chance it will be right, or 2) it will be wrong (but we can deal with that when the time comes). People seem to be more willing to accept a highly questionable figure, over a range of numbers that delineate the degree of uncertainty.
One of the principles of the Declaration of Inter-dependence (DOI) (www.apln.org) addresses the topic of uncertainty directly, “We expect uncertainty and manage for it through iterations, anticipation, and adaptation.” Your approach to uncertainty must be multi-faceted—no single strategy or practice will be enough.
Having an agile mindset means accepting uncertainty about the future as a way of dealing with the future. Any development effort should be a balance between anticipation (planning based on what we know) and adaptation (responding to what we learn over time). Managers, and teams, need to find the balance point—how much time do we spend investigating requirements, technology, etc. in the beginning of a project versus actually developing product features (working software) and adjusting/adapting to new information as the project unfolds.
Traditional teams attempt to drive out uncertainty by planning and analysis. Agile teams tend to drive out uncertainty by developing working software in small increments and then adjusting. Traditional teams often think they have mitigated much of the uncertainty, when in fact a high degree of uncertainty still remains in the project. Late in the project the uncertainties begin wreaking havoc—and major cost overruns and schedule slips are announced.
Agile teams, on the other hand, often project uncertainty early in the project but become more certain later in the project. Agile project managers are often hard pressed to defend their uncertainty because upper managers are in the “you can be right, and you can be wrong, but don’t be uncertain,” mindset. Dealing positively with uncertainty, being willing to accept that certain things are unknown and unknowable (for now), is a big part of learning to be an agile manager.