Executive’s Guide To Large-Scale Agile Transformation & Sustaining An Adaptive Enterprise w/ Mike Cottmeyer

Mike Cottmeyer explores the key attributes in each of the three systems necessary for making a success out of the otherwise complex tax of large scale Agile Transformation. The three systems include a System of Delivery, a System of Transformation, and a System of Sustainability. In this talk from Agile Arizona, you’ll learn the critical success factors of each system, why they are necessary, and how they work together both individually and collectively to help build momentum, become a more effective delivery organization, and sustain that momentum over time.

Transcript

– [Announcer] This is Mike Cottmeyer’s talk from Agile Arizona, The Executive’s Guide to Large-Scale Agile Transformation and Sustaining an Adaptive Enterprise.

– So I’ll tell you a little bit about me and my background and the kinds of things that me and the folks at LeadingAgile are doing and what is really shaped this talk and this conversation. So we started LeadingAgile about 10 years ago. And what we are is we’re a consultancy that’s focused on doing Agile Transformation specifically. And what that means to us is not just teaching people how to do agile or how to do kind of methodologies in this space like say for Scrum or what have you but really like how to create the kinds of organizations that really can do agile really well and really effectively at scale.

One of the most formative experiences I had before I started LeadingAgile, I worked for Version One for a little bit here in Atlanta and went in and got to spend probably, a lot of time with maybe 150, 200 different companies and got to see how folks were dealing with agile and Agile Transformation. And one of the things that I got really clear on was one of the biggest impediments to actually being able to do agile effectively was things that you guys all know.

So it’s like the ability to form teams, the ability to create clear backlogs the ability to get to a working tested increment of software at the end of every sprint. And when you started to think about like how did you scale that? Like what are the networks of teams? What does it look like when we’re doing large scale teams of teams? What does it look like when we’re trying to figure out how to do agile governance? What are we asking our organizations to measure in control? Not only at the team level, but at the program level at the portfolio level, at the strategy level, like at the macro level of governance and that was kind of the problem that we really set off to solve. And the way that I would talk about it with people is I would tend to start to build from kind of a team level perspective up to an enterprise perspective. And then a couple years ago, it really kind of dawned on me that people had started to form a point of view around what team level agile was or even what enterprise level agile was. And a lot of times I was getting a conversation that went something like yeah, I’m not talking about team level stuff. I’m not talking about SAFe. I’m talking about business agility or I’m talking about something else.

And what I was starting to recognize in these conversations that I was having with executives was that people are hunting something that is different than team level agility. And they’re hunting something that’s even different than what I might even call enterprise agility. They’re really hunting organizational agility like how you get your company to become more agile, like at scale, like they weren’t talking like Fortune 10, Fortune 100 companies sometimes what does it mean to have business agility at that level of scale? And I was noticing what was going on in the market. And there is a shift towards talking about business agility, or digital transformation or like the industry is hunting some of these big words. And so what we started to try to shift the conversation into when we were out doing talks was not so much about practices at the team level or even at like the department level or the division level. But like, what does it talk? What does it look like to do? Like agile, like really, really big but to have actually have an adaptive company.

And so that’s kinda what we’re talking about, but one of the big challenges is when you’re dealing with agile at that level of scale like how do you begin the process of transformation? Like how do you start it? And so what I was hypothesizing is that in order to get organizations to actually move. In order to get them to even start to have the conversation with you, there’s a couple of prerequisites that I wanna introduce you guys to. And so it’s not gonna be anything that is that mind blowing, except I’m gonna try to frame it in a way that it’s very big. So in order to get executives to really pay attention to doing any kind of large scale transformation anything that we talk about with regard to agile whether it be at the team level or whether it be at the enterprise level, program level, strategy level what have you is that we have to anchor on executive level value and a lot of times what that means it isn’t velocity at the team level. It’s not even necessarily features delivered.

What it really is the ability to be able to deliver dynamically products to market in a way that is satisfying strategic objectives. It’s about the ability to pivot that strategy when we learn new things about what the market needs. So again, I’m anchoring not on feature level agility that we often talk about when it comes like agile software development but how do I pivot an organization? How do I adapt the organization’s ability to deliver value dynamically to a changing like market? And think about like what we’re going through right now with COVID. A lot of these companies had to pivot from, building whatever healthcare product they were building to building PPE, or some manufacturing companies were going from building automobiles to having to build ventilators, things like that. Like what does it mean to have like that kind of business agility, the ability to redeploy strategic business capabilities into something totally different. And so there’s a lot of things that go into that. But a lot of that value conversation is some around predictability and return on investment and product fit and innovation and such.

