The Hidden Factors Holding Agile Back In Your Organization

Agile methodologies promised transformative value but, in many large enterprises, Agile has become commoditized—a standard process that teams follow rather than a strategic driver. Many transformation leaders find themselves marginalized as Agile is increasingly seen as “how we get work done” rather than a vehicle for business agility. In this session, we’ll explore why simply “doing Agile” often falls short of delivering meaningful value and what transformation leaders need to do to bridge the gap between Agile practice and true organizational agility.

We’ll begin with a return to agile’s core principles, focusing on team autonomy, feedback loops, and iterative delivery. Yet, we’ll expand this foundation by addressing critical organizational enablers and blockers that impact agility. From technical dependencies to cross-functional collaboration and architectural constraints, we’ll look at the ecosystem around Agile practices that can hinder or enable agility. This holistic view will offer practical insights for creating the conditions Agile needs to thrive, driving tangible business results and reclaiming agile’s strategic impact.

Video Transcript

So much of what we’re doing, whether it be agile or product extraction or engineering modernization or technology practices or buying tools to do data buying tools to do DevOps, buying tools to do ai, what we’re doing is we’re just piecemealing an organization together. And if we can really take this first principle of encapsulation over orchestration, if we can take that idea all the way from the top of the organization all the way down and create these strategies across with minimal, lightweight, flow based governance empowered teams at the bottom right, then we’ve got a shot for. I might also say that if we did all those things, the methodologies that we choose likely wouldn’t matter as much.

Agile First Principles

When I think about first principles of Agile, just really, really simply, and we’ve hit some of this stuff, we have this concept of a team. I like to draw teams as circles because the implication is that they’re encapsulated, they’re a unit that stays together over time. And team composition can be largely variable depending upon the needs of any given team. But the general pattern in software is to create teams that they have developers. If you have testers, the testers are on there. If you have a business analyst, the business analyst is on there, you get into a lot of questions about where do you put database people or where do you put tech writers or where do you put whatever. The way that I think about it is that whatever that team’s responsible for, it needs to have everyone and everyone and everything necessary to be able to deliver what’s in its backlog.

So if it doesn’t have the ability to do that, we by definition have a dependency of some sort. But for the purposes of first principles, what we want to do is we want to establish that there is this thing, this aspirational thing that we need is a team, everyone and everything necessary to be able to deliver a working test and increment software. And that team, by the definition of Agile is operates off a backlog. So if it’s back in the XP days, I know that all this stuff’s evolved over the last 23 years, but you had this notion from Ron Jeffries, a card, a conversation, a confirmation. We want a placeholder for a conversation. So it was just enough to be able to enter the sprint and be able to have a conversation about what it was we were going to be able to build.

And so we have a stack of cards or sticky notes on the wall or what have you, but it represents the user story or the capability that the end user would like to have in it. And that’s probably an interesting note too. And large complex systems, as we start to think about teaming strategies, not everybody’s customer is an end user. That gets complicated too. So you ask yourself, who’s the customer? If you’re creating a service or some sort of component, your customer’s, other applications within the organization. And so your customer is different depending upon their perspective of the team. But at the end of the day, I need a backlog and then I need a team and then whatever it is that team’s building, I need it to be able to produce a validatable increment of the product. And I’m using those words really, really carefully.

If it’s software, that measure of success is working test software. And back in the early days to try to get this idea across to some of the teams I was working with is definition of done isn’t that you finished the code at a minimum you have to extend it to it’s tested. Ideally you’d like to extend it to it’s deployed, at least it’s in production, even if it’s toggled off or something like that. But back in the day, one of the definitions I offered is basically set the criteria for this particular team. It’s like I want the definition to be done that the product owner can run it from their workstation, can understand how the capability works and gives you confirmation that it solves the problem that they ask you to solve. That’s a pretty high definition of done, but you think about what is required to do that, I have to have user stories that are written in small increments.

They have to be clear enough to have a conversation around that team in the course of the sprint has to have the necessary people and tools, technology, resources in general that they need to be able to build it and they have to be able to deploy it at the end of the sprint and to be able to get feedback on it. And so the last component, and I never know quite how to draw this one, so I tend to draw it as like a screen, a database, a report, something like that. But the idea is that it’s a piece of the product. It enhances the functionality and capability of the product. And so over here we started off with the idea of working tested software.

We’ve worked with marketing companies and book publishers and all kinds of different things, hotel chains, fast food restaurants, all kinds of different stuff. So the definition can be extended. We all know that Agile came out of the software world. So our default position, most of the companies we work with it. The idea is working custom software can easily be extended to any kind of increment of any kind of product that is out there. And if you’ve been following me for a little bit, one of the things that you start to, you’ll know about me is that I grew up in project management. Actually before that I grew up in IT infrastructure. That was probably the first 10 years. Second 10 years was largely around project management, program management, portfolio management, things like that.

And then last 15 years or so, I’m getting old last 15 years or so running, leading agile and now I’m a marketer and I’m a sales guy and all this different stuff, but I think I’m an idea guy. I think I’m somebody that can kind of see the hole. And that’s a little bit what we’re talking about here is how do you see the hole, but you have to start with some of these first principles. And so you start to think about are we in an environment that this is an interesting point. Are we in an environment where you can just inspect and adapt and figure it out as you go? Or are we operating within a certain set of constraints? My biases where the environments I grew up in dates mattered, and the general ethos and the agile community, at least as I was getting introduced, and I still see evidence of it today, is that it’s like trust the team.

They’re going to do the best they can. I would suggest that that is true if the conditions are created, where them doing their best will create the results you want. But in a lot of situations, the ecosystem that surrounds these teams or even the way the teams are constructed themselves, doesn’t allow people to necessarily make the right decisions. Now, if you have a properly encapsulated team, the team can generally make the right decisions. But when your constraint or your impediment is outside the team, let’s say you’re a team that’s operating on a legacy monolith that requires 400 people and long release cycles and all kinds of different things. I grew up in financial services, so it can’t be off by a penny who wants their bank account to be randomly decremented by pennies or dollars or more. So it has to be right. And so we’re dealing with these constraints that it has to be right, at least has to be delivered on time.

We have to know to some degree what it’s going to cost so we can make the investment. And so these were all the challenges that I was trying to face. And again, as you build these bigger arguments, you often have to start from the idea of well, if agile is going to scale or agility is going to scale, it has to be connected top to bottom. I mean all the stakeholders have to work. If you truly want to do just emergent adaptive, agile, by all means spin up a small team and go, A lot of what I talk about doesn’t apply, but if you’re dealing with large complex ecosystems solving critical business problems with critical dollars, you have to tailor Just kind of to pull a little quick aside, one of my probably biggest influences of my life is Alistair Coburn read everything that he did, and it’s really fascinating.

Alistair was a signer of the Agile manifesto. You guys probably all know that, but he spent a lot of his time before that doing methodology work for IBM. And one of the things that I think is really underappreciated and under talked about is his crystal family of methodologies because, and I think the reason why is that on the one end you have something like crystal clear, this incredibly lightweight, and then I want to say the highest one’s like Crystal, ruby or something, crystal sapphire, I don’t know, right? It’s harder. And basically what Alistair’s doing is he’s making the case that as complexity goes up, size of the team goes up, criticality of dollars goes up. I might’ve added that one. It might just be complexity and team size or something like that. But I think criticality of dollars comes into the equation as well. You need a more rich methodology. And again, that’s why we start to see safe and less and other things.

So, it all comes down to first principles as you start to build methodological frameworks that scale and organizational models that scale. And so again, we’re just planted squarely in this space of what does the team need to look like and how do I create those conditions?

Why Predictability is Critical

So back to this idea of predictability, back to this idea of operating within constraints. There’s two main reasons for predictability. The first one is, is that if somebody is investing money in you, they have to have some notional idea of what they’re going to get for their dollars. We have a small agile team that works for us in the confines of leading agile building discretionary software with discretionary dollars. We’re inventing, we’re learning. We don’t even do, we barely do Scrum. It’s really lightweight. There’s cadences. Don’t do velocity, don’t do estimations, don’t do burn down because at the end of the day, as long as we’re learning, it’s great.

