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.

Three statements separating poor and great leaders

Many people think they are great, but when push comes to shove, they succumb to fear - and avoid doing the very thing that would be required for others to move forward. This applies to workers and managers alike - it's everyday leadership that we should all exhibit, or, as Tobias Mayer coined the term - it's merely "thoughtful citizenship".
Here are three statements that many leaders might be too afraid to state:

I don't know

Smart people can easily come up with a plan or explanation which sounds so feasible that others will nod in appreciation. People with high charisma can make others believe even the most ludicrous things, such as for example: "clouds are actually giant, floating marshmallows".
This is very dangerous, as there is a huge potential of leading people on rabbit chases, and in extreme cases - even on witch hunts against those who disagree. The more respect a person receives, the more ready they should be able to state, "I don't know". Prominent leaders exercise great caution when making claims or providing instructions, as they have experience that a statement affecting many people can lead to massive problems, even when made from the best intentions.

I was wrong

"Hindsight 20/20". It's easy to be wise after the event. Statements about the future are always subject to error. Great leaders know this, and when they discover a dead end, they should be the first to pronounce, "I was wrong, we can't go on like this." Similarly, when they haven't seen the problem by themselves and are made aware by others, the three words will be like a rain of relief after a scorching summer: "I was wrong." - no lingering, no justification. Just closure. This open the door to progress. It frees others to go on.

I need help

Many people feel that exposing vulnerability is a sign of weakness, something that can and will be used against them. Great leaders don't care about weakness as much as about strength. Instead of saying, "I can't do this" - they say, "I need your help to do this!", knowing full well that everybody is good at something else.

In some cases, they will even ask others from help not because of their own need - they do this in order for them to grow and build them up! 

Summary

"I was wrong." - "I don't know" - "I need your help." 

These three sentences sound like they describe a weak person, even though saying these three things requires an incredible amount of courage. A person using these three sentences when appropriate displays massive strength of character and integrity. On the other hand, a person too afraid to speak these simple words when needed isn't worth following.

Do you have the courage to stand in front of your team, your company - even your own family - and say these words?

What consequences do you expect when you utter them?

How agile coaching changed me

When I actively started going into the direction of coaching, I was a typical consultant. In short: Do as requested, give the customer what they asked, play by the rules - help wherever possible, and be a nice person overall. All of that has changed. I will use Dungeons and Dragon's "Alignment Model" to explain what, how and why. To avoid confusion, remember that this is a model, not a religious view. The terminology is set like this simply because I'm copying a pre-existent model!

This is a rather personal post, I neither expect you to agree with my position, nor to adopt it. I created this post to encourage you to reflect on your own outlook at life with this model.

The model

One can sink quite a bit of time into this model, so I'll keep it short:

On the "Stance" Y-axis is the distinction between "the belief that everything should follow an order, and that obeying rules is the natural way of life" (lawful), as opposed to "the belief that life is random, and that chance and luck rule the world" ("chaotic).

On the "Morality" X-axis is the distinction between the belief that one should put the benefit of others before oneself ("good") and the belief that one can take advantage of others for one's own benefit ("evil").

The "Neutral" middle ground in either direction is a respectful attitude without any form of compulsion in either direction.
From a structural perspective, it means that law has advantages and disadvantages, and while order is often preferrable, it is neither attainable nor unconditionally desirable.
From a moral perspective, it is a stance that helping others is preferable to harming others, yet taking care of oneself and those with a close relationship is more important.

My journey

The past

For most of the past ten years, my behaviour could have been described as "Lawful Good" in the model.

My stance
I used to believe in explicitly defined structures and processes. I supported organizations and managers in optimizing their structure, defined rules, created process charters, developed and conducted change initiatives. I monitored and enforced the adherence to plan, structure and rules. It was my duty.
That's "Lawful".


My moral attitude
I always believed that I must help others and that my contribution is important. Is that bad? No - and yes. I made thousands of hours of overtime to help projects and help my company succeed. I didn't have time for friends or family. I neglected those who should have mattered to me in order to help others. Help them succeed, help them earn money, help them advance their career.
That's "Good".

The journey

As I started the coaching journey, I already had some issues with Scrum and the ScrumAlliance's moral setup. But because my company wanted me to become a CEC, I tagged along, so I applied. I got rejected, but that's a story I already told.

How my stance changed

As coach, I learned that it was the structures, processes and rules which destroyed the productivity of intelligent people in so many different ways. For example, developers are forced to commit to plans that can't possibly work out, they are expected to make a forecast on the Unknown - and they are entrenched with processes which forbid them to do the right thing.

I learned that neither is structure always helpful, nor does predictability always exist, and there's no way we can correct that once for all.

There was a short time when I resented and loathed hierarchy and structure, but it was a phase. I have become agnostic to those things, seeing both ups and downs.

I came to accept that we can't know upfront whether the rules we're following are helping or hindering, and rules themselves can lead to both good and evil: One can't be good and support evil rules.

I learned that a "Lawful" stance can achieve the opposite of what it is meant to do.
I have taken a "Neutral" stance ever since, being much more wary of the impact a rule might have.

How my moral attitude changed

Through reflection, I came to realize so many things:

First, that "well meant is the opposite of well done", aka. "The road to hell is paved with good intentions" - I had no way of knowing whether the help I provided was actually achieving its purpose. Too many times, things happened such as misguided transparency bringing people into trouble, well-meant processes misfiring and causing damage yada yada.

And the worst part - the people whom I helped and for whom I sacrificed so much were, for the most part, evil (based on this model). Not evil like Dr. Mabuse or Hannibal Lecter - but they hired and exploited me as well as others for their own benefit. The systems I created exploited many for the benefit of a few. And I let it happen!

Being good doesn't mean the outcome is good.

I have since learned that trying to help others is a double-edged sword. I have taken a "Neutral" attitude, dropping the concept that doing things for others is better than enabling them to do things on their own.

That's me

I classify myself as "True Neutral" in the D+D model, and I'm proud of having come there. I am no longer under a compulsion to do something for others, and have become unwilling to further an "evil motive", as in letting others take advantage or oppress me.

I can appreciate beneficial rules and structures without losing my freedom to scrutinize anything that I disagree with. I accept that we can't control the future, and understand that tremendous harm can be caused by trying to create a "perfect system". While I have no problem with ambiguity and uncertainty, I understand the fears of people who prefer to be stuck in a bad structure towards having no structure.

I can positively respect both Lawful and Chaotic people, I can get along with both Good and Evil people, but I don't have to be like them or support their cause. I prefer a good environment over an evil environment, but I won't go on a crusade to make it the way I think it should be. Instead, I will seek balance with my environment and harmony with the people around me. 

I work to help others gain a deeper understanding of their situation, so that they can freely choose to take whichever course of action they consider most suitable. At the same time, I reserve my right to not join them on a course I personally disapprove.

I am "True Neutral".

The "Technical Triangle" of Effort Distribution

"The TQB Iron Triangle" has long since been overhauled. Still, there is a tradeoff that we need to make - and we all do this, every day. Unconsciously. The Effort Distribution Triangle is one way to bring the tradeoffs we make into visibility, so we can have a meaningful discussion whether we're making the right choices.

The Model

The label indicates "We aren't investing into it" and the opposing line indicates "Everything invested into resolving this".
The normal condition would be somewhere in the middle.

We have 100% of our effort to distribute. We can invest it any way we choose into delivering features, improving technology and discussion about goals and methods.
Regardless of how we distribute our effort, 100% is 100% - so choose wisely!

Opportunity Cost

By delivering features that might add value to our product, we do what development teams are supposed to do: create tangible business value. We always need to keep sight of business value, as this is the purpose of doing development work.

At the same time, excessive focus on delivery might cause us to neglect the underlying technology or communication.
In turn, the risk we run by spending too much time aligning and optimizing our technology is the time we lose on innovating and delivering things others need. This is our opportunity cost.

Technical Debt

Phrased positively, "Continuous attention to technical excellence and good design enhances agility."
It allows us to get more things done faster, and make changes with less effort.

Taking a pessimistic view, everything that isn't as good as technically possible can be called "technical debt". We always have technical debt, so at best we can control whether we consider the debt pressing or not.

Sometimes, we just want to get something through the door, and we're cutting corners on a technical level. We might have skipped the occasional refactoring, or anything like that.
Without accusation, I have observed many developers who prefer spending time on improving technology over time spent in meetings. While there are bad meetings, the consequence might be that some people don't understand things they should understand - communication debt!

Communication Debt

As mentioned in another article, "communication debt is the communications we should have had that we didn't have".
Good communication provides alignment, transparency and clarity of purpose. It's the basis for autonomy and self-organization within a company.

Communication takes time. Scrum, for example, dedicates five Dailies per week, plus one Planning, a Review and a Retrospective plus occasional Refinements - for a total of roughly 15% of your calendar to pure communication, and it's incredibly difficult to function as a team by going any lower. And that doesn't even include work floor communication, such as whiteboard design sessions, pair programming, code reviews and whatnotever.

Communication effort is an integral part of your total capacity to do things.

While some effort put into communication is in fact part of your ability to optimize both delivery and technology - there is also communication aside from that: Like letting other people know what you're doing, letting them learn from you or learning from them.

Make your choice

Take your pick anywhere on the triangle. Discuss the long-term consequences of this choice with your team. This choice is never once-for-all, you can always change it. Yet, there are choices of strategic nature and choices of tactical nature.
Strategically, a delicate balance is most suitable to maximize sustainability. Tactically, the team might decide to go all-in on technical improvements or feature delivery. That's not viable - so the Scrum Master and Product Owner should keep an eye that the triangle doesn't get too lopsided for a prolonged period of time.

Closing question

Who in your organization is making that choice for your team - and who is aware of the consequences of this choice?