But a lot of the indicators have to do with like how well are our business capabilities align to the market? How well do those business capabilities operate independently of the rest of the organization? Do we have encapsulated delivery units that can be redeployed against the different value prop? There’s lots of different things that go into this conversation. And so aligning towards what executives care about when they talk about agile and they’re not really talking about Scrum and velocity or even SAFe and feature level throughput, they’re talking about how do we redeploy our corporate assets in a way that allows us to achieve our strategic objectives.

So that’s what executives are thinking about right now. They’re not thinking often about like team level Scrum. So then the next thing becomes, okay, so we’ve signed up that we’re going to do some sort of transformation and the hypothesis is that we’re gonna be able to align that transformation towards enterprise class business value. Now, what you find is that when you start to get above a few 1,000 people and you start to get into the tens of thousands of people you have to have some sort of leading indicator that tells you that you’re making progress. And so we’ve decided that we’re going to do this thing. We’ve decided the value that we want out of it now how are we going to be able to measure that we’re actually moving in the direction of this increased level of business agility and these increased level of being able to dynamically pivot business outcomes. And then on the backside we need lagging indicators that actually say are we achieving the business results that we want?

And so what we find is that when you’re talking to executives and you’re trying to influence leaders if you can align with their strategic value you can give them a way of measuring progress along the way. And you can actually prove the business benefits that you’re trying to achieve as a result of this enterprise transformation. What you can do is you can keep the executives attention longer long enough to actually make measurable change within organizations. But it requires a level of thoughtfulness, planfulness intentionality, and really making the changes in the organization that actually prove the business benefits that you’re looking for. Okay, so that’s like the first thing to being able to lead change and to be able to sustain change is anchor to business value, be able to show a measurable progress and be able to show measurable results along the way.

So let’s talk a little bit about why this conversation around business agility is really, really difficult to have. It’s a little provocative saying why it fails but sometimes it’s difficult to even figure out how to start the conversation. And so sustainable business agility. A lot of times we focus on agile as a methodology or agile as like a work group development or a way of building products collaboratively and things like that. But a lot of times, and you guys know this. You guys experienced as viscerally every day in your jobs. It’s like the methodology is only part of the problem how the business is organized, how it thinks about governance, how it measures and controls, investment and value is often in congruent with what it is that we’re trying to deal with in the enterprise problem.

And so like what we’ve been exploring and LeadingAgile is how do I create the conditions that these methodologies can really take hold and deliver this value prop that we’re trying to do. And so we’ve been talking about I’m gonna unpack this a minute, but we’ve been talking about the difference between what we would call a system of delivery versus a system of transformation. Making a very clean distinction between the operating model that it’s, we’re trying to install to achieve the business benefit, but distinguishing that from how we’re going to actually install that model over time. So like where I wanna try to go here. I keep clicking on a keyboard is like for example.

So if we think of a system of delivery is like team level Scrum. And so we could teach the organization how to do Scrum and we can say, okay you have a team of six to eight people. You have this role called a Scrum master. This is what a Scrum master does. You have this role called a product owner, and this is what a product owner does. This is what the team does. Here’s how you do sprint planning. Here’s how you do a daily standup here. So you do review and retrospective to say, do a burn down chart. This is how you write a user story. This is how you get to a definition of done? All those kinds of things. That’s like the system of delivery. The ecosystem that system of delivery operates then is the presence of a complete cross functional team. That team has to have very few dependencies.

That team has to be able to produce a working test increment of software at the end of the sprint. That product owner has to have the authority to be able to create a backlog that they have basically decision rights over. That product owner can decide. So I need a backlog, I need a dedicated team and I need the technical ability to produce a working test and increment at the end of every sprint. A validated definition of done. The practices of Scrum, are the system of delivery. The conditions necessary to operate within that system of delivery is like the ecosystem that I’m talking about.

And so the idea of transformation at the Scrum team level is that you start people doing Scrum and then any conditions that don’t aren’t present have to become present over time. And, but when you start to scale that up and you have hundreds of teams, or even thousands of teams what you find is that just starting to do the system of delivery just starting to do the practices and hoping that the ecosystem emerges through trial and error is often a very expensive and disruptive way of being able to try agile.

And so what we’re seeing in the marketplace right now is that there’s a lot of folks that are doing agile in the presence of malformed teams, backlogs that are not conducive to being able to do iterative and incremental delivery having a general inability to produce a working test and increment of software the end of every sprint, but very fundamentally. One of the problems that a lot of Scrum teams have is they have a lot of dependencies between them and everybody else. And so those dependencies get in the way of a team being able to operate with agile. So we’ve kind of came to market as a community over the last 20 years or so. And we basically said, this is how you do agile but we didn’t pay enough attention to, okay how do we create the ecosystem within the organization to be able to do agile really well? And so where it kinda went, right?

