Aligning Your People, Processes, and Technology to Customers

Find out what’s really getting in the way of your Transformation as Mike Cottmeyer explores the single biggest problem preventing change inside large companies across the globe—dependencies. Regardless of the buzzword, process, or framework you’re currently subscribed to, watch this video and find out why dependencies are the exact problem holding you back and what you need to do to overcome them and start aligning your people, processes, and technology.

Video Transcript

They say, “Okay, if we’re going to adopt Agile, what are the necessary preconditions to adopt Agile?” And you said, “Okay, well, I have the whole complete team’s minimal dependencies. I have to have backlogs after we all have the ability to produce working, testing, test Software Corp, right? That’s the fundamental precondition for Agile. So what would I have to do to create those conditions over time?”

Right. That’s really the fundamental question you’re asking yourself because there’s no easy button. You’re having to pull this system apart and rebuild it differently. How do I take my people, align them with the business, take the technology, align it with the people in the business, minimize dependencies so folks can operate with more local autonomy and make good decisions on behalf of the customers?

Right? Because that’s what we’re really trying to do.

Dependencies in Agile

I’m going to explore something that I talk about quite a lot, and it’s the idea of dependencies and Agile. Our industry is circling around something that I think is really interesting. So if we talk about just pure play Scrum, right, we have the idea of teams, backlogs, working custom software. So what’s a team in Agile? Six to eight people that have some amount of autonomy over their technology stack and dependencies between them and other teams?

They can operate off of a backlog. They can produce a working, tested increment, a software every sprint or so. This idea of dependencies, right? Anytime we have dependencies between teams, we have to orchestrate those dependencies in some ways at the most simple level. If I have an occasional dependency, then I might walk across the room and ask somebody to help me resolve the dependency in the course of the sprint.

If they’ve got some capacity, they’ll probably help me. If the dependencies are heavy design dependencies, then those dependencies are really difficult to resolve during the sprint. Typically, when you have lots of dependencies between different parts of the organization, between different parts of the technology stack, between different requirements, it requires some sort of orchestration mechanism. So we’ve talked a lot about SAFe over the last couple of months.

And what I would suggest is that SAFe is really an approach to orchestrate dependencies across teams because if you didn’t have dependencies between teams, you wouldn’t need them. And so this idea that the industry is hunting around stuff. So last time I talked a little bit about this idea of Agile Open Digital that was part of this code aspect that we’ve encountered quite a bit, really similar to the stuff that Justice is talking about with how Tesla and SpaceX are building cars and rockets.

You know, there’s been, I’ve been getting turned on to from some of my tech teams, some of the stuff around Domain-Driven Design. And one of the things that Dennis Stephens, 50 years ago when we first met, was talking a lot about was the idea of business architecture. So I was hypothesizing last time that that may be a way of talking about this, thinking about the business architecture of the organization, the capability model of the organization, and the intersection of that.

And what the technology guys are really thinking about in terms of Domain-Driven Designers. So we want the business ultimately and the technology and the people to be in alignment, right? So think about we’ve got the business in alignment with the technology and the people, and you really have the Scrum teams, right? You have encapsulated relief trains, right?

You have encapsulated value streams, right? So if you can pull that off. And so, even taking it one step further, one of the big buzzwords out right now is the idea of like product-driven organizations. What is that? If I want to have a product-driven organization instead of a project-driven organization, I’m basically saying the same thing, right?

The product is the value, right? That’s the alignment with the business. The product is the technology, and it’s the people that build it, right? As a product, you have an organization that is fundamentally the same thing. You look at some of the stuff that’s coming out right now around the Composable Enterprise, right? Well, what’s a Composable Enterprise?

Well, it’s an Agile, Open Digital kind of enterprise where the organization is, in effect, built of reusable components. And so there’s this idea, right? It’s really interesting. It comes down to what we’ve been hunting for forever in the Agile community. I was talking about a couple of months ago, I was up in Raleigh, and I was talking about how you create a culture of agility.

