Leading Transformational Change in Large Organizations

Agile Transformation, Digital Transformation, DevOps Transformation; they’re all just different ways large organizations attempt to achieve the same results. And they all fail for the same reasons. No plan. No vision. No way to measure success. No alignment. And no results. For any of these approaches to work, we’re going to have to fall back on the principles of change management and get super intentional about how we approach Transformation.

Video Transcript

This idea of Digital Transformation, DevOps Transformation, and Agile Transformation are all starting to blend together, and the reason why these changes often struggle is because we don’t appreciate the complexity and the amount of intentionality required to execute them.

(Musical Interlude) 

The Reality of Change Management

Well, good morning, everybody. How are you doing? We’re a little off schedule here at Leading Agile. I usually record these things on Friday afternoons, but it is Thursday morning and my eyes haven’t adjusted yet, so I have my reading glasses on and some notes underneath me. But we’re working on some interesting content this week around the idea of change and change management.

As you know, I’m always talking about agile and agile transformation, but I had three events happen over the last couple of weeks that have really got my brain turning. The first one was when I was at the Triad conference in Raleigh, North Carolina, a couple of weeks ago, and I was doing a talk on how to change culture.

I’m generally not a culture-first kind of person when I think about agile transformation because culture feels like the problem, but it’s not actually the problem. There’s a lot of resistance to change and adapting behavior, but my belief is that if we get the systems and organization right, including teaming structures, governance, metrics, and controls, and enable them with solid agile practices like Scrum or SAFe, culture can emerge over time.

However, during the conference, a friend of mine from the Agile community, whom I have known for almost 15-20 years, raised his hand and said something to the effect of, “But when we go in, we can’t actually change the teaming strategies.”

And it was an interesting thing to me that there are coaches in the world, right, Agile consultants, that have totally acquiesced to given up on the idea that organizations are static and then we don’t have any influence over them. So that was like the first thing that got me thinking. And then the second thing that got me thinking was, you know, I guess it was last week or so we did a content series on SAFe and SAFe with Agile, and you know, one of the things that I think is interesting is, you know, most people don’t have the breadth of experience that like me and Dennis Stevens and a few of us do.

Yeah, I’ve been running this company for almost 13 years now, and then prior to that was working for VersionOne for a couple of years. And so, you see hundreds of Agile transformations. We’ve seen hundreds of different kinds of organizations. And one of the very persistent problems that I see is that, you know, people are going off of training, whether it be Scrum or SAFe or something like that.

And they’re bringing back Agile practices, and they’re trying to apply them on top of organizations that haven’t been transformed. Right. And probably just like that coach that I was talking about at your conference, they don’t see how to actually create decoupled teams or decoupled value streams and that kind of a thing. And so, I was having this conversation around, you know, SAFe not really prescribing a transformation strategy. And this lady on LinkedIn was kind of debating back and forth with me that it does. And, you know, so I went, okay, okay, like maybe I’ve missed something over the last couple of years. And I and I went digging around and, you know, what I see is, I see general guidance for issues around value streams. And maybe there is an implication that value streams should be loosely coupled, right? Not have a lot of dependencies between value streams is important.

When people attend Scrum training, they may assume that they will return to a complete cross-functional team. However, in practice, this is not always the case. Teams are often organized around things that may not necessarily be considered value, such as a feature set or a business capability.

Our perspective on Agile transformation is that we must ensure that team strategies, governance, metrics, and controls are all correct. If you try to apply Scrum or another methodology on top of an organization that is not ready for it, you will inevitably face difficulties. Although methodologies may implicitly or explicitly suggest encapsulation, I do not see evidence of a strategy for attaining it.

One comment that I make and I’m probably going to piss Bas Vodde and Craig Larmen off at some point in time, continuing to say this, but like in their first book, unless you know the way I kind of joke about it, it was like saying, “Hey, in order to do LeSS, you need totally encapsulated teams and yeah, it may take years, but you know, I keep at it.”

I was like the general tone of it, at least as I remember it. It’s been a few years since I’ve read that book, but that’s like where the work is, right? It’s like that cartoon where it’s a bunch of math on one side, a bunch of math on the other side. And then it’s like, “And then a miracle happens here,” right?

