Quantifying the Benefits of Agile for Better Transformation Results

In this video, we explore the evolving landscape of Agile and examine why traditional frameworks may fall short in complex, large-scale organizations. While Agile principles have empowered small, cohesive teams to deliver value quickly, the real-world complexity of interdependent systems often demands a more proactive approach to orchestration and encapsulation. Our discussion highlights the importance of stable teams, clear backlogs, and tested products—”The 3 Things”—as foundational for Agile success. Join us as we delve into why these essentials are crucial and how shifting from rigid frameworks to adaptable orchestration strategies can unlock true business value across your organization.

Video Transcript

Agile as described, wasn’t really enough. Because again, if you’re a small Scrum team working on an app or working on a small project, or you’re working on something that is loosely coupled from the rest of the organization, you can handle the occasional dependency, you can handle the occasional external constraint. But when external dependency is an external constraint, so the norm, you find yourself in a situation where you have to deal with that stuff proactively. And if you can’t deal with it proactively, what you’ll find is situations where you’ve got lots of Scrum teams working, even if they’re good scrum teams, even if they’re operating off of backlogs, even if they’re able to produce a working tested increment of software, then their work doesn’t roll up into a cohesive hole and can’t actually be shipped. So you can be doing a lot of Scrum that’s really working well, but it isn’t producing business value for the organization.

It’s an Encapsulation and Orchestration Problem

There are people out there that are struggling to adopt Agile. There’s people that think Agile is a process. When I do see things online, I’m looking for hopes that people understand this problem, that the industry is starting to wake up to it. And what we’re starting to see is that I think the Agile community is doubling down on the same things. There was an article I read a couple weeks ago, I want to say it was on scrum.org or something, but I don’t remember. And it was around this idea that frameworks are not the answer, but then it went right back to its mindset and principles. It’s the same stuff, right? It’s an encapsulation orchestration problem.

The Current State of Agile

It’s almost like you want to start and you want to have, okay, what is the current state of agile? Where are we at? Right? So we’re 20 years into this thing.

We’re 20 years into the Agile movement, maybe longer. I guess it was signed in what, 2001 or no? Yeah, 2001. So we’re sitting here 23 years post signing of the Agile Manifesto. We have a community in this that I think is dwindling right now. And what I think the industry is starting to recognize is that the way Agile, as it’s commonly applied, is not working. We started this movement with the Agile manifesto and it got a lot of traction really fast. The way that I’ve talked about this in the past is that when I think about the history of Agile, when I think how it kind of grew up, don’t have firsthand information just from reading stories and talking to people that signed the manifesto, it was like what we recognized was that big upfront plans were not solving the problem.

We recognized that incremental and iterative delivery was likely the way to go. My perception of the early days of Agile is nobody really set out and said, okay, let’s figure out how to build a new product from scratch in a large complex organization on top of a legacy monolith that was moved to the cloud that had really complicated data architectures and such, what they were largely doing was something was within the scope of 5, 6, 7 people. They had easy access to customers, they were able to everybody get in the same room. And there was an implicit part of it. It was like you get everybody in the same room, put a customer in the room, you have Alistair Coburn’s idea of osmotic communication. Everybody hears everything that’s going on, and you can continuously deploy the software. You can continuously get feedback, you can inspect and adapt and change as you learn things.

And so where we started this conversation was around the idea that if we could create those conditions, then we could deliver greater business value faster. And the way that the story played out over the last 23 years was probably twofold. There was an aspect of our community that was largely, I dunno victimizes the word I want to use, but it’s probably not the right word. They felt on the receiving end of a lot of management practices that didn’t make sense. They were not able to do the software craftsmanship kinds of things in the software because they’re under such crushing date and time pressure. There was this huge pressure to define all the requirements upfront and get sign off on ’em.

And so, what kind of happened is that when the manifesto came out, it was a set of values and principles. And so, it prioritized for things like responding to change over, following a plan, customer collaboration over contract, stuff like that.

Two Agile Camps: Culture vs Practices

And over the last 23 years, I think there’s really two camps that evolved out of this. I think that the one camp really indexed on the, what I might say, the cultural ethos of Agile, where it was about teaming and strategy and fun in games, very high touch, very high collaboration. And then the other side of the industry went to processes and frameworks. And when Jim Cundiff was the managing director of the Scrum Alliance and partner with PMI, which ultimately led to the PMI Agile certification, what really Jim did is he caused the scrum training stuff to take off. And Scrum is an interesting thing because it’s really kind of a hybrid of a cultural ethos and a process or a methodology.

