Embracing Change

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.


    1. I explain that every day for my product manager. It is a pity that he never will.

      My confidence in the team and the constant deliveries we do is that give me peace of mind to continue always following the same path.

      Nice post.

    2. I like “Any development effort should be a balance between anticipation (planning based on what we know) and adaptation (responding to what we learn over time).”

      Embracing change does not mean ‘everything MUST change or otherwise we are not agile’. When driving I make continuous adjustments to the car to keep it on course, and occasionally some more severe adjustments to avoid unforeseeable obstacles and events. However, if I have not driven the route frequently, I do check a map or ask someone who has to give me directions before I start out.

      If I have high-level knowledge available to me before a project that would provide me with a better initial backlog, not investing a small amount of time to consider it is not sensible.


      Stephen R. Palmer
      Certified Scrum Practitioner, FDD Associate, Coad-Certified Mentor
      http://www.featuredrivendevelopment.com, http://www.nebulon.com, http://www.step-10.com