And again, if you can get that, you get it. That’s what I would do. That’s what I do with my dollars. But if you’re in a place where you’re accountable to dollars or you’re working with teams where people have to come together in sync over time, then there has to be some element of predictability. And so at the team level, the way that I always looked at that is that if I know the size of my backlog, I know the velocity of my team, I can start to anticipate with some degree of fidelity what is going to be my cost, team size, hourly rate, daily rate, annual salary, basically teen size times duration, or I can start to calculate in the presence of fixed costs, I can start to calculate duration. And for me, back in the early days, that kind of became the holy grail again, project manager.

So I go back to this whole DSDM diagram. It’s like triple constraints of project management, let’s say time, cost, and scope. The fallacy in software project management oftentimes is that we don’t understand variation, we don’t understand risk, and so we estimate time, costs and scope, and then we fix the triple constraints and there’s no degrees of freedom. What agile basically came along and did is it said, okay, we’re going to fix time and cost and we’re going to vary scope. We’re going to turn the triangle upside down, so to say, in doing so, there’s mechanisms for doing that. So if I know that I have to be at a trade show in 10 weeks and that’s going to be five sprints, then five sprints is my constraint. If I know that my team’s velocity is let’s say a hundred points per sprint, then I have capacity in the backlog to do what is that roughly 500 points, but controversial topic.

In order to do 500 points, I have to have a way to estimate the backlog. I have to know that it’s 500 points. I have to have a way of measuring the velocity of the team, and then I have to be able to calculate or be able to operate within the constraint of five sprints. If five sprints is not my constraint, let’s say, and I have to get that 500 points done, but then I measure my velocity as being 50 points a sprint, well then I know it’s going to take me about 10 sprints to get that backlogged done. So there’s this element in agile that I think is interesting that there is a way to start to anticipate, and I’m not saying hold people accountable. I’m not saying put ’em on death marches, all those kinds of things. I’m like, we have a rough idea of what the backlog is.

We have a rough idea of the velocity of the team and there’s ways of it, and then I can start to anticipate scope or duration costs, things like that. And that’s like my fundamental ethic. Certain things that go along with that, we have to have the idea, this is some of the physics that I talk about, is we have to have kind of a commitment to this idea that once the team establishes a capacity, they have a throughput metric of some sort, all kinds of different ways to get that right. We have a throughput metric of some sort. And if I know the size of the backlog, that’s really to my demand. So I know my capacity, I know my demand. What as leaders we have to do is we have to be committed to the idea that if the team has a stable proven track record of being able to deliver software product at a certain rate, then I have to respect that throughput.

It’s reasonable to ask questions like, well, is there anything I could do to help that throughput improve? Right? Is there any waste in the system? Do you need more people on the team? Not that that’s an infinitely scalable thing, but maybe there’s a key skillset or something you don’t need. I can put that on the team. But the holy grail of agile at this fundamental level is the idea that we’re going to know the size of the backlog, we’re going to know the demand placed on the organization, we’re going to know reliably the capacity of the team, and then we can start making some business decisions. And another thing that’s kind of fascinating, and now we’re starting to think of topics of scale and stuff like that, but at the simplest level, the idea is is that if I have a backlog of 500 points and I’m only going to have capacity to do 250 of ’em, then I get to put the highest priority things at the top. So when I run out of time, when I run out of money, then I at least have something that’s potentially shippable and usable by a client that maybe I could go do a demo on or something like that, or put an early feature set out in market. So you start to think about these first principles, it’s like have first principles, capacity has to be balanced with demand.

That’s the one that I probably talk about the most. Other things that we talk about around here is the idea that dependencies just kill agility. And so when we start to think about what we want to do at scale, now we start to think about the idea of if I don’t want orchestration costs, I don’t want planning costs, I don’t want to have to put this layer above the teams to do prep work and crosscutting concerns and all those different things, then I have to start breaking dependencies between the teams, which kind of leads to the next thing.

How Do You Approach Breaking Dependencies?

It’s like with dependencies, you either have to manage them or you have to break them. And sometimes what we’re guilty of in the agile community is the idea that we are going to self-organize dependencies away again in smaller environments, less complex environments where maybe the goals of the organization are totally aligned, maybe it is reasonable to expect two or three teams to create encapsulation strategies for their particular part of the application and get it to a place where it’s communicating through interfaces and such like that.

But just the reality is in the early stages of this, for a lot of companies, that is just not the case. Everything’s really super misaligned. And so this idea that you either manage dependencies or you break dependencies, break those become kind of just the fundamental physics to me of this. I’ll give a nod to large scale Scrum. I haven’t been tracking less for a while, so I don’t know how that’s evolved as a methodology probably in the last seven or eight years. But one of the things that I appreciated about VO and Craig Laman and the work that they did is that they really articulated a strategy for how agile should work at scale. And when I get pressed into a corner, I’m fairly methodology agnostic, but when I get asked for which methodology I think is the most applicable or is the most right, I would probably lean towards large scale Scrum because it is a methodology that prioritizes for maximum encapsulation with minimal orchestration.

But the challenge is that most organizations aren’t built that way. They’re teaming strategies, their organizational design, their technology architecture, all that kind of stuff. And there’s a line in one of, I think it’s the first less book that talks about the idea. And it’s really kind of a really interesting throwaway kind of acknowledging this is paraphrase 10 years old or something. But it’s like the idea is that that’s really hard, but it’s required, so get to work. So a lot of what we’ve been doing over the last 14 years of leading Agile is, okay, cool, I agree with you. What is the process or what is the approach rather for starting to progressively decouple organizations? So maybe that’s a way of looking at the family and methodologies that are out there. You have really lightweight things like let’s say Crystal Clear. You could argue scrums pretty lightweight, you could argue XPS pretty lightweight.

And then on the other extreme, you start to see things like Scott Ambler might disagree, but you start to see things like discipline, agile delivery. I see, seen some of the stuff out shallow way invented around the flex model. You start to look at probably the most popular prolific one, the Dean Leffingwell invented around safe. And what you fundamentally have is in some form or fashion, you have an orchestration strategy to create a compensating control in the place of dependency, managing dependency breaking. So that’s kind of a thing. And so we’ve come to the conclusion that agile transformation isn’t really so much about changing mindset or culture. That’s part of it. It isn’t so much about the introduction of methodology, but what it’s really about is this fundamental idea of creating the conditions for the methodology to work and the culture to emerge. And so we walk into a lot of clients, they’re doing something with Spotify.

I don’t even know if that’s quite a thing anymore. I don’t even think Hendrik Berg thinks it’s much of a thing anymore. I don’t even know Spotify thinks it’s much of a thing anymore. But it was an interesting pattern and it had its moment. You look at scaled Agile framework, people call us and they want to talk about scale agile framework. Sure, there’s some people that just want to do lean startup stuff and I’m all for all of ’em, and they all have their place. But even with something heavyweight like safe, it’s like you’ve got to, you’ve got to not only be able to tailor the application or the methodology to get it into a place that you need it, but you also have to be able to create the conditions in the organization where that methodology works. So while I might be a big proponent of less, none of the companies that have ever called us over the last 14 years have a set of conditions where I believe that less will work, very few candidly actually have a set of conditions where Scott Framework will work.

I had a conversation with Dean Leffingwell years ago at a, I want to say at a Lean Systems conference or something up in Fort Collins, I believe it was. I was like, Dean, you got to give people more guidance on teaming strategies and how to break teams up and what to organize teams around. He goes, that’s not what we’re doing. What we’re doing is that’s the domain of consultants. Now, again, I don’t track safe all that closely anymore. It’s more of an idea for me than an implementation detail. But assuming that’s the case, that was an acknowledgement that the teaming strategies and the way that you think about your software architecture or your product architecture is unique and cannot be described in a methodology. And again, really, really tough because it’s like we’ve gotten to a point where people want to believe and they want to believe that this stuff works and it does given the right conditions.

