Descaling Your Organization for Faster, Smarter Results with Agile

The Agile industry seems insistent that practices, methodologies, and frameworks will be how large organizations achieve Business Agility. But, the clients and companies we talk to seem to have a different opinion. Many of them are saying, “yeah, we tried Agile. It didn’t work.” And they’re looking for something else. Is the Agile industry in a rut?

Everyone knows Agile works. We’ve seen it. For many, it just doesn’t work when they try to scale it. But what if we took the principles of what makes Agile work in the small, and applied that to the broader organization in a way that wasn’t so dogmatic about the roles, ceremonies, and artifacts of Agile? What if we descaled the organization and created the conditions for the practices to add value? We might find that a whole new world of possibilities opens up.

Video Transcript

If we keep beating the drum that it’s about methodology and practice and mindset and culture and we can’t wrap our head around what a broader operating model is going to look like, we’re going to wear everybody out. I think we’re fighting the wrong battle talking about scaled methodology. I think what we have to do is talk about the principles that make small team agile and scaled methodologies work and focus on the idea of scaling the principles behind these methodologies rather than scaling the practices behind the methodologies.

(Musical Interlude)

The Limitations of Scaling Agile Practices

So what we’re going to talk a little bit about today is the idea of scaling principles versus scaling practices. And let me tell you what I mean by that. Over the last 20-some-odd years, we’ve had a progression of Agile methodologies and a lot of innovation in the Agile methodology space as of late. But if you look over the last 23 years at this point, something like that, we kind of started with some relatively small team Agile stuff, right?

So we have things like Scrum and extreme programming, or if I get really out there, talk a little bit about Alastair Cockburn’s crystal clear stuff in his family of methodologies. And then probably 15 years ago at this point, maybe a little bit more recently than that, we had Dean Leffingwell come out with the Scaled Agile Framework.

We had Bas Vodde and Craig Larman started to talk about large-scale Scrum. I guess it was Scrum Inc, maybe it was Schwaber and Sutherland who came out with the whole Nexus thing. We have Ambler with Disciplined Agile Delivery. We have some of the work that Ash Callaway did with his Flex model. We have the PMI ACP stuff.

And what’s really interesting is, as we go into really large organizations, it’s like the methodologies that we’re talking about don’t fundamentally scale. Even if you think of something like SAFe, SAFe is a methodology for dealing with what, 150 people is the recommended size? And SAFe is going to make some assumptions about that. It’s going to assume that you have encapsulated value streams. It’s going to assume that you have well-formed Scrum teams. And when you start to set up your release trains and you start to do your planning, Dean Leffingwell makes an assumption that we’re at about 150 people.

So when you start talking about doing even a scaled framework in a really large organization, it’s difficult because at some point the organization is going to hit the limits of the methodology.

One of the things that I’ve heard the last guys talk a little bit about is that it’s not really about scaling the methodology. It’s really about scaling the organization. And if you think about what that means, it’s not that we’re not going to do big products and it’s not that we’re not going to have large companies.

But when we talk about scaling an organization, what we’re really exploring is the idea of how do I create entities within the enterprise that are loosely coupled from the other entities within the enterprise. So if I’m dealing with something at the team level and I’m talking about Scrum teams, I want to have teams that have few, if any, dependencies between them.

If I’m up in the scaled areas, then I’m talking about having maybe value streams that don’t have dependencies between them or I’m talking about work groups that don’t have dependencies between them or product areas that don’t have dependencies between them. But when you start getting into really, really large organizations, there are dependencies everywhere.

And so when we talk about scaling so that either a team or a work group can operate with greater agility, what we’re really talking about is how do we look at the organization in a way that we have smaller groups that are able to actually own delivery, have interaction with a customer or product owner or aspect of the business, and can operate relatively independently from each other.

So this idea that it’s not the practices of the methodologies that scale, it’s really the principles of encapsulation versus orchestration that fundamentally scale. It’s the idea of small batches that scale. It’s the idea of creating flow across those small batches that scales, the idea of a learning or a can process that scales, right?

So there’s a lot of stuff within the Agile world that absolutely is applicable across the entire enterprise. But when we think about it from a practices-first perspective, there’s going to be some size of the organization that the methodology is going to hit. Dependencies, organizational impediments, organizational design, technology, architecture, anything that creates any kind of dependencies, the methodology is going to hit that and it’s not going to have an answer for it. That’s the problem, right? That’s the thing that we’re trying to solve.

Descaling Large Organizations to Scale Agile

So when we talk about transformation strategy, what we are fundamentally talking about is how do we systematically over time start to create this notional idea of a decoupled enterprise?

How do we start the process of breaking dependencies so that teams, work groups, product areas, or different parts of the organization can operate more independently? This is why I think it’s super important. Companies out there, we’re 20 to 23 years into Agile as a formal thing, right from the signing of the Agile Manifesto in 2001.