So sure, it’s one thing to say organize teams around value. It’s one thing to say we’re going to encapsulate value streams, but what if value streams and teams aren’t encapsulated? That’s really, really tough. We just started working with a client about six months ago. We went through and did kind of a funny and stayed.

We started working through all the different aspects to get prepared for some of the changes we were making. We’re running a pilot, a pretty small pilot, but some of the things that we need to have in place just aren’t in place yet. So, we don’t have the right team strategy. We don’t have the right persistent teams. We don’t have the right ability to build backlogs.

We don’t have the right ability to produce a working tested increment. And even amongst my team sometimes, it’s like you get into these big corporate bureaucracies and it’s like everybody you talk to says, “Yeah, that’s not possible.” “Yeah, that’s not possible.” “Yeah, that’s not possible.” “Yeah, that’s not possible.” But it has to be possible on some level, right?

Because that’s the fundamental physics of anything we’re going to do, it’s Agile, it’s encapsulation versus orchestration. We have to break dependencies, or we have to manage dependencies. And so, if we acquiesce, if we just give up on the idea that we can create the conditions, what I wonder is, are we able to ever deliver on the business benefits that we promised?

And I think what’s happened is because so many people see that kind of organizational change as impossible, what they define success as, you know, is are we doing the practices of Scrum or SAFe correctly? And that is never what we’re really trying to do, right? We’re trying to organize around value. We’re trying to get to the place where we’re closer to the customer, and we can deploy rapidly, and we can get feedback and we can inspect and adapt.

And if we don’t have a dependency-free environment, it’s really, really difficult to do. So there are a lot of things that we might recommend in an early-stage transformation that we call compensating controls, right? So in the presence of dependencies, or teams that aren’t formed, or governance that isn’t fully in place yet, you start to put that in place and you put some extra orchestration in until you can actually create the teams.

But it’s fascinating to me, the number of people in our industry that either don’t see it or they see it and they don’t believe it’s possible. And the net effect is that we’re doubling down on practices and not more effectively getting the business benefits from it that we’re trying to do. So, it’s a really interesting problem.

Introducing Change into Large Organizations

And so, there was an article from McKinsey and Company that came out a while ago. Tim Zack, my Chief Marketing Officer, sent it to me, and it was talking about the problems with Digital Transformation. What I thought was really interesting as I was going back to the idea of introducing change into an organization. I’m not really good at remembering specific details of different things, but I was thinking about the eight-step Kotter model of change. The Kotter model is very much like building guiding coalitions and wins, and all those things. It’s really super good guidance, but it’s not specific enough in terms of what those wins mean. The McKinsey article was basically saying that a lack of a clear in-state vision, a lack of clarity on what acceptance looks like, what done looks like, and how we are going to specifically get ourselves there, is a challenge.

I think a lot of change fails because we say, okay, we convince people of the problem, we might even be able to get them excited enough to want to do something about it. But the challenge is that we’re dealing with some very complex systems, very complex technology systems, complex organizational design, complex financial models, complex governance models, places where we don’t have really clear ways to adjudicate prioritization. We’re dealing with organizational politics. So when we’re dealing fundamentally with organizational system-level problems, those kinds of changes need to be incredibly thought out. We’ve had some success over the last 13 years since we’ve been in business, but really more maybe specifically over the last four or five years as some of our methodology has started to emerge.

One of the things we really distinguish between is the idea of a system of delivery, which is basically like your operating model, like your enterprise operating model, and the system of transformation, like how do you get to that end-state operating model? And what we’ve generally found is that there’s a lot of work that has to be done in order to enlist people around the patterns and principles that are going to make them successful.

Then you have to sit down with them and understand all of the constraints that are in the system and all of the things that are going to make change difficult. And not only do you have to understand what’s going to make change difficult, but you have to have a credible strategy for overcoming those things, because if somebody’s sitting there, one of the classic examples, and this is maybe an example from seven or eight years ago, as I was talking to a mainframe architect, and he was just totally blasting what we were trying to do with team-level Agile.

