Overcoming the Barriers to Business Agility

If you could magically create a new world where large organizations had overcome the barriers to Business Agility and Agile came naturally, what would have to be true about that world, the organizations, and the people working there? To make your new world a reality, what beliefs and worldviews would need to get left behind? What would the organizations have to look like? And how would we know that this new Agile world was any good?

Join Mike Cottmeyer as he shares some of his earliest observations and latest thoughts on the Agile industry and explores what must be true for Agile to succeed.

Video Transcript

We’re not talking about doing local optimization. We’re talking about doing large-scale change. We’re not talking about creating agile projects or agile teams. What we’re doing is creating agile organizations and whether that be transforming existing organizations or creating models for new organizations that are going to come down the pike over the next 10, 15, 20 years.

What do we want to be educating our new leaders on? What old things do we want to deconstruct and pull into a new paradigm? What are the current beliefs that need to change so that we can do this really well?

(Musical Interlude)

So hey everybody, how are you guys doing? So we’re going to talk a little bit today about some things that have been noodling on for a while. And what I’m going to try to do is I’m going to try to enlist your help and your support and help me figure this out a little bit. So as you guys know, Leading Agile, we are exclusively in the change management business.

Typically, we’re doing Agile transformation and all the change management is associated with that. And one of the ways over the last 12, 13 years that we’ve been around and really before that when I was just doing social media stuff on blogs and Twitter and things like that. But a big part of what we try to do is we try to educate people on how to think about change, how to think about Agile transformation.

Because if you call us up and you say something like, “Hey, we want some training,” you know, it’s like, “Okay, like what do you want to be trained on? What do you believe? What’s your environment like?” There are a bunch of different things, right? And so if you show up and like you say, “Hey, I want to adopt Agile,” but you know, you’re not familiar with the strategies or Agile governance strategies or such, right?

There’s just a lot of stuff to unwind. And so what we try to do is, which I do a lot of videos like this, to enlist people and to get people thinking around things the right way, and the people that see things our way and have a need for our services will typically pick up the phone and call.

And so I started thinking about this week all of the different things that really go into helping somebody fundamentally see how to transform. So I started taking some notes. I have some notes over here on my page. And so I’m going to kind of do a survey of my top-of-mind stuff throughout the week.

And then the idea is I’ve got my marketing team on the call with me right now. They can’t, you actually can’t see them, but they’re listening, and they’re going to take this and turn it in and edit it and all that kind of stuff. And then what we’re going to do is turn it into a series of more micro topics.

There we go. So today is kind of like a survey. And what I’d really love for you guys to do is as you’re listening to this, to start to think about for me, am I missing anything? Like what other barriers do you see? What other conceptual gaps?

Success in Agile

And so the first thing I want to talk about a little bit is the idea of what does it actually mean to be successful with Agile? And on the one extreme, you have things like the actual business results you’re going for, whether it be predictability, quality, putting things in market fast so you can charge for them, particularly your return investment cost savings.

Are we optimizing the throughput of the organization? Are we doing it in a cost-efficient way? Do we have the right people in the right seats? Innovation, are we able to get feedback from customers and invent products that they want to use, product fit? Are we generating the right kinds of feedback to make sure we’re building the right products, whether that be innovative or more in a structured way?

But then, and so those tend to be like the business benefits of it, right? And the other side of that coin, and this is something that we see a lot, is like success for Agile tends to be like, are we doing the practices effectively? And there’s like this assumption that says something to the effect of like if we’re doing the practices effectively, theoretically we should be getting the business results from it.

But as I’m sure a lot of you guys have seen as a lot of people run around doing Scrum or SAFe or whatever, and they’re not actually achieving the goals of agility and you know what’s hard? And I won’t go too deep into this one, but what’s really difficult about that is that the there are impediments in your organization that people can’t fundamentally change.

And so because they can’t change the things that are getting in the way of agility, they start defining success in an Agile transformation as, are you doing the Agile things?

And so, on the one extreme, it’s very much like a cargo cult kind of, you know, if we do these things, it will happen versus all the way on the other side of measurable benefits, business benefits. And so one of the first things we try to help people overcome or get really clear on is what does success look like? Why are you doing this, and what does success look like?

The Possibilities of Transformation

The second thing that is interesting, and I gave a nod to this in a talk a couple of weeks ago coming out of the Triangle event that I spoke at. And the idea is, is like what is possible to change in the organization? And there are a lot of folks that are adopting Agile that are in organizations that are really, really difficult to change.

