Why Agile Transformation Fails | AgileIndy 2021

Transcript

[Announcer] This is Mike Cottmeyer’s talk from AgileIndy, 2021 on “Why Agile Transformation Fails.”

– Okay, so we’re gonna talk about today is this thing I call “Executives Guide to Why Agile Transformations Fail.” And if you’ve been following my stuff, there’s really kind of a fascinating evolution of this story. So I got involved with agile back in like 2003 and I was working in this company called CheckFree. We were doing like large online banking bill payment kinds of things. And so my indoctrination to agile was never ever in the small. It was always large scale agile stuff. And I was working for this VP that was like really super cool, is very into agile and we were coming up with really creative things for like team formation strategies and agile governance, all stuff. And this was like way before the days Dean Leffingwell hadn’t even written his first book on scaling. None of the stuff on scaling was out there. So we’re inventing scaling models and really trying to bring this. It was like these four or 500 people, this organization through an Agile Transformation. And so I started writing about multi tier models and different teaming strategies and things like that and then I went to go work for version one for a couple of years. You guys remember them? It feels like I talk about them and I don’t even think they exist as a thing anymore. Version one CollabNet or something, I guess I call them now. So anyway, kind of a different company, but worked there probably about 10, 12 years ago and was going into a bunch of different organizations that were trying to adopt agile. And then the process developed a point of view around kind of why companies were jacking it up. And so I did talk on the three things and then we came up with this talk. It was just why agile fails. And the hypothesis behind that rev of why agile fails was largely about people trying to adopt practices of agile, and whether it’d be Scrum or extreme programming or now SAFe or LeSS or disciplined agile delivery, something like that, trying to adopt the practices of agile without the the words I would use now, but I wouldn’t use them, the business architecture necessary for those practices to work.

And business architecture kind of a nebulous term, but how do you form teams? How do you form teams across the enterprise? What do you organize those teams around? What responsibilities do those teams have? Do they own the technology or do they have dependencies with tons of teams around them? Where are really good clean backlogs coming from? And then how do we make decisions when teams are in conflict and how do we subordinate backlogs to a portfolio? How do we measure progress? How do we control things? And so I’m looking at like all these people that were trying to adopt Scrum and what they were missing was this idea that if we can’t form complete cross-functional teams, giving them really super clear backlogs and give them the ability to produce a working passive increment of software at the end of every sprint, then it would fail. So over the years we were building on that idea and then I think we came up with something like the executives guide to Agile Transformation. And then we were talking about just different ways of elevating the story. A couple of years ago, we ran a conference, we were supposed to at last year, hopefully we get into this year here in Atlanta called Elevate Agile and the impetus behind that was that, a little bit about me, if you guys don’t know, I started leading agile, like 10 years ago and I went out as an independent consultant and over the last 10 years, I’ve got about 150 people that work for me. I’ve got like 50 open jobs right now. So if you’re a really solid agile coach, call me, but like a change, enterprise transformation kinds of things, like big stuff. And we pay really well for those position. If you’re really good, call me. But anyway, so we’re gonna be like 200 people as soon as we can find those 50 people and we’re gonna grow to 250 and we’re working with like fortune 10, fortune 100 kinds of companies. And we’re trying to go into these organizations and we’re attempting to make really meaningful business changes.

We’re trying to connect a strategy. We’re trying to align organizations and teams to like core delivery capabilities and trying to get the flow work to move through in small batches, being able to put releases out quarterly. All of the things we want to do, but like really systematically at scale. And it’s difficult as you guys might imagine. And so one of the things that we started talking as we were evolving this elevator agile story, I started really using this in my conversations with executives to talk about why they were struggling and why this was hard because over the last 20 years, one of the big things we’ve done is we’ve to some degree and we’ve done it with like honesty and good intent, but we’ve kind of sold the executive community kind of a bill of goods. If you just do Scrum, you’ll get the goodness out of it. You just do SAFe and you’re gonna get the goodness out of it. But the reality is, is that in practice quite often, that those dots aren’t connecting. And where it really hit home for me is probably about 18, 24 months ago. I was doing some BizDev with a really large company in the Southeast and I think I tell like a fairly good story about enterprise agile and business transformation, all these things and I’m walking through this story, and this lady said to me, and it kind of caught me off guard. She goes, agile is something that the teams do. I’m talking about business agility, helped me with business agility. And I’m like, that’s what I was talking about and it was just like, it just dawned on me that there’s this group of people that think like business agility is something different and it is, but it’s connected. And so what I started kind of noodling on was how do you begin to tell somebody a story about businesses agility without like going to the fundamentals of like team level agility. ‘Cause as soon as you try to about you’re in the business agility context, you go try to talk about team level agility, they go, well, that’s not what I’m talking about. I don’t mean Scrum. I mean, SAFe, I mean, business agility. But then if you stay up in business agility, like what does that even mean? It’s almost like you need team level agility to achieve business agility, but team level agility is like necessary, but not sufficient for business agility.

So what we’re starting to kind of wrap our heads around is, how do you hold space with somebody long enough to be able to talk about this. And so, as I was thinking about you guys tonight and trying to figure out how I wanted to spend this talk, because I try to use really lightweight, soft slides and just story tell with people. I don’t like to do like really super pre-prepared can talks. And so I have some notes here, so I’m just gonna glance at my notes for a second here in a minute. But I think what I want to share with you guys, it’s just the highest level and I’ll start flipping through a few slides here is why is our Agile Transformations failing? And I think probably one of the first points that I want to explore is this idea that team level agility somehow implies that we’re gonna get the business agility and I think sometimes we truly believe that and I think sometimes it’s true, but when people are talking about business agility and they almost always at any kind of scale, I want to go through an algebra transformation because they want business agility and they think that’s gonna get them there. But we need to start to understand how business agility is different from team level agility. And what are the concerns of the executives when they say they want to do a digital transformation. Separate, different, but often similar, overlaps. What about, well, they want to do a dev ops transformation? Why would they say that? I don’t know if you guys hear the word product driven organization, that’s one that’s coming up, like Gartner talks about it all the time. McKinsey talks about it. Different people talk about product driven organizations or one thing that I think is fascinating is this idea of projects to products. What does that mean? And what we’re doing is in industry is we’re trying to figure out, we kind of come to conclusion, the team level Scrum is insufficient. I think even this idea of enterprise agility as kind of embodied by like maybe say large scale Scrum nexus, disciplined, agile delivery, the scale method insufficient.

There’s something that the organization is missing. And so we want to be able to figure out how to have that conversation. So team level agility necessary, but not sufficient. I think another problem with why Agile Transformations are failing, and this is gonna be provocative and I’m gonna be intentionally provocative with you guys. Is that because we believe that team behavior emerges in the small and that we want people to collaborate and be cross-functional on a team, somehow we’ve extrapolated that out to the organization and said, well, Agile Transformation is emergent. we’re agile, we don’t plan agile or we’re agile, so all we’re gonna do is build a backlog and then run off the backlog. I just spent four hours on the phone today with a prospect that we were working for, and this is the reality of the situation. Kind of a quasi governmental agency, state level, really understands the work that’s going to be necessary in order to be able to deliver a transformation, but they always ask the question, when am I gonna have it and what am I gonna get for my money kind of a thing? Like, what’s it gonna look like and what am I gonna have and how much is it cost? And as you guys might imagine, really, really tough questions to answer, but if we don’t have a framework for being able to have that conversation, we’re really just kind of saying, trust us, trust us and let us coach your people and the goodness will happen. And that’s gonna kill us because this one large transformation that I don’t even know if we’re half way through. Probably been working with this group for three or four years, we have probably touched 1,000 teams, 15,000 people globally and it’s a 300,000-person company and the more success we have in the delivery, they want to bring us some product and HR and all these different things. These guys are gonna be transforming for a long time. And so this idea of spending millions of dollars and just saying, trust us, it’s gonna take multiple. We have to be demonstrating business performance changes as we go and it has to be really quantifiable. And so I think if we as a community want to have a solid shot at being able to have the impact that we know we can have, we are going to have to get better at answering some of them, these kinds of questions. And then maybe the last thing, and it’s probably related a little bit, is this idea of, we have to be able to connect the business outcomes.

