Building a Solid Business Case for Agile Transformation

In this episode of Definitely, Maybe Agile, Peter Maddison and David Sharrock explore the critical aspects of creating a compelling business case for agile transformation. They discuss the importance of understanding an organization's current state, setting clear goals, and implementing change incrementally. The conversation delves into the challenges of organizational change, the value of external help, and the need for effective communication across all company levels during transformation efforts.

This week´s takeaways:

• Before embarking on any transformation, it's crucial to understand where your organization currently stands.
• Successful transformations require buy-in and participation from all parts of the organization.
• Rather than attempting large-scale changes simultaneously, focus on implementing transformations in small, manageable increments.

Join us as we navigate the complexities of organizational transformation with practical advice on achieving smooth, well-communicated change. 

Chapters

• 0:04 Creating a Compelling Business Case
• 8:43 Navigating Organizational Transformation Smoothly
• 13:17 Harnessing External Support for Organizational Transformation

Transcript

Peter: 0:04

Welcome to Definitely, Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you doing?

Dave: 0:14

Peter, very good to see you. I'm doing very well. Good to catch up again. What's our topic of the day?

Peter: 0:20

Our topic of the day is creating a compelling business case for agile transformation, which I think is a fascinating business case. Come on, give me some.

Dave: 0:30

I was just going to say it feels a little too late to be talking about agile transformations. But if we say digital or any whatever the flavor of the month transformation, is that business change? Maybe can I start by asking why would you want to go through a transformation of any kind?

Peter: 0:50

And this is a very good question. I mean, there has to be a problem that you're trying to solve, like why are you trying to do this anyway? Like if the organization, if you're in a situation, there's usually a couple things. If the organization is delivering what it's supposed to deliver, things are reasonably well, your costs are under control, things seem to be going. Why would you put yourself through it? I mean, that's like you're, you're. There has to be a reason to change. You have to be trying to achieve something by changing, and so that's the one of those key pieces, right?

Dave: 1:18

well, and I I think part of the reason that we start with this piece as well, as we talk a lot about building a habit of continuous improvement, and so transformation suggests this big sort of beast that we're building up, and it's going to have momentum and lots of people will be involved in some so on, and maybe the first place to start is why are we changing? And and therefore can we use the muscle in the organization for continuous improvement?

Peter: 1:48

Yeah, because if you already have that ability, then can we just adapt, can we just feed into the existing system what it is we're trying to achieve, like, have you already built that capability for absorbing change or changing how things are? If you are, because so that's a part of it the business case is largely going to depend on where you're starting from and where you're going, and this is one of the other pieces that we were talking about before we started is that having an understanding of where are we today, so that we know where we're changing to, is an important aspect of this.

Dave: 2:21

There's this really interesting. It's a little bit like the grass is greener. Analogy right If we're in an organization and we've not done a transformation for a while, or we're just brand new in the organization and we think we might go looking for a greener pasture somewhere and say we need to be more like X, y and Z, whatever that is, without first considering where we are Maybe we don't need to be where we're pointing at, where we're trying to aim for, or maybe we're already doing lots of things really well and if we don't understand that, we tend to throw a lot of really good stuff out of the door as we sort of try and realign for some outward objective.

Peter: 2:57

Yeah, exactly, and the. So I mean some of the mistakes that we've seen. We've talked about those on a number of occasions. Like come in fire all the managers, fire all the architects. Everybody's agile. Now You've all got new job titles.

Peter: 3:11

I haven't seen one of those in a little while, thankfully, it's disastrous when you do and I've had to pick up the pieces from that in the past because you lose so much your knowledge, walks out the door, so much of the communication channel and trust and everything just leaves at that point and the organization often ends up in something of a shambles trying to put things back together. That's not really any kind of designed transformation at that point. But when we talk about the business case, like what is the value that I'm going to get out of this? How do I justify putting the organization through this? I've got to have an understanding of, like the, especially if I'm going to bring in external help. Like I'm going to say, okay, I'm going to go spend some money and bring in coaches and consultants to help me with this transformation, how do I justify the cost of those coaches? Like, what's paying for it? What's the?

Dave: 4:03

payoff and I'd much rather see this as an investment to an end goal right. So to your point of putting a business case together, there needs to be a recognition, first of all, of where the organization starts baselining what works well, and we've talked about this many times. The number of times we walk into an organization, they say they want to deliver more quickly, higher level of quality, better alignment to customers, whatever the drive will be. And then we try and find out what their baseline is and they're not actually aware of how quick things get delivered quickly, slowly, medium, whatever it might be. They have no awareness of that quality, not really a common understanding. They're not even sure, maybe they don't even validate what does resonate with customers and what doesn't. So you find that the baseline is effectively missing and I think that one is a real challenge because there's a lot of work sometimes just to get an understanding of where the organization is.

Peter: 4:57

