On Managing Expectations of Methodologies & Frameworks

The Scaled Agile Framework wasn’t exactly what the authors of the Agile Manifesto imagined 20 years ago when they set out to define a better way of building software. But that doesn’t mean you can’t achieve greater Business Agility with SAFe. You just might not get the results you think you will get.

And that’s the problem with SAFe. It oversells what it is in the market. SAFe thinks it’s THE way to do scaled Agile when it’s actually just one way to do it. SAFe, like all methodologies, is limited by its environment and requires a certain context to be useful. But it shouldn’t be vilified for having limitations because it does some things really well—even if those things aren’t Agile as defined in the Manifesto.

SAFe & The Agile Manifesto

{The following is a transcript of the video}

So, I was running around on LinkedIn last week and I was noticing a conversation that was going on out on LinkedIn and it’s a conversation that comes up quite often and it’s the idea is it’s SAFe Agile. And you know, me personally, my company LeadingAgile, we’re fairly methodology agnostic.

You know, my general belief is that most, I’d say all the Agile methodologies, like the ones that come to mind like Scrum, XP, Scaled Agile framework, Large Scale Scrum, maybe Nexus on some levels, Disciplined Agile Delivery. My general belief is that there’s kind of like a core underlying reference architecture and most of the prescriptive methodologies are really just reference implementations of these kind of fundamental patterns and principles.

So, this idea is SAFe Agile. First, I think you have to think about is you ask yourself what is Agile? So, if you’re saying Agile is a thing, right? So Agile is a small team methodology that’s based upon the values and principles in the Agile Manifesto. It requires a co-located team. It requires access to a customer. It requires the ability to continuously deploy software, to continuously get feedback on it. Right?

If you take that approach to Agile, which is a valid approach, right? That’s how Agile was designed. It’s probably reasonable to say that SAFe isn’t an Agile methodology. I had a conversation with Alistair Cockburn about 10, 15 years ago at this point where we were talking about some of the emerging scaled frameworks that were coming out during that time. And his comment was something to the effect of like what we were doing in Snowbird back in what 2021 was a thing. We were talking about these small team methodologies. And what’s emerging in the larger ecosystem of methodologies, like scaled methodologies. It’s not that it’s bad, it’s just that it’s different. It’s just not what we described.

Will SAFe Lead to Greater Business Agility?

So, there was a post that came out that was like, you know, all the signers in the manifesto basically saying that SAFe wasn’t Agile. And by the definition of Agile, it absolutely isn’t, right? That’s inarguable, right? The guys that invented it say it’s not. I think they get to decide. Now the challenge is, does SAFe lead to greater Agility? Okay? And you know, LeadingAgile really isn’t in the methodology business. We’re in the change business. And so, if a company wants to implement SAFe, we can help them implement SAFe.

If a company wants to implement Large Scale Scrum, we can help them implement Large Scale Scrum. Disciplined Agile Delivery? Fine, right? Generally, what we end up doing is implementing hybrids of different things, right?

So, we take, you know, in effect, team-based at the work surface level, we do some sort of Kanban/Big Room Planning, kind of release trainee kind of stuff and what in what we call like a middle tier. We tend to think of having a portfolio tier at the top. Because what’s really going on with SAFe is that the organizations that are trying to adopt Agile are not built very well for Agile. They’re not built around small teams. They don’t have lightweight governance. They’re not dependency free. There are architectural dependencies. There are people dependencies, there are requirement dependencies, there’s governance and controls and metrics and all those kinds of things.

And so, what SAFe kind of came along and did in my opinion is it said, okay, given the constraints and an existing organization, poorly formed teams, dependencies, all the things we just talked about. What we’re going to try to do is we’re going to try to create a framework that increases Agility. Right? So, it’s not Agile as described in the Agile Manifesto, but there are conditions where SAFe can deliver greater Agility.

