Does "being agile" reduce IT cost?

Which truth is to the claim, "using the agile approach could cut banks' IT spending by 20% to 30%" as proposed by BCG and other consulting companies? 

I doubt that it will reduce a single penny in IT spending. Let me explain why.

Perspectives matter

Let me start with a metaphor.

As a hobby gardener, when I buy a new rosebush, I go to the garden shop and I can get one at around €10. It takes me about 1 hour to drive from and to the store and select a bush - and another 2 hours to plant it (hey, nobody said I'm a pro digger - a pro could do it in half an hour!)
Assuming that working time costs €80 per hour, let's compare the Cost of "planting 1 rose bush".
Hobby gardener:  €250.
Professional gardener: 50.

Superficially, you'd obviously turn to the professional gardener to plant your rose then.
Unfortunately, if I want a rose for €50, I would need to hire the gardener - full time.
And that means spending €60k annually on gardening, while I currently spend €1k.

So - it depends. Do you want to run one IT project, or do you want a cost-efficient IT that can deliver a hundred?
If I want only one rose, the professional gardener's cost is a few hundred times higher than the inefficient DIY approach.

As long as you focus exclusively on one project, cost for that one project is all that matters. Looking at IT overall, which constantly and consistently produces value, it's an entirely different story - which we will explore now.

The bottom line

Let's suppose I run an IT organization with 250 people. They cost me €20m in salary every year. Add 1000 servers that cost me €10m in hardware+maintenance every year.

In the past, I was working Waterfall.  How much did I spend? €30m per year. 

Let's say I switch to an agile approach.  How much do I spend? €30m per year.
Now where is the cost reduction? 

Truth is: Bottom line cost doesn't go down. 

Where are my savings? Do I fire people or turn off my servers to reduce cost? 

How agility reduces cost

There are many ways in which an agile organization has lower cost than a traditional organization:

Optimizing the work itself

When people are restructured into cross-functional teams where all people working to bring a feature into production cooperate in close proximity, a lot of activity dissipates. For example, we're no longer organizing a meeting to get information from each other - we just talk. We no longer write detailed specification documents - we collaborate to draft out something that everyone can work with, and then document only that which is needed for posteriority. We don't need to review DSD's any more, as we discuss until everyone has the same understanding. Oh - and since we no longer work based off a dead document, we can talk to the person. We're no longer tormenting our brain, "What did they mean?" - we just ask. And when we turn understanding into executable tests first - we're no longer getting into arguments whether the tester tested the right thing or the developer developed the right thing.

We can save a lot of time by reducing all of this scheduling, coordinating, intermediary documentation, reinventing the wheel and pointless arguments.

Optimize the flow of work

Traditional organizations often create huge batches of work, called "projects" or even "programs". These are intended to be delivered at a certain specified date.
Agilists would cut this batch into small, independent units and purposely descope all but the single one they work on and get that delivered. At best, they wouldn't even let the big furball of undone work accumulate and start working on every single item as soon as it become the highest priority.
By only having one thing to worry about at a time, we save efforts on task switching, status tracking and coordination.
We make work items independent and enable different teams to deliver autonomously. This massively cuts down on coordination overhead as well.

Optimize the content of work

Traditional project contain a lot of things which were considered to be important when the project was defined. Nobody really knows how much these features will actually be used until they went live - i.e., until the project is completed. By default, all project features are "Must-Have" (everything else isn't delivered anyways). A project must deliver the entire scope to be fully successful, so this is what the project manager will ensure.
Studies have shown that a good 50% of software features are "rarely used" or even "never used". Any effort invested into such unused features is burnt money.
As agilists, we would constantly apply the Simplicity principle and start incrementally increasing the value delivered. If the first simple version of the feature isn't even being used, we would stop building and focus on more important things.
We reduce the waste of building useless features.

Optimize value streams

When people can eliminate useless activity, they can deliver more features in the same time. By spending less time on delivering useless features, a higher percentage of developed features will actually help the business. By delivering in small increments instead of big batches, value gets into the hands of business earlier.

Optimize responsiveness

When new information comes up that invalidates old information, in a classic project, we have three options:
1. Ignore the new information. Do another project in the future.
2. Escalate as the project's goals are in danger.
3. Scrap the project and go back to the drawing board.

In environments where new information comes up on a daily basis, it's hard to fix something for months in advance. Many project managers have gone back to option #1, as that's the only way to ever conclude any project under such circumstances. Unfortunately, this means that the business always gets sub-optimal, outdated solutions.
While IT can perform well with this option, business performs terribly.
By reducing the lead and cycle time as well as delivering in smaller, incremental amounts, we reduce the risk that a specific new information devastates whatever we have been working on - and even if that happens, we reduce the loss incurred by incorporating the change.

We become more responsive to change, the main purpose of being agile.



All of this means - IT has a chance to become more efficient and more effective.
Oddly enough, none of this means that IT will be any cheaper.

Conclusion

The math is not "When you're agile, your IT cost goes down". It's "When you're agile, your business ROI goes up".
IT cost cuts are only possible when the organization is in the comfortable situation that they have too many developers and too little things that could be developed - a rather hypothetical stance, as not even corporations like Google or Amazon ever run out of work for developers.

What matters is not how much IT costs. What matters is whether an investment into IT is good. IT should have a high business value. And agility helps a lot there.

Cost - is the wrong focus. ROI is better.