And I guess, Dean Leffingwell came out with the first book on scaled agile. I think it was called “Scaling Software Agility” I wanna say back in the mid 2000s came up with agile software requirements. So it was about seven, eight years ago. I might be getting the exact titles wrong but that’s when SAFe first started getting codified. And what Dean was trying to do with SAFe and then subsequently Bas and Craig with Large-Scale Scrum and then Shriver and those guys with Nexus. And then I guess, Ambler just went out of delivery and Shallow way with some of the Flex stuff. Now, PMI, right? What we’re trying to do is we’re trying to wrap some of this team level agility with things that like help teams coordinate more complex issues across multiple teams.

So if you really think about what SAFe and all these scaling frameworks are is that they’re really a way of dealing with like departmental level agility. Maybe groups up to about 150 multiple teams with lots of interlocking dependencies. Okay, and we’re kind of loosely calling that like team level agility or enterprise level agility rather. The challenges, is that whether it be at the team level or whether it be at the department or work group level there’s still a lot of challenges organizationally with just getting the right ecosystems in place.

How do we get teams strategically formed? How do we get backlogs coordinated? How do we align team level agility and department level agility with organizational goals up at the program and portfolio level. And again, our experience is that there’s just a lot of brokenness, there’s a lot of functional silos. There’s a lot of traditional governance and financial metrics.

There’s a lot of problems with dependencies and getting to a definition of done at the end of every sprint. And you see examples of where more, I guess, newer organizations were kind of more digitally native, more agile native were able to do some of this stuff right out of the gate. You look at it companies that we’re all familiar with a lot of the web companies and social companies and things like that. They seem to have figured this out kind of natively without, necessarily getting super prescriptive about the practices of say for Scrum or what have you, but the companies that are not as digital native they’re struggling with, okay we want to adopt the practices of agile, but we don’t really know how to create the ecosystem necessarily within our organization to be able to do this at scale because the core fundamental problem is that all of the different value streams interact.

And again, I just generalize that it’s gigantic dependency problem. And so when I started like playing with this, we LeadingAgile at our 10 year anniversary back in August. So we’ve been at this for about 10 years and we’ve been very fortunate that we started off with some small clients and we’ve done, we’ve worked in a couple of Fortune 10 clients working in a couple of Fortune 10 clients now that are very large, very complex software and hardware, physical products enabled by software. A lot of really interesting complex things. And it’s more difficult and it’s more has to be more intentional than just doing team level stuff.

And so what we found is that we had to create this structured framework for figuring out how to begin to progressively untangle these organizations. And so we kinda coined this thing we talk about as a system of transformation. It’s basically how do you start gathering all the leading indicators? Like what’s your hypothesis on how you’re going to start to transform an organization that is just hopelessly tangled up. And what’s emerged over the last four or five years specifically for us is this idea of organizing like around business capabilities organizing teams around business capabilities focusing business capabilities on specific customers and then creating dedicated teams around these business capabilities and then measuring the performance characteristics of these business capabilities but being very mindful of the dependencies between them.

‘Cause remember at the beginning I was talking about when a company talks about business agility or like real enterprise organizational agility. What they’re talking about is not just the necessarily the ability to be able to insert new things or to pivot the workflow that’s going through the system. What they’re fundamentally talking about is the ability to redeploy delivery capability into radically new business problems as markets change and evolve. Even if it’s as simple as changing requirements to deal with uncertainty or to build products that our market wants.

The ability to pivot basically means that I have to have this dedicated encapsulated unit that can make autonomous decisions. And when these units are coupled with each other by dependencies, your technical dependencies, organizational dependencies or requirements dependencies then it limits their degrees of freedom. So what we found is that this process of transformation what it tends to start with is kind of organized around the structure that you want. Organized around something like business capabilities or value streams or product areas or something like that. Organize around what you want, what you can get today. Recognize the presence of dependencies but then what you have to realize.

And this is where I think a lot of the methodologies we’re dealing with fall short is that they don’t deal with cross team organizational dependencies very well. So what we found is that the transformation journey tends to start with overcompensating and over-planning and the presence of dependencies. Operating in an agile way down at the work group level but giving ourselves explicit permission to plan ahead and to deal with cross cutting concerns and dependencies because they exist. And recognizing that of the time. And I’m not saying this unilaterally, but most of the time in complex organizations, dependencies don’t self-organize away very easily.

So the transformation journey tends to start with overcompensating for the presence of dependencies and then systematically reducing batch size systematically breaking dependencies over time. Then as you begin the process of breaking dependencies then you can start to treat those teams like the autonomous units that they are. And you can start to think about funding business capabilities, or funding products, or funding these autonomous delivery units whatever they happen to be organized around value streams or whatever.

