Revisiting the Business Value of Agile Transformation, Part 1

Carrying the Business Case to the Rest of the Enterprise

Since “The Business Value of Agile Transformation” was first published five years ago, the fact that Agile generates far more business value than was previously possible using traditional methods has become generally recognized — at least in IT. However, it is still the case that the financial benefits that businesses actually obtain from their investment in Agile fall far short of what could be achieved.

One reason for this suboptimal performance is that, even as Agile speeds up software development in IT, upstream and downstream business activities remain mired in outdated business practices. If more business value is not delivered to the end-customer, more business value will not be received in exchange by the business. The solution is to apply Agile methods to eliminate bottlenecks that slow cycle time wherever they occur across the broader value stream. In some cases the worst bottlenecks are not in software development but upstream in product management or downstream in staging to production.

Unfortunately, if the scope of an Agile initiative is limited to a subset of the value stream, the opportunity to globally optimize the value stream is compromised. Although the business case for Agile is better understood in IT than ever before, it is still not well understood in other parts of the business (e.g., product marketing or portfolio management). Furthermore the jargon of IT frequently creates the impression in other parts of the business that they have nothing in common with IT. Consequently what might be accepted as a perfectly valid business case for IT may not seem applicable to others. This makes it all that more difficult to develop an agreement to collaboratively optimize the value stream between the IT and non-IT aspects of the business.

There is a straightforward solution to this dilemma. Lose the IT jargon and domain specific references and speak the lingua franca that is understood across the entire enterprise: money and risk. With this in mind, we will now revisit six business benefits expressed in financial and risk-reduction terms that are obtained through Agile methods and are available to all segments of the business.

  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


Benefit 1: Reduced Failed Project Risk

The purpose of project (alternatively: initiative, program, etc.) management is to reduce risk of failure (or if you are a glass-half-full kind of person, increase likelihood of success). Traditionally we begin with a charter that documents what should be delivered, when it should be delivered, and how much it should cost. The second step is to create a project plan that describes in detail the best approach for delivering the desired outcome that optimally balances cost and risk.

Project risk is managed first and foremost by avoiding deviation from the plan and getting quickly back on track when unplanned deviations occur. When, for whatever reason, a change to a specification or some other element of the plan is desired, a formal change process is used to make absolutely clear that the change is authorized and properly incorporated into the project plan. The change process is a tool that project managers use to control risk. Other risk controls include time and budget buffers added to increase the likelihood that the project will end as planned. There are many many controls designed to reduce different kinds of risks. Although controls reduce local risks, they increase project cost and complexity. Good project managers introduce the controls they need to achieve an acceptable level of risk and no more.

This classical approach to project management works extremely well when it’s very clear what the desired outcome and how to achieve it. For example, building a spec house from a blueprint using standard materials and experienced tradespeople. This approach to project management fits hand in glove with classical financial governance. Funds are approved if and only if a charter and plan exists that makes crystal clear how funds will be spent and the value of the delivered outcome.

However, what happens if you must begin construction without a clear idea of what it is that you are supposed to build and therefore you also are not sure what materials or skills you will need or when you will need them? How can you predict in advance how much it will cost or what it will be worth?

More and more this is the plight that every aspect of the business faces. Increasing business uncertainty means initiatives must begin without clear objectives or the knowledge needed to predict outcomes. Important characteristics of the solution cannot be known in advance and will only emerge as the project unfolds. Unexpected exigencies demand frequent, radical changes to project plans.

Traditional risk controls were designed to keep project plans from changing. Yet we now see that, for projects to succeed, plans must continually adapt to changing conditions. Adding more and more controls won’t reduce fundamental uncertainty, and the increased cost and complexity of additional controls means that, like the heads of the hydra, for every risk you control, new project risks pop up elsewhere in the project. Ironically enough, when conditions are uncertain, traditional risk management often leads to project failure rather than project success. And in today’s business environment when are conditions not uncertain?

No matter if you are in IT, product marketing or some other part of business, Agile mitigates failed project risk by:

  • Reducing risk under conditions of high uncertainty
    • Project Risk Strategy
      The Agile organization can implement a project risk strategy that recognizes that changes to project plans and specifications don’t always increase project risk and often reduce it.
    • Change as Constant
      The organization can reduce the cost of change by allowing, encouraging and anticipating modifications to the specs and plans throughout the project lifecycle.
  • Delivering incremental value
    • Even Failures Yield Value
      Incrementally delivering the outcome over the course of the project allows for value to be received even if the project is ended prematurely. It also allows outcomes to be tested in production to verify their value and improve subsequent efforts.
    • MMF
      By focusing on the minimal marketable feature (MMF), the Agile organization can to deliver something of value as early as possible
    • Highest-Value Features First
      The organization can also focus on delivering the highest-value features first.

Next up is how Agile reduces the incidence of projects delivered late and/or over-budget.

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.