It’s like sometimes as Agilists, we get enamored with what I might call it, the softer side of agile, the touchy, feely side of agile, teams and collaboration and work environment, and happiness and engagement, things like that. And all that stuff’s like really super important, but we have this debate internally quite a bit with my leadership team. We were talking about it the other day. It was like team level engagement or is team engagement a first order of business concern. Some people think it is and I get it right. But what I would suggest that it’s only a concern to the extent that we’re a profitable company, that we can put out software when we say we’re gonna put out software or put out product, when we say we’re gonna put out product. And so I’ll tell you guys a funny story at a COO at one point in time was working for me and we were joking before the call that people say they want to work for leading Agilists and I said, be careful what you ask for it ’cause it’s not all rainbows and butterflies. It’s kind of a hard place to work sometimes because we are super focused on client outcomes. And so this lady was like, that worked for me. She was like you’re gonna kill our culture if you don’t stop acting this way. And I went, well, if we don’t figure these problems out, we’re not having a company to have a culture. And so there’s this balance between you have to demonstrate outcomes while we’re building culture that we want to have. And so we have to decide, which is the first order of concern and which is kind of a secondary outcome. Both important, but I believe if we’re not connecting to business outcomes, then we’re on very, very thin ice, especially if we’re gonna do a multi-year transformation. If you’re gonna train a Scrum team and you have like 20 people in your company, probably not as a bigger concern, but really when I’m dealing with transformation.

I’m really dealing with thousands of people in multinationals and how do you get big gigantic organizations to move? So what I’m gonna do for the next 40 minutes or so is that about how much time we have 40, 50 minutes, something like that. Start explaining to you guys a little bit about how we’re thinking about this. And so one of the things that I’ve learned, meeting with the C-suite and candidly selling people on the idea of how to do this. You start to get really, really clear on what executives care about. And it’s interesting. So if you hit our website, I talk about the value prop of agile. I talk about things like predictability quality, early return on investment, cost savings, innovation, product fit. I’m probably gonna have to change those here pretty soon because like what companies are trying to figure out is they’re trying to figure out, how do I align my, I want to say resources but I’m gonna try to avoid that word. How do I align my teams and my people and the assets that I have deployed to dynamically satisfy customer need? A lot of business agility is about, how do I pivot the organization? How do I dynamically when my market shifts, how do I redeploy parts of my organization to do the most valuable things? So a lot of times at the enterprise level or at the team level, we’re thinking about how to change requirements to build the best possible software at the level of business agility, businesses, transformation, what we’re really trying to do is how do we change the organization to meet the dynamic needs of the marketplace? And so regardless of whether we’re doing a predictability quality, early trial investment, cost savings, innovation, product fit, or we’re trying to make a dynamic strategic alignment play an allocation of resources to the highest priorities, dynamic reallocation of teams to different business needs.

One of the things we have to be really clear on is what is it that we’re actually trying to solve? What is the value profit that executive cares about? I’m getting confused and to make computers here. So the second thing that we have to have is we have to have a metaphor or some way of talking about how we’re making progress. And so one of the things, and I don’t think we’ll get super deep into this tonight, but in some of my early talks, I talk about this thing called the four quadrants and I talk about I introduce this idea of expeditions and base camps. And the reason why we did that is because when you start off with an organization that’s going through a transformation, there’s so much that has to be done. We have to get teams formed, we have to get dependencies broken, we have to get the teams aligned with value, whether that be business capabilities or value streams, or feature sets or whatever. We have to figure out how to install governance. We have to be able to start reducing batch size. We have to start getting predictable. We have to implement a whole different kinds of metrics systems and get them thinking about how to dynamically allocate and break things into smaller pieces, tremendous amount of work that has to be done conceptually across the enterprise to get everything into alignment. And what we’re finding is that if you point where you’re going too far out and all people can see is the resistance, they don’t want to move. And so what we started trying to think about was how do you break this up into smaller pieces? And so we came up with the idea of base camp one. Get the organization predictable. Base camp two, start to reduce batch size, base camp three, break dependencies, base camp four, let’s start investing in teams rather than in projects. So it’s a little bit where the projects, the product story kind of comes in. And then base camp five was like, okay, so now we have these encapsulated, independently funded teams. Now, how do we get them to go out and be more innovative?

It’s a long road for a lot of different parts of the organization. So how are we gonna measure progress along the way? So we created this model. It takes the base camps and outcomes and there’s activities and very Gantt chart or should I admit, or you just think about it like a rolling wave backlog, kind of a thing. There’s a lot of different metaphors. But what we found is that it’s really essential to keep the organization’s attention is you have to be able to decompose the work in a way that as you’re moving the organization along, coaching consulting, doing workshops, helping develop skills, helping to stabilize velocity, things like that, we have to be able to tell the organizational story about how the work we’re doing is progressing against our plan and then we also have to be able to track that back to value the whole time. And so the last little bit is like measurable results. And so we can’t wait until the whole organization has changed in order to start seeing benefits. So we have to start even breaking our value hypothesis up into smaller bits so that we can do some work. Like we can say, okay, we’re gonna get this group of teams, we call them an expedition to base camp one to be predictable. I can do these seven teams in three months with two coaches and I can demonstrate that they’re gonna be able to make any commitments. They’re gonna be able to operate off of a known backlog, and they’re gonna be able to deliver against the known backlog in a reliable and predictable way. Like that’s a result that I care about. It might not be the ultimate value that we want, but it’s like a leading indicator. And so what you start to see, I don’t know if you guys are familiar with the concept of leading indicators and lagging indicators, but it’s like a leading indicator is like, okay, what can I measure that’s really real that gives me confidence that the things that are gonna take months or years to measure are going to be delivered? And so what we find is that you can set up the right leading indicators, measure progress against them, and then show enough intermediate lagging indicators that are showing that the actual, the business performance is actually improving, then you can create a longer term roadmap to where you can hold the organization’s attention long enough to actually go through these changes. Super fascinating like thing. But this is what organizations need.

