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.