So the process of transformation, isn’t teaching people how to do Scrum and teaching people how to do SAFe. That’s part of it. But the transformation process is organizing around these hypothetically discrete, decoupled, encapsulated delivery units. And then dealing very practically with the dependencies in the early days. And then systematically reducing batch size and breaking dependencies over time. So the system of delivery what you find actually changes over time, because early on in the presence of dependencies in large batches you have to do things early. And then as you improve the system, as you decouple and reduce batch size, then you can start deprecating some of those compensating controls that you had in the early days. So the system of transformation evolves, the system of delivery, as you move closer to your desired instate.

Okay, and so what you end up with, and it’s very useful. Because what you find is that once you acknowledge that your system of delivery is going to change based upon the needs of the business and the nature of the dependencies that connect everything together then you can start to think about, I’m actually running a transformation program, that is evolving these different states of the system of delivery as we go. Now, for me personally, as the CEO of a company that’s outdoing this. What we’ve found is really interesting is that most people don’t fundamentally understand the story. They don’t really understand like how we’ve evolved as a community over the last 20 years.

So you think about like the signing of the manifesto back in 2001, what was going on during that time is Scrum was at the table, XP was at the table, Leanne was at table. You think about like what Jim Highsmith was doing back in the day, the only things that were kind of a nod towards anything that was like roughly at scale where the DSDM people in the FTB people. Most everything was like team-oriented stuff that was only like 20 years ago. And that’s kind of largely where we started within the last seven, eight, nine years. We started thinking about like how to scale these things up. So a lot of people that have experienced agile over the last 20 years, have experienced it through the lens of methodology. And they’ve experienced it often through the lens of methodology in appropriately applied into organizations that weren’t quite ready for it. So the methodology is wild perfectly effective in generally applicable. We’re often not actually delivering the promise that the methodologists that invented them we’re offering to the market.

So Scrum, I think there was a quote from Schreiber at one point in time. And again, he’s never called me on it, but it’s, I’m just I continue to quote him. He said something to the effect of like 78% of the Scrum implementations won’t get the value that people expect from it. And it’s largely in my belief just because we’re not good at forming teams, building backlogs and creating the right environment to produce work and test the software. I think SAFe often struggles for a lot of the same reasons, very difficult at scale to have truly encapsulated value streams, truly encapsulated product area. So, when you talk about business agility and you really talk about these sustainable adaptive enterprises this is what’s the difficult thing is that enterprise agility, business agility I’m actually loading my words up here too.

True business agility, true organizational agility in my opinion is predicated on enterprise agility and enterprise agility is predicated on team level agility. So it’s kind of like turtles all the way down. I don’t know where that reference comes from, but it’s like you have to have team level agility in order to get departmental level agility, to get enterprise level agility and all that stuff proceeds true business and organizational agility. But here in lies the challenge. When you start talking about team level agility people tend to anchor on how they’ve experienced Scrum. Or if you talk about enterprise agility they starting to anchor on how they’ve experienced SAFe. And we have to acknowledge that over the last 20 years that we haven’t done a great job creating really solid reference implementation that we can turn around and build upon.

Okay, so where I’ve gotten, where I start talking with executives about this kind of stuff is like you have to be really careful talking about team level and departmental level and even enterprise level stuff because it anchors the conversation. So when I find myself starting to do with these three bubbles that are on the screen right now is go imaginable world in which you had dedicated teams that were organized around business capabilities are something you cared about a value stream or a feature area or something. That team operated totally autonomously with no dependencies was operating off of the clear strategically aligned backlog and could produce a working tested increment of software every sprint. And then at the enterprise level we were able to have groups of teams that were focused on really, really large projects. And we could actually do something similar.

We could put strategic objectives into these large groups and reliably and predictably be able to every quarter or so have something of value that you really cared about like that would be a vision for the future. And so as I talk about this with the executives I’ve almost gotten to the point where I don’t talk about Scrum and SAFe anymore, because what we’ve done over the last 20 years we’ve kind of anchored them on that’s what the teams do. That’s what the developers do, that kind of a thing. And in order to have this broader organizational agility conversation, you almost have to extract it out and talk a little bit about, okay, let’s just talk about the attributes of an organization that leads to this level of business agility or organizational agility.