And we started talking about teaming strategies, and we started talking about where backlogs come from and what enterprise governance looks like and what we measure and what we control. I told a story about one of my buddies who was in the audience and raised his hand and said that as Agile coaches, we can’t change the organizational structure, we can’t change the team strategies.

And I was kind of blown away because if we’re not changing that, then what the heck are we really doing around here? And so, you watch, you look at all this Gartner research, all the McKinsey papers, all the Accenture papers, the Deloitte papers, the stuff that’s being published, the things that people are thinking about around this idea of Composable Enterprises, Agile, Open Digital, the idea of product-centric organizations.

Right. It’s all fundamentally the same thing. How do we get teams of people, how do we get them to align with the business, and how do we get them to have some autonomy over the technology stack so we don’t have to have this crazy, easy level of orchestration between different parts of the enterprise? And so I think about it because we’re in the change business.

And you start to ask yourself things like, “Well, why is it so difficult?” And this is what I think is interesting.

It’s like part of the challenge that we have right now is that it’s really difficult to see past your current constraints. And that’s the argument that Agile Coach I was telling you guys about was making.

It’s like if the organization can’t see past its current constraints, then what’s available to us? It’s like we’re sitting there saying, “Okay, we’re going to buy some new packaged software, we’re going to implement and devise some new technology, we’re going to overlay some new process.” But why is it that we get to this point where the process keeps changing, the buzzwords keep changing, the angle of attack keeps changing?

The products and software we offer keep changing. And it’s like we’re constantly trying to hunt this holy grail, some silver bullet. But at the end of the day, it comes down to encapsulation and orchestration, right? That’s what it comes down to all the time. And one of the things we need to sit in as a community, as a marketplace, as a movement in the Agile community, is if we can’t figure out how to help companies create these kinds of teams, product-centric organizations, composable enterprises, agile, open, digital, then what are we really doing?

If we can’t see past our current constraints and do this for real, you know, I hate to say “lipstick on a pig,” but that’s fundamentally what we’re doing here. It’s kind of fascinating.

The Challenges of Change Management

And I think part of the challenge is that as practitioners, even if we recognize it, we don’t know quite what to do about it. We don’t quite know how to orchestrate the change.

If I’m a senior leader, then I might delegate it down to my people, and I don’t really know necessarily what are the underlying patterns that need to be changed. I’m trusting the people underneath me to do it. But there’s an element, there’s an element of how do we get the executives to understand and do a product-driven organization, do a composable enterprise, do something that’s agile, open, digital? We have to fundamentally rethink the architecture of our systems.

We have to fundamentally rethink the architecture of our business, like Domain-Driven Design and business capability modeling. We have to fundamentally rethink how we orchestrate value and how we feed that system. If we want the benefits of this Agile, Open, Digital, Composable Enterprise, product-driven organization world, it’s really all fundamentally saying the same kinds of things.

It’s fundamentally an encapsulation and orchestration problem, right? It’s the same problem that companies face when they take legacy mainframes and try to turn them into a service-oriented architecture. That might be an interesting pattern to explore because that’s kind of what we do in our transformation world. If you’re going to take a legacy system and refactor it into a microservice, containerized, cloud-based ecosystem wrapped in tasks, what would you do in the software? Well, you’re really doing the same thing to the organization. It’s fascinating.

And I think that’s the principle. I think that’s the core truth underlying all of this. Once you get past the consultants, the process, the technology, and the resistance to change, there’s this pattern, this underlying thing that we’re trying to do. How do we create encapsulated autonomous entities? And one thing that, again, I would challenge everybody to think about is that we hear that and we agree with it, but then we look at our organization as it is, and we can’t see past the current constraint.

We can’t see how to change the organization in a meaningful way. We can’t see how to launch a change program that will do that in a structured and disciplined way. And, at the risk of being a little self-serving, that’s kind of what we do, right? Like, why else do all these CEOs come to us? So I think of leading Agile very much like we’re a hammer looking for nails, and nails are everywhere. But when somebody comes up to us and says something like, “Hey, we want to adopt Agile,” that’s usually where we start.