You have to align the transformation to the value that the executives want, the performance characteristics of the organization. You have to structure the transformation in such a way that we start to see these leading lagging indicator relationships and then as we do the leading indicators and lagging indicators, we have to start seeing incremental measurable progress. We get in the trap sometimes because we don’t really have a solid plan for how we’re gonna do the transformation that we start, they’re like vanity metrics. I’ve run all these people through Scrum training or I have product owners on every team, or I have a Scrum master on every team or every team has a backlog. That’s probably not a totally invalid one. But unless we can connect those things we’re doing to the actual performance of the organization and show a direct correlation, people get tired of spending money on this stuff really, really fast. And we experienced that viscerally as a consultancy, but you guys experienced it too. You need four more coaches or you want to do whatever or you want to go do this training and people get to a point where they’re like, okay, look, I’m tired of spending money on this stuff. I don’t see any change. Or the change, they might give you small dollars to do things because okay, fine, we got to train people anyway, if you want to train them on Scrum, who cares, but unless we’re really getting the value, we lose the ability to actually engage the executives over time. Okay, cool.

So that’s kind of like the start of it. So now what I’m gonna do is I’m gonna kind of pivot conceptually for a minute and I’m gonna start talking about the different layers of things that we need to think about. And I’m gonna ask you guys for a minute to kind of like suspend disbelief a little bit until we get enough of the story told that you can start connecting some dots across these different things. And so sustainable business agility. So one of the things that we’re talking a lot about is we have four different systems that we’ve codified in leading agile. So there’s one thing we talk about just the system of delivery, which is basically like your agile operating model. But that’s really only part of the story. So one of the things that’s fascinating is where we’re at 20 years, literally almost 20 years to the day of signing a manifesto, there’s a lot of people in this world that know what an agile organization is supposed to look like. They do, right? I mean, people get the idea of teams, people get the idea backlogs, they get the idea of working test the software, they understand how the technical practices fit in and they understand how dev ops works, they understand how agile program or portfolio governance. This lady I was talking to today when we had our first call with that group, she could articulate where she wanted to go so clearly. But in the question she’s asking is, well, how do I convince everybody else to do it? Because you have people in the organization that are worried about, are they gonna lose their job? Is their job gonna be materially different or are they gonna go from having a 50-person organization where they’re the boss to having nobody. People are like really scared of agile in a very visceral way. They want to know if their job is gonna exist. And again, another bad habit we have is telling people their jobs aren’t going to exist. And unfortunately I say bad habit, but sometimes it’s true, but it’s not always true. So we have to create safety for people. And so this idea of a system of delivery, the operating model is only part of the overall problem. Helping an organization understand how to get there safely and in a reliable and predictable manner, I believe is the secret sauce. The third piece is once you’ve gone through the transformation and now remember, my brain is like, I’m not thinking about team level agility, I’m not thinking about enterprise agility, I’m thinking about dynamic organizational agility at this point, when I’m talking about business transformation at this level with exact, because that’s what they care about. So what I have to think about is what are the organization’s mechanisms for adapting, not just requirements, but adapting the business architecture?

Which value streams are important? Which value streams should we invest in? What is strategic alignment to our marketplace? That kind of a thing. And so we’ve kind of codified this in terms of three things. I’m gonna cut sheet up. I don’t think the slides are gonna actually build this way. They might, but the idea of a system of delivery, a system of transformation, how we’re gonna get there, a system of continuous improvement and there’s actually a fourth system that I’m probably not gonna talk about it as much here, because it’s more specifically, it’s not really about the organization. It’s really about engagement, design, how we think about it. Well, one of the biggest problems as you guys might imagine is that you can’t walk in, snap your fingers and have everybody in alignment. So the question is, it’s like, how do you start to build shared cognition across the organization in order to be able to funnel people into agreement that they can actually do what it is we’re trying to do? And that’s it again, it’s really super tough stuff. We’ve learned a lot of this stuff the hard way over the last 10, 11 years at this point. So we have four systems. We’re gonna talk about three of them here and the first thing is we’re gonna talk about is like the system of delivery. So if you think about just small teams, Scrum, what is the system of delivery in small teams Scrum? We know that we have six to eight people. We know that they have ownership over the technology, stack. They don’t have technical dependencies. They have everything and everyone necessary to be able to deliver the product. They’re not worried about anything on the outside. They’ve got a really clean backlog. They have the ability to produce work infested increments software, and they do sprint planning. They do daily stand-ups, they do reviews and retrospectives.

They do burn down charts, they measure velocity. They do all this stuff that we’re super familiar with. And so the system of delivery in the small is actually very well self-contained. And so when you start to think about enterprise level agility, what we added, and the reason why things like SAFe and LeSS and disciplined agile delivery exists is because in most non-trivial organizations, again, I’ve worked with some fairly small organizations and no organization I’ve ever worked with has been a single Scrum team. There’s almost always multiple teams that have relationships between them and those relationships have to be managed in some way. So in the early days of this, we would talk and maybe we still do talk about this. We talked about a Scrum of Scrums. So Scrum of Scrums is like a lightweight way of coordinating the activities of multiple teams. And so the most simple understanding of Scrum of Scrums that I was ever exposed to was like, okay, well, the day of the Scrum masters are all gonna get together through teams and they’re gonna meet for 15 minutes afterwards and kind of do lightweight coordination. And that works when the teams are fairly decoupled and dependencies between them are the exception rather than the rule. What we’d find is that most organizations are trying to implement that Scrum of Scrums model, what would happen is that teams would come out of sprint planning and they’d have fully loaded backlogs. Somebody in another team would go like, I need this team to do something. And they go, oh, can you do it? And they’re like, well, no, I can’t. You’ve got to put it in the next sprint. Well, so now what happens is we have teams that are delivering asynchronously. They need each other, they have dependencies, but they don’t have a mechanism for coordinating dependencies across multiple teams. So what starts to happen as people are stuffing out code, and they’re putting things in other people’s sprints and nobody’s delivering what they say they’re gonna deliver on time and business value just gets further and further and further out of sync. Fairly, hopefully famously on record, just to me, I think dependencies are the root of all evil when it comes to agility.

People, I still read stuff on LinkedIn about how people are talking about like like how monstrous SAFe is and how awful it is. Well, what SAFe basically does and the reason why I say it exists is it acknowledges the presence of dependencies. So what are you gonna do when you have dependencies? Well, you only have two choices. You either manage them like SAFe tells you to do, or there’s other ways. But you manage them like a heavyweight SAFe implementation, or you break them, right. People don’t fully understand about LeSS, the whole LeSS operating model, the system of delivery behind LeSS is largely a dependency free environment. It’s like a pyramid of independent teams. Makes total sense. Totally support what those guys were doing with that if you truly don’t have dependencies. So this is another interesting thing. I think super, super fascinating is, I mean, you think 20 years ago, when again, this is very timely, these guys were celebrating the 20th anniversary of the manifesto. They were talking about teams of people getting in a room. I think the XP guys called on-site customer. The Scrum guys called a product owner. I don’t know what the formal times, those seem to be the two that lasted. But the idea was is that we would get the business involved. So somebody who has authority to decide what goes into the product would be in the room with the team and that was the team’s way of doing it. But I know you guys have experienced this. I mean, to answer this question every day. What happens when you don’t have a product on our Scrum team? Well, it tends to happen in practice is you have a product owner, but they’re like a business analyst. They don’t really have authority. They’re just the person that’s feeding the team’s requirements. So what do you do when you have a non authority native product owner. That’s kind of a problem. And so as we’ve scaled out, even at the team level, like one of the biggest problems is we don’t really have business engagement. So why do executives think that Scrum is something to the teams do? Because nine times out of 10, the product owners actually in the technology organization, trying to be a liaison to the business, but it’s kind of in congruent how the business is operating. So it’s just this IT thing and it’s just the team. So you remember the execs are thinking, how do I adapt my business to the changing needs of my market? How do I align and deploy my resources to the most valuable things to improve my stock or my profitability or whatever? And we’re sitting down here going, I just need a product, I don’t care.