So on some levels, I’m almost saying it’s like we need to stop fighting the fight at the team level. We know it’s there, but this idea of team level agility, enterprise level agility and enterprise transformation is almost like a, I almost have to presuppose, it’s true to start talking about like what business agility is. So some of the conversations that we’ve started to have is, imagine a world, imagine a future state where you have an encapsulated business capability or an encapsulated value stream that becomes a reliable trusted system that you can now begin to delegate into. You can put your strategic objectives into and it becomes almost kind of like a black box in that, on regular intervals you’re going to get these business outcomes that you need. If you need to redeploy that business capability and point it at something else, it has a reliable system of delivery that you can delegate into to get the new thing that you want out of. So you envision that world. So one of the big challenges that we have this at the team level, persistent problem. We have it at the enterprise level persistent problem. We have it at the business level as well is how do we get our business partners to engage? And so, and it’s a problem at the big level, as well as at the small level. The classically represented like, how do I do Scrum if I don’t have a product owner.

How do I do Scrum if I don’t have an empowered business person sitting down with me? How do I do enterprise level agility? How do I run a SAFe PI planning meeting if I don’t have the right business people on the room? Well, it’s the same thing at the enterprise level too. And so at every level, whether it be teams or enterprise or organizational agility.

The answer is that what we have to do is we have to fundamentally we have to build the organization that reliably and predictably delivers business value. And then we have to offer it to the business and we have to teach them how to exploit it. ‘Cause one of the big challenges that you guys might imagine as a lot of times, the way that boards work and the way that markets work and things like that is that these executives have to make 12, 18 month bets. They’re making sometimes in some organizations they’re making three, five, 10 year bats. And so how do you teach an organization to begin to break down their strategic initiatives into larger chunks that can then be fed into these business capability aligned organizations that then get further decomposed into features that are being fed into work groups and they get ultimately fed into user stories that get down and funnel into the teams, such that the user stories and the features and the strategic objectives and everything all the way up yields the business outcomes that we want within this encapsulated business entity.

So the tricky here is, the trick is we have to figure out is we have to create the conditions where we know that the business can exploit this new way of being able to do work. And then we have to engage with them. And then we have to teach them how to use it to their economic advantage. We have to teach them to place smaller bets. We have to teach them how to inspect and adapt. We have to teach them how to pivot when they learn new things. But until we have the ability to actually do that we’re asking a lot of them.

So oftentimes whether it be at the team level, the enterprise level or at the business agility level within product lines and things like that. A lot of times what we have to do is we have to kind of work with them in their current world and their current understanding. Build this trusted and reliable system of delivery that enables them to be able to put smaller batches in and reliably and predictably get the right business outcomes out. And then we teach them about how it’s in their economic advantage to exploit the system that way. Really difficult to bring them to the table at the same time. Not saying it’s impossible, your mileage may vary in your particular organization but we find a lot is building a reliable delivery system and getting it working so that when we reach out and teach them how to exploit it and they actually exploited it then they actually get the results that we’ve promised.

A lot of times what we’re doing now is we’re promising them this ability to operate this way. But in reality, because the team level and enterprise and that transformation stuff hasn’t actually happened then what tends to happen is that we sell them on this idea and it doesn’t actually work that way and practicing and it gets cynics out of it so. Apologize, I’ve been doing a lot of talking today. So my voice is in the process of wearing out on me. So the system of delivery has to be encapsulated teams at the work surface level, operating off of clean backlogs able to produce a working test and increment at the end of every sprint. At the enterprise level we want encapsulated either value streams, products or business capabilities that can take strategic initiatives and reliably and predictably on a cadence of probably 12 to 24 weeks or something like that, be able to produce value into market. And then we have to make sure that we have the business engaged in such a way that they understand how to feed the system in smaller batches so that they can redeploy and realign these critical business capabilities.

When the markets around them fundamentally change. When we wanna go into new product areas or we wanna start building ventilators or we need a new medicine or we need a new something or other. But the only way that that level of business agility will work is if we have these encapsulated business units that have a reliable predictable ability to produce stuff of value. And then we teach the business how to exploit it for their economic gain on the other side. That to me is the very definition of like organizational agility. We want to be able to redeploy, just like at the team level, we want to be able to redeploy a team into a different product area or a different feature set. I want to be able to redeploy encapsulated organizations at different classes of problems.

Okay, so that becomes kind of a holy grail of organizational agility. It’s encapsulated teams at the smallest level all the way up into the organizational level. All the way up, but the transformation journey on that. The system of transformation there it’s a different level as well. If you’re familiar with any of my transformation talks or you’ve hit our website we talk about this idea of expeditions to base camps. And like, what we’re trying to talk about in that frame is an expedition is a group of teams, it’s a part of the organization that moves on a transformation journey together.

So think about execution level teams, program level teams portfolio level teams, strategy level teams. So like a complete vertical slice of the enterprise. That’s moving through a set of various states. So we have predictabilities, smaller batch sizes break dependencies, team level, or business capability level investment strategies versus like a lean startup thing where we’re just experimenting and market.