And you know, we get into clients like that and our consultants get faced with these things all the time where you live in this kind of this weird dichotomy of I know these things must be true to be successful, but the organization doesn’t seem to want to change them.

And so, to some degree, you have to cast a vision for what is possible to change, of course, the vision. But you also have to sometimes get people to suspend disbelief enough in terms of what’s possible. Because as we know, right, Agile requires a certain kind of operating model to really be functional at scale and to achieve the goals.

So, the challenge that we have is we have to get people to suspend disbelief that certain things that are hard to change are actually not impossible to change. And that there’s a path forward and there’s a way to engage in doing this.

So, you know, the first point is, why are we doing this? Like, why does it matter? What does success look like? And then what are the things that we’re willing to tackle in the organization to create the conditions to be able to achieve those goals? And so those are the first two things I listed.

The Physics of Transformation

The second thing that I was thinking through was stuff that we’ve done talks here over the last couple of years, what I call the physics of transformation. And there are certain really interesting rules, right? Like we have to be able to bring capacity and demand into balance.

And so from an Agile perspective, like if I know the size of my backlog and I know the velocity of the team over 100 points in my backlog velocity, the team 20, you know, we’re not going to pull more than 20 points into a sprint, and we know it’s going to take about five sprints if we want to get through the entire backlog with negotiation and variation, we have to bring capacity and demand into balance because most organizations we go into are like ten times overloaded. It’s not just about cost savings, but also trying to figure out value density and what path through the backlog will deliver the most value within the time and cost constraints.

Organizing around value is important, especially in early-stage adoption of Agile. While projects are valuable, they are also transient and encourage a cost accounting versus a throughput accounting model. To overcome this, we need to organize around the persistent value objects in the organization, such as value streams, feature sets, or business capabilities. However, there is a conceptual challenge to overcome as many people still believe in organizing around activity, putting people in functional silos and assigning them work based on their skill set. Without overcoming this, it is hard to make a case for Agile teams.

What’s Getting in the Way of Agile?

The idea of theory of constraints is also important, where we optimize for the flow of value, limit work in process, and prioritize getting things finished before starting new ones. Identifying constraints in the system and moving resources to the constrained objects helps increase flow through the system. These conversations often involve cost accounting versus throughput accounting.

And so if you’ve grown up in a traditional mindset, you’ve grown up in a traditional project management model. Very often those folks are centered around the idea of functional silos, local optimization, focusing on cost accounting versus throughput accounting, where Agile tends to be more like organizing around value, sub-optimizing the idea of cost for the elevation of throughput, making sure value streams are encapsulated, things like that.

The idea of encapsulation versus orchestration, you know, so we have to overcome the idea that when you organize around value, you want to do it in a way that minimizes dependencies because when you have dependencies in place, you have to break dependencies, or you have to manage them. A lot of times Agile is in the presence of dependencies and wants those dependencies to self-organize away. So, it’s like the traditionalists want to hyper manage dependencies. A lot of agile folks want to ignore dependencies and believe the team will self-organize. Often there’s a middle ground, but you have to make the case for that middle ground a little bit. So, there are underlying thinking tools that are involved that we have to get people to be able to see.

Does the Methodology Matter?

Probably the third category of stuff, and this is what I find interesting about the industrialized agile frameworks at this point. So, you think SAFE, Large-Scale Scrum maybe, although I don’t know that fits in that category, Scrum as a model, XP as a model, and things like that. The idea that it’s a description of the methodology that matters. We talk in LeadingAgile a lot about the idea of reference architecture versus reference implementation.

And what I say about SAFE often is that it is very valid. It’s based upon a very valid reference architecture. Scrum teams at the bottom, some sort of orchestration mechanism, the product middle tier, some sort of orchestration mechanism up at the portfolio tier, some linkage to investment tier investment strategy, focusing on the flow of value at each level, understanding lean principles.

So fundamentally, under its core, I don’t have any issue with SAFE. I think SAFE is fine. There are things that we often will do differently or in addition to or subtract from a SAFE-type model. But the point being is that almost all scaled methodologies, probably all scaled methodologies, are built around some sort of fundamental reference architecture that we believe is inarguable.

Then on the other side of that, you have this idea of reference implementation. And that’s where I think SAFe gets a little wonky sometimes, is that it’s a specific reference implementation on top of a very valid reference architecture. And so, what happens, and it happens always, that happens with the PMBOK. It happened with RUP, it happens with SAFe, it happens with Scrum, it happens with everything.