And so in that ethos, you have roles and responsibilities, you have ways you measure things. You have daily standups, you have reviews and retrospectives, you have sprint planning meetings and such. Mike Cohn came out with the Agile Estimating and Planning book and really put some structure and discipline around how we’re going to break down user stories, how we’re going to measure velocity, how we’re going to do release planning, such like that. And it gave this illusion in some ways that it was a thing. And that thing where pretty clear works when you have the conditions created to make that thing work. And those conditions are largely fairly simple.

And those conditions are, can I form a complete cross-functional team that stays together? Can that team operate off of a finely grained, well-articulated backlog? And can that team produce a working tested increment of software? It’s what leading Agile we talk about is the three things. It’s like these three things must be true or else nothing else in Agile is really going to work. In the absence of those three things, what it’s really difficult to do is to create a teaming strategy that actually produces working tested software at the end of every sprint. It’s really hard to create a team that can establish a stable velocity. It’s really hard to operate off of a known backlog and be predictable at the end of every sprint. And I think what we’re seeing in the industry right now is that in the absence of those three things, we’re doing one or two things depending upon which camp we’re in. We’re either over indexing on process or we are over indexing on culture.

I’m a huge fan of agile cultures, and I’m a huge fan of the spirit of adaptation and the spirit of experimentation. But the challenges, I’m all for games, right? I’m not a big game guy myself, but I’m all for games. I’m all for facilitated techniques and engaging everybody on the team. But when you don’t have a team that stays together, that cultural ethic is, I’ll say very difficult. It’s hard to say impossible, but it’s very difficult for that kind of an ethos to emerge out of a team that is in and out all the time or a team that’s not dedicated.

Why Scrum is Insufficient

And then the other side of it is, is that what we started to see in the methodology community is that Scrum was inherently insufficient as a methodology. So as we started to see Scrum emerge and take hold, people recognize that they didn’t have teams that stayed together. They couldn’t produce a working tested increment of software at the end of every sprint. They often didn’t have clear backlogs. And a lot of the reasons for that was the idea of external dependencies. So if the team can’t make independent decisions about what’s in the backlog, the product owner can’t make independent decisions about what’s in the backlog. If the team doesn’t stay together, if the team has external technical dependencies between it and the rest of the organization, then what starts to happen is that you start to create orchestration mechanisms. And the earliest instantiation of an orchestration mechanism that I’m aware of was this idea of a scrum of scrums.

And I had a really fascinating conversation with Jeff Sutherland probably 15 years ago at this point. It was a minute. And the way that I had been introduced to the idea of scrum scrums is that the scrum teams are doing their scrum stuff. They have a product owner, they’re doing sprint planning, they’re doing daily standups, they’re doing reviews and retrospectives. And then the idea was that the scrum masters would get together in kind of a meta scrum and they would work out dependencies or they would work out resource constraints or they’d work out whatever. And in that context, all that stuff would kind of play itself out. Well, what starts to happen is you start to have dependencies that can’t be resolved within the sprint. You have work that you need from other teams that they’re already largely booked.

Dealing with Unbroken Dependencies

And so how we ended up addressing a lot of those dependencies over time was we created something that I had originally coined as a product owner team.

And I saw the scrum of scrums as a largely reactive model, and I felt like we needed something proactive. And so what we started to do was to get people who played an architect role. I know that’s not a popular word sometimes, but architecture exists. So whoever’s doing the architecture or whoever has a primary say or could be a representative of the architecture, get them together with a product person, somebody like an analyst, maybe somebody with a project manager view and have them collaborate and prepare a backlog. Product owner could still bring it to the team. They could still do all the stuff. But the challenges we were starting to see is typically cross-cutting concerns or two pieces of the application that depended upon each other in order to be able to produce an integrated feature. And through that discovery process, the way I would kind of think about it was, are we doing a late dependency management strategy where we’re finding dependencies later in the process?