But the question you ask yourself is how do you create the conditions for that to work?

Redefining What it Means to Do Agile

Okay, so we talked about the idea that basically any methodology that you pick off the shelf has the possibility of working. They all work somewhere. I mean, all these methodologies came out of this idea. You had a consultant on the ground that was doing some cool things. They created a framework that would work, they packaged it, sold it, set training around it, built consultancies around it, all that kind of stuff. And it became a thing because that’s what the market wants. The market wants a thing for this. They want an easy button to some degree. But I think from the early story I told you about Jeff Sutherland and to the later story I told you about Dean Leffingwell, I think everybody recognizes that this is all very contextual, but contextual is hard and training classes are easy.

So, there we do, we find ourself in this situation. And one of the things that it’s really bit of interesting feedback is probably about a year ago I happened to be in London of all places, and I did a video on something with regard to Agile. And the bit of feedback that I got, I think from a couple people was that, and it was something really snarky. It was like to the extent of tell me nothing about Agile without telling me nothing about Agile. And when I was thinking about this and maybe how I wanted to approach this conversation with you guys was it’s like I don’t care if it’s agile, candidly, I don’t care if it meets the definition of agile. I’m not part of that religion. I’m not part of that cult.

What I think about is what businesses are hoping for by making these investments or adopting these methodologies is that they’re going to improve their business outcomes. So I started down the path, I was writing a couple posts. I don’t think I ended up publishing ’em actually, I know I didn’t end up publishing. They were part of a longer story, and I don’t think I was committed to writing out the longer story is maybe I should have been, but it was this idea that, okay, if Agile’s a thing and we’re just going to put walls around it and we’re going to say that Agile’s about culture and Agile’s about scrum practices, if that’s our definition of agile, okay, you can have it. I don’t need that definition of agile. I don’t have anything better to call it. I think more broadly it’s agility. I know some folks try to go down the path of business agility, but the way that I think about Agile at the team level is take the word out, take the word, it’s connotations, it’s baggage, it’s attachment to culture and ethics.

And ethics is printed out the right culture and value. You take out its attachment to processes as they’ve been popularly described over the last 20 years. And you just really think about what we’re doing, what agile fundamentally is. To me, it’s an incremental and iterative process that is designed for close customer collaboration at a minimum, maybe lower fidelity specification and rapid feedback. I want to be able to produce a working test and increment of product that I want to be able to put out in market, and I’d like to be able to do it in a reliable, consistent cost-effective way. I want to be responsible for the resources that the organization that I’m working in and has me under their employee. I want to be responsible steward of those resources. So when I start to think about agility or agile, the definition is much broader to me. Which actually, this is kind of interesting aside. This is something I think about quite a lot and it’s probably going to be relevant to a lot of our conversation.

The thing with Agile is that agile, agile is fundamentally a good idea, I believe as it was originally described. It’s a way of thinking about building software that I believe is universally true and it does rest upon certain values and principles. Sure. But there’s a set of outcomes that it was conceived to try to achieve. And it’s like a lot of things in life, right? It’s like we take something that is true and we proceduralize it and we turn it into a thing and then we start doing the thing and somehow along the way we get lost in what it was actually designed to create politics falls in this category. I think religion falls in this category. Just a lot of people are checking boxes and doing things without achieving the benefit of doing it. And I think that’s why a lot of people accuse agile of being like a religion because it’s like there is a truth.

You might agree with that or not, but there is a truth and up underneath that truth is a way of living the truth. And so more broadly, I think about a lot of things, and there’s a lot of things we’re going to talk about through the course of this that are fundamentally good ideas. Lean’s a good idea, Ru wasn’t a bad idea. There’s lots of things that aren’t bad ideas, but when they get over-prescribed over ritualized and we forget what the good idea was actually in place to describe, then we get really super prescriptive and it becomes the one way or the only way. A lot of the stuff that I am going to talk about is I tend to take the good idea and I abstract it up into the principles that made it a good idea. So some of the things that we’re going to explore are ideas like business architecture, business capability modeling.

Great idea. If you take it down into its prescriptive methodological attributes, it loses something. But if you think about what it is more abstractly and more principally based, it’s actually really, really cool Domain design, domain driven design is kind of the same thing. I’ve been talking a lot about that in our organization lately and using it as a pattern. And when you think about something like domain design, I’m not a technical architect. I’ve read some books, I thematically know what it is, but I also know there’s a lot of people that get very prescriptive in terms of what domain design is domain-driven design is and what the words mean and how it’s applied and it’s a thing and all this stuff. And I’m like, okay, cool. At the end of the day, it’s just a way of thinking about software in terms of what it produces for the business.

Probably one of the most interesting books. I don’t read much books anymore. I kind of skim ’em for content and kind of do surveys of them, but there’s a book that I read called Data Mesh Action. I’m not going to be able to pronounce the guy’s last name who wrote it, but it’s a good book and he actually makes a really interesting distinction. He talks about the relationship between data and domains and business architecture. The first person I’ve ever read, not that I’m that extensive in my reading, but first person I’ve ever read that made that direct connection. And so you think of something like Data Mesh is not an expert in implementing data mesh, but best I can tell, it’s fundamentally an encapsulation strategy for data, a way to make data available to the organization via APIs, a way of having teams own their data.

And so you start to think about something like data mesh, you start to think about something like the main design, you start to think about something like business capability modeling. And what you start to see is when you abstract up all kind of the same stuff, we’re all hunting encapsulation orchestration, but that’s a little far down story. So I guess just point being is that if Agile has been co-opted by the mainstream and has been defined as scrum or safe, or it’s been defined as empowering people and collaboration games and sticky notes and stuff like that, okay, you can have the word, I’m not going to fight over the word, but I believe what we were really doing when we coined this phrase, I say we, the 17 signers of the manifesto coined this phrase. They were basically saying, and this is what I think is unfortunate, and it was the implied stuff that I thought was really important.

Can we put six people in a room, give them ownership over the technology, have them collaborate with a customer, deliver the most business value first, make sure there’s working tested software going all the time. And in that context, in that ecosystem, sure we can proceduralize it or codify it with frameworks, we can create really awesome teams and really awesome communities that work really well together. All that stuff’s really super important. But if we don’t create the ecosystem where all that happens, I don’t think you can do it in reverse. I don’t think you can teach people practices in a bad ecosystem and hope the culture emerges. I don’t think you can teach people the right cultural behaviors, the right collaboration behaviors, and hope that process emerges and the organizational structure emerges. Again, I don’t deny that it might not be possible with the right team and the right conditions and the right leadership and the right everything, and maybe that’s why people double down on the idea of culture first.

If I get everybody convinced that this is the right way to do it, then maybe, but that gets into some of the other stuff that we’re talking about. Some of these ideas that I started branching off into is the idea of, well, what about when the data’s not in alignment with what’s going on? What about when the data’s managed by a different group? You have a data warehouse, data lakes, what about when security is outside the purview of the team? And that’s an outside influence. What about when your team doesn’t own the architecture of the system or the tools you use? What if the business isn’t aligned in a way that supports encapsulated technology?

Practices and Culture Aren’t Enough to Achieve Agility

So when I start to go down this idea of agile enough, you can really start from the practices crowd, right? Are agile practices enough? I would say that the verdict is out and that wholesale adoption of practices is not going to solve your problem if you are going to believe that, right?

You would find yourself in a situation where you would have to believe that if I start doing Scrum or I start doing safe, then I will identify the impediments, technical architecture, data architecture, business misalignment, all those things that somehow by doing Scrum or safe, we’d identify those impediments and we would systematically remove them maybe in a small team. But I think that in most large organizations, that stuff is fairly entrenched outside the team and those impediments are unable to be removed within the purview of a team and let’s say even in a complex software ecosystem that they were able to create those conditions and were able to fully decouple themselves At best, you would create a local optimization within the broader enterprise, and we talk about organizational antibodies, it just wouldn’t be tolerated. So that team has to operate and play nice with the other teams around it, and even under the best of circumstances, like I said, start doing scrum impediments, identified impediments beyond the purview of the team.