We take the implementation details and say that it’s the details, right? The roles, the ceremonies, the artifacts, the cadences, all those different things that we model as implementation details. We take that as the thing and then we over-index on having the roles, having the titles, having the ceremonies, having the artifacts, all those kinds of different things.

And so you take something that’s very valid, like SAFe, and then you pick up the reference implementation as described in the SAFe materials and SAFe training. The people that invent these methodologies will acknowledge that they are designed to be tailored. But in practice, very often they don’t actually get tailored, right? They get implemented as a whole because people want to believe it’s the implementation details of the roles, the ceremonies or what have you, and not the underlying reference architectural patterns.

You have to help people see it’s like this weird, non-dualistic way of thinking about things. The patterns are immutable, the implementation details are helpful. And then we have to ask ourselves what implementation details are going to help us best support the reference architecture patterns that are actually the secret sauce.

If I think about that from a really simplistic perspective, you take something like Scrum. So one of the things that I do from a reference architecture perspective is I talk about the three things. So what is the fundamental pattern of Scrum? The fundamental pattern of Scrum is that you have a dedicated team organized around value with few, if any, dependencies.

You have a well-defined backlog, and you’re able to produce a working, tested increment at the end of every sprint. To me, if you have those three things in place, that’s the only thing you need to be able to do Scrum. Now, you can further specify that you say, okay, the product owner is the one that creates the backlog, and the team is made up of these roles and not these other roles.

And you know, this is what it means to get to a definition of done. And we can be really dogmatic about, “Is there a Scrum master? Is there a product owner? Is there a burn down chart? Are we using sticky notes on the wall? Are we doing story point estimating or are we using planning poker? Are we doing reviews? Are we doing retrospectives? What kind of reviews and retrospectives are we doing and how are we doing them?” Those are all details, right? And sometimes they’re helpful details and sometimes they’re not.

And so, like, I’m not interested in the prescription of Scrum that says you have to have a product owner as helpful if you have a product owner as Scrum describes it. But if you don’t like putting a business analyst in front of a backlog, someone who doesn’t have the background understanding, it’s not helpful.

Putting a ScrumMaster on that team that can’t actually go out and remove the organizational impediments that are required often isn’t helpful. But that’s what we’re doing in practice, right? So helping people understand the difference between reference architecture and reference implementation, and whether there is a different implementation that can help us more effectively achieve our goals when we deeply understand the patterns, the principles, reference architectures that are involved is important.

So, you’ve got to get people through that kind of hang-up.

Recommended Approach to Agile Transformation

Which really leads us to something else that I talk about quite often: the idea of systems first, systems practices, then culture. If I can get the training strategies right, I can get the governance strategies right, I can get the measurements right, so I call systems then, and I can start to build a solid system of delivery on top of those patterns.

Then I can create the conditions for the Agile practices to come in, right? So I can pick out elements of Scrum and Kanban and SAFe and LeSS and things like that, right? XP. And then I enable it with really solid practices, and then culture can emerge over time.

Common beliefs suggest that culture is the primary obstacle to Agile taking hold, but there is also some truth to the idea that teaching Agile practices alone will solve all problems. However, education is key to understanding what makes Agile different from traditional project management, which often does not address organizational design.

Agile inherently implies organizational design, and without aligning the systems, operating model, and methodology practices, it is unlikely that a culture of Agile will emerge. Therefore, it is important for people to understand this fact because the competing belief is that changing mindsets alone will solve all problems and ensure the success of Agile.

However, this is not always the case, even when leadership teams are fully committed to Agile. For example, teams may have the spirit of agility but be hampered by a poorly designed technical architecture that is not congruent with Agile principles. In such cases, having the right attitude is not enough if the underlying technical architecture, organizational design, governance framework, and measurement are not consistent with Agile.

Although it may feel like an attitude problem, it is important to recognize that an operating model needs to be developed. Implementing solid practices is key to changing hearts and minds over time. Therefore, education plays a significant role in helping people grasp the intricacies of Agile transformation.

A Holistic Look at Change Management

There’s another thing that I’ve been thinking about a lot as we work with larger and larger clients and we start to deal with really issues of scale. And it’s a classic like Blind Man and the elephant problem. And I think you guys are probably mostly familiar. I mean, I know I got introduced to this parable through the Agile community probably 15 years ago at this point, but the idea of the blind man and the elephant, you have these three blind men that are standing next to an elephant and one’s touching its ear, one touching its tail, and one touching its leg.

The one touching its ear says an elephant like a palm tree, right? As fronds and leaves and things like that. And the one touching the tail says, no, it’s more like a snake where you have because it’s long and thin and flips around and stuff. And the one touching the leg is like, No, it’s like a tree. And they get in fights because they’re all looking at the same thing from very different points of view.