You could apply that to risk too. It’s kind of a risk mitigation strategy. Are we doing late risk reduction? Are we doing early risk reduction? Well, the things that are cross-cutting often need to be dealt with early. So who decides that? When does that happen in scrum? Scrum doesn’t really have a good mechanism for that. And my observation was that the scrum of scrums, while theoretically able to accommodate that wasn’t proactive enough. It was reactive. So then we have teams that can’t establish stable velocity teams that are in weight states teams that can’t get to a definition of done. And so as we implemented this product owner team and we put together this kind of collaborative entity that could kind of play a look ahead game, it’s a little bit like how I envision maybe while I’m not technically accurate, like a dual scrum or dual track scrum kind of model where we had one team that was kind of scrumming on market identification and requirements and architecture and trying to get some ahead of some of the cross cutting concerns across the organization.

The Scrum teams could be left to work their backlog, deliver consistently, produce a working tested increment. And then as that matured, we started running that through more of a Kanban based system because a lot of times that team wasn’t dedicated. Sometimes there were other parts of the organization that we needed to include. So we went down that path, and that was early, early days. This was my time at version one. It was definitely before we started leading Agile. And somewhere along the way, I got to spend some time with Jeff and I told him what we were observing in market, my understanding of scrum scrums and how we were basically applying this concept that I had called product owner team. He just looked at me, he said, yeah, do that sounds like a great idea. Basically, I’m not sure if he was that affirmative of it, but he’s like, yeah, do that. And I had this moment where I went, oh, okay, interesting. This is a more pragmatic, loose framework than I had experienced, or it is how I had applied it. I was fairly not respectful of the rules, not respectful of the rules. 

Governing the Flow of Value Through Large Organizations

And so that kind of opened things up for me a little bit. I’m like, okay, cool. That’s what I’m going to do, right? Jeff Sutherland says, I can do it. I’m going to do it. And so from that kind of emerged a more formalized upper tier of the system. And so what we would do is we would have Scrum teams operating at the lowest level, and then we have this orchestration layer that wrote above, typically cross-functional, typically not dedicated, responsible for moving something that was bigger than a user story. You could call an epic. You call it a feature. I typically called it a feature. And what that team would do is they do some analysis and design collaboratively. They would start to do user story decomposition. They would start to look for cross-cutting concerns. They would have an eye towards sequencing the backlog and making sure that as individual Scrum teams completed their user stories, that they were all rolling up in a way that the feature item could move across the board.

It gave us a way to anticipate and visualize bottlenecks. We started applying lean theory of constraints kind of things. We started using flow-based metrics at that level. And what we found is that in most cases, that worked. Right? So that was probably my first experience with this idea that Agile as described wasn’t really enough. Because again, if you’re a small Scrum team working on an app or working on a small project, or you’re working on something that is loosely coupled from the rest of the organization, you can handle the occasional dependency, you can handle the occasional external constraint. But when external dependency is an external constraint, so the norm, you find yourself in a situation where you have to deal with that stuff proactively. And if you can’t deal with it proactively, what you’ll find is situations where you’ve got lots of Scrum teams working, even if they’re good scrum teams, even if they’re operating off of backlogs, even if they’re able to produce a working tested increment of software, then their work doesn’t roll up into a cohesive hole and can’t actually be shipped.

So, you can be doing a lot of Scrum that’s really working well, but it isn’t producing business value for the organization. And so, I think as a result of that fundamental problem, that’s why we saw the emergence of SAFe, right?

Thoughts on SAFe

And really the way I think of SAFe, simply what Dean did in Safe was fairly powerful. He took a lot of best of breed thinking and rolled it into a methodology that folks could adopt, but in doing so, created a lot of complexity because it’s a really solid reference architecture full of a lot of really good ideas. But what the market demanded of Safe was make it a thing. And I have a lot of empathy for that because it’s really hard to bring abstract ideas to market. They kind of have to be a thing. But the more you make them a thing, the more prescriptive they become, the more that you have people that adapt or adopt the specifics of the methodology and kind of forget the first principles of that methodology.

And so what you start to see very much rational, unified process before it, you start to see, or the PMBOK for that matter, or any other methodology that has come down the pipe, is that people take it out of the box and try to implement all of it. And if they don’t take it out of the box and try to implement all of it, and they start to customize it, they don’t customize it with an awareness of first principles. And so maybe that’s where we could build up into a much broader story about why I think Agile is insufficient necessary, but insufficient to solve the broader class of problems that a lot of companies are trying to solve.