Revisiting the Business Value of Agile Transformation, Part 2

Today Agile is generally recognized in IT as generating far more business value than previously possible using traditional methods. However, the financial benefits that businesses actually obtain from their investment in Agile fall far short of what potentially could be achieved. In this series we revisit the original white paper “The Business Value of Agile Transformation” in an effort to do away with the IT jargon and domain specific references and help business get the full benefits of their Agile initiatives. We will review each of the six business benefits of Agile transformation and reframe the conversation for the new realm of Business Agility. They are:

  1. Reduced failed project risk
  2. Reduced over-budget and late projects
  3. Reduced waste
  4. Improved return through early and frequent releases
  5. Reduced write-off risk
  6. Higher-quality software with fewer defects

Here, we consider how Agile reduces over-budget and late projects. Read Part 1 on reduced failed project risk here.

Benefit 2: Reduced Over-Budget and Late Projects

Knowledge work is a complex, organic process, which makes it inherently difficult to estimate when it will be complete or how much it will cost. Knowledge work is a creative design process that calls for the integration and development of emergent ideas. This is a different kind of work than, for example, the construction of a house from a detailed blueprint. The ability to predict when the house will be done is easy because there is an exhaustively complete specification to work from and the type of labor needed to build it (drywalling, plumbing, etc.) is highly fungible. That is to say, the variance between how experienced tradesmen will conduct the work and how long it will take is very small. Finally, since the desired outcome is inert and physical in nature, it’s easy to verify that the outcome comports with the specification. Because you can calculate how much time and labor will be needed, you can accurately estimate the cost. Very little design work occurs during house construction: the design work is conducted prior to the construction phase by the architect. For construction projects, the ration of design work to construction work is very low. However with knowledge work in a commercial setting that pattern is reversed.

For example, coding software from software specifications is a design process. The actual construction process begins when the software is compiled and released to production — a tiny fraction of the overall effort. The same pattern holds for any kind of knowledge work. For example, most of the time spent by a management team developing corporate policy is spent in discussions and meetings. This is a design process. The construction process — drafting the policy document — is comparatively trivial. How much time will be needed depends upon how long it takes to reach a consensus. Could be one meeting, could be a year.

The big mistake that organizations have made that result in over-budget and late outcomes is using project management techniques designed for construction on design projects. In software projects, for example, traditional approaches often attempt to predict with precision what will occur a year or more down the road before the project begins. However, with no reliable way to accurately predict the cost or time needed, these estimates are largely unreliable no matter how much effort is expended to develop them. Traditional milestone segmentation of project schedules won’t solve this problem, since there is no way to accurately measure the completeness of project artifacts until late in the project schedule. The result is poor project performance. Projects are either late with overrun budgets or contingency buffers are used to improve estimates at the cost of diluting project outcomes and inflating costs.

Agile methods address these problems in a number of ways:

  • By empirically measuring the time it takes to complete a short increment of delivered work, you can project a fact-based estimate of the time and effort needed to complete the rest of the work. Initially the confidence interval is wide and narrows over the course of the project.
  • By completing all the work necessary to deliver a slice of requirements during the iteration, you can more accurately measure the percent of work completed. The fallibility of the traditional milestone approach is avoided.
  • Continuously re-estimating work over the course of the project encourages the use of the best information available and “truth telling” even if it contradicts initial estimates.
  • Team artifacts such as “definition of done” are used to ensure that all necessary work is completed during each iteration. This also helps makes notoriously abstract knowledge work more concrete.
  • Frequent demos of work in progress (WIP) that depend on visualizations and simulations of outcomes rather than comparatively abstract text make it easier for customers and stakeholder to recognize progress is or is not being made and provide useful feedback that incrementally improves the course and content of the initiative.
  • Shorter release cycles means shorter forecast time horizons, which means more accurate estimates.
  • Because short term estimates can be quickly confirmed they help identify trends early on. This means that schedule and budget problems are forecast early, leaving more time to implement the proper mitigations.
  • Because the first production release is delivered much earlier than would otherwise be possible, the chance of complete failure is dramatically reduced. Early release also provides opportunities to reduce project scope and corresponding costs.

More and more Agile techniques are found to be a better fit for design projects such as software development than traditional methods. What more people are coming to understand is that these techniques will work for any kind of knowledge work. This includes, management teams, marketing teams, digital media content production — you name it. It is not true that collaborative design activities can’t be managed or estimated. You just need to use the right techniques — techniques designed for that express purpose: Agile techniques.

Next up is how Agile reduces waste.


Want to Skip to the Head of the Class?

Download the white paper that started it all. In “The Business Value of Agile Transformation”, SolutionsIQ CEO John Rudd discusses six business benefits that can be measured using traditional financial and production metrics and that are available to any Agile enterprise.

comments powered by Disqus