The reason why was because it was like, okay, small teams inspecting, adapting, continuously deploy, right? He understood Agile, and he was open to the idea of it, but he was looking at this technology architecture and basically saying that’s not going to work. He was right. That’s not an attitude problem, that’s not a culture problem, it’s not a mindset problem, it’s not a behavior problem. That is a constraint of the system problem.

So just like you wouldn’t walk into a legacy mainframe platform that needs to have product extraction work done, legacy refactoring, legacy recovery kinds of things and just go, oh, okay, we’re screwed. For some people, I don’t know, just be fine. You have to be very thoughtful about those kinds of things. So, a lot of what we’re doing in Agile Transformation is very similar. We’re fundamentally refactoring organizations to be able to operate more effectively.

After you enlist people on the patterns and principles, then you sit down with them and understand the design constraints that are in the system, and you evaluate where you are now, what’s the state of your organization, where do you want it to be?

You start to think through like, what’s possible today versus what’s possible in the future as we make changes. And then you do what you can today to be successful, and then you systematically start improving the system. You start to deprecate some of the compensating controls, and all of that stuff can be planned. Right. And, and, and so like what we’ve done is you hear us talk about expeditions to Basecamps.

You know, we have this four quadrants model, we have Base Camp One, Two, Three, Four or Five where we define kind of the next intermediate state. And then we have outcomes that enable us to be able to get from one base camp to another through 8, 10, 12 intermediate steps. And you can think through the different activities and you can say all day long that that’s big upfront planning.

But, but like the alternative is sitting there and just, you know, kind of air quote, empowering a group of people to make these kinds of decisions. And most people can’t conceptualize how to make radical organizational change. Gosh, another blog post from back in the day, I had my son, who’s 26 now. He was, you know, the kid at the time, 13, 14. And he had this goldfish sitting in his room. And I didn’t think anything of the goldfish, but it’s just sitting in a small goldfish bowl.

And, and I walked in one day and I’m like, the goldfish bowl hadn’t been cleaned. It had to be a year or something. It’s like basically the water is yellow. And I was just sitting there thinking, this little goldfish is kind of swimming around. That sound felt like, And if you’re that goldfish, like, how do you how do you clean that tank? Right? How do you extract yourself from the system so that you can empty the water, clean the sides, do all the different things that needed to be done, fill it back up with water, put yourself back in it.

Really, really difficult. And I think that’s the problem. Sometimes inside companies, it’s like we see all the constraints that are around us and we don’t know. We don’t know what to do about them. We don’t know how to influence or orchestrate that kind of organizational change. And so and so that that manifests itself as a lot of local optimization.

We have a lot of, you know, teams doing the best they can and, you know, folks trying to manage dependencies and, you know, and then they end up bending the rules of Scrum or bending the rules of SAFe to accommodate their organizational dysfunction. Because again, just most people are not systems thinkers and they have a really hard time changing the systems that they have to operate in.

Right? There’s politics and negotiation and people have different points of view and there’s no authority and all that kind of stuff. And so for us, the secret, the change, the secret to organizational Transformation has been is getting really, really clear on what your intermediate states look like, the outcomes you have to achieve to get there, the specific activities, the underlying design principles of the organization, what are the things that you can do now and the presence of suboptimal conditions to help get yourself into the place where you want to be sometime in the future?

And, and so yeah, so that’s kind of just, just what I’ve been noodling on.

Why Transformations Struggle

And what I think is fascinating is a lot of what we’ve been doing in the Agile Transformation space is actually translating and very complementary to some of the stuff that’s going on in the DevOps world right now. And so we’ve started a few engagements with clients to help go through DevOps Transformation.

I was just with a client yesterday and we were talking about Digital Transformation. And what’s fascinating is that all of these things are really related. They’re just different views on the same fundamental problem. You know, we’re trying to figure out how to organize around value. We’re trying to figure out how to create continuous flow. We’re trying to figure out how to leverage systems and technology to solve business problems.

And so, this idea of Digital Transformation, DevOps Transformation, Agile Transformation, it’s all starting to kind of blend together. And the reason why this stuff is struggling often is because we don’t appreciate the complexity and the amount of intentionality that is required to actually execute the kinds of change. Again, you have to enlist people. You have to help them understand the practices and the principles and the things that are going to help them be successful.