And one of the earliest engagements we ever did, it’s been with a long-standing client, and one of the things I said to their President was, “you’d be halfway to being an Agile organization if you just stopped approving 18-month projects.”  If the organization just did three-month projects, right? And was able to put things in market faster, there would be a greater level of Agility.

But when I really break down, what is it about Agile? Agile is, by definition, a small team methodology. It’s six to eight people, typically co-located, I guess it’s probably not as much of a thing anymore. They have access to a customer or a Product Owner in Scrum and they’re able to produce a working tested increment at the end of every sprint.

One of the things that I’ve been observing for a long time is that what Scrum fundamentally assumes is that the value stream is fully encapsulated in that team. So, the whole idea from voice of customer, the product owner, analysis, design, build, test, deploy, typical Waterfall kind of stuff that’s all kind of encapsulated within that team. The team meets on a regular cadence, identifies the backlog, breaks the backlog down, roughly plans out their work. Daily stand-ups, burn down through the sprint, able to produce a demonstrable increment of the product, signed off by the Product Owner.  We do reviews and retrospectives, right? That’s typically Scrum.

But what do you do when the value stream is not encapsulated in a single team? What do you do in a situation where you find yourself with lots of teams that have to come together in order to be able to deliver in an Agile way?

Well, like Large Scale Scrum, I think has it largely nailed, right? You know, Bas Vodde and Craig Larman, it’s been a while since I’ve read their work, but they were rather insistent, I recall, on the idea that you had to organize around features or capabilities. You had to decouple those dependencies. They had to be set up in a way that they’re continuously deployable. And then you could imagine an ecosystem where maybe a product was supported by 50 teams, but each of those 50 teams were able to largely operate independently of each other. So, when I think of even aspects of something like the Spotify model, aspects of Large Scale Scrum, I think that is what those systems are calling for. But in a lot of corporations and a lot of technology platforms, you don’t have that level of encapsulation at the team level. And so again, SAFe is a response to the fact that you don’t have the appropriate decoupling.

And so, what we find in an early-stage Transformation is that there’s a lot of organizational dysfunction. And so, in an early-stage Transformation, you can generally get yourself to a place where you’re able to form teams, but those teams are often not perfectly formed and often don’t have everyone and everything necessary to be able to deliver. Often, they can’t truly get to a working tested increment of software at the end of every sprint. So, a lot of times what we’ll do is we’ll wrap a bunch of teams in what we’ve been you would call like a program level or product level Kanban. Right?

So, we’re doing more upfront planning. We’re kind of doing rolling wave, progressive elaboration. We’re doing a lot of decomp ahead of the team. We’re making sure that backlogs are sequenced across teams and those backlogs are like cross-cutting concern, dependency aware. We’re making sure that as user stories get sequenced, we are optimizing for the flow of features across teams. If I’ve got multiple product or program teams, maybe like a value stream kind of organization, then sometimes that will like flow up to a top tier like or like a portfolio tier or an investment tier. And all of that stuff, right, regardless of how you implement it, whether you implement it kind of like LeadingAgile does by default or whether you choose to go with something like SAFe, what you’re acknowledging is that you’re acknowledging that you’re installing a compensating control that is absolutely necessary in the presence of dependencies.

It’s absolutely necessary in the presence of cross-cutting concerns. It’s absolutely necessary in the presence of integrated deliverables. It’s absolutely necessary in a situation where you have coordination across teams and over time. But they are compensating controls. And to the extent that you have dependencies, you have to manage them. But anytime you leave a dependency in the system, it going to reduce your ability to be pure-play Agile.

So, when you look at LeadingAgile’s model around what we call our Quadrants, our Basecamps, and our Expeditions, what we’re basically acknowledging that is in like a Basecamp 1/Basecamp 2 ecosystem, it’s a lot just to get organized around teams. It’s a lot just to get everybody doing Scrum. It’s a lot to bring the business and the technology people together to do the coordination, the decomposition, and figure out what’s minimally viable and all those different things.