So with the best of intentions, we want to include the business, but we didn’t actually include the business. Now, I’ll tell ya, I know that SAFe, if you’re a SAFe person, has all the mechanisms for including the business. Very solemnly do I really, really see, I see two failure modes. I don’t really see the business included in a meaningful way or they’re included, but the business hasn’t really transformed. So they’re a bit of a standoff. The business is trying to play, but not really. They’re not really designed to operate the way that the enterprise level agile system of delivery is supposed to operate. They haven’t really learned how to fully exploit that capability. So they’re kind of doing things their own way. And so what ends up happening is that businesses there maybe, but it’s still not bad agility. It’s kind of enterprise agility because we’re coordinating dependencies. We’re talking about breaking dependencies and we have business representation in the room, but how do I go back to that same issue of what the executives want to be able to dynamically pivot my resources to exploit market needs as they arise? Tough. So one of the things that I think that we introduced, and I’m kind of proud of this, because I it’s been picked up by people have just settled on this, talked about it, but like our four quadrants model and transformation, the expeditions to base camps and things like that, what we were articulating that in market and we were doing it fairly informally and really rolling this kind of out into our clients, but this one really large enterprise class client that I’m talking about, we codafide at working with them because it was so big, we all had to get internal. We had to get our ducks in a row internally on how to do it. So what we basically did is we created these roadmaps of these groups of teams are going to these different base camps, running these outcomes based plans and we could really do progressive elaboration and rolling wave backlog against that roadmap, bringing in the work in a very dynamic and collaborative way to deploy our resources very consistently so that we could move this organization along. We instantiated roles, transformation leads, expedition leads, integration codes, different things like that to really codify how we were going to get these guys transform. And what we talk about, it’s like most great ideas, you don’t just sit in a room and invent them. You’re you’re doing the work on the ground. If somebody started my team, I think it was guy named Chris Spiel started talking about the system and transformation. And it was like the first major bifurcation of thought. We had always thought about systems and delivery but we really started exploring this idea of a system a transformation.

What’s cool about it, which is interesting if you can think about it this way is that the state doesn’t matter. If a company wants to go to SAFe, a company must go to LeSS, disciplined agile delivery, Scrum of Scrums, large-scale Scrum nexus, like whatever. Cool. So you ask yourself, in order to do this methodology well, what conditions have to be true in order for that methodology to work? I’ve actually realized I’ve learned this about myself. That’s actually I think, right. What do you want? what are the performance characteristics? What things have to be true, have to be true in order for those characteristics to be achieved? And then the work of the transformation is about making those conditions true. So if it’s, I need to have Scrum masters, cool. If it’s I need a product that is cool. More than likely, it’s something like, I need to break dependencies. It’s I need to align around the business architecture. I need the ability to form teams. I need to have dedicated teams around something that my customers care about. So you can start to think about, how am I going to sequence the activities that my coaching team is doing and my teams are doing? What skills do they need to have? What must they learn? What permission must they go get from the organization? What funding must I have in order to be able to create the conditions for SAFe to work? It’s kind of fascinating when you think about it through that lens. So your system of delivery can be incredibly custom for whatever business problem you’re trying to solve. Your transformation, your system of transformation is actually fairly repeatable. It’s really kind of interesting. ’cause here’s why it served people. The conditions that you have to create for almost any of these methodologies are largely the same. Forming teams, building backlogs, the ability to feed those backlogs to teams, able to produce work fits and increments software in small batches. Right dependencies so they can operate autonomously, right? It’s almost the same story, no matter which methodology you want. So it makes the things you have to do to be able to get there, to exploit that methodology fairly consistent. But here’s my challenge. This is why I’m out talking to people. So these three circles are becoming, I don’t say table stakes, but they’re becoming very uninteresting for most people to talk about. Because let’s say you want to talk about a PDO transformation.

So I’ve got a CFO. That’s like, okay, I want to align my entire organization around products. First thing it’s like, what’s a product? That was a conversation we had on our morning call this morning with my whole leadership team and my entire consulting company. Not half of the show so it wasn’t all of us, but there’s a lot of us. It’s like, what’s a product? I mean, we don’t have time here, but like, if I asked you, it’s like, what’s a product? On some level, it’s intuitive. It’s like something customer cares about. It’s a feature set. It’s like Microsoft Office, it’s Spotify, it’s like, whatever. But the reality is, is that it’s like products, most products that we have are made up a smaller products. So how do you have that conversation? How do the products that you align around in this product driven organization, how do they operate? What gives you the benefit, what’s the benefit of a product driven organization? How do things roll up? How do small products roll up into big products? So I mean, there’s a whole lot of stuff. Once an executive reads a Gardner report and says, yep, projects or products is what we need to do to stop this project funding. We need to go to products. The next question you have to ask yourself is how? And as soon as you start explaining how, you go into these three circles that I just had that aren’t interesting to people, ’cause they’re looking for something that’s very top level, like an overlay and what we know is that is that you have to be agile all the way down. You have to be agile all the way down. The way you achieve business agility is you have to have team level agility, encapsulation of teams and clear backlogs and the ability to produce work and has software, then you group those into a lightweight agile governance model and then you group those into portfolios and those are all encapsulated. And then you align those with the strategic organization and you call this set of things, products, and you stop funding projects, you start giving them steady funding. There’s all these different things in the how that are really difficult to talk about. People kind of want easy answers. And so what, we’re kind of figuring out how to do a little bit, as we learn about how to do this, is how do you talk about it in a way that these three things are understood? And so a lot of like, what I’m finding with executives is they say, okay, so you want a PDO.

