One of the touted benefits of agile development is better early information on project problems and issues. This early detection enables management — project and otherwise — to take adaptive actions. However, early problem detection comes with its own problem — discomfort with early information. In waterfall projects management and staff are used to getting information about problems late. This leads to a perception that projects are typically on-track until late in the lifecycle. In fact, the lack of working software until late in the project provides a false sense of progress. Because coding and testing come late in waterfall projects, they “appear” to be in good shape — until the end when the project falls apart.

However, managers still perceive that projects should be, “on-track” early and “off-track” late. Agile projects flip that perception since they are often “off-track” early and “on-track” late. This flip is disconcerting because it is different from prior experience. Even though rationally it seems better to uncover problems earlier, the variation from historical norms is still disconcerting and it takes time to adjust.

One reason for being disconcerting is that management has to face the reality of wish-based planning early. It is much easier to create a traditional plan to “hide” the fact that the plan is undoable. Agile plans tend to expose unsupportable “wishes” early. Planning to actual capacity (capacity-based planning) is often a sobering experience because much less can be accomplished than early guestimates assume.

Agile management is the “art” of balancing. Early problems and issues can be the result of inadequate planning or the result of uncovering new information in early iterations. Traditional project plans are deterministic, they exude confidence. Misplaced confidence, but confidence none-the-less. Agile plans, especially early ones, exude uncertainty — they point out explicitly where potential problems lie — and plan to examine those problems early. A “confidence” profile of a waterfall project starts off high, remains high through early periods as requirements are and designs are documented, and then begins to falter as coding and testing begin exposing problems. In contrast, the “confidence” profile of an agile project is lower early in the project but then increases slowly and then more rapidly over the course of the project as features are built and tested and high risk areas are mitigated.

avatar

Jim Highsmith

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

Discussion

  2 Responses to “The Early Problem Problem”

  1. Yes this is a problem in companies new to agile.
    Especially in large corporations that typically have a more blaming culture.

    I have felt a lot of times being punished for being open about small problems.
    Nevertheless I think it is the right thing to do.
    But it is important for the agile coahes that have acces to higher management to explain this upfront.

  2. Very nice frameup.

    Those who’ve rolled around in the construction of software for a long time are generally comfortable with the view of a project as a process to drive uncertainty from 100% to 0% over period of time by building something.

    Those who have been victimized by custom software creation (to often our stakeholders and patrons) tend to demand certainty too early as a risk mitigation strategy. Only too willing to please, many teams capitulate by creating the facade of certainty (e.g., detailed project plans). It’s easy to understand why.

    Stakeholders who don’t like uncertainty want to DO something about it. In reality the only thing to do is to begin the real work of the project. But, all too often, the unfamiliar stakeholders demand more planning. Which only exacerbates the problem. The facade exists as an artificial way to create time and space from the stakeholders.

    That is, we have done this to ourselves. This behavior seems to fit Tom Demarco’s explanation of an addiction: a behavior that in the short term mitigates pain, but in the long term only makes the situation worse.

    It would behoove us to educate our stakeholders that it is the job of the project to reduce uncertainty by delivering something often. And to live by the words of that apocryphal general “the only thing worse than bad news is bad news late.”

 Leave a Reply

(required)

(required)

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=""> <strike> <strong>