And so, sometimes it’s enough just to kind of break apart the existing structure and just to get it operating using Agile teams and flow-based metrics and more collaborative requirements decomposition, more just-in-time, more progressive elaboration, more rolling wave. You can get a lot of Agile out of that.

So, is it Agile as described by the Agile manifesto? No, it’s not. Is it greater Business Agility? Does it actually allow the customers to get more business benefit earlier? Yeah? Does it start to establish some healthy patterns? Yeah, It absolutely does. Is it small, team-based Agile as described in Manifesto? Absolutely not.

The Real Work of an Agile Transformation

So, the trick in Transformation isn’t to teach people how to do SAFe. The trick in Transformation is to, you know, aim for completely decoupled teams to acknowledge that those teams are not going to be initially decoupled. And then to install appropriate compensating controls in the presence of the dependencies.

As you move more to continuous integration, continuous deployment. As you move into DevOps. As you are able to negotiate more frequently release cycles with your customers. As you’re able to break dependencies between teams. As you’re able to change the governance model and the financing models and going from projects to products. As you’re able to empower those teams to make independent decisions in market. You can actually deprecate some of those compensating controls.

So, Transformation, again, is not about installing SAFe or installing Scrum. What Transformation is about is taking the organization from where it is to the level of Agility that it needs to be. And so, what we do is in an early-stage Transformation, a lot of times the compensating controls are actually heavier than SAFe. And then you actually have to change the organization in some ways to even get it ready to be able to do SAFe. You have to break a lot of dependencies and create a lot of technical infrastructure to get it ready to do LeSS. You can take it further and have every team be able to operate independently off a backlog. You can take it a step further than that and you can have those teams operating independently in market and being able to inspect and adapt and to figure out what those customers need. But it’s not one-size-fits-all.

The Transformation Journey is about improving the underlying organization.

The Problem with SAFe

So, I guess in short, what I think the problem with SAFe is, it’s not that SAFe is an invalid methodology. I don’t really care whether it’s pure Agile or not, right. I’m totally fine. I think there’s a lot of places where SAFe can lead to greater Business Agility, but I don’t think even that’s a guarantee because a lot of really large organizations that are trying to install SAFe, they actually have insufficient compensating controls and they’re not focusing on the org design and the dependencies as much as they should.

And so, I think the rub with SAFe is that it says that it is THE answer for Agile at Scale. It is AN answer for Agile at Scale. It’s often implemented poorly on top of organizations that can’t support it very well. And then to kind of add insult to injury because it says it’s THE answer, people think that if they do it, that it’s going to solve their problem. SAFe is just one of many compensating controls for how to achieve greater Business Agility in the presence of poorly formed organizations and dependencies.

So, my in short answer is I actually prescribe more planning in an early-stage Transformation. It actually requires work in most companies to get to a place where you can actually do SAFe, but leaving it as a SAFe implementation is probably suboptimal as well. What you really want to do is you want to decouple as many teams as you can, get those teams operating independently, get your project funding turned into product or team-based funding or organizational-based funding. And then, ultimately, for a subset of the organization basically be able to marry that set of teams or that subset of the organization with a customer and be able to take feedback and expect them to adapt as you go. Right? That’s the answer.

So, is SAFe Agile? Like, no, it’s not by the original definition. Under the right conditions, can it increase Business Agility? Sure, I believe it absolutely can. Is it an end-state that I think is recommended? No. Again, I think it’s not enough at the beginning and I think it’s too much at the end.

So, I guess my position on it would be is that the only problem with SAFe is that it’s overselling what it is in market. Yes, it is a mechanism for being able to orchestrate across multiple teams with dependencies. And that’s what it is, right? And it can lead to greater Agility, but it’s not small team Agile. And I don’t think it necessarily achieves the level of Business Agility that most organizations think it’s going to. Again, primarily because in most SAFe implementations that we’ve seen and cleaned up after, it doesn’t go far enough prescribing the actual nature of the organizational change or how to actually make those changes in the organization. So that’s kind of like my hot take on Scrum, or excuse me, on SAFe, and if SAFe is Agile.