Well, let’s talk about what has to happen in your business, how your business has to change, how your business has to think differently, how your business has to operate differently, fund differently, govern differently, all these things. So here’s the characteristics of your business. This is the characteristics of your product delivery organization. How does it need to operate? And so like, I don’t get into Scrum and I don’t get into SAFe and I’m getting these things, but I look at like, okay, so what are the characteristics of a business that has a delivery partner that can operate in this way? And it implies all these other things. And if anybody asks, how are you go on the ready? Align around business architecture, creating capsulated teams, agile governance, blah, blah, blah, blah, blah. You can tell that story, but it’s not an interesting story to start off with anymore. And again, it’s like, you almost have to assume it, even though it’s not really there to start off with. And so what I’m probably gonna do is I’m getting ready to package this talk up ’cause this is kind of where my head is right now in the industry. You’re gonna package it up for the agile conference, agile 2021 conference, which is gonna be virtual too, not looking forward to a virtual agile conference, another virtual agile conferences way. But they’re gonna try some interesting things with the format. So I’m gonna probably repackage this a little bit and really talk about system of delivery, system of transformation, system and continuous improvement probably at the team level at the enterprise level, the business level, probably blow this out a little bit more as I have these conversations and think about it. But again, like the core of the challenge is that nobody wants to talk about these three things anymore. They want to talk about business agility topics. And so that gets to the third piece. So how business agility in the business and like product management and stuff like that is starting to express you’ve heard us hunting for words, maybe not in the agile community per se, but in like business literature and such, and it kind of started like digital transformation was kind of swirling around it. We’ve got the Business Agility Institute spawned out of our community. I was actually caught off guard when people really started talking about product driven organization, PDO is a thing. That’s something that has C-level attention. And then it’s like the idea of PDO, projects, products. So that’s where, that’s the words that the industry is using to try to explain the way that they want the business to interact with the marketplace. And it’s not just about dynamic reallocation of teams to different requirements in a backlog. It’s more fundamentally the ability to dynamically reallocate teams to fundamentally different business problems. And I’m right on the edge of like word like inventing some of this stuff right now. So like I’m hunting for words to talk about it effectively with you guys, because here’s another interesting challenge. It’s starting to be like almost like layers. It’s almost you have to like lay layers of sediment in order to build these structures within the organization. And so our enterprise system of transformation was largely focused on this idea of expeditions going to base camps. So we take a group of maybe 100 people, maybe eight to 12 teams, and we move them to the state through an outcomes-based plan and we would build the stack all the way up from team level to programs, to portfolio. We get all the investment decisioning made on all these things. But then you look at like a large fortune 10 company where you’re dealing with 15,000 people and what you realize is that some of the things that actually have to change, like how funding happens across the organization, how governance and decision-making happens, how something like going from a project-based funding model to a product based funding model, how we communicate performance in the market, that stuff can’t change. The business can’t flip it until enough of the organization is at critical mass to be able to change it once and for all? So we have a bit of a chicken and the egg problem. It’s like, we know that fundamental things have to change about how the business interacts with the delivery organization, but the reality becomes is that, we live in these hybrid states longer than we would like, because enough of the organization has to move to where it becomes kind of the preponderance of the way we operate and we can start to change some of these frameworks. So one of the things that we’re exploring internally in this business transformation story is the idea of again, I don’t think we’ve got good words formed yet. We’re kind of calling them organizational base camps where it’s like, you bring these expeditions to base camps.

You get enough of the organization predictable that you can start to talk about changing how the organization makes and meets commitments or you get enough dependencies broken in aggregate that you can start talking about funding teams or funding organizations versus funding projects that span organizations. One really fascinating observation that we’ve had with a couple of these large multinationals at this point is that a lot of the guidance at the enterprise level, the enterprise system of delivery level says something to the effect of like organize around value and so how we do that is we figure out where the value streams are. I imagine any of you guys that are working in some non trivially sized company, you’re dealing with value streams that aren’t encapsulated. They all intersect. They run through the same resource pools. They run through the shared same services. They run through the same platforms, they run through the same, whatever. And so the mental model of flipping a large organization to be organized around value out of the gate is really, really difficult. People can’t even see it clearly enough to have a conversation. Even if they could see it hypothetically, again, you ask yourself like, how do you get there? And so like one of the things, and it’s just gives you like an example of the kind of business transformation threads that I’m talking about is so one of the things that we’ll do often, because it’s way more straightforward it and unlocks the performance of the organization is organized around business capabilities. And so you come in, you do like a heat map, look at the business architecture, you look at the organizational architecture, where people are, looking at the technology architecture, and you look for ways to create encapsulated teams. So you’re going to start forming teams and you start creating agile governance, agile program management, agile portfolio management, you start creating these pyramids. And you get work flowing through the system. That’s great, until you realize some business capability over here needs to coordinate with some business capability way over here, and the way you’ve set up your governance, that has to go up five levels before you can resolve a decision. So it’s fascinating is that in the transformation story, how you orchestrate a transformation is that all the coordination costs all get pushed outside the team in an agile governance model. So you look at SAFe, or you look at last or whatever, all of the coordination costs are pushed outside the team. It’s kind of cool and it makes it very, very visible. So you start to be able to have a conversation once enough of the organization is organized around business capabilities, you start to expose the orchestration costs up and down the organization and then you can make a rational argument that if I put these five capabilities underneath this part of the organization, then what I do is I reduce the latency and the orchestration costs across the enterprise. And what you end up with most of the time is being organized around value streams. So you don’t start with that because the value streams are too big, too complicated, but you start a business capabilities, expose your illustration costs. Once you see where the orchestration costs are expensive group them, and that becomes a value stream. It’s fascinating. So again, part of the reason it’s like, it’s really hard to build slides around this stuff ’cause I don’t think we have like dot answer yet, but what’s fascinating is that this pattern is starting to emerge in and some of these large clients and so the language that we’re using is starting to come out, we’re starting to figure out, okay, well, how does that relate to what the market wants to do with PDO or digital transformation or projects to products or business agility or DevSecOps at scale, all these kinds of interesting things. Super fascinating. But then you can ask yourself, you go like, okay, so now I’m in a situation where got enterprise agility taken care of. I’m starting to understand how the enterprise has to be at sufficient critical mass to start changing business behavior, then you can start to think about how do we orchestrate the business transformation. That becomes a really powerful story. And then you can imagine an in-state where you have encapsulated value streams, really solid business ownership, value streams are able to produce small batches on a regular cadence, and the capabilities are largely grouped, the ones that work together. So you start to think about that and now you can start to think about some of the stuff we’ve been talking about.