Yeah, and if the organization? For example, they might measure KPIs in terms of performance of the organization, like how much revenue we make, how much money we spend, but they may not measure necessarily success in terms of what do our customers look for us to? How do we know that we're winning in the marketplace? And a lot of organizations do. But they may not necessarily tie these things together in a way that we could say well, I'm going to change the organization because I feel quality isn't good enough, I'm trying to do something different.

Peter: 5:33

I need to be able to tie this to something which I'll be able to see. Am I moving the needle here? Am I making a difference by doing this? So I can say here's my business case. My business case is I'm going to spend this money and this time and this effort on the organization in order to achieve these outcomes, and I'm going to measure those outcomes by looking at how much the needle moves on these. At the business case stage I may not necessarily know. I mean, your first little piece might be for me to build a business case. I need to go find out what those are so I know what needles I want to move.

Dave: 6:07

I think that's a really good way of looking at it. So sometimes there's lots of you know it can be relatively clear that some changes are required. So if we look at the economy, recently a lot of organizations have, you know, they've got capacity constraints. They've tightened up on capacity in many ways. Many organizations have not actually reduced the number of things that are being done. So of course capacity is further flattened because people are overloaded. It's not clear.

Dave: 6:36

I was just doing a training a couple of weeks ago where one of the biggest problems that people were identifying is it's all well and good talking about how we're going to do this, we're going to do the other. That people were identifying as it's all well and good talking about how we're going to do this, we're going to do the other. But when there's a sudden shift or reorganization, it takes months sometimes just to figure out the connections that you had before, to figure out who can support and help you in making those changes. So these sorts of shifts that organizations are going through, it's very obvious something has to change. But what's not clear is what the measure of success would be as you're looking at that. So I really like what you're saying there about maybe spending the first period of time just locking in what's the current state, what can be changed or improved, so that you have a very clear idea of what the end goal should?

Peter: 7:22

look like. So you know when you spend that money and whether you bring in external help or not, you are spending money. You're taking time from the organization to do this, that you've got an understanding of what is the return on that. What are you looking to achieve? This especially applies if you're trying to build a new product or enter a new marketplace or look at something different and you're looking at changing it. How are you going to do that in the organization and we often associate the transformation with sort of organizational change there's always, very often should be, an organizational change piece and the understanding is that organizational change in support of what I'm trying to achieve and for that I've got to be able to tie it back into strategy and that in turn drives the business case. Is my business case now aligned to the strategy and what is the transformation I'm going to do in order to help with the business case that supports that?

Dave: 8:24

strategy. So once you've sort of defined a baseline, you've got an understanding of what the end goal is. The business case comes around. In what way?

Peter: 8:33

What would you do next. So now we've got to think about what are the challenges, what are the things in front of me, what has I got to get done? How am I going to start to understand to do this? I mean, you and I are both big proponents of the fact that large changes all at once is massively disruptive and should be undertaken very, very rarely with the utmost care and with very intentional thoughts behind it. It's not to say you don't do that. There are sometimes reasons that you may want to. For example, you may want to disrupt things in that way.

Dave: 9:21

But if you are generally trying to do something new, then looking at a small, some small way of moving from where you are versus disrupting the entire system is nearly always the best way to go.

Dave: 9:26

Yeah, and I remember you and I discussed the my Iceberg is Melting book John Cotter wrote several years ago now.

Dave: 9:29

But one of the key things that struck me as we kind of went through that book is the importance of kind of communicating and bringing a lot of people on board with that change.

Dave: 9:40

So one of the things that we sometimes see is a transformation driven out of, let's say, it or wherever it is, name a department, name a group and not, you know, communicated, not involving many of the other departments and groups and sort of leadership who are going to be impacted, who have skin in the game somehow because they depend on it. And I think that becomes a sort of chasing the the tiger once it's out and running free, rather than sitting down and actually having a conversation with everyone and getting everybody on board so that we all know what the we've got buy-in and people are recognizing that this is necessary for the organization and, um, there's something that that people are going to be talking to, you know, coming to their, their organization. They're are going to be talking to coming to their organization. They're not going to be sort of sidelining those conversations but actually supporting and getting those through.

Peter: 10:35

Right, because having that involvement with communication is that critical part, right? It's like we've got to make sure that everybody's on the same page as to what we're doing. I think that's an important part of that business case too, is the going out and having those conversations If we're doing. I think that's an important part of that business case too, is the going out and having those conversations If we're going to undertake a change like this, is everybody aware of it? Is the business case included, all of the people who need to have input to this business?

Dave: 11:00

case. So many times you find out that other parts of the organization are also going through a big change because there's some existential threat, whatever it might be. So everybody's suddenly changing all at once and of course then you've got certain parts of your organization often IT, but not necessarily just IT that are critical to everybody's transformation, which means now everybody's transformation is going to get slowed down, delayed or even just never get off the ground unless there's some coordination and acceptance of what that means.

Peter: 11:31