Agile methodologies have been emerging for ten or 15 years prior to that, maybe even longer. One thing that I find really fascinating is that we haven’t given up on Agile yet. I know some people have. We have some clients that won’t even use the word “Agile.” They know they need agility, the performance characteristics of an Agile organization. But they’re so burned on the dogmatism of Scrum or the dogmatism of SAFe that they don’t even want to talk about it.

We have some big problems to solve organizationally, such as how do we get organizations building the right products? How do we get organizations building products that customers are going to use? How do we get organizations building products on a regular release schedule, making sure that we’re doing the most important things right? We have some really big challenges. The only reason we haven’t abandoned Agile yet is that we haven’t really come up with anything better. If you say, “Agile isn’t the answer,” where are you going to go back to? Functional silos? People focused on activities rather than outcomes? Big upfront planning and long release cycles? We just intuitively understand that isn’t the answer.

We’re looking for the answer. You’re starting to hear the industry around stuff. Is that a DevOps problem? Is that a digital transformation problem? Is it a business transformation problem? You’re putting new labels on things, but we’re fundamentally talking about the same thing. We want to have small encapsulated teams that are focused on an area of the technology that are closely coupled to the customer, that can produce working, tested, and validatable software at the end of every sprint.

We want to be able to produce working, tested, and validatable software in a way that’s reliable and consistent across the organization. When we have multiple teams that need to come together in multiple workgroups or multiple product carriers, we need an organizational channel planning metaphor that allows us to flow value across multiple teams. That’s why it seems like every week I come online here, I’m doing podcasts with Dave, and we’re talking about what it takes to really do Agile at scale because I don’t think we have a good alternative yet.

At the end of the day, complete cross-functional teams organized around value that have autonomy over their technology stack, that are rapidly getting feedback from clients that are testing as they go, that are continuously deploying – maybe I’m myopic, maybe I’m too close to the problem – but I don’t see us coming up with something fundamentally better.

The challenge is my constant struggle with the world of Agile and Agile methodologies. Some people call it the Agile industrial complex. Maybe we’re a part of that, I don’t know. But this idea that we can install Agile via training, methodology, and so on – that’s the part of the Agile movement that I believe is failing right now.

If we can create small, encapsulated teams that are operating in a more continuous flow model, testing, getting feedback right, we have the opportunity to fundamentally do Agile in any size organization. We’ve been fortunate to work with some really, really large organizations, tens of thousands of people going through Agile transformation, and in every single one of them, it’s never been the methodological elements that have created performance and scale.

What it really is – and I guess we could use the word “scaling” – is about breaking the organization up into encapsulated entities so that each entity can operate with agility. Once the whole organization is operating with some level of agility, we can start orchestrating in small batches across and do some really interesting things with multiple teams at scale, managing flow with Kanban systems at a program or portfolio tier level. We can start managing investment strategies, tying up to OKRs and KPIs, looking at the business architecture of the organization, and understanding where we’re going to have bottlenecks in our system. We can invest in those capabilities over time so that we alleviate the bottlenecks in the system.

We can start running the entire enterprise in a way that’s risk mitigated where the risks are front-loaded in the system. And you can really do some pretty interesting things.

The net result of all these interesting things is getting past the idea that it’s going to be the implementation of a methodology that’s going to do it. Again, I feel like a broken record sometimes coming on and saying these things. If you have a blog post, I’m going to do a companion to this video that, hopefully, you’ll be able to read in conjunction with it.

The challenge is, as an industry, we’re going to have to start figuring out how to talk about some higher-level things. We’re going to have to start talking about things that businesses at scale really care about. It’s investment strategy, faster time to market, being able to get the organization to inspect and adapt and to pivot effectively. The only way we have found to do that is through this idea of descaling.

Scaling doesn’t mean we’re not going to do big things. It means that the big things will be amalgamations or roll-ups of lots of smaller things.

On Reengineering the Software Factory

So, one of the metaphors that I use, I happen to be a University of Florida guy, and so over the last couple of years, I’ve been doing a lot of work down on campus with the entrepreneur and innovation group—engineering leadership. And probably six or seven years ago, I got connected to the industrial and systems engineering program. And, I started talking to the professirs and the students in that world, and I was kind of asking them about what they were doing. And it kind of dawned on me that I think what we have is, we have an industrial and systems engineering problem. But basically what we’re doing is we’re trying to figure out how to re-engineer the software factory. Sometimes I tell those kids that there really is an assembly line of sorts that’s going on. You go into an IT shop and see a bunch of people sitting in team rooms, cubicles, or working from home on Zoom. The idea is that we have all these people sitting and typing at their computers, but they really are delivery pipelines, an assembly line of sorts.

There’s a metaphor where you start to think about components that are being created and arriving in a just-in-time way and being assembled into larger subsystems. Subsystems are assembled into ultimate products. We’ve done a lot of work in the defense industry and automotive industry. When you start to look at how physical goods are made on an assembly line, there are serious metaphors. It’s almost like the difference between doing a really high-end boutique car made one at a time versus having a factory of things where teams are working on user stories that roll up into features, and features are continuously delivered.