And it’s weaving practice. It’s like, you know, we get involved in leading Agile. It’s not just in team level transformation, but in enterprise-level transformation, a whole IT organization transformations we get involved in, helping people change their financial governance strategies, KPIs, OKRs, things like that. And in doing so, DevOps transformation, right? Digital transformation, business transformation, business agility, right, all these buzzwords, right? They’re all aspects of the same thing at the end of the day, right?

What people are trying to figure out how to do is to use technology to leverage technology to generate better business outcomes. And so some of it is, it’s like I think there’s almost, and I should probably try to write an article on this or something, but it’s like there’s almost like a unified theory that is starting to emerge that really takes like you can take things like, you know, we talked about structure, practices, and culture kind of in the Agile world.

You can tie that to the whole Occupy movement, you can tie it to a digital transformation story, you can tie it to a DevOps transform story. One of the fascinating things we’re seeing right now, a huge opportunity in the market around DevOps, and it’s like you could almost ask yourself the question why DevOps fails? I’m not a deep DevOps expert.

I’ve got a lot of really deep DevOps experts on my team. But what’s kind of funny is that DevOps is failing for the same reason everything else is failing. It’s like, we treat it like it’s a tool problem or we treat it like it’s a practice problem or we treat it like it’s a mindset problem.

And almost always, it’s an organizational structure problem, it’s a governance, it’s a working tech problem, it’s a culture problem, it’s an adoption problem, it’s a lineman problem. It’s an integrating with the whole problem. And so when we take a thread like DevOps, highly unlikely if we’re not thinking about it from a systems perspective that we’re going to get a lot of stuff wrong.

And so you start to weave when you think through this blind man and the elephant lens. It’s like we’re all blind men and we’re looking at our particular piece of it and failing to respect that. The idea of organizational design, governance practices as metrics, culture, all these things, it’s all an integrated whole. And that has to tie together because it’s one fundamental company.

So investment strategy, OKRs, KPIs, audit controls, financial compliance, governance, all that stuff, product management strategy, requirements, decomposition, traceability, Agile delivery and execution, DevOps, enterprise architecture, all of those things are all part of the same story. And oftentimes we talk about it like three distinct things that happen in a company. But again, blaming the elephant problem, they’re all pieces of the same thing

Planning a Transformation

And like the last little bit that I want to hit on again, this is just kind of a top-of-mind exploration for me as I was contemplating what I want to talk with you guys about this week is, you know what the difference between what we call a system of delivery, a system of transformation. We also talk about a system of engagement versus a system of continuous improvement.

And there are really four questions that people are trying to sort through when they call us. It’s like, what does it look like? What is the operating model look like when Agile is done? Like how will we operate differently? I had a client in the early days leading Agile go, “What will be the evidence that you were here after you’ve gone?”

Something like that as a paraphrase of it. So, like, what will my organization look like when we’re done? That’s a question that people want to know the answer to. And so basically saying, “Well, it’s just going to emerge, we’re going to figure it out as we go,” is usually not a satisfying answer. There has to be a starting place.

So what is the end-state operating model look like? The second question is how are we going to get there? What is the transformation strategy? How are we going to introduce these ideas? How are we going to break up the organization? What are we going to form teams around? How are we going to do that? What are we going to do with resource disparities across the organization?

How are we going to measure progress on the transformation? How are we going to know what done looks like? How are we going to know we’ve actually improved? How are we going to know that we’ve actually delivered against the goals of the transformation? So you have the end-state model, but then you also have the transformation strategy, right?

So when you hear me talk about expeditions and base camps of outcomes-based plans and activity guides and leading and lagging indicators of the transformation, what we’re really talking about is how do you orchestrate the transformation, but more generally, like what does the change management around the transformation look like? How are we keeping everybody informed? How are we making sure the organization knows what to expect, what the impacts are going to be, right, all those kinds of things?

So there’s stuff that has to be overcome there. The third piece we call System of Engagement, which is a couple of different things, right? A lot of times for us as a consultancy, it’s really about like how we structure contracts and how we think about deliverables and how we think about milestones. But it’s also a lot about how our consultants collaborate with each other, how are they co-conspiring, collaborating with the client, how are we demonstrating economic value for the dollars that they’re spending with us?

Maybe most importantly is how are we reducing cognitive dissonance and creating shared understanding through the course of the transformation? So how am I going to get my stakeholders enlisted in being able to do this? And then the last piece is okay, once we’ve transformed, is that a one-time event or is that something that happens over time?

