I once overheard an interesting conversation during a governance meeting with a global pharmaceutical client I was working with. The organization had recently embarked on an agile transformation program. The CEO said to the CIO, "So this agile transformation is costing us a lot of money. When will I see a return on this, and how do I know our money is being better spent?"

The CIO replied, "We can release every two weeks, and we're not putting features in that people don't want. Is that good enough return for you?"

I thought the CEO’s question was a fair one and one that gets asked all the time. The benefits of adopting agile practices can sometimes seem intangible, and people naturally want to know if things are improving.

We all know agile is better...don’t we? It can help deliver things to the customer earlier and more often, increase quality and customer satisfaction, foster happier teams, blah blah blah. These things are good, and together they can make a compelling argument—but what about the bottom line stuff? What about the no-nonsense questions that executives and customers want to hear about?

One question that I hear a lot is “Is agile cheaper?” For the purposes of this question we can assume “cheaper” means that a project can be completed with the same or smaller amount of people for the same or shorter length of time.

Now, consider this more specific interpretation of the following question: “If we have a software product with a known and unchanging scope and all other things are equal, will it be cheaper to deliver the product in its entirety using an agile methodology rather than using waterfall?” The short answer to this question is no. Agile has, especially with Scrum, a degree of ceremony, and in this make-believe scenario that would get in the way of pure analysis, design, build, test, etc. As you can see, this degree of ceremony would slow things down, hence making a project more expensive.

Thankfully, the interpretation of the question is wrong—or rather, it’s attempting to make a comparison that doesn’t exist in the real world. The cost/value mix for a product developed using waterfall could be very different when the same product is delivered using agile methods.

To explain this a little more, let’s dissect the following section of the question; “…with a known and unchanging scope…” The comparison is assuming the scope would be the same for each development approach, but who knows the scope? No one really. We might think we know the scope up front, but how many projects have you seen where the end-product scope was exactly the same as the original scope specified at the beginning of the project?

Let’s look at another section of the question: “… will it be cheaper to deliver the product in its entirety…” Agile is about delivering a product in valuable chunks as quickly as possible, so there’s not really a concept of “entirety;” agile focuses on delivering a valuable chunk, making adjustments, and then delivering another chunk.

So comparing waterfall with agile is like comparing apples with oranges. This is because following agile principles and processes would, in my opinion, nearly always generate a different product than if the same business need was addressed using a waterfall-type methodology. In other words, you’re more likely to build the product the customer really needs with agile, whether or not the customer knew what he wanted at the start. Even when product requirements are quite predictable and lots is known at the beginning, in my experience there is nearly always some parts of the scope that can be considered waste or their value is not worth the cost of delivering. Agile’s relentless focus on business value and just-enough-work identifies this waste—or poor return of investment (ROI) requirements—and gives the team the opportunity to change it or leave it out all together.

The Standish Group research on IT project success and failure rates (Jim Johnson. The Standish Group International Inc. 2002) states that when requirements are specified early in the lifecycle, 80 percent of the functionality is relatively unwanted by users. The report goes on to say that 45 percent of features are never used, 19 percent are rarely used, and 16 percent are sometimes used.

With this in mind, perhaps we can re-frame the question posed at the beginning of this article to make it more applicable to the real world: “For a specific business need, will following agile principles and processes enable us to develop a product that meets those needs (no more, no less) more cheaply than if following a waterfall type methodology?”

In this case the answer is “Yes, absolutely!”

So agile economics work, and we haven’t even talked about cost of delay or increased ROI yet, save for another time. Following agile principles can save money, and—more importantly—it helps spend the money you do have more wisely.