The Right Way to Think About Cost Savings with Agile

Cost savings is a tricky subject with Agile. But it’s not because Agile can’t impact cost savings. It’s because Agile has very little impact on direct and immediate cost savings. The problem is, most people think the wrong way about how to save on cost with Agile. They usually say Scrum is how they realize cost savings—but they’re missing something. 

To watch the full webinar on how Agile adoption can reduce costs, check out the Key Business Drivers of Agility on-demand webinar series here.

Transcript

In its simplest form, like why shouldn’t you think about Agile as a cost-savings tool? Well, the problem is with thinking about Agile as a cost-savings tool, is that most of the organizations that we walk into are are legitimately 10 X over subscribed. I mean, it’s absolutely insane what most organizations are being asked to do. You know, you go through and you do this kind of annual planning cycle and you have all this stuff, you have all these objectives and OKR’s all this different stuff, and you’re trying to run it through an organization that just is not capable, in reality, of being able to do that. So a lot of times the challenge becomes is like what do you do when you legit need to save money?

But the problem is, is that you’re super overloaded. So, just to kind of give you guys a little bit of a hint of, I think where this is going to go, is the right conversation, I believe, is that what we have to focus on are things like throughput, getting things in market as fast as we can, making sure that we’re focusing our delivery dollars on the highest value things we can possibly do, things that are most likely to yield return on investment, things like that. And if you can do that with the existing staff, that’s great, and so, but sometimes, you know, we’re out of balance and so sometimes it’s like redeploying staff and getting people into the right seats or getting some of the wrong people out, some of the right people in. So there’s like, there’s like a like a big efficiency play, but like cost savings is like really, really difficult to promise.

And so what I want to talk about a little bit to start off with those kind of hypothesizing a previous hour, like how would I start to tell the story to you guys? And so where I thought it would start are what I kind of see as a few anti-patterns. So there’s a belief, there’s a belief, it’s almost like a Dilbertesque belief that Agile, just by virtue of doing Agile stuff, right, so by virtue of doing Agile process, that we’re gonna save money. So our challenge is to unpack a little bit why, but as we do that, right, this belief is, is pretty pervasive, right? So it’s almost like if I send you to Scrum training and you start doing the Scrum ceremonies, you start having the Scrum rolls, right. So we’ll do a daily standup meeting, that kind of a thing, then somehow that’s going to magically like solve the problem.

So what we see in practice, right, the simplest thing is that we have this hypothesis this belief that Scrum is going to save us this money, so we train everybody on Scrum. And then we do like really crazy things like fire all our project managers, or we get rid of all of the architects, right, ’cause Agile doesn’t do architecture. That’s not true, but that’s like what a lot of people think. Or we realize that we think Agile is going to flatten our organization by default, so we let go of all our middle managers or something. I mean, you guys might be laughing on the inside or maybe you’re cringing because you’ve experienced it. But people do stuff like that, right? And so what ends up happening is you have this big, complex organization that hasn’t really fundamentally gone through a transformation, it’s full of dependencies, lots of orchestration costs to try to deal with those dependencies. You teach that organization’s Scrum and then you remove all the costs associated with orchestration, but the dependencies and things like that, that are in place that necessitated that orchestration didn’t actually go away.

So it’s like we spend the dollars to teach people Scrum, and then we save the dollars by letting people go, and we ended up on the backside, not with cost savings, but with a more chaotic environment than we had before. People get frustrated, say Agile doesn’t work so they throw Agile out. But the reality is, is that Agile wasn’t the problem. We prematurely tried to reap those benefits before we had created the ecosystem where those benefits could be realized. Okay? Another thing that we’re seeing, and I’m going to anchor this back to a talk that I think I launched in the market about eight years ago called “Why Agile Fails,” but another thing that we’re seeing quite a bit with some organizations are going into, usually like a lot of times we’ll follow behind another consultancy or something like that, or maybe it’s a failed Agile implementation and they like our approach to trying to figure this out, so we come in behind somebody in one of these things.

And a lot of times what happens is that somebody decides, and I don’t know what the, exactly what I want to call it, but somebody basically decides to create some sort of like green field pilot. So they do this, right? So they go on, they say, “okay, we’re going to do something in a totally new business with really open requirements. We’re going to give it total autonomy over the tech stack. We’re going to give it a total dedicated team.” Right, all this stuff, right. They’re going to basically create like all the conditions for Agile to be successful. And they’re inevitably doing it in something that’s built on new technology, mobile web, right, some distributed system kind of architecture, things that really lend themselves to service orientation, all that kind of stuff. And so we’re gonna do a pilot, right, and that pilot’s going to be really fast and it’s going to be really efficient, and it’s going to use some variant of Scrum XP, Lean Startup, right, something like that, right.

So the hypothesis becomes is that because we used the methodology that is what drove the efficiency and the savings. The reality is, is that it was actually the new business, open requirements, ownership of the tech stack, continuous integration deployment, good architecture, dedicated team. These were the things that actually led to the efficiency play. So like what we’re seeing is we’re seeing is that like an organizational will come in here and any organization has some percentage of new stuff, innovative fast stuff, and then organizations have some percentage of legacy stuff. And so what will tend to happen is you’ll carve off a piece of this and you’ll do your pilot and it will work really good, right, because we know Agile works if you create the conditions to do it well, and then we’ll say, “Oh, okay.” So we’ll take that hypothesis, we’ll come and we’ll train everybody else on Scrum and we will cut 25% out of the staff.

Well, the reality is, is this legacy stuff, we didn’t create the conditions for to get those efficiencies, so what we ended up doing is we have this really shining star example of something that worked and we have this really bad example of where it didn’t work. So going back to the themes, right, some of the physics stuff, right, if we don’t create the right levels of encapsulation, if we don’t figure out how to break dependencies, we can’t alleviate the orchestration costs. And so we save the money, but we don’t get the organizational improvements we want. So this is why I think this is like a really, really dangerous conversation to have.