Let’s say we even overcome that, you end up with a local optimization that doesn’t work well and play well with its neighbors. The most challenging things that I’ve seen over the years is when people come in and they try to do what we call culture first transformation around here, we’re going to teach people, values, principles, all those kinds of things. We’re going to teach people how to empower their teams. I can go on rants for days about this kind of stuff, but at the end of the day, the way most organizations are designed is that there’s somebody above that team or multiple IES above that team that have fiduciary responsibility for the output of that team. They’ve hired the people, they’ve allocated the dollars, they have made commitments, and so you get yourself into this place where asking that leader to delegate authority to the team and let them decide and power the team. We hear that kind of stuff a lot. Again, not a bad strategy if they’re in the right ecosystem, I would encourage it if they’re in the right ecosystem, but until you get the rest of the organization in alignment with that, it’s just not going to happen.

So, we find ourselves in this. Practices first isn’t sufficient. We need the ecosystem around it. Culture first isn’t necessarily the right thing because teams that working together don’t necessarily produce the right outcomes and the presence of all this other stuff. I’m talking about asking leaders to delegate into teams that can’t be reliable or predictable or make and meet commitments or what have you, that’s not going to fundamentally work. So even at the team level, practices and culture are insufficient. What we really need are the three things that I talk about. Complete cross-functional teams that own their technology, working off of clearly defined backlogs that align themselves up into organizational priorities and working tests and software that can be regularly evaluated and integrated with the rest of the application suite, whatever that is, or rest of the product suite. So that’s what we’re hunting for. So practices insufficient, culture insufficient at the team level.

I have to have the three things wrapped in practices and wrapped in culture to even have a shot at this.

Determining Your Current Level of Agility and How Agile You Want to Be

Now I’m going to walk through a little bit of some of the language that we’ve used to untangle some of this, and it’s going to be a little bit of a build up into some broader concepts that I think are relevant. But one of the models that we introduced about 8, 9, 10 years ago, something like that, we just call it four quadrants because we’re apparently not super creative with our naming. So we have the three things, we have the four quadrants and we go down even further. We have the 10 circles, so we like to count geometry, I guess, and leading agile, but I’m going to walk through it because I think it’s somewhat informative if you look at this, what we did is we basically came up and we said, okay, vertical axis, horizontal axis.

On the horizontal axis, there’s two tensions. On the left side of the tension, I put this idea of predictability on the right side of the axis. I put the idea of adaptability, and this was probably 16, 17 years ago when I was working at version one. And what I was realizing is that I had bought into this, I’d come out of this big corporate financial services thing, but when I joined version one, I was really getting introduced into the ethos and the values in a way of the agile community that I hadn’t been exposed to. And what I observed was is that most folks in the agile community value adaptability. When I talked to most leaders that were trying to adopt agile, what they really biased towards was this idea of predictability. I thought that was interesting. And so I would facilitate workshops and I’d put my quadrants up and I’d explain it.

I haven’t finished explaining yet, but I explained it and I’d talk about that access and I’d ask the room often full of senior leaders and executives is do you value your team’s making a meeting commitments all the time? Everybody on their hand raise their hand. Yeah, value predictability. Everybody wants predictability, okay? So if you think you’re going to work with a leader that doesn’t want you to make and meet commitments or do what you say when you’re going to do or deliver a project on time, it’s not going to happen. But the other side, you ask them to raise their hand. You say, how many people want to change when they learn new things? Everybody in the room would raise their hand. Everybody wants to change when we learn new things. And so I’d say that’s reasonable too, because as a leader, I need you to make meet commitments.

I need to be able to respond to change is my market changes. The thing that I would ask them to consider is that the more you push to the left towards predictability, the less easy it is to change. As you push more towards the right for adaptability, then you start to lose the ability to make meet commitments. So it’s a tension, it’s a set of trade-offs. Right? Now on the vertical axis, this came out of some of the clients that we had back in the early days, and some of my version one time as well is on the vertical axis. We put what I might describe as market expectations. So the horizontal axis was kind of like organizational expectations, and then the vertical axis could probably be called market expectations, although I don’t think it’s universally market expectations. And what I put at the top of this was this idea of emergent.

And what I meant by emergent was something along the lines of we don’t really care what we build, what we care about is can we figure out what the market needs? So I think about the early days of Facebook or Google or Snapchat’s, one of the ones that I use when at least I did 10 years ago or five years ago when I talked to college kids using Snapchat. You look at the evolution of products over time, something like Google, they just have to basically sell advertising, at least in their core products. They would just sell advertising and they would sell your data, your information, whatever they use to gather that or to sell advertising or what have you. It didn’t really matter. They could build all kinds of things. They could build feed readers and Google docs and social media platforms and search engines and what have you, because the product was the data and they were selling you advertising.

That’s how they made their money. And so the features that they built over time were somewhat emergent, right? They can truly inspect and adapt in the marketplace. On the other side of emergent, I picked the word convergent, and what I meant by convergent when I put this on here was to some degree, we believe we know what we want. We might have a requirement or a specification. Now for those of us that have done requirements and specifications or built requirements and specifications or tried to project manage the requirements and specifications, requirements and specifications aren’t always as certain as they’re made out to be, right? So that’s part of the problem. It’s like there’s this illusion that we’re building to a fixed set of requirements, and I’m sure sometimes in some domains we are, but in a lot of cases we don’t really know exactly what we want to build, but we think we know exactly what we want to build.

So it’s kind of emergent, but there’s at least this illusion that we’re moving towards convergence. So in that context, what you start to think about is this idea that in the upper left quadrant that tends to be very ad hoc and heroic because the organization has an expectation that something’s predictable and the market or the product has this need to figure out what to go build. That’s a really, really tough place to be. You find yourself often in this kind of a place when maybe you might even know what to build or what you want to build and you need to hit a certain date, but the technical complexity is really too high, or there’s a lot of technical debt in the software, or you’re inventing new algorithms or new math or something like that. And so anything that upper left quadrant tends to be ad hoc, and to the extent that you’re able to deliver in that quadrant, it’s usually heroics.

Death marches a few exceptional human beings that are just killing themselves to figure it out. It’s not really a way typically to run a business, although businesses run that way down. On the lower left, we have this idea of predictability and convergence. So we want to make a meet commitments, and we know at least we have a notional idea of what is we want to build. And this is where typically the plan driven side of the world comes in. We know the requirements, we know the estimates, we know the timelines, we know the scheduling, we know all this stuff. So that has typically been the home base of maybe what I might call traditional project management.

Fine though is that we know that in practice, when you try to fix the triple constraints, you create an illusion of certainty, but you don’t have the reality of certainty. And so in the presence of the organization’s need for predictability, we have this illusion of certainty. In some of our early transformations, we actually had leaders that would say things to this effect. It’s like when we were doing waterfall, we were never late until we were 90% away through the project. Now with Agile, we’re 10% in and we find out we’re late. Well, we have this illusion of certainty. Gosh, so many threads we could pull problems with estimation problems with human beings doing knowledge work. I mean, there’s just a lot of stuff. There’s a lot of variation in the system that is really, really difficult to account for. You compound that with matrixed organizations and part-time team membership and just go down that rabbit hole all day long as to why that’s set up for failure.

Now, giving nod to a guy like Glenn Alman, I dunno if anybody knows who he is, he wrote a blog called Herding Cats, and I used to follow him a lot in my early days. If you’re doing really mature software project management and you have Monte Carlo simulations and you’re able to operate within calculate ranges and those kinds of things like sure, right? If that’s your level of project management maturity, there’s a lot of stuff you can get away with and implement Agile, and most organizations aren’t like that, right? So what we did is down here, this is where traditional project management plan driven lives, but what we found is that through these different layering systems in Agile, not so much safe, but the way we think about it, scrum or based at the team level, these program layers that operate just above the team that are doing some of this look ahead work and then up the top, we might subordinate that to a portfolio and investment tier and have cascading intent through the organization.