Well, I think in practicality the transformation has a beginning and an end. But an Agile organization is supposed to be continually adapting to market changes and new opportunities. Right? And in one way that manifests in terms of small batches and backlog items and epics and features and user stories moving through queues. But that’s a little bit like the work in the system, right?

But the challenge is there’s an element of stuff that’s on the system, like how do teaming strategies change over time when we need to enter new markets? How do we redeploy resources, people, teams, things like that into new opportunities? How does the organizer of the organization dynamically adjust it? We call that the system of continuous improvement. How do we continuously reevaluate the business architecture?

How do we align business architecture to strategy in an ongoing way? Simple things like when new people come in, how do we orient them to our new system and how we work? How do we educate them? How do we coach them? How do we support them? How do we find people that are capable? Like these things are all what we call the system of continuous improvement and education.

The point of education is that, you know, you think about it at one extreme. If I see Agile or as its own means to an end, like the goal of adopting Agile is that we’re doing Scrum. And so in that world, I say, “Okay, well, I’m going to train everybody on how to do Scrum.” And if everybody doing Scrum is the measure of success, okay, fine, right then, then we have a pretty simple worldview.

But in practice, right, our experience, and I bet your experience, is that really doesn’t work. It doesn’t work at scale. It works for a team that works for a small work group, right? No argument in the small, but in the large. Right. We have to have a greater conceptualization of all the different little pieces that have to be hooked into.

And so many people, it’s like what they want is they want an easy button. It’s like, “Hey, we want to do Agile. I’m excited about Agile. Can I get some training to do Agile?” And that’s good, right? It’s a great introductory step. A lot of our clients start off with kind of a training-first approach. They’ve gotten everybody doing the practices and just got really limited results. So then they start looking at scaled methodologies and they start trying to transform, but they don’t really fully understand the systems, practices, culture, interrelationship, right? So, so they introduce scaled methodologies and that kind of works a little bit. Or maybe they start trying to figure out how to do teams and agile structures and agile governance.

But, it just everything doesn’t click into place. And so, this idea that we can separate the definition of the operating model, the initial idealized end state with a separate strategy for how we’re actually going to move the organization around. And then a third piece that is how are we going to create shared cognition across the organization, do all the change management and then how are we going to stay there and make sure that we have a continuously adaptive organization over time?

So that was my top-of-mind list as I was sitting down thinking about what I want to say to you guys. So what I’m hoping you might do for me and I’d love for you to respond in the comments, whether you’re seeing this on YouTube or LinkedIn or Facebook or whatever. And my marketing team is going to be paying attention and they’ll alert me, and I’ll engage if appropriate, or we’ll deal with it in a subsequent video.

But I’d love to hear from you the kinds of what I would call conceptual things that need to be overcome. What are the current beliefs that need to change so that we can do this really well? I’d really love your thoughts on what you’ve experienced. I love to compare notes, see what you guys are thinking, and if you’d be so kind, help us advance this message because I think we’re on to something.

Paving a Way Forward for Agile

I think there’s a way of thinking about this that enables us to deconstruct existing worldviews and to build new ones. I think a lot about, and this is a total aside, but I think a lot about because I’m a University of Florida guy. And so pre-COVID, I spent a lot of time down there talking to the entrepreneur and innovation groups and leadership, engineering leadership, industrial and systems engineers, that kind of thing.

And I’ve thought a lot about like, what would you do if you’re going to build a curriculum to do large-scale transformation and you were going to mentor IS and agile transformation strategy? Like, what are the things that you would want them to know? What are the things that you would want them to believe?

And I think there’s a huge part of this that is industrial and systems engineering-oriented. I think there’s a bunch of organizational design, organizational psychology. I think there’s a lot of business and change management. We would pull in a lot of large-scale software architecture and then tons of industry knowledge and DevOps and project management and all these different things.

And so we have a big task at a strategic level. We have to convince people that we’re not talking about doing local optimization, we’re talking about doing large-scale change. We’re not talking about creating Agile projects or Agile teams. What we’re doing is creating agile organizations, whether that be transforming existing organizations or creating models for new organizations that are going to come down the pike over the next ten, fifteen, twenty years.

What do we want to be educating our new leaders on? What old things do we want to deconstruct and pull into a new paradigm? And so that’s what I want to explore with you guys. So anything you could offer would help, and I would love to engage in conversation on it. Thanks for your time, and I’ll look forward to talking with you guys next time.

Have a great day.