Sep 162008
 

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.

avatar

Jim Highsmith

Jim Highsmith was the founding director of Cutter Consortium's Agile Product & Project Management practice.

Discussion

  2 Responses to “To Attract Agile Change, Embrace Uncertainty”

  1. Any “traditional” team that claims to have eliminated uncertainty at the start of the project deserves what it gets down the road. Any good “traditional” project starts with estimates with a wide range of values, usually stated as X plus/minus Y percent. X represents what we know at the start, Y reflects what we will learn. If the future is truly uncertain, then Y will start as close to 100% as you can get. As you proceed through the early stages of requirements and technology choices, Y will decline as we know more.

    The question of interest is the value of Y when coding starts. Management will want it low, but the trade-off is indeed how much effort is expended getting to coding, because Management will want that to be as minimal as possible as well. That is the tipping point you refer to, and it applies to any kind of project.

  2. […] on what we know now) and adaptation (responding to what we learn over time).– James Highsmith, Embrace UncertaintyScrum’s Uncertainty Principle is: Customers don’t know what they want until they see it, […]

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(required)

(required)