We say, “Okay, if we’re going to adopt Agile, what are the necessary preconditions to adopt Agile?” And you say, “Okay, well, I have the whole complete team’s minimal dependencies, I have to have backlogs, I have to all have the ability to produce working, test synchronous software Corp. Right. That’s the fundamental precondition for Agile.” And then you ask yourself something like, “Well, if I can’t create those conditions, I’m not going to get the business benefit from it that I want.”

So what would I have to do to create those conditions over time? That’s the fundamental question you’re asking yourself because there’s no easy button here. You’re having to pull this system apart and rebuild it differently. So if it’s an Agile question, you have to start with that fundamental precondition.

If I were going to use the same kind of metaphor on the system side, I might think about it something like this: I have a legacy monolith that I want to move to the cloud, some legacy software that I want to move to the cloud. And you have to ask yourself, what would it take to be able to move that software onto that different platform?

You could do it in a couple of different ways. You could take that legacy platform and move it to the cloud, and I think they call that “cloud-enabled” or something like that. But there’s a difference between being cloud-enabled, cloud-ready, or cloud-native. For something to be truly cloud-native, you have to pull it apart.

You have to make it more service-oriented, containerized, wrapped in APIs, and tested in order to fully exploit the cloud at that level. So, if somebody came to me and said, “I want to do Agile,” you’d have to work your way back to this encapsulation and orchestration thing.

If you want to do a cloud migration, you’re fundamentally having to think about it in the same way.

Why Digital Transformation is Failing

Another word that keeps coming up is this idea of digital transformation. And what we’re starting to see in the industry is that digital transformation has been largely treated as a technology problem, and now we’re seeing articles being written about why digital transformations are failing.

The reason why is that it has been treated as a technology problem. It hasn’t been treated as a people and process problem. It hasn’t been treated as an organizational design and governance problem. The inclination is either to put new technology in place or wrap the existing organization in a new set of processes or ways of working.

But at the end of the day, once you see it, you can’t unsee it. You have to figure out how to take the new digital technologies and wrap them in people, give them a more Agile, lean governance framework to experiment with. Once again, once you see this pattern, you see it everywhere. It’s fundamentally a teaming strategies problem, an orchestration problem, a dependency problem.

And again, I just think the root of the reason why I don’t think that’s hard to understand, and I don’t think most people would disagree. But the hard part is seeing past the current constraints.

How do you get the people in the organization to understand that this is the problem at hand, right? And then how do you get executive buy-in to make the changes? And once you have the buy-in, how do you manage and cost-justify the change? All those things.

Transformation is Transformation

Over the last couple of years, we’ve been working on larger and larger Agile Transformation work, it’s really interesting. It’s not just about installing Scrum. It’s very much in the space of digital transformation, cloud migration, and technical uplift. We call it Agile transformation, but all those things are interconnected. They’re all in the same space. How do I take my people, align them with the business, take the technology, align it with the people in the business, minimize dependencies, so folks can operate with more local autonomy and make good decisions on behalf of the customers?

Because that’s what we’re really trying to achieve. And so, I’ll say it one more time. If we can’t figure out how to overcome our current constraints and create the necessary conditions, we’ll just keep throwing dollars at this. We’ll keep throwing technology at it. We’ll keep throwing new processes and labels. But at the end of the day, it’s the same thing. It’s the alignment of people, process, and technology.

It’s kind of consulting 101. But what does that mean? Encapsulation, orchestration, minimizing dependencies. If you can encapsulate, you have to orchestrate. If you can’t break dependencies, you have to manage them. That’s the problem. What we really need are organizations that are adaptable. That’s why we’ve been gravitating towards the term “composable enterprise” because it brings together the systems view, the technology view, and the people view under one umbrella.

I’ve been using that term a lot, trying it on a little bit. It’s an interesting thought. So feel free to reach out, make a comment. My team keeps me updated, so I can engage and reply. I’m super happy to do that and I look forward to the conversation. Thanks a lot, guys. Have a great day.