Features get rolled up and delivered into an epic or an initiative, and the ROI of the initiative gets tied up into an OKR. We can argue whether that’s Agile or not, but there’s a huge opportunity to think Agile, independent teams at the work surface level, but then agility at the program, portfolio, investment tier levels.

There’s something here, right?

Why the Agile Industry is Stuck

One of the things I want to do over the next week, month, couple of months is to start talking about some higher-level things in the industry, such as how to deal with OKRs, business architecture, investment strategy, enterprise architecture, leadership in organizational design, and all those kinds of things. But if our mental model is installing Agile by installing a methodology, and that’s where it ends, then I think we’re going to lose an opportunity to have a broader conversation.

Candidly, I think that’s a big part of why we’re stuck as an industry and why nothing else has emerged so far. The challenge is not a better methodology. The fundamental problem is understanding organizational design, dependencies, and breaking dependencies. As Agile coaches, we need to call this to a higher level of thinking.

A few weeks ago, I was in a room with one of my Agile coaching friends talking about something as simple as forming the right kinds of teams, and I think a lot of us have given up that it’s even possible. How do we elevate the conversation as Agile coaches and consultants in the Agile space to talk about how to organize in such a way, break dependencies, and effectively scale these enterprises?

I don’t mean be scaling in the sense that we only do small things, but we be scale in the sense that we have encapsulation and minimal orchestration from the work surface all the way up into the broader enterprise. Understanding that, having our heads wrapped around that, is what will give us the language to talk about higher-order concepts.

In addition to those higher-order concepts, we’ll talk about how to form the right kinds of teams, how to break dependencies, and how to move an organization from a scaled mindset to a descaled mindset, an encapsulation, minimal orchestration mindset.

And again, just to kind of close a sub, the reason why I think this is so important is because if we keep beating the drum that it’s about methodology, practice, mindset, and culture, and we can’t wrap our head around what a broader operating model is going to look like, we’re going to wear everybody out.

We probably have, to some degree. So, you know, maybe sometime in some of my next sessions, what we’ll do is we’ll actually get a virtual whiteboard, and we’ll start drawing some of this stuff out and exploring. But for now, that’s all I kind of want to say, kind of a shot across the bow in terms of I think we’re fighting the wrong battle.

Talking about scale, methodology. I think what we have to do is we have to talk about the principles that make small team Agile and scaled methodologies work and focus Transformation on the idea of scaling the principles behind these methodologies rather than scaling the practices behind the methodologies. Because if we can get the principles of encapsulation and orchestration, break dependencies, balance capacity and demand, focus on small batches, and we hold those higher than we hold the practice side of it, then we can start making some really wise choices about how to do org design, how to do governance, what to measure, what to control, what practices actually make sense for our organization.

We can talk about how systems and practices lead to culture. We can start talking meaningfully about Transformation strategy. We can talk meaningfully about how do you continuously improve an organization over time? We can talk about strategies for getting alignment across your organization, Shared Cognition. But all of that stuff is really, really difficult if we’re taking a practice focus.

So I’ll just tell you personally, like sometimes in these videos, I feel a little bit stuck. I feel like I constantly want to go back to the basics because I don’t think as an industry we’ve aligned around that yet. And so to talk about the promise of higher level organizational Agility, it’s almost like you have to reset the understanding of team-level Agility.

We did a conference a couple of years ago at this point called Elevate Agile, and the first one we did in Atlanta a while ago. It was a little bit frustrating because it’s like that was the trap that we fell into. We were trying to have this really high-level conversation about what does Agile really look like at scale?

How do we tie it to business problems, how we deal with governance and corporate issues, and all these different things? But we got trapped in this idea of laying the foundation of team-level Agile, so we had to do a dance halo around to figure out how to have these higher-level conversations, understanding that these principled underpinnings are what’s really important.

So I’m going to try to hunt that out. I don’t have any answers of exactly how I’m going to do it just yet. But that’s what I’m going to hunt for. And so super informal, super exploratory. I’m going to try to share some of the things that we’ve been doing for the last 13 years with you guys and just open up a conversation and see where it goes.

And so it’s not going to be like me sitting here saying, “Hey, this is the answer.” What I’m going to try to do is open this conversation up and just explore some ideas and see what you guys think, right? See if there’s a way that we can move the industry into a healthier way of understanding what is really going to drive Agility.

And I’m telling you, it’s not Scrum, it’s not XP, it’s not SAFe, it’s not LeSS, it’s not any of these things. It is the principles that underpin those things. And then what will start to happen is we get really, really good at applying those principles. Organizationally, methodologies are going to start to make a whole lot more sense. So that’s what I have to say with you guys today.

I hope you’re enjoying some of these new videos that we’re doing and some of the thinking that we’re trying to put out. I hope I don’t sound like too much of a broken record, but we’ll see what we can do to pivot past this over the next couple of weeks and months. So you guys have a great weekend.

We will talk with you next time.