To Attract Agile Change, Embrace Uncertainty

by Jim Highsmith, Director and Fellow

The subtitle of Extreme Programming Explained , Kent Beck’s groundbreaking book, is “Embrace Change.” The full range of behaviors that this seemingly simple phrase can be affect are in fact very far-reaching. Part of this impact can be explained by altering the focus of the phrase to one that is a little, well, fuzzier: embrace uncertainty. In his intriguing talk on the future of agile development at the Agile 2008 conference, David Anderson commented about three outcomes: right, wrong, and uncertain. Of the three, uncertainty, is the hardest to deal with in most organizations. The comment, “I don’t know,” is often an unacceptable response, while it is often the best response.

To a manager’s question, “How much will project Zebra cost?” the answer: “Well, somewhere between $2 and $6 million,” would be rejected in many, if not most, organizations. The project manager who says, “Project Zebra will cost $3.2468 million,” 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 figure that they highly suspect is wrong over a range of numbers that delineate the degree of uncertainty.

Becoming agile means accepting uncertainty about the future as a way of dealing with the future. Any project development effort should be a balance between anticipation (planning based on what we know now) and adaptation (responding to what we learn over time). The critical management decisions are dealing with the balance point — how much time do we spend investigating requirements, technology, and so on, 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. However, traditional teams often think they have mitigated much of the uncertainty, when in fact a high degree of uncertainty remains in the project. They “project” certainty in plans, estimates, and presentations, and upper management becomes comfortable that the project is “on track.” When, late in the project, as the software is actually running (or not), the uncertainties begin wreaking havoc on the project, the team becomes less certain about real progress, and major cost overruns and schedule slips are announced.

Agile teams, on the other hand, often project uncertainty early in the project and 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) are big parts of learning to be an agile manager.