There was a lot we could do with Agile and Lean that wasn’t traditionally agile, wouldn’t meet the definition of the people who tell me, I don’t know anything about Agile by not telling me I don’t know anything about Agile, that kind of a thing. But there’s a lot of agility that you can get out of that. You can get a reasonable shot at making a mean commitments. You can take a reasonable shot at orchestrating dependencies, getting ahead of these things, really operating in a more lean value flow kind of model. So there’s a lot of agile type things. There’s a lot of agility that you can get when you’re trying to balance predictability, fixed time and cost with some notion of variable scope so that we have a shot at converging within the time and cost constraints that we want to do. My general take is that Agile kind of lives down here.

So you think about the idea of a backlog or the ability to write out user stories, a release or several sprints in advance, the ability to put estimates on them. There’s at least some notional idea that you have an idea of what you want to build. If you’re going down like a true agile path or at least an agile as commonly prescribed path, then what you’re finding is that you can at least sit down and think about the requirements. Now, you might need to respond to change. Some things might get bigger, some things might get smaller. You might leave some things out, you might add some things in, but you got a pretty good idea of what it is you want to do. But in order to maintain the adaptability, what Agile does is it says, okay, every two weeks, let’s say if we’re doing sprints and scrum every two weeks, we’re going to make the commit.

We’re going to let the team deliver against that commit within that sprint. We have fixed time and cost. We have some ability to vary scope. And I know this isn’t popular in every place in the agile world right now too, but I have a belief that within sustainable pace within the team getting to decide what they bring into the sprint, that the team should meet the sprint commitment. There’s reasons at times why they might not. But if I start to look at velocity, I want stable velocity over time. So if I have impediments to stable velocity, then I have to go remove those impediments. Some we’re going to know about in advance, some we’re going to find out as we go. Not all of ’em can be resolved day one. That’s where orchestration comes in. But in general, we’re hunting for stable velocity and we’re making small commits every two weeks such that we can establish that stable velocity over time. It’s like a sampling rate, a non-stochastic system, that kind of thing.

So basically what Agile is doing, most of the agile methodologies are doing either the sprint level or sometimes at the release level, is that they’re building an adaptability by creating checkpoints in the system, sample intervals in the system so that they can change their mind, but within the context of that boundary, that sprint or maybe that release to a lower degree of fidelity, then we preserve this idea that we’re moving towards something we know, but we’re creating opportunities for change. And if we find that it’s way harder or more complicated or the scope is continuously increasing, we at least have real indicators so we can let people know when we’re 10 or 20% in versus when we’re 80 or 90% in.

And so in a well-run agile ecosystem, we have the ability to do a lot of project management stuff that can be very valuable to the organization. Now, where it gets kind of blurry, most people would probably say in some form or fashion, especially if you’re kind of an agile purist, they might say, not agile. I’m okay with that. We’ll call it something else. Team-based, iterative and incremental delivery, we’ll call it rolling away planning progressive aberration, we’ll call it whatever, don’t care. But they said it doesn’t meet the strict definition of agile. I had this really cool conversation with Alice Coburn probably, gosh, 10, 15 years ago, something like that. And he said something that I’ve thought about ever since he goes, he goes, it’s not that I think I’m paraphrasing here and he can come back and fact check me at some point, but I’m pretty sure he said it this way.

He goes, when we invented Agile, it was a thing and it had a definition. And by that, I get it right When we ever do anything at scale, it’s not agile. But his comment was, and again, it makes a ton of sense to me given his history with the crystal family of methodologies, it’s not agile, but that doesn’t mean it’s bad. It just means that it isn’t what we defined when we signed the manifesto in 2021 or 21, yeah, 2001. That’s what I’m trying to say. So it wasn’t what we called Agile when the signing of the manifesto happened. Fair point, no argument, but it doesn’t mean that certain things that we do at scale can’t lead to agility or business agility. It’s not that it can’t create optionality. It’s not that we can’t have great teams. It’s not that we can’t have collaboration, but this idea of radical empowerment and the teams get decide everything.

It goes beyond whatever we’re trying to do at scale is we can have aspects of it, but it’s not going to be the full thing. Fair point. So we’ll figure out something else to call it at some point now. So it’s interesting. So this lower right quadrant is where things I think Scrum and Safe Live. I might put less up here at this line, but how I tend to think about the upper right quadrant is very much Lean startup. And so if I put Lean Startup up here, now think about Eric RISE’s book Lean Startup and what he’s really talking about. He’s talking about testing market hypotheses, investing as little as you could possibly invest to either validate that hypothesis or disprove that hypothesis. Are there are elements within corporate America that need to operate that way? For sure. There could be a whole lot more of that going on than is currently done.

I’m a big believer that we should think about disrupting our current market before our competitors disrupt our market for us. But to think about Lean Startup is a methodology that’s on par with Scrum or with some of the stuff that I talk about down in the lower left quadrant. Not only do the conditions have to be created for that level of hypothesis making and validation and this emergent exploration of what a market might possibly be and the goals of most corporate systems that are trying to adopt Agile. And so while Lean Startup might be the most lean, probably really hard to do lean startup work at scale, probably really tough to do Lean startup work within an established corporate ecosystem. And so up here like Lean Startup, you’re almost getting the crystal methodologies. So maybe Lean Startup is up here in crystal clear and lower rights, maybe something like Crystal Orange and Lower Left Crystal Ruby or something like that.

I don’t think I invented any of this stuff. I’m just trying to tell stories around it. A lot of smart people came before me in this stuff. So my initial hypothesis around this was that most organizations, at least ones that call us, they tend to start here because they are going for predictability. Stuff is changing all the way around them. They’re probably trapped down here in this project management traditional project management framework. And they’re looking to do some sort of agile, and my initial hypothesis around this is, we started telling this story 10 years ago or something like that is I was like, organizations want to go here. And sometimes they do. Sometimes they’re able to do it and they’ll create a unique application opportunity. They’ll put a really good team around it, give them everything and everyone necessary to be successful. Maybe they will codify that with Scrum or XP or Lean Startup or something. They’ll have some sort of lightweight framework, crystal clear around it, and they go, wow, that really works. And so they try to take the methodology that they adopted over here, methodology, or maybe even they went down here and maybe it was Scrum and they did that, right? And they were adaptive and everything worked.

But then they tried to bring it back as the answer to this really tightly coupled legacy organization where none of the conditions that supported the methodology in the upper right or the lower right, none of them work in the upper left.

Basecamps: An Iterative & Incremental Transformation Framework

And so, what we started to hypothesize was a really a transformation framework that would enable us to get a company from up here in the ad hoc heroic space into something that was agile. Again, don’t have to use the word team-based, iterative, incremental, lean value streams, lots of Kanban governance flows, trying to work on smaller batches, stabilize the organization in place, and then start to think about decoupling dependencies over time. So maybe getting back to the theme of this conversation, agile isn’t enough at a team level, at least as described in the manifesto and the common methodologies, scrum, XP, things like that.

Agile isn’t enough at that level because you have to wrap an ecosystem around it. As you start to scale, even this extended definition of agile that we’re taking, where we’re willing to include my broader definition team-based, iterative, incremental, governed, flow-based, all those different things, even that kind of stops being enough because we articulated this customer journey, this roadmap we call. And so the idea is that we would go from Basecamp one, see if I can write this correctly. We would go from Basecamp one, which is really just about getting the teams stabilized in place, maybe not the existing teams. We do some teaming strategy work, some names and boxes we call it. We’d figure out what to organize them around. Sometimes we’d use business capabilities or domains or even sometimes components, what have you, to get the organization working. But we also know that even though we could make some change, initially, there were lots of things we couldn’t untangle right out of the gate.