So there’s this whole transformation journey right at this level. But what’s been fascinating is that when you start to get into mega organizations, you start to get mega organizations, dependencies or like a really, really real thing. And, but it’s really difficult. It’s really difficult to go into like a large auto manufacturer pharmaceutical company or a large financial services organization and ask them to flip into a value stream oriented organization on day one. You might be able to get one or two of them. You might be able to get something that’s easy, low hanging fruit. But the reality is that a lot of these delivery capabilities are hopelessly intertwined. So when you start off and you’re doing your enterprise transformation and you’re organized around business capabilities.

What starts to happen is that you have to start building in layers to orchestrate the dependencies. And here’s the interesting thing them, in the early stage of a transformation the dependencies are really, really hard to see. But when you start to group teams in this way that we talk about an agile, whether it be around product areas or business capabilities, or what have you is the dependencies between them have to get surfaced up into program and portfolio level. And when the dependencies get surfaced and they start to be orchestrated across teams. It starts to be really clear organization where are the expensive dependencies to manage are, okay?

And this is something we’ve learned with one of our largest clients over the last couple of years. You couldn’t flip straight into a value streamlined organization, even though that’s where they needed to be. What we had to flip them into first was a business capability aligned organization organized around their business architecture. And then what you start to see is that there’s clusters of dependencies across that business architecture. So where there’s clusters of dependencies those tend to be really good candidates for like wrapping it with like a SAFe kind of PI kind of a thing. So you can’t quite see where the lines of demarcation are until you start explicitly orchestrating the dependencies. Where you start to see where the dependencies are then you can start to cluster those things into delivery units. And then at that point, that gives you a really, really clean line of demarcation.

So ideally I want dependencies broken at every level but once I start orchestrating dependencies and see where the expensive ones are sometimes I can start grouping them and then start to do something like a projects to products initiative because where I had to do project based funding before because all of the resources were all over the place in all dependencies and managing all that kind of stuff. What I have the opportunity to do now is to say, okay, gigantic funding increment for a product that’s given to this group of business capabilities that all have the dependencies managed within this delivery unit. And then I get one degree closer to this level of organizational agility that I’m looking for.

Okay, so the business transformation tends to go from team level agility, enterprise level agility, orchestrate, break the dependencies you can, orchestrate the dependencies that remain figure out where there’s clusters of dependencies. And to start to think about reorganizing your business capability focused teams into business units, where those dependencies can be encapsulated within a particular business unit and then start to think about changing the funding model so that you’re driving dollars into that business unit where all those dependencies can be encapsulated again rather have all the dependencies broken even within the business unit.

But if I at least get the business unit encapsulated to where it owns its dependencies and it has dedicated funding and it has accountability for business outcomes, then you start to think about this is how you start to shift the organization from a project-based mindset into a, more of a product based or value stream based mindset.

Okay, but that’s a process, sometimes it takes a while and there’s gotta be some intermediate steps in there because they can’t see how to do it until they’ve taken these early steps. And all of these dependencies get surfaced and start to be pulled out from being managed by the team. Okay, now I’m gonna up the level one more. We’ve been talking a lot lately about this idea of a system of continuous improvement. Okay, so if you think about the way that executives think about their organization, the, well, I guess the not all executives, I guess, think about it this way but a lot of organizations, large companies they think about their organization as a series of business capabilities or series of value streams.

So you have strategic objectives and then those strategic objectives light up their business capability map. They can see what organizations need to be invested in in order to be able to deliver this. So there has to be like a mechanism within the organization in order to be able to continuously kind of inspect and adapt around how to get the organization to change dynamically in response to competitive needs.

So again, I go back to the team level. So think about like a team that’s like self-organizing to be able to deliver a backlog, a work group that self-organizing be able to deliver a set of features and epics. Now we were talking about how do we reorganize a group of business capabilities or division to be able to redeploy assets dynamically into marketplace. And so we’ve been playing a lot over the last couple of years ’cause of this idea of what we call a system of continuous improvement that down at the lowest levels has things like the like communities of practice and training and coaching capabilities and the ability to do performance and health checks and assessments and things like that. But also things like business architecture, capability realignment, strategic capability, realization, things like that.

And so what you end up with is almost like a function that gets built that is really designed to help dynamically reallocate the organization as the business needs and then the marketplace change. Okay, and so what that looks like kind of in practice, as we start to talk about going through and doing this kind of large scale transformation type of event, is that you start off with this idea of a system of transformation. And the system of transformation is designed to act on the organization, so that it moves progressively through these different systems of delivery. Team level instantiation, enterprise level instantiation, enterprise level transformation and the ultimate integration of the business on the other side.

