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.