We couldn’t untangle the technology architectures out of the gate. That takes time, even if you have agency to do it. And we also couldn’t untangle any of the corporate governance stuff. We might have some influence over project management or portfolio management strategy, but there are going to be certain things around like audit and compliance, financial controls, go to market strategies, what have you, that were going to be difficult to get on the first swoop. Okay, so Basecamp one for us was largely this idea of predictability. And then we would go to Basecamp two, still kind of all in the same lower left quadrant, same compensating controls, that kind of a thing. And what we would do here is we would try to help organizations reduce batch size.

I would make the argument that there are parts of your organization that never need to be more agile than that. Maybe products that are in maintenance mode, technologies that are in maintenance mode. Back to my financial services example, systems that can’t be off by a penny. Gartner kind of calls these things down in this lower left as Gartner mode one. That’s another idea that’s been, I think, consistently misunderstood and misapplied, I think largely because of the tool vendors that don’t want to be disintermediated in the process. If you’re a traditional project management tool vendor, then you’re going to assume mode one is traditional project management. They should need to be traditionally managed. Again, my ethos is that there is almost no environment where some level of agility isn’t required. There’s almost no environment where big upfront planning and a really strict plan driven schedule is the best way. I think even in hardware and other product domains. Right now, we’re learning that there has to be a better way. Okay, so Basecamp one, Basecamp two for us were largely lower left quadrant constructs. If our goal was greater agility, these are inevitably just compensating controls that we would like to dismantle over time. And so when we started talking about Basecamp three, we kind of labeled that as break dependencies.

And the original idea behind that was we understood that the technical dependencies were going to be some of the greatest inhibitors to being able to do agile development practices, test driven development. It were going to be barriers to continuous integration, continuous deployment, the presence of dependencies were drive costs in the cloud, create legacy monoliths that didn’t scale effectively. I mean, just all kinds of challenges. So we had this notional idea that we could start to break dependencies over time in practice. What’s a challenge with that is that once you’ve gotten the organization working in Basecamp one and Basecamp two, you’ve entrenched some systems at that point, even entrenched some systems. And so when you start to think about, okay, so now I’m going to start to break dependencies between technology objects or even doing reorgs or rethinking out product management works, or what have you start to find yourself in a situation where going back and re-engineering or re-implementing some of the Basecamp one and two stuff around the new technology architecture, it’s a challenge.

So really candidly, what we would start to see is that clients would get a lot of benefit from Basecamp one, Basecamp two, but it was ultimately limiting their business agility. So about four years ago, we spun up a studios practice to tackle this problem. It took us a minute to get the methodologies aligned because the people we brought in were XP people, enthusiasts had background experience and product extraction and technology modernization, technology rationalization and such like that. But largely two practices until we learned how to integrate them into similar engagements. But for the sake of this, the thing to remember is that at some point, there’s only so much you can do with methodology and organizational structure and dependency management on your path to agility without somehow fundamentally addressing the underlying technology issues that are really, really, truly getting the way of being operating with any speed without breaking the technology dependencies that are really going to get in the way of some of the things that you might like to do.

And so on our roadmap, we had this idea up here around Basecamp four, the general idea behind this was really almost like what we’re talking about now in terms of the idea of a product driven organization. Some other words that get used, the idea of projects to products. It starts to get into a little bit about what Gartner’s talking about with the idea of a composable enterprise. But at this early stage as we were thinking about it was like we had a encapsulated technology object with a dedicated team with its own funding that could be invested in continuously and measured by the organization for its performance. Okay, that’s going to be a key concept as we go a little further down this path. And so what I coined it 10 years ago or whatever, was this idea of team-based funding. That’s a bit of anomaly because in my head at that time when I conceived it, what I was tracking towards was again, really like a PDO or a projects to products.

I don’t want to deal with the incremental variable funding tokens that happen in a traditional project management-based organization where I have a portfolio of projects that then get matrix teams assigned to them that are operating against project plans. Like the holy grail of this. And this gets very much into, I believe what Les is trying to achieve is this idea of I have these encapsulated entities within the enterprise that are funded persistently that can then be deployed to solve different business problems. I think at this point I was probably largely allowing for the fact that there was probably still something in the portfolio, some funding increment that was feeding that team. There were still some objectives that they were trying to hit something that needed to be in market. If they were operating as a dedicated team, like our services or component team within a larger enterprise, they still had to be at certain places at certain times.

But where I was headed was that up here is what we call Basecamp five was, okay, imagine a world where you had gone through this organizational decoupling, and you had that dedicated technology object that you could deploy at will continuous integration. Continuous deployment was based upon solid modern engineering practices, test driven development wrapped in Scrum, maybe operating in a less ecosystem kind of a thing that had persistent funding Over time, if I had those conditions, I actually have the option of being able to create something that could approach a more, what I would call experimental or emergent, maybe not quite lean startup, but something that was a little bit more like let’s sense and respond. Again, just to kind of go back to the early days, a lot of what I was trying to sort out was what I was reading about Agile felt very much to me upper right quadrant, Basecamp five.

And so as I was evolving this thinking, what I was asking myself is if I were going to achieve that, what conditions would I have to create to make that work? What would be the organizational conditions and the technology conditions and the project management conditions and the product management conditions and the funding model conditions would I have to create in order to do that? And so what we ended up doing was going through this idea that in order to get there, you would have to do it somewhat linearly and sequentially. And I would say that that has largely been proven true. If you were going to go to something that was like Basecamp five out of the gate, you could do what I was talking about here on this line is go spin up a team, go spin up a lab, go spin up something that is responsible for doing that disruptive market work, like great do it.

But what you might find is you productize it. You’re coming back through here. You probably wouldn’t go through a step of creating dependencies, but you would definitely go through a process where something that was very loose and fast starts getting customers and deadlines and roadmaps and things like that. So you might want to add some governance to it over time.

Summits: The Challenge of Running a Mega-Transformation

Where this began to break down for us about four or five years ago is we did a couple of really, really large mega transformations. And what you start to see in mega transformations is that they kind of operate in two layers There, this layer that I might consider in the realm of corporate governance, can’t type here, can’t write, let’s try this again, corporate governance and then down here execution.

Okay, so this will be relevant later too. So what we would find a lot of times is that you can get special dispensation if you’re doing this in a really plan driven, economically driven way. You can get special dispensation even in large organizations to start slicing the organization up and getting it to do Basecamp one, Basecamp two agile type things. And so we would start to figure out how to slice the organization up, start moving them into a Basecamp one, Basecamp two kind of model. But all your corporate governance, your corporate controls, your reporting requirements, all that stuff that doesn’t change. And here’s the challenge with this. It’s like we can’t expect them to change and we can’t expect them to maintain two governance models forever. It’s hard to even maintain two governance models at scale for any amount of time. So what we found ourselves doing was basically creating an abstraction layer.

And that’s one of the cool things about our Basecamp one, Basecamp two way of thinking about things is that because it not Basecamp five, Basecamp four, it still operates against a structured portfolio and a roadmap. It’s still doing rolling wave planning, progressive elaboration. It’s doing a lot of agile and Scrum stuff at the workplace, at the work surface. We can get a Basecamp one, Basecamp two implementation doing better project management and more able to support the corporate governance than traditional project management can because we respect the adaptability and the change that’s happening underneath. And you can communicate that up. So what we found is that we kind of would set up these abstraction layers, abstraction layers in a Basecamp one, Basecamp two kind of environment, provide all the reporting that you needed up there. Doing this combination of lean governance and Scrum is you got deeper into the organization and you could start to create a model that would start to, okay, the idea is, and it’s complicated, it’s hard, and you don’t get to do this everywhere, but the idea is as the organization gets critical mass at this execution level, then what you start to be able to do is to teach the corporate governance functions, how to flip, how to do projects to products, how to do a product driven organization with product-based funding, how to do things like make smaller bets in market, how to commit differently in market.