There's some sort of I mean, whether it's a compromise, whether it's collaboration, whatever it is but there's got to be some coordination there, yeah, and I think, and you can, with that coordination, collaboration across the different areas, understanding those pieces, shorter time horizons, understanding like we're going to do this in increments, presenting your business case in that way, and understanding what we're looking to move is, I think, some big pieces around that right as we start to look at. How do you build this out? How do you build the business case for transformation?

Dave: 12:04

And I wanted to sort of touch on a kind of comment that you made earlier on. We've not raised this one yet. But external help we talked a little bit about external help. You've got a provocative post-it note here that says spend a million dollars on coaches and expect to see what exactly and let's talk a little bit about is a transformation a transformation if you don't get external help.

Peter: 12:28

Well, yes, I mean and I think I touched on it a little earlier I mean, even if you're not having other people come in and help you do this, you are still changing. You still need to consider what's going to be involved in doing that. You may have, in some organizations, you may have internal people who can help you through that change. So finding the right people and the assistance to do that is nearly always a good idea, because it's, if nothing else, having somebody who can look at it more objectively and help you understand if there's anything you might not be considering or you might be missing, or if there's something else that would be good to bring to the table, can be very valuable. Yeah, and then there's a cost to doing any kind of change. So you've got to understand what that is and understand. Are you doing this to a particular goal? Like what am I trying to?

Dave: 13:20

achieve here. I'm always struggling with this one because obviously part of my role with IncrementOne and your role with Zodiac is we're there to support transformations with organizations, with the external help that gets pulled in, and yet at the same time, I'm struggling in my head to think of really successful sort of transformations of an organization that don't have support. And I think part of that is and I'm thinking of renovations you were chatting about the renovation that you're going through, but when we go through a renovation, there's definitely an option where I can do the renovation myself with, you know, my friends and family helping out, um. But if I go out and get help, there's a number of benefits that come with that like.

Dave: 14:02

Part of it is speed. I'm paying to be, you know, as as to shorten the period of disruption, right, um, so that I can get something out of the door quicker. Part of it is expertise. I may be able to get a YouTube video on exactly what's involved in doing some plumbing or whatever it is. Or I can find somebody who does that for a living and say come on in for a day, half a day, a week, whatever it is, get it done, make sure it works the first time. Make sure he passes all the tests and you're not sitting there wondering what to do with a flooded basement at the end of it.

Dave: 14:35

So there's, so we don't. I mean, there's a number of reasons why we can bring in that expertise. Now I think it has to be coordinated rather than just bringing people in and having them wandering around the house doing things.

Peter: 14:46

But I have to say more and more no-transcript, then having external help is just invaluable at that point because you're essentially bringing the capacity in to help with that.

Dave: 15:23

Yeah, maybe a couple of things. How would we summarize where we're going? Or have we missed a topic you want to bring to the table?

Peter: 15:30

Well, we can see if it comes up in the summary.

Peter: 15:33

So I think the sort of three main sort of summary points here and if I stretch my mind back to the conversation a little here as well is the ensuring that we have the baseline.

Peter: 15:44

And if you don't have an understanding of the baseline, then before building out the business case, put the effort into working out what that is so you can build your business cases and potentially some pre-work of that. Making sure that we look at, make sure everybody's at the table, that we involve everybody, have them be part of the conversation, because that communication, ensuring that there's the different points of view, and then maybe other things, as you said, in the organization we may have other parts of the organization trying to do very similar things. Another one would be around looking at if you're looking to implement and we highly encourage you do in most cases in small increments and build that into the business case and tie it back to those measures of success so that you can see that and you can see what are we trying to achieve and it gives you more opportunity to be able to then course correct if you find that you were wrong as you start to get underway.

Dave: 16:36

Well, and I might just so. This is perhaps something we just briefly touched on but I haven't really dug into. I'm seeing right now we've got a number of conversations, a number of areas that we're working where the sort of uncertainty and the pace of kind of demand coming at the teams that are trying to go through a transformation is so great right now for a number of reasons. There are some very specific things happening in these organizations, but what it's almost sort of stirred everything up. So there's a lot of demand coming in and the impact that has on.

Dave: 17:10

If I'm trying to look long term, medium to long term for a transformation objective, it gets blown out of the water by the continuous kind of pattering of demands coming at you all the time, and so one of the consequences of that is you have to turn that medium to long term piece into much, much shorter time horizons, and so the organization I'm thinking of right now is able barely to think two weeks out. So having a strategic 90-day plan doesn't make any sense, because within two weeks that plan is torn up and broken up. And so how can you look at that in two-week or four-week chunks so that there's at least some continuity there?

Dave: 17:50

Yeah yeah, I think that's a very good point.

Peter: 17:52

Okay, well, thank you, dave. As always, it's always good to have these conversations. I think we covered a lot of ground and I hope people find this valuable. And don't forget to hit subscribe and you can send us feedback at definitelymaybeagilecom.

Dave: 18:06

Pleasure, as always.

Peter: 18:08

Time to break for the weekend. You've been listening to Definitely Maybe Agile, the podcast where your hosts, peter Madison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.