How do I take that value stream? How do I deploy it at pointed at something else in market? How do I go from making something like some sort of consumer electronics product to making ventilators or whatever? How do I flip on a dime in a way where I have this encapsulated business capability, and it makes sense to pointed at something else as the market changes? So once you have that, then like kind of Holy grail, a little bit keep pressing the wrong keyboard is how you pivot that organization. So some of the things we’re starting to explore with some of these clients is creating like a very persistent organization. And again, we’re working on the metaphors for it, but it’s almost like, how do you put in like a control that basically monitors the health and alignment to business objectives, to strategy of the organization and actually orchestrates pivot in your enterprise? How do you look at how the business architecture, the value streams are functioning, how they’re performing relative to market expectation and constantly innovate that. Some of the things we’re starting to play with are things like I don’t know, like formal business architecture practices as it relates to an agile enterprise, or sometimes it’s as simple as like communities of practice or it’s the ongoing ability to assess the performance of the different capabilities, making sure that the capabilities are pointed at the right strategic things. And so, again, we’re in the early stages of kind of hunting down what the system of continuous improvement looks like. So just to kind of re anchor on our theme for a minute, I’m gonna kind of pivot into the next little bit, and then hopefully we’ll have a few minutes for questions after I get through this. And I also apologize, I see like the chat as like 44 chats, it’s super hard to have a conversation and to talk about this and actually follow the chat. So maybe we’ll get a minute towards the end and we can maybe I’ll ask you guys to kind of put som of your questions back at the top of the queue and see if we can try to deal with it. But anyway, so these are like the things that we’re thinking about. So tying back on the idea of why business agility fails, it’s like, what we need is we need an organization that can pivot. We need a way to get there that is structured and measurable and demonstrates business value as we go. And then yeah, is able to prove results. And again, I think the challenge, I think the agile community has the answer. But our belief often, is that we can teach people Scrum and do the lower level system and delivery stuff and it will actually solve the problem. And so I think part of what I’m encouraging here is for you guys to recognize that there’s this third class, there’s this other set of problems that we’re trying to solve, this business agility problems, the governance things, the funding models, the PDOs, the PDPs, all those things that requires the organization to be at sufficient mass and sufficient scale to be able to flip these models. The transformation story becomes important is because if we can’t articulate with some level of kind of fine grained confidence how we’re gonna go about doing this and what the business benefits are gonna be as we go and be able to manage the expectations of the organization, then you might, if you have a really strong, like a really strong leader with really strong, kind of a cult of personality, kinds of behaviors that can really enlist people, you’ll get some energy around it for a bit, and you’ll get some movement, but these are multi multi-year things and a lot of organizations. And so you won’t sustain the energy. And so again, I just reiterate, that’s why it’s so essential to be able to get the intermediate results, to be able to show how it’s actually improving you now because if it’s lots of years of undefined pain to get to some promised land, you won’t do it. So the pain has to be counterbalanced with incremental reward and a plan for how we’re gonna keep getting rewards, not just keep experiencing pain. And so whether you guys think in terms of like our stuff, expeditions and base camps and organizational base camp size things, what I would just strongly recommend is being willing to create at least a high level roadmap with like a three to six month rolling wave plan that basically says, we’re gonna do these things. This is how we’re gonna do them. Here’s the changes that we want to make. This is how we’re gonna make them and here’s our hypothesis on the business outcomes you’re gonna get as you go. That in and of itself would be huge. That’d be huge because I think that’s the biggest reason why this stuff is failing fast followed by the idea that candidly, we’re not solving a big enough problem right now. SAFe isn’t a big enough problem. It’s not the problem companies are trying to solve. Companies are trying or trying to solve the problem of how to pivot and market. How to respond to pandemics and stuff. Different class than I just need to be able to swap this requirement for that requirement. So it’s a really different thing. So now let’s talk a little bit about in practice, kind of what it looks like. And so one of the things that we’d been doing a lot, but putting a lot of thought into how to talk about, is what does it look like to install or to orchestrate a system of transformation? And so one of the things that resonates with a lot of our clients is this idea of building like an Agile Transformation office. And it’s interesting, sometimes people go well, is that what the PMO is now? Is the PMO and Agile Transformation office? Could be. Maybe right. Some of those people might be a good fit for an Agile Transformation office, but there’s a set of services that an Agile Transformation office has to be able to provide. So if you think about, if you’re orchestrating a transformation and you’ve bought into this idea that it’s teams that roll up into teams of teams, and it’s the systematic breaking of dependencies, and it’s running expeditions to base camps, all the different things I’m talking about has to be kind of an entity within the enterprise that is looking out at the business architecture, is making decisions about how to group teams and then is actually running the outcomes based plans and measuring the outcomes, establishing the playbook of how all this stuff is gonna be run, creating coaching capabilities within the organization, creating training capabilities in the organization, being able to do expedition intake and approval. And some of the things that we do, I’m very big on engaging leadership. So we’ll create like a executive steering committee and transformation leadership teams and these different things to make sure that the organization is enlisted and actually owns the transformation. So all this stuff is emerging into this concept for us we call an Agile Transformation office. And again, tying back to the theme having a group of people, whether it be the PMO or whether it be a different group of people, or it’s your agile coaching team or whatever, being in front of this Agile Transformation office and being accountable for how this thing’s getting orchestrated and making sure it’s not a free for all, critical, critical success factor. Critical success factor. And I can’t even gonna tell you. So how I’m trying to visualize this, I’m trying to keep it really simple and it’s like most things it’s messier in real life. So you set up at the early stages of a transformation this locus of accountability, this locus of orchestration, this locus of accountability and what their job is fundamentally to do is to begin instantiating the system of delivery in these various expeditions. Moving them to these states based camps through these outcomes based plans to get them to vary predefined performance characteristics. So it’s a little bit like one of the metaphors I’ve been using for a lot of years is like in pool, it’s like calling your shots. If you ever played pool with little kid, they come up and just start shooting pool and balls go everywhere and they sink a ball and they’re like super happy. We can’t do run transformations like that. You have to be able to say eight ball corner pocket. You gotta be able to get that ball, that ball, that ball, that ball, that ball. So that’s what the system of transformation has given for us. But as we call our shots and we start demonstrating the value of the transformation and these new performance characteristics, and we start anchoring them back up to the things that the organization cares about, probably a lot of leading indicators upfront. So the system of transformation begets the system of delivery. But you also have to recognize that while it’s building the system of delivery, it has to like give a nod to building the system of continuous improvement. So what’s the monitoring capability? What’s the continuous improvement capability? What are the business architecture things? What are the strategic alignment things? The organizational design considerations that have to be maintained and nurtured. A lot of these things exist in organizations. They don’t have to be grouped, they just have to function. And this is kind of like maybe like a last point that I’ll try to make around this, is that a lot of organizations have been at this Agile Transformation stuff for a long time. And people get tired of transforming. They just do. There’s been a lot of companies that are like, our agile is not working and we want you to help us, but we can’t call it a transformation because we’re transformed out. So it just needs to be continuous improvement or it need just help us to be not messed up anymore, but it’s not a transformation, done.

Done with transformation. And that’s real. And so there’s lots of things that you can dance around in order to make that a thing. But again, there is a reality if we’re transformed or we’re transforming, but you can change the words however you want. So system of transformation begets this medullary and systemic continuous improvement, all those different capabilities kind of running a parallel. And then the way, I’m gonna be honest with you. We haven’t gotten this far as some of these big multinationals ’cause these are years and years and years, but this is how it’s emerging and you can just see where it’s gonna go. What starts to happen is at some point, system transformation activities get deprecated and they basically get built into system continuous improvement. And then you basically have two kind of things. You have kind of a, I talk about this internally a lot, like in the business, on the business. So as a CEO of a 150 person consultancies, soon to be 250, I spend most of my time on the business. So I’m monitoring organizational health, organizational culture, financial performance, our organizational design. We just went through a major refactoring internally, carving out some different services, creating greater encapsulation, trying to break dependencies, created some new dependencies. So in a large part right now, Mike Cottmeyer is leading Agile’s system as continuous improvement. I’m the guy that focuses on the business. Chris Beall is kind of my in the business guy. He orchestrates with Dennis Stevens and Brian Sonaguard and few other people on my team to do client work. But so in the business, on the business is very visceral to me. But I think even within your organizations, I think you’re gonna end up with an, in the business on business kind of function. So you’ll have, so once you’re done transforming, you will have a agile delivery capability. You need to care and feed it. You need to maintain it and you need to make sure people come in and they get trained. They understand your operating model, understand how you work, what you measure, how you control behavior, expectations, cultural indoctrination, all those different things. But they go and they work in a relatively static system of delivery. As the market changes around the system of delivery, you have to have a capability to be able to monitor and improve and dynamically reallocate. And that class of things is largely in a system of continuous improvement. So there’s lots of failure. You can fail an Agile Transformation by not aligning to the right things. You can fail an Agile Transformation by not going far enough up the stack, and not dealing with enough of the business concerns. You can fail at transformation by not actually putting in the control mechanisms that enable you to dynamically repurpose the organization as market conditions change. And so kind of my story. It’s pretty late, pretty exhausting, to try to tell it and that’s a lot to think about. And I know it’s like, I hope if anybody’s ever heard me talk, I don’t do a lot of whole how to talks. I’m not a big how to write better user stories. I’m definitely a big ideas guy. But this is what’s really cool and this is something I was telling my team the other day. I’m being probably too transparent with you guys, when I tell you this story. A lot of times you’re growing really fast and we’re brand consultants then. And I talk a good game and we have built these systems, but the reality is that everything’s messing around on the ground. I was talking with one of my lead consultants the other day and we had an engagement started off a bit rough, and then it stabilized and are getting tons of kudos from the organization. They’re bringing us into other things, helping us solve bigger problems, displacing other consultancies, it’s very cool. What changed? And the reality was, when we got on the ground, we didn’t have the influence to be able to do all the things that we were supposed to do. All the things I’m talking about here. And then once we built some momentum and got a better foothold and were able to run a system transformation, get metrics in place, be able to prove incremental value and to be able to unequivocally, beyond a shadow of a doubt in like four months after working this group go, this is where they started, this is how they’re performing differently today, this is what you sign up for. This is what you got, this is how much it costs. All these different things. and to be able to just go, boom, call your shot and nail it. Huge, huge. So whether that’s us working with a client, whether it’s you guys working with another consultancy, whether it’s you guys working internally, I think the physics of this apply, no matter what. We have to be able to orchestrate these transformations and measure and solve the right level of problems and do it in a really sustainable way. Okay, cool. I think I said just 10 minutes thing. So anybody wanna like, take a look at the 56 messages in the chat and throw a question at me? So Eugene, so I’m just literally just picking this off, like first thing that caught my eye. So Eugene asked, I noticed his barring vocabulary from the past, but the organization that can pivot might need the leadership of an Uber product owner, COE. Yeah, and there’s a lot of different things that you can call that. One of the things I’ve caught myself saying, and if you guys aren’t familiar with the thing, you can find it on Wikipedia. It’s like turtles all the way down. And so remember a thing back in the day, it’s like, well, what does the earth float on? What’s a turtle? What does a turtle float on? Another turtle? It’s turtles all the way down. And there’s like this whole line of philosophy around it’s like almost like a five why’s thing. Well, why is this? Why is this? Why is this? Why is this? Why is this? I think these problems are interesting. They’re all recursive at the end of the day. So we want teams backlogs working because the software at the orchestration, at the ground level, and then as you start rolling things up, it’s basically teams backlogs, working, tells the software at every level. It’s encapsulation at every level. It’s clean backlogs at every level. It’s the ability to put things in market basket at every level.