But again, we’re talking about really, really large-scale transformations. And so we developed a bunch of methodology to do that. There was something that maybe my team can put in the comments or something we did. We ran a couple of conferences towards I guess the end beginning of covid, we called Elevate Agile, which was where we really introduced a model that we talk about here a lot where we talk about base camps and summits. And so our idea is that if you look at taking somebody through a space camp, one Basecamp 2, 3, 4, 5 journey, it becomes like a series of peaks. So we kind of visualize it as 1, 2, 3, 4, 5. But the organization also goes through a transformation as well, right? Summit one, summit two, summit three, summit four, summit five kind of a thing. And there’s an analog. So it’s like as the organization becomes more predictable, then the enterprise can be more predictable as the delivery organization starts delivering in smaller batches, the enterprise can deliver in smaller batches as the delivery organization breaks dependencies, the organization can break dependencies.

And what we find it’s probably a lag between the two because again, you got to critical mass down here before you can start changing some of the stuff up at the top. So another case why agile isn’t enough, because transforming the delivery organization or a product organization, irrespective, no matter how well you do it at a technology, from a technology view, the rest of the organization is eventually going to have to come along. And so as you might imagine, it’s tough to go out and hire a bunch of people, do scrum master training, or be scrum masters and go to scrum master training necessary, not sufficient. It’s interesting to teach a bunch of people how to do safe necessary but not sufficient. So over time, what we have to do is we have to start to bring the rest of the organization along with us.

And so that story for us was this whole idea of we have expeditions that go to base camps and we have organizations that go to summits, and that’s how we started to extend up into some of this corporate infrastructure that was ultimately going to get in the way of doing something like a full fledged product driven organization kind of metaphor.

Encapsulation: The Requirement for Large-Scale Change

So, as you might imagine, what starts to get really, really complicated around this kind of stuff is that this is a lot of change. And so what does change require? Change requires investment. It requires dollars, right? Time, energy, people like what have you. So change requires investment and it also requires a pretty big goal.

And so if we can’t get investment and it’s not pointed at a really big goal, then it’s really, really hard to get things funded. So now you start to think about, right, I’m going to see if I can connect some dots here a little bit, right? We talked about the idea of expeditions, going to base camps, organizations, going to summits. Let’s talk a little bit about the areas of the organization that have to be decoupled and aligned for this to be able to really fundamentally be an organizational metaphor, an operating model for a large company.

So up here at the top, you have something like, I’m just going to call it a business unit, but it could be a product area, it could be lots of things. The idea is it’s like a business object, probably has a p and l, probably has revenue expectations, lots of ways to group at that level, depending upon the size and scale of the organization. But you have this idea, there’s something up here at the top that is a business unit. Underneath that, something that I’ve talked about a little bit in passing is this idea of business capabilities.

A gentleman I used to work with named Dennis Stevens, who was here in the very early days, introduced me to this idea of business capability modeling as a way of understanding what the business does, irrespective of the technologies that it uses to do it. And different business capabilities have different attributes. They have criticality attributes, they have risk attributes, they have performance attributes. A lot of consultancies do this. They’ll come in, they’ll do a business capability map to help you understand what it is, what are the core business capabilities that your organization delivers against. So the way I think about this is that business units are made up of capabilities right now. You get into certain things where sometimes you have shared capabilities, sometimes you have duplicative capabilities. That’s beyond the scope of what I want to try to do here. We might give a nod to it when we start to talk about some of the product extraction and modernization stuff. But let’s just talk about the hierarchy for right now. You have this business unit at the top. It breaks down into business capabilities. It could also be product capabilities too. That’s a discussion we have internally a lot. Sometimes we’re looking at a product organization more than a pure, like a business. I’m not making any assertions about how to extend this out, but you might have this idea of business capabilities or product capabilities.

Up underneath that, we have the idea of technology domains. So when I say technology domains, I’m thinking in the context of domain driven design, and that’s what I was talking about earlier. So if you think about the idea, irrespective of the practice, you think about the concept irrespective of the language, you think about what we’re trying to achieve, irrespective of the tools, what we start to see is that if I have a business that’s made up of aligned business capabilities, that is where the business capabilities are made up of a aligned technology domains. Now we get into what I talked about a little bit earlier, the idea of data. This is kind of where the idea of data mesh comes in. If I have encapsulated data that is nested up underneath the technology domain, nested up underneath the business capability, exposed BS business or technology, kind of API, conceptually wrapped in its own set of tests or performance considerations, what have you, right?

It’s capsulation all the way down is what we’re really looking at. So it goes down into data. There’s actually a strategies for thinking about application level security to make sure that there’s no supply chain vulnerabilities in your software or that your software is behaving consistently, cannot be exploited. You can do that down here at the team level, not really talking about firewall and all that kind of stuff right now, or DNS strategies or anything, private public stuff, thinking more application security at this point. Then you start to get into concepts like now we can start to think about creating teams around these objects. And then you get up underneath the team level, and now we’re starting to think about stuff like SOA objects up underneath that we start to get into T-D-D-C-I-C-D, things like that, all the way down to just good engineering practices. It’s kind of in that family of stuff. So if you think about this, I mean you could almost, I don’t want to draw all these circles, but you can almost see these things as nested.

And so when you start nesting things like this, you start to create this encapsulation strategy all the way down now. So each level, you might have a team, you might have a set of tests, you might be exposed through a service, API. You start to think about that metaphor all through the stack.

How to Cost Justify a Transformation

And so now you start to ask yourself the questions like, well, okay, how do I do that? How do I do that? What is my economic justification of the investment and what is the big goal that I’m attaching it to? So within that context, what we started to do probably four or five years ago, maybe sooner, is when we go in and sell transformation work. And remember at that time, we were largely a Basecamp one, Basecamp two organization. So that was the level of change that we were technically capable of making at that point in time.

And so, what we would do is we would basically look at how well we could lean out the organization. And sometimes that was taking out a lot of orchestration layers because again, another funny aside, when I started doing software project management, gosh, probably what, 25 years ago, something like that. I can remember models when we put together staffing plans and stuff like that, we would roughly estimate maybe for every five developers, there was a tester, maybe there was a BA for every 15 developers, there was probably a project manager, that kind of a thing. It’s not uncommon for us to walk into an organization where there’s six times more orchestrators than there are people that actually do the work. And it’s a problem. And so the orchestration costs at these organizations is just through the roof. And so, part of the strategy is we’re doing the expedition to Basecamp work, Basecamp one, Basecamp two, base camp three.

A lot of what it is that you can put the orchestration at a level that you can see it and you can see its cost and it starts to cost justify the transformation work. You can start to do analysis on the dependencies and start to see the delay in latency and overhead in the system. If can economically justify the cost of dependencies, then you can start to economically justify taking those dependencies out. So over the last 14 years, we’ve just gathered a ton of data because metrics are a big part of what we do around here. And what’s pretty fascinating is that you can start to say things like, if you spend 5 million over the next three years, you are going to save $25 million. What is the net present value of that investment in today’s dollars? Let’s say that’s 12 million. I’m just kind of making that up.

And what is the internal rate of return around that? And let’s say it’s 300%. So if you want to talk to your financial people about how to cost justify any of this work, you can start to have conversations about the people that you’ll take out of the system. You’ll start to talk about things like, how can I modernize this platform and rapid and test? So we create a zero defect environment. What if we can take the weight out of our release management process? What if we can get to continuous integration, continuous delivery? What if we can strategically refactor our application so that we’re optimizing our cloud usage and we drive our cloud costs down by a bunch? What if we’re thinking about implementing AI and we want to strategically implement AI in a way that only satisfies our critical use cases and optimizes the spend that we’re going to have in that direction?

