Redefining What it Means to be an Agile Organization

We explore what it truly means to be an agile organization. By stepping back from prescriptive frameworks and over-simplified solutions, we aim to refocus you on the core principles of agility: iterative processes, close collaboration with customers, and delivering consistent, impactful business outcomes. This discussion challenges the mainstream view of Agile as a set of practices or rituals, advocating instead for a broader, principle-driven approach that adapts to context and fosters sustainable value creation. If you’re navigating the complexities of agile transformation in your organization, this conversation offers thoughtful insights to guide your journey.

Video Transcript

Basically, any methodology that you pick off the shelf has the possibility of working. They all work somewhere, right? 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 and they packaged it, sold it, set training around it, build 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.

It was 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, 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 them. 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, its 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 an 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 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. 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, RUP 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. I tend to take the good idea and I abstract it up into the principles that made it a good 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 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 and Action, not going to be able to pronounce the guy’s last name, I 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. So you think of something like Data Mesh is non-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 domain design. You start to think about something like business capability modeling. And what you start to see is when you abstract up all kinds of the same stuff, right? We’re all hunting, encapsulation, orchestration. 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.

So they’re 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 the customer, deliver the most business value first, make sure there’s working tests, software’s going all the time. And in that context, in that ecosystem, we can 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 and 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.