That’s what business agility is about. So when we say that we want to redeploy organizational units to solve different problems in market, I saw somebody commented on the thing I did around like pivoting from making something to making ventilators or whatever in the COVID. I think that’s just a big way of, that’s the same thing as putting one user story in and inserting a different user story. It’s just that user story is a ventilator. It’s a bigger thing over a longer period of time. But like I said, it’s turtles all the way down, right. The principles, the principles that we’re talking about when I say recursive or fractal or whatever, it’s the patterns just repeat infinitely. They go infinitely down and they go infinitely up. Super fascinating. So to Eugene’s question, might they need like an Uber product owner or a COE? Yeah, by all means, right. I’m kind of the Uber product owner of leading agile and my executive teams are kind of like product owners of the accounts and we built some software internally and I have product owners for that. But who does the buck stop with at the end of the day? Me. I dynamically change our organizational architecture. I dynamically allocate funds. I dynamically do all these things ’cause we’re still small enough for me to do that. So yeah, I think it’s a perfectly valid metaphor. I just don’t call myself an Uber product owner. CEO sounds way better. But like, however you want to structure that in your organization. So it took me a little bit to get used to that title. We are nine people, people were like, oh, you’re the CEO. I’m like, can you be a of nine people? I don’t know. It feels like a pompous title, but if 150 people, it’s not far off. It’s kind of cool. Okay, isn’t it continual transformation, David says, are you never done? It’s a little bit of what I’m trying to hit at with this idea of continuous improvement. Again, organizations get transformation fatigue. There’s a whole lot of organizations that we talked to that really need to get better at what they’re doing, but they’d been through a transformation. They’ve spent the money, they’ve hired the consultants. They’ve done whatever they can. Sometimes politically you just can’t say we’re transforming. So you got to come up with a different name for it. But it gets into like, does an organization, can an organization like you adapt or you die, you grow or you die. I believe that to be 100% true. People ask me all the time. It’s like how big are you gonna grow leading agile? What’s more is there to do? And I’m just like, look, I love what we’re doing. I don’t want to atrophy. And so the only thing you can do besides atrophy is grow. ‘Cause there’s no homeostasis. I don’t think there is in any organization. So we’ll come up with different ways of talking about it. But yeah, continuous and change, continuous adaptation, continuous market realignment it’s gonna get more intense than less intense. And so the ability to pivot like this is gonna be more key. Okay, I’m totally, I have no idea what question this is, so we’ll have to see if I can answer it. And lean manufacturing frontline workers can always safely pull the cord if they start to see problems, everything stops, the issue gets solved. They’re encouraged to do that. Executives and managers and Scrum need to create a culture where that’s safe to do, not train barreling down railroad, no matter what they run into. How do you persuade executives to implement that culture?

So I have a fairly strong point of view on culture. It’s like, and I think people don’t, it’s just a fascinating thing to pull apart. I don’t think you attack culture directly. I think you align systems and you give it really clear policies and governance, and then you encourage certain behaviors and attributes and mindsets to emerge out of the aligned systems and the really solid practices. So you think about it. We want collaboration at the Scrum team. It’s so easy to get sucked down this level, ’cause it’s such a powerful metaphor, we understand. So I don’t go to six people that are spread across 92 different projects operating across eight different Gantt charts across five different organizations and say, “Hey, you guys need to be more collaborative. “You need to have a culture of collaboration. “I need you guys to work together. “I need you guys to be really safe “pulling the end on cord on this stuff.” You just don’t do that. What you do is you say, “Look, we’re gonna do this. “We’re gonna put you on a dedicated team of eight people. “We’re gonna give you a single voice of the business, “the product owner “and we’re gonna ask you to make commitments “on two week-intervals. “We’re gonna ask you to establish stable velocity “and we’re gonna ask you to get to agreed upon definition “of dawn at the end of the year “and if something’s not done, expect you to raise your hand “during the screening and done.” That’s how you pull on in and Scrum. You have to create the conditions where it’s safe and expected to pull the end on cord. That’s how you do it, right? Because here’s the reality. If you have an executive up at the top who’s like, we have to get the market. And here’s the thing, as an executive now, you got to have empathy for that. We have to get to market. We have like, it’s so critical that we get to market and we satisfy these objectives. The agilists have often gone way to the other side that basically says, we’re so tired of getting beaten up that we’re just not gonna commit to anything. And that is an untenable situation. There’s no executive in the world is gonna say, look, software craftsmanship, pulling in oncore, all these different things, just do whatever you want and it’s gonna be okay. So there’s some balance, right? And so to me, that balance at the team level is a dedicated team, everybody necessarily do the work, capsulate technology, no dependencies, clean backlog, able to produce work and tests of software, continuous integration, continuous deployment, test driven all day long, except this criteria, product owner sign-off at the end of the sprint within that safety, we’re just gonna basically say this story wasn’t done and it’ll carry over to the next sprint that will impact velocity. I can go to my leadership team and I can say, okay, we were hoping for a velocity of around 40 points, we’re averaging a velocity of 32 points. That means that we’re gonna drop these features out. These features are gonna be in, or we need more time or we need to find out some of the features. We need to do something, right. There’s an option. There’s always options. But just saying, pull the cord, stop development. Nothing’s gonna work because there’s a middle ground. So this is the reason why I’m so big on systems is because it’s like to Daniel’s question, it’s like, how do you attack that behavior? How do you get somebody to speak up when they’re gonna get fired? Or how do you get the execs not to put pressure on the organization when they have no idea when anything is gonna come out the backside, right?