So the key to doing these big kinds of things is really this idea of do we have the data? Can we make an assertion economically such that it actually makes sense for the organization to make this investment because they’re going to get an inappropriate ROI around it. So the idea of a big goal, I mentioned AI right now, everybody’s talking about ai, and it is really fascinating because I think there’s a lot of usages for AI tools in the course of doing business. But when we start to think about strategically leveraging AI for around business analytics or new insights, things that require our unique data to be able to be exposed in a way, and now we’ve got data architecture issues and data governance issues and all those kinds of things. So AI is kind of the current big goal. But before that, it was digital transformation or it was internet of things, or it was blockchain, whatever is it that we want to do, whatever hypothesis that is that we have in market, based upon where the market is heading and where new technologies are emerging and where we want to exploit those new technologies.

At the end of the day, what we fundamentally have to have is an organization that can not only respond to those changes, but can respond to those changes in a safe economically viable way. My general belief is that if we want to achieve true business agility, again, what I mean by true business agility is to be able to respond to the needs of our marketplace, leveraging new technologies, being able to put features in continuously into market, being able to inspect and adapt as we learn new things, to be able to do it in a reliable, predictable way, being able to do it in a way that creates safety so we’re not having a bunch of problems. What starts to be kind of fascinating is that this organizational metaphor, this encapsulation over orchestration metaphor is actually really, really key because what you’re seeing in a lot of organizations right now is that it’s like, okay, we want to do something with ai.

So we go and we spin up a Basecamp five AI team. Great, okay, cool. If we have a localized problem, a localized team, an encapsulated technology stack, probably some really interesting things, some really smart engineers can do with AI to solve local problems. But what about if I want to have an AI enabled business? What if I want to do AI driven optimization across disparate data sets? What if I’ve got data governance issues, I got security issues, I got all these different things, how do I prioritize that to the top to make those kinds of changes? And so to start to put a bow around a little bit of this, what you start to see is that this principle of encapsulation versus orchestration is really key, right? It’s like the key that unlocks all of this stuff and kind of unlocks everything.

Demonstrating Success During a Transformation

And so, whether it be down here at the service or object level, whether it be up here at the data level, whether it be at the domain level or the capability level or the business object, business unit level encapsulation is what starts to happen.

And so you find yourself in a place where if I can quantify the investment, I can tie it to a big goal, I can put accountability for it around the business and then through some of these other layers start articulating a coherent strategy for how I am going to start pulling this monolithic organization apart. I can show that as I do it how these use cases are being realized, how that the OKRs and KPIs and overall economic conditions within the organization are getting better, how I’m increasing throughput, increasing resiliency, the increasing defects, and I can connect the dots all the way down. I can show how encapsulated data strategies are enabling my business and allowing me to leverage my data in more strategic ways. I can show how I’m able to increase security and I can show how I’m efficiently using my teams to optimize for throughput rather than cost because I’ve dealt with costs in a different way all the way down to the engineering practices that fundamentally enable all this stuff.

So we find ourselves in this position, we find ourselves in this position where we need business agility, and in order to achieve business agility, we have to have agility at all the layers up underneath it. And the only way that I’ve seen to be able to pull this off is to create these nest encapsulation strategies all the way down. And anything there’s complications to it, right? Sometimes you have technology domains, services components, product areas that support other product areas. Sometimes you have shared services, all that kind of stuff. But at the end of the day, anytime we make a decision to share something, then what we fundamentally do is make a decision to reduce the agility of the thing that it is dependent on. Because anytime I share something, it’s a dependency. And so broadly how you think about that is if you’re going to create a shared component in any level within the organization, you basically have to capacitize it so that it has instant availability to the thing that is above it or the thing that’s calling it.

Closing Thoughts: Agile Isn’t Enough

Let’s see if we can tie this back to the main theme of this conversation, this idea that agile isn’t enough. I think what I’ve exposed is that we’re in this situation as an agile community, and I consider myself kind of part of the agile community. I feel like I’m a little bit more of a CEO and a business owner and stuff, more entrepreneurial at this point. But what we’re really passionate about is figuring out how to make meaningful change within the organization. And I believe that the only way to make meaningful change in an organization is to look at your organization as a system. So much of what we’re doing, whether it be agile product extraction or engineering modernization or technology practices or buying tools to do data buying tools to do DevOps, buying tools to do ai, what we’re doing is we’re just piecemealing an organization together.

And if we can really take this first principle of encapsulation over orchestration, it’s really like services oriented all the way up to the top. And again, I’m not dogmatic about service oriented, I’m not talking about microservices or whatever, just this idea of encapsulation exposed by APIs, wrapped in tests, that kind of a thing. If we can take that idea all the way from the top of the organization all the way down and create these strategies across with minimal, lightweight, flow based governance empowered teams at the bottom right, then we’ve got a shot for, I might also say that if we did all those things, the methodologies that we choose likely wouldn’t matter as much. And so you wouldn’t have a battle over whether Scrum is better or safe is better or less is better, or discipline, agile delivery is better or flex is better, or scaled Scrum is better or whatever, wouldn’t be having these conversations because teams aligned towards business problems that are just obsessively focused on their customers, obsessively focused with solving problems in a cost-effective economically justifiable way.

And the teams aren’t so big at the delivery team level, it’s maybe seven, eight people, maybe at the organization level, it’s 150 or 200. But if we can do that, then we create the conditions for agility and then we can start to think about ideas like wrapping them with process that makes sense, whether that be Scrum or Kanban or some lightweight governance or even a lightweight form of safe, like no problems. So we get the organization, we get the encapsulation, we get the data strategy, get the security, get all that stuff thought out and then wrap it in practice. That makes sense. We can get the culture to emerge, and we really get the best of both worlds over time. So in closing, it’s not a matter of just installing practices, it’s a matter of changing the fundamental operating model of the organization, understanding that it’s a system and all the stuff has to be aligned.

And also understanding and recognizing that it has to be driven by a rational economic strategy, and it has to be driven by a big goal. And so if that’s ai, great. If it’s the next thing that comes on the pipe, great, it becomes a facade of sorts. It’s the next thing. We want to be able to respond to the next thing. We want to be able to respond to the emerging needs of our customers. And then to justify this level of change, it has to be driven by people out of the system or costs out of the cloud or infrastructure that we’re able to deprecate or efficiency gains are even tough, but greater productivity, greater throughput, more product in market, able to achieve contract goals, what have you. So a big focusing objective, really, really solid economic drivers. And the last part is how are we going to slice through this organization and pull it apart over time so that as we do the things that are necessary to untangle it all the way from the work surface all the way up to the business object, we are in a situation where we can show incremental benefit as we go.

I don’t see any other way to do it because these are too big a changes. They’re too expensive. They happen over too long a period of time. So again, the goal, the economics show progress towards that goal in an incremental and iterative way. And then what you start to see is you have a pretty coherent model for figuring out how to really do this, how to do it in a meaningful way. And so one of the things you’re going to see from us is we start to unpack this story. This is probably my first, I’ve been talking about this internally for probably two years. This is my first attempt to try to communicate it over a video. So if you’ve made it this far or you’re watching a clip and you go back to maybe watch the whole thing at some point, love your feedback, would love to see if you see the world differently.

But from my agile folks talking about methodologies like Scrum and safe, it’s just not the point Arguing over whether something’s agile, not agile, doesn’t matter. It’s like rely on first principles and understand those principles operate all the way from the work surface all the way up to the highest levels of the organization. And that true ag agility is really only going to be achieved. And we can start encapsulating dependencies and giving people local control. But in order to do that, you got to change a lot of stuff to get it done. Lots of different starting points, lots of different ways to get started, lots of small problems that you can generate economic value around. But if we’re not solving those small problems within the context of a greater economic lead driven plan for what this is going to look like when we’re done, tends to fall short and tends to result in a local optimization. So we’d really love your feedback and just kind of how I told this overview, but where I was headed with that was that a lot of our content, we’re going to wrap in this frame because agile isn’t enough. And if we just need to have a different conversation, we need to elevate the conversation around Agile. And if we can’t do that, this whole movement that we started 23 years ago is going to be fairly short-lived. So wish you all the best and look forward to continuing the conversation. Talk to you later. Bye-Bye.