Making the Case for Agile Without Invented ROI Numbers

When transformation leads prepare a case for agile, the temptation is to reach for a striking number: a percentage improvement in productivity or a multiple on return, borrowed from a vendor slide or a conference talk. It feels persuasive. It is also a trap.

A borrowed statistic cannot be checked against your organization, rarely describes how it was measured, and becomes a promise you will be held to. The first time progress dips, the number turns into evidence against the effort. Finance, audit and skeptical peers know this, which is why honest cases tend to hold up better in front of them.

This guide shows how to build a case for an agile transformation that rests on risk, learning and your own data, with sources you can stand behind.

Why invented numbers backfire

The most authoritative neutral sources are careful about benefits. The U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506) states plainly that "there is no guarantee that Agile development will deliver the full capability more quickly than Waterfall development." The experienced practitioners GAO interviewed for its 2012 report (GAO-12-681) advised organizations to be prepared for difficulties, regression and negative attitudes, because agile is not painless and people may backslide to entrenched methods.

If your case promised a specific gain, every setback looks like failure. If it promised faster learning and better decisions, a setback becomes information.

Frame the case as risk reduction and learning

GAO's guide describes the value of agile in terms leaders already use. Its emphasis on early and continuous delivery of working software, collaboration with customers and adapting to change "helps to limit the chance of continuing to fund a failing program or outdated technology." GAO also notes that information from frequent iterations can help measure progress and let developers respond quickly to customer feedback, reducing technical and programmatic risk.

That is the heart of an honest case: the organization will find out sooner whether its investments are working and can change course before sinking more money into the wrong thing. Most boards and executive teams understand exposure and decision quality better than they trust productivity multipliers.

Anchor the case in your own baseline

Scrum.org's Evidence-Based Management Guide offers a useful vocabulary. It sorts measures into inputs, activities, outputs, outcomes and impacts, and observes that "measuring activities and outputs is easy, while measuring outcomes is difficult." It also proposes four key value areas: current value, unrealized value, time-to-market and ability to innovate.

Use that structure to describe where you are now, with your own data. How long does an approved idea take to reach users? How often do you release? How satisfied are users? How much capacity goes to maintenance and rework instead of new capability? These are facts about your organization, not claims about someone else's.

GAO-12-681 adds a practical rule: identify measurable outcomes, not outputs, of what you want to achieve. Its example is a vision of project outcomes, such as a decrease in processing time by a specific percent in a set time, rather than outputs such as the amount of code produced. Note that such a figure is a target you choose and test, not a result you promise in advance.

State hypotheses, not promises

The Evidence-Based Management Guide describes a hypothesis as a belief that doing something will lead to something else, and an experiment as a test designed to prove or reject it. Write your case in that form.

For example, imagine a hypothetical county benefits office: "We believe that moving the online application team to two-week iterations with weekly user testing will reduce the time from reported problem to fix. We will compare against our current baseline after six months and decide then whether to extend the approach to two more teams."

That statement is specific, measurable and honest. It also gives leadership a clear point at which to decide.

Ask for a bounded decision

Rather than asking for a multi-year commitment up front, ask for a scoped first step, typically a pilot with named outcomes, measures, a budget and a decision date. Be explicit about how results will be judged.

GAO's 2020 review of the Department of Homeland Security (GAO-20-213) shows why. DHS had clarified expected outcomes for its agile transition, such as reduced risk of large, expensive IT failures, but had not tied them to target measures. GAO concluded that without them, DHS would not know whether the transition was achieving its desired results. Among GAO's best practices for agile metrics are establishing and validating metrics early, aligning them with incentives, establishing management commitment and committing to data-driven decision making.

Return on investment is not off the table. GAO-12-681 lists determining value based on customer perception and return on investment, comparing solution value with its cost, as an effective practice. The difference is that you calculate it from your own results as they arrive, rather than asserting it before you start.

Anticipate the hard questions

• What will it cost? Be candid about training, coaching, tools, technical environments and staff time. GAO notes that synchronized environments for frequent releases can be expensive and logistically challenging.
• What happens to oversight? GAO describes modified governance with clearly defined guard rails and a fast-moving process for decisions outside a team's control, and points to demonstrations of working software as touchpoints for oversight bodies.
• How will we know it is working? Name the baseline measures and the review date.
• What if it does not work? Say what you will stop, change or try instead at the decision point.

Key takeaways

• Borrowed or invented ROI figures cannot be verified and become promises that undermine you.
• GAO frames agile's value as reducing the risk of continuing to fund a failing program, not as guaranteed speed.
• Build the case on your own baseline, using outcome measures rather than outputs.
• Write benefits as testable hypotheses with a measure and a decision date.
• Ask for a bounded first step, and calculate return from real results as they arrive.

Sources

• U.S. Government Accountability Office, Agile Assessment Guide: Best Practices for Adoption and Implementation, GAO-24-105506 (reissued December 15, 2023)
• U.S. Government Accountability Office, Software Development: Effective Practices and Federal Challenges in Applying Agile Methods, GAO-12-681 (July 27, 2012)
• U.S. Government Accountability Office, Agile Software Development: DHS Has Made Significant Progress in Implementing Leading Practices, but Needs to Take Additional Actions, GAO-20-213 (June 1, 2020)
• Scrum.org, The Evidence-Based Management Guide (May 2024)