Speaker 1: 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. Well, good morning, everybody. How are you guys doing? We're a little off schedule here at Leading Agile. I usually record these things on Friday afternoons, and it is Thursday morning. And so my eyes haven't adjusted, so I can't totally see clearly yet. I've got my reading glasses on. I've got some notes up underneath me. But we're working on some content this week that I thought was pretty interesting around the idea of change and change management. And obviously, I'm always talking about Agile and Agile transformation and that kind of thing. But I had kind of three events happen over the last couple of weeks that have really got my brain turning on a couple of things. And so I'll tell you what the three events are. So the first one is I was up at the Tri-Agile conference up in, I guess, Raleigh, North Carolina, a couple of weeks ago, and was doing a talk on how to change culture. And as you guys know, I'm generally not a culture-first kind of person when I think about Agile transformation, because culture is one of those things that it feels like the problem, but it's like it's not actually the problem. There's a lot of resistance to change. There's a lot of resistance to adapting behavior and things like that. But my general belief is that if we get the systems in the organization, how we're doing teaming structures, and how we're doing governance, and how we're doing metrics and controls, we get all that stuff straight, and then enable it with some solid Agile practice, some combination of Scrum or Safe or Kanban, that kind of a thing. We can get culture to emerge over time. But the event that happened is, I just really doubled down on this idea that if we don't form complete cross-functional teams at the work surface level, that it's really difficult to do pretty much anything else that we want to do with Agile. And so a friend of mine, I've known through the Agile community for, gosh, 15, 20 years almost at this point, kind of raised his hand and said something to the effect, and this isn't a quote, but he said something to the effect of but when we go in, we can't actually change the teaming strategies. And it was an interesting thought to me that there's coaches in the world, 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 kind of like the first thing that got me thinking. And then the second thing that got me thinking was, I guess it was last week or so, we did a content series on Safe and if Safe was Agile. And one of the things that I think is interesting is most people don't have the breadth of experience that like me and Dennis Stevens and a few of us do. I've been running this company for almost 13 years now, and then prior to that was working for version one for a couple years. And so, you know, we've seen 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 to training, whether it be Scrum or Safe or Less 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 Triagile 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, OK, like maybe I've missed something over the last couple of years. And I went digging around and, you know, what I see is I see general guidance that you should organize around value streams. And maybe there's an implication that value streams should be loosely coupled, right? Not have a lot of dependencies between them and other value streams. You know, there's maybe an assumption in Scrum, like when you go to Scrum training, that you're going to come back and you're going to have a complete cross-functional team. Just in practice, across the industry, that just isn't true, right? That just isn't true. And to the extent it is true, teams are often organized around things that I wouldn't consider necessarily value, right? It's not necessarily just customer-facing value, but like something that is valuable, like a feature set or an area of the product or a value stream or a business capability, something like that. I just don't see it in practice. And so our take on agile transformation is that we've got to get those teaming strategies correct. We've got to get the governance correct. We've got to get the metrics and controls correct. And so if you apply SAFe or Scrum on top of an organization that isn't quite ready for it, then, you know, you're just going to inevitably struggle. And so while the methodologies might explicitly or implicitly imply encapsulation, I don't see evidence that there's actually a strategy for attaining it. One comment that I make, and I'm probably going to piss Basva and Craig Larman off at some point in time continuing to say this, but like in their first book on LESS, you know, the way I kind of joke about it, it was like saying, yeah, in order to do this, you need like totally encapsulated teams. And yeah, it might take you years, but you know, keep at it. It 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 like that's like where the work is, right? It's like that cartoon where it's like 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, right? That's really, really tough. We just started working with a client about six months ago, and we went through and we did kind of find the end state, and we started kind of working through all the different aspects to kind of get prepared for some of the changes we were making, and we're running a pilot, pretty small pilot. But some of the things that we need to have in place just aren't in place yet. And so we don't have the right teaming strategies. 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 test in increment. And even amongst my team sometimes, right? 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's like it has to be possible on some level, right? Because that's the fundamental physics of anything we're going to do with Agile. It's encapsulation versus orchestration. We have to break dependencies, or we have to manage dependencies. And so like if we acquiesce, right? 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, 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 we can adapt. And if we don't have a dependency-free environment, it's really, really difficult to do. So there's a lot of things that like we might recommend in an early stage transformation that we call compensating controls, right? So in the presence of dependencies or, you know, teams that aren't formed well 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 kind of 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 any of the business benefits from it that we're trying to do. So it's a really interesting problem, right? And so there was an article from McKinsey & Company that came out a while ago. Tim Zak, my chief marketing officer, sent to me, and it was talking about the problems with digital transformation. And, you know, and what I thought was really interesting as I was going back to the idea of introducing change into organizations, and I'm not really good with remembering like specific details of different things, but I was thinking about like the eight step Cotter model of change. And the Cotter model is very much like, you know, build guiding coalitions and wins and, you know, all those things. And it's like it's really super good guidance, but it's not like specific enough in terms of like what those wins mean. And, you know, the McKinsey article was basically saying something to the effect of like, you know, lack of a clear in-state vision, a lack of a clear of what acceptance looks like, of what done looks like. How are we going to specifically get ourselves there if we don't necessarily have a plan? And where I think a lot of change fails is that 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, right? 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. And so when we're dealing fundamentally with organizational system level problems, those kinds of changes need to be incredibly thought out. And where we've had some success over, I'd say the last 13 years, right, since we've been in business, but really more maybe specifically over the last four or five 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 in-state operating model, and the system of transformation. Like, how do you get to that in-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. And then you have to sit down with them and you have to 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 like understand what's going to make change difficult, you have to actually have a credible strategy for overcoming those things. Because if somebody's sitting there, you know, one of the classic examples, and this is maybe an example from seven or eight years ago, as I was sitting there talking to a mainframe architect, and he was just totally blasting what we were trying to do with team-level Agile. And the reason why was because it was like, okay, small teams inspect and adapt, continuously deploy, right? He understood Agile and he was open to the idea of it, but he was looking at his technology architecture and basically saying like, that's not going to work. And he was right. That's not an attitude problem, right? That's not a culture problem. That's not a mindset problem. That's not a behavior problem. That is like a constraint of the system problem. So just like you wouldn't walk in to 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 just gonna throw some people out and it'll just be fine. Like, I mean, you have to like be very thoughtful about those kinds of things. And so a lot of what we're doing in Agile transformation is very similar. Like we're fundamentally refactoring organizations to be able to operate more effectively. So, you know, after you enlist people on the patterns and principles, then you sit down with them and you understand the design constraints that are in the system. And you evaluate kind of like where you are now, what's the state of the 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, right? 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 so like what we've done is you hear us talk about like expeditions to base camps. You know, we have this four quadrants model and we have base camp one, two, three, four, five, where we define kind of the next intermediate state. And then we have outcomes that are, that enable us to be able to get from, you know, one base camp to another through eight, 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 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 gosh, he's probably 26 now. He was a 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 was just sitting in a small goldfish bowl. And I walked in one day and I'm like, the goldfish like bowl hadn't been cleaned in, it had to be a year or something. It's like, basically the water is yellow. And I was just sitting there thinking, you know, this little goldfish is kind of swimming around in its own filth. Like, and if you're that goldfish, like, 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 what to do about them. We don't know how to influence or orchestrate that kind of organizational change. And so that manifests itself as a lot of local optimization. We have a lot of teams doing the best they can and 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 differing points of view and there's no authority and all that kind of stuff. And so for us, the secret to 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 so, yeah, so that's kind of just what I've been noodling on. 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. 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 we inspect and adapt our way through, 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 like 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 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 into market faster. We're trying to be able to make and meet commitments on our regular intervals. We're trying to get fast feedback from clients. We're trying to maximize 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, okay? And so again, intentionality around change. Enlist, design the system, run pilots, get feedback, understand how it's working. Are you getting not only the performance improvements you want or those 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 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 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. 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 progress that we've promised. And 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 that it's possible, well then you have the opportunity to have a conversation about how might we actually make it possible. I'm 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 like 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 hope you guys have a great week and I will see you next time.