That’s the holy grail. Encapsulated divisions aligned with strategy, business and IT working hand in hand to be able to do this. So the system of transformation orchestrates and installs the system of delivery, the system of delivery is this emerging thing from highly dependency focused and coordination and management control. And then as you improve the system you start to decouple teams, you start to get smaller batches, you start to break dependencies, things like that. The system of delivery changes over time.

As you start to get the organization into a healthier state the things that you were doing the calm compensating controls or the compensating controls that you put in place to deal with dependencies and to deal with organizational dysfunction as you transform the organization you can start to deprecate some of those compensating controls, and you can go into a more of a pure play agile kind of situation.

Now, the other side of that is while you’re building this system of delivery you have to kind of build the care and feeding of the organization as well. So you probably want to build an internal training capability. You probably want to build an internal coaching capability, an internal business architecture capability, communities of practice, things that like monitor the organization for its alignment to the strategic objectives and roadmaps and things like that. So those are all things that are candidates for being in this system of continuous improvement. So the idea is that the system of transformation kind of gets the system of delivery and simultaneously starts to get the system of continuous improvement.

And then what we’re finding is that after a minute, one of the things we might recognize as agile is this is a continuous journey. Getting better over time is something that you never stop doing. But I will tell you that a lot of the organizations that we work around, they get into something that I might call like transformation fatigue, and they get to the point where they’ve invested time, dollars, what have you in this heavy lift, into this new way of working this new operating model. And at some point they wanna say, “Hey we’re done transforming.” And so one of the ways we’ve been thinking about is in modeling it is that after your formal transformation is done, you have the system of delivery, which is kind of in the business, it’s the work of the business.

And then you have this system of continuous improvement which is the stuff you’ve built that continuously works on the business. And I think it’s a fairly compelling story especially for internal coaching teams, because a lot of times organizations make a solid investment in the idea of transformation. And then when they get done with the transformation they basically say, okay, we’ll done transforming. Let’s all the coaches go kind of a thing. Let’s let all this infrastructure that we’ve built to sustain this go, but getting very explicit with the idea that this continuous health check monitoring, coaching, training evolution of the organization. The organization isn’t static because it’s an adaptive enterprise. It’s an ongoing concern.

So if we can figure out a way to build a capability that continues to adapt and add value to the organization by helping it continuously reinvent itself. That’s kind of like the secret to it.

Now I’m gonna make one final point and then you guys get some questions ready. And we can talk for a little bit. I actually tried to hurry this talk up a little bit so we can have a few minutes for questions. So don’t let me down be ready to ask some questions.

So, basically, so if we go back to the first slide. I should have put it here as the next thing. But if we go back to the first slide we wanna align to business value. We wanna align to the things that the executives care about. We wanna be able to demonstrate intermediate progress and we want to be able to demonstrate business results. And so what we found is that by thinking about the organization in these ways, then what you can start to do is you can start to put together a very structured and disciplined, managed kind of change program because the work of the transformation at the team level is forming teams, getting backlogs clear being able to produce work and test the software.

And the actual work is removing all of the impediments that get in the way of that. And you guys experienced this, those impediments are non-trivial even at that level. At the enterprise level we have to start thinking about how we’re going to structure in a structured and systematic way begin to introduce the coordination across multiple teams even when there’s dependencies between things. And then how do we any structured disciplined way begin not only to engage the business but to get them to start reorganizing such that they’re localizing dependencies and being able to do this organizational level investment funding this projects and product stuff.

And so when, but again the point being is when you untangle all this and you think about it very systematically like it’s not just like train a bunch of people on how to Scrum, hope they self-organize all this stuff away and kinda wish for the best. And if they don’t do it, then they just didn’t get it. Like people need help with this stuff. They need help untangling their organizations.

So focus on value, orchestrate a change management program that actually helps the organization systematically in a very business value driven way, start to break these dependencies. And then as the dependencies get broken in the organization begins to improve. Then you can start to see the actual business performance and the business metrics. And then it gets supported by the system and continuous improvement over time.

So that’s my story. So what questions you guys have for me got like seven minutes. No? You get seven minutes of my day back. You guys get seven minutes of your day back.

Eric Willockie, man how are you doing? I’m actually going through lists good to see you. Good to see your name. It’s good to see everybody else. I just happen to know Eric, so it’s been awhile.

– I’m trying to come up with a tough question for it to be covered as well.