And then you have to spend time and you have to think through what is my desired end state, like, How is this system going to perform on the backside? Like, what is our hypothesis on how this organizational design is going to support the performance characteristics that we’re looking for? And then once you’ve done that, then you say, okay, well, let’s pilot, let’s try it, let’s test our hypotheses, let’s see if it will work.

And then as we get in and we actually do it and we learn and we apply these things in the organization and we create feedback loops and, you know, we inspect and adapt our way through. Right? All the things that we kind of talk about in Agile, we can do with transformation. But if we don’t do it thoughtfully, if we don’t do it with full respect for the systems and constraints that are in place, what we end up with is a lot of going through the motions of whether it be Agile Transformation or Digital Transformation or DevOps Transformation.

And we’re going through the motions of doing it without actually getting the results and because we all want to be successful, at the end of the day, we claim victory. We claim victory on our installation of SAFe, right? Because people are doing the SAFe things and have the SAFe roles, right? The whole reason we’re trying to do SAFe is because we’re trying to unlock value.

We’re trying to get things to market faster. We’re trying to be able to make and meet commitments on regular intervals. We’re trying to get fast feedback from clients. We’re trying to maximize our ROI. Right? And so if your SAFe isn’t doing that or your Scrum isn’t doing that, it’s not working. It doesn’t matter how well you’re actually doing.

The methodology can. And so again, intentionality around change in list design the system run pilot, get feedback, understand how it’s working. Are you getting not only the performance improvements you want, but are these performance improvements resulting in the business results you want? Are they driving your OKRs? Are they improving the business outcomes? Because at the end of the day, that’s the only thing that matters and I just think, just to kind of put a bow on this, is that the thing that we have to recognize is that any kind of transformation work isn’t soft culture first mindset.

Let’s get everybody into the same headspace and then somehow it will all magically happen. I’m just a huge believer that a reasonable amount of upfront system design, a reasonable hypothesis on how those things are going to be orchestrated with the different practices, and then once we have a significant change in the operating model and we can actually see it working, that’s when hearts and minds start to change.

So we’re going to see a lot of why DevOps fails, why Digital Transformation fails, why Agile fails, because a lot of the stuff is struggling and it’s not because they’re not good ideas, it’s just that it’s really difficult to see how to make the organizational changes happen. And so what we end up doing is we end up buying training, we end up buying tools, we end up buying things that make it look like we’re making progress, but without actually making the progress that we’ve promised.

So maybe just the last thing I’ll say is that we have to be able to suspend disbelief. We have to be able to believe that real systematic change is possible. And at the point that you’re willing to believe it’s possible, well, then you only have the opportunity to have a conversation about how might we actually make it possible.

Not saying it’s easy, I’m not saying it’s straightforward. I’m not saying that you won’t get resistance. I’m not saying that there won’t be skeptics, but you just create more skeptics when you don’t speak the truth and you don’t talk about the things that have to be true in order to make this work. And some thoughtful preparation and a thoughtful plan for how we’re going to get from point A to B to point C to point D goes a long way in being able to help manage these kinds of changes.

So, I hope you guys have a great week and I will see you next time. We’re going to see a lot of why DevOps fails, why Digital Transformation fails, why Agile fails, because a lot of this stuff is struggling and it’s not because they’re not good ideas, it’s just that it’s really difficult to see how to make the organizational changes happen.

The thing that we have to recognize is that any kind of transformation work isn’t a soft culture-first mindset. Let’s get everybody into the same headspace and then somehow it will all magically happen. We have to be able to suspend disbelief. We have to be able to believe that real systematic change is possible. And at the point that you’re willing to believe that it’s possible, well, then you only have the opportunity to have a conversation about how might we actually make it possible.

Not saying it’s easy, I’m not saying it’s straightforward. I’m not saying that you won’t get resistance. I’m not saying that there won’t be skeptics, but you just create more skeptics when you don’t speak the truth and you don’t talk about the things that have to be true in order to make this work.