So you have to address the visceral concerns of the people on both sides, because the executives need safety as much as the people need safety. ‘Cause you think those executives they’re sitting in a seat of power and they make all this money. They’re more vulnerable in the developer on a team because if that stuff doesn’t come out in six months, they’re gone. They have power while they’re in the seat, but their seat is so fragile, right? So we have to get an execs, Dennis likes to say, Dennis Stevens one of my partners in leading agile talks about you have to have a reliable system that you can delegate into a trustworthy system that you can delegate into. So for the execs, we have to build a trustworthy system that they can delegate into and get predictable outcomes. Within that context, we have to create safety for the development teams to tell the truth. And we create the safety for both everybody. Everybody gets to behave rationally at that point. Most people behave badly because they’re afraid. They put pressure on other people because they have power, but it’s because they’re afraid. So how do we create safety for them so that they get, so everybody gets what they need, right? Everybody’s operating in a healthy ecosystem. My version of that, people are like, how big are you gonna go leading agile? How are you gonna run it before you sell it? I’m like, I’m gonna grow it as big as I can grow it and I’m gonna run it as long as I can, as long as it doesn’t suck. But it can’t suck. I can’t be miserable coming to work every day and realize people are in situations they’re just been miserable to go to work every day. So we’ve got to create a healthy ecosystem so people can behave rationally. Do we have time for one more or should we cut it? You guys tell me.

– I mean, if you want to do one more.

– I am totally cool. I can hang out for a half hour if you guys want. You don’t need me for that long, but everybody els is like no.

– I think one more is fair.

– We’re biasing towards the people ask questions later. Okay, so let’s take Sam’s question. Let’s see if it’s something I can answer. Deliver something you can clearly identify and understand under commit, ever deliver succeeding, continue to fail and move on. I wish I had business. Agile but in the end it’s just a better approach. It’s not changed reality. Not really a question and I don’t know if I want to try to get in that philosophical loop here. So I wanna try to anticipate what Sam was thinking there. Okay, angels coming to the rescue. What do you recommend for a leadership team that refuses to make the necessary changes to the ecosystem? I’m gonna tell you, I’m gonna tell you great end question. I’m gonna tell you how I think about this. I alluded to this earlier. I’ve been thinking about this a lot. I’m gonna write a post on it or do a talk on it or something. But if you want outcomes. If you want certain performance characteristics in your organization, there are things that have to be true to achieve those performance characteristics. So what you’re basically saying is if you say, what about a leadership team that refuses to make the necessary changes? What they’re basically saying is, I want the business benefits, but I’m not willing to make sacrifices. I want to lose weight, but I’m not willing to eat less and exercise more. You can’t have it. You can’t. You just can’t, it’s physics. So this is why I started my own company. I know this isn’t fair ’cause a lot of you guys worked for companies and you don’t get to play this. I’m gonna tell you, you get to play. I spend a ton of time. This company I talked to this morning, we’ve probably been on eight phone calls with them and it’s very short burn here. We just had a four-hour session with all their executives. And like every single time, they’re like, you’ll do that for free, you’ll do that for free. And I will tell them, I say, look, there’s a way that we do this and this is what works period. And you gotta know that when we come in, this is what you’re gonna need to do. So when you hire us, this is what you’re signing up for. So I need to make sure that you’re willing to do these things as much as you wanna make sure that we’re the right consultancy for you. Because if they’re not willing to do them, what does that do for me? So I put some people on the ground and make some money for three months. I burn a relationship. I can’t solve their problem. They think it’s my fault. They start talking bad about leading agile and in market and next thing you know, we have a dang on our reputation. Don’t need it, right? It’s not worth the money in the short run for me. So I will sit on what I call the physics of trend. These are the things that have to be true, period, or you’re not gonna get what you want and you shouldn’t hire us. And so what do you do when they won’t do it? I mean, candidly, what it comes down to is you have probably two choices. You either operate within your span of control and you apply the principles the best you can locally, fully recognizing that you are creating a local optimization within your enterprise. It’s cool. So what I might do is I might say, okay, I’m gonna get my people in my team to operate with as few dependencies as I can and I’m gonna create a healthy ecosystem within the world I can control. A lot of people are content with that and you could probably carve a nice little way of life for yourself and a large jack-up company. If your ambitions are bigger, then you have to be able to sit in the face of power and clearly tell them, you have to do, ABC and D or you’re not gonna get what you want. And if they sit there and go like, well, I expect you to give me what I want, but I’m not doing any of that. I’m gonna be a little disrespectful here, but I call it like, I want a pony syndrome. And I guess like, I want a pony? Well, you’re not gonna get a pony. But I want a pony. You’re not getting a pony. So it’s like, you can’t have a pony. And then you have to decide as a professional, a high integrity professional in your field, probably operating under some sort of code of ethics, do I wanna be in this environment? That’s what it comes down to. Tell people the truth, ’cause what’s what most people are doing is they’re running around like, well, execs won’t change, environment will change, ecosystem won’t change, but I really love everything Mike said so I’m just gonna sit here and just totally bastardized the hell out of Scrum and just try to the best I possibly can and nothing’s gonna work. There’s a lot of people are really disillusioned and sad. It sucks, right? I mean, who wants to be chuffed to be worked and be disillusioned? I would just rather be really real, right. Either I’m gonna be influential globally at the level I want to be influential or I’m gonna operate super locally and be content about it. And if none of those are good, then you gotta go find someplace else to work. That’s my take. And I know that’s not the answer anybody wants to hear. I do these things with Dave Pryor, who’s our Scrum master or not a Scrum master is our Scrum trainer and poor Dave, right. He’s in these classes, he’s doing Scrum training, he’s fantastic Scrum training. You guys should like email. We don’t make a ton of my off Scrum training. It’s almost a break even business. We just do it because I’d rather us do it than other people do it. So go to one of those classes. Fantastic trainer but he’s always come back to me with like, all these people are asking all these questions. Like what would I do if I’m a project manager and I can’t do this, I can’t do this, I can’t do this, I can’t do this, I can’t do this and I’m just like, you can’t do it. It’s just like certain things have to be true or usually it’s just gonna be suboptimal just period. It’s just the way the world works. So I know that’s not a super positive message. There’s just isn’t a silver bullet. Either you make it work, you diet and exercise and lose weight or you don’t. What do you do? So I hope that was a note I should have ended on, but I think that was a moment of truth, I think. What is that?

– I’ve been super energized by the last five minutes of everything that you’ve just said. I find that to be great.

– Cool. I’m glad it was a positive end. Sometimes I go and do talks. I mean, university of Florida guy. So I graduated, I do entrepreneur and residents. I go back, I talk to students and you remember like our lines of business, it’s like, we go into the most jacked up companies and a lot of these companies or companies these kids really want to go work for. Sometimes I’m like, just be really careful because these companies, they look like awesome companies and they are and they’re doing great things, but they’re really jacked up on the inside. Just have your expectations really, really clear. These are not crystal palaces on the hill. They’re just messy workshops where people are figuring stuff out. So that was fun. That was a great last question. Glad we had it.