– Yeah well, cool man it’s good. Now it’s good to see your face even, excellent. Yeah, so it’s interesting. So when it comes down to it’s like, Eric I guess I’m talking to you a little bit directly here but it’s like the life of a consultant. It’s like, we’re going in and you’re trying to add value, but you’re trying to add value in a way that like everybody sees the incremental progress and you wanna get to a place where like the engagement kind of pays for itself. I would suggest that even if you’re an internal group. It’s like, I’ve seen a lot of coaching teams get, rift internally because the things that they were doing didn’t necessarily add up to the promise. So one of the big goals here is trying to figure out how do you go about doing this kind of change in a way that it’s like, I use the metaphor of like calling your shots and pool. It’s like a really good pool player knows how to run the table. And one shot sets up the next shot and everything you can like call your pocket. So this is a lot about being able to call your pocket and be able to say, I’m gonna do this. I’m gonna do this, I’m gonna do this. I’m gonna do this, I’m gonna do this. And then all of that sums up into sinking the a ball. So yeah.

– I do have one for you, Mike you talked about the groups that go through change together. I think that was transformation units. I forget what word you used for it.

– Yeah, expeditions but yeah.

– Expeditions, say a little bit more, if you don’t mind about how you design those or select them or draw boundaries without pulling the whole enterprise and makes nothing.

– Yeah there’s a little bit of an art and science. One of the things, you know Dennis Stevens he’s got, co-founded LeadingAgile with me. He came from a business architecture background. And one of the things that he and I actually used to fight about a lot 12, 13, 14 years ago before we even really started this thing was the idea of business architecture and business capabilities. And he was doing a bunch of work like David Anderson, Corbus, Microsoft, and that space. And they were writing HBR articles and stuff around this whole idea of business capability modeling. And it was pretty early in my understanding and the industry’s understanding. But in practice, like what we do is we kind of we look at the business architecture of the organization and the organizing hypothesis is get business capabilities, technology capabilities, and organizational delivery like people like into units. So, there’s a bit of a hunt, some art and some science. So it starts with business capability modeling. It starts with technology rationalization. It starts with organizational design and then you start creating hypotheses around how you’re going to group teams. And it’s usually by like nested business capabilities for us to start with. Okay, so we usually try to do it around the business architecture and if we can get teams operating at the lowest levels and then they roll up into like, Leffingwell might call like a program or a portfolio but you could think of like small business capabilities midsize aggregates of business capabilities, large organizational business capabilities, that tends to be our starting place. So a group of business capabilities and their associated orchestration layers is a candidate for us, for a expedition. That’s kind of how we think about it. Now ideally like if I was in a small organization this is where I have to get be really careful. ‘Cause sometimes we’re dealing in super big organizations. Sometimes we’re dealing in smaller organizations. Smaller organizations sometimes you can go straight to teams. Sometimes you go straight to value streams, like whatever. You don’t need to jump through these hoops, but some of the large Fortune 100 ones. You have to untangle them over time. And so what I’m really talking about as a strategy for how to help them untangle over time and in practice we find that it’s more straightforward and higher business value faster to be able to organize around the business architecture, surface of the dependencies. And then once you have the dependencies really clear then start to reorganize around value streams and do some of the program and portfolio governance changes that are gonna have to remain. As like a it’s like a two minute answer to probably a day and a half conversations. I have to fly to Atlanta and we’ll have some whiteboard sessions notes. Okay, anybody else?

– [Roger] Hi Mike, this is Roger, I still have a question along the same lines. Oftentimes, in a large corporation you have multiple pleasing similar at work. And when you go through something like a transformation you often find it’s more efficient to bring that together so that they can work towards that goal, to having their conversation can be difficult at the large organization. Do you have any tips in how to kinda get that conversation started?

– Yeah, so it’s actually not just multiple teams doing similar work oftentimes as you probably are well aware of they’re actually building like duplicate technologies. There’s lots of different technologies doing similar kinds of things within the organization. So that’s why we actually like this capabilities focus approach because very dispassionately you can look at where all the like all the business capabilities that are going on in your organization, you can kinda decouple it from how those business capabilities are being deployed. And you can very easily look at duplicated business capabilities and places where there’s not only duplicated business capabilities but there’s duplicated technologies servicing similar business capabilities. And what it does is it gives you the opportunity when you do the org redesign and you kinda create your in-state hypothesis for figuring out how to rationalize those things and overlap. Okay, and so I don’t want to have the conversation ad hoc. Because I know inevitably that I’m dealing with somebody’s fiefdom or their domain or their job, what they do. And so looking at the organization through this lens of business architecture and really asking the question do we wanna continue to maintain these similar business capabilities in these similar technologies across the different pieces of this organization? There’s also usually a lot of opportunity for cost savings in that conversation ’cause that duplication of work is very expensive. But I guess the short answer to your question is you do it in the context of a business architecture conversation.

– [Announcer] Thanks for watching for more content and upcoming events, visit leadingagile.com/events.