Is SAFe Agile?

I don’t spend a bunch of time on LinkedIn, but the other day, I was scrolling around and happened to catch a thread where some folks in the Agile community were debating if SAFe was actually Agile. People have been debating this topic for as long as SAFe has been around. The post generated a lot of good conversation, so I thought I’d take a minute and share how I think about this.

In short, it really comes down to what you mean by Agile and Agility.

A few years ago, I was discussing the idea of scaled Agile with Alistair Cockburn. One of the original signatories of the Agile Manifesto. I’m going to paraphrase, but he said something to the effect that “what we did when we invented Agile was a specific thing. The emerging methodologies for Agile at scale are not that thing. It doesn’t mean they are bad. It’s just means that, by definition, they aren’t Agile.”

That comment really stuck with me and it shaped the way I tend to think about Agile and Agile at Scale and Agility.

What is Agile?

Agile is an incremental and iterative approach for developing software products. It’s typically best for small teams. Typically, of 6-8 people. Agile methodologies adhere to the values and principles articulated in the Agile Manifesto. The most common small team Agile methodologies are Scrum and XP, maybe Kanban, or a combination of the three.

Scrum focuses more on management activities. XP focuses more on technical practices and software craftsmanship. Kanban focuses more on flow and less on teams and time-boxes.

Agile teams, by definition, operate independently, in close proximity to an actual customer or product owner. They deliver frequently and get constant feedback. Requirements are written in such a way that it’s easy to change and reprioritize. Software is written so that it’s safe to go fast and so you know instantly if you’ve broken something along the way.

There are various methodological practices that enable an Agile approach. You have ceremonies and cadences, ways you track progress, techniques for safely writing, testing, and deploying software; and various roles and responsibilities that make up a typical Agile team.

You have cultural aspects in terms of how teams collaborate, respond to change, and engage with the marketplace. You have a mindset of ownership. A disposition toward empowerment. And an attitude of collaboration with each other and the marketplace.

When Agile first came out, or really when it first started gaining mainstream popularity, lots of people were learning the frameworks and trying to apply the values and principles. They were applying the practices and mindsets in large organizations where many of the core underlying conditions to support an Agile ecosystem didn’t exist.

They didn’t have small teams. They didn’t have close proximity to customers. They didn’t have requirements and systems architectures that were resilient to change. That said, Agile methodologies are a forcing function of sorts. You use them and they show you your impediments. You remove the impediments, and the team gets better over time.

But many of the impediments in larger organizations are difficult to remove by a single team. Especially if that team works in a larger ecosystem of teams, building bigger, more complex products, with heavy corporate governance and financial controls. The net effect is that teams changed Agile, rather than letting Agile change the teams and the organization.

So, in practice, we have lots of teams and organizations that are going through the motions, doing all the Agile roles and ceremonies, but not achieving any of the real goals of Agility. Being able to collaborate with our customers and making sure they’re building products that they want to use and are willing to buy.
Where Does SAFe Come In?

Sometimes I’ll describe an Agile team as one where the entirety of the value stream can be encapsulated and delivered by an onsite customer and a dedicated team.

Team based methodologies tend to break down when the value stream cannot be encapsulated within a single team. In other words, when we have dependencies between the team and other parts of the organization.

SAFe is a response to larger, more complex value streams, where dependencies have to be orchestrated and we need to align with corporate priorities, funding models, governance and control.

SAFe gets that you have to have Scrum teams at the base of the organizations doing the work. But when you have unresolved dependencies between teams, dependencies that get resolved late, and disrupt the predictable delivery cadence, you must do something with them. You either break dependencies or you manage them. You can’t ignore them, and they don’t often self-organize themselves away.

On some levels, SAFe is like Scrum. It assumes the practices will reveal the impediments, and teams will remove the impediments and improve over time. But what do you do when the impediments are outside the purview of the team?

So, the way I think about SAFe, is that in the presence of dependencies, and corporate governance, and the necessity of getting lots of teams to operate in unison against an integrated deliverable…you need some way to manage it. You might not like the roles, responsibilities, ceremonies, and overhead of a SAFe implementation, but if you’re doing software at scale, you need to have something. You just do…It’s kind of inarguable.

So, pick your poison. You break dependencies between teams, or you manage them.

What you can’t do is pretend like they don’t exist.

Is SAFe Agile?

Clearly not.

At least not in the way the signatories of the Agile Manifesto intended it.

SAFe at its best can be based on small teams. Promote incremental and iterative development. It can support rolling wave planning and progressive elaboration of requirements. It can allow a company to get better at delivering to market faster. Getting more rapid feedback. Maybe even generating revenue that will help sustain future development.

A well implemented SAFe organization can use solid software craftsmanship practices. Good architecture. Solid design principles. Whatever technical practices you so choose.

Most organizations don’t understand the fundamental organizational changes required to make SAFe work, so we have a lot of poorly implemented SAFe.

In all fairness, most companies adopting Agile don’t do small team Agile very well either. At least SAFe isn’t ignoring dependencies. It isn’t ignoring the corporate governance that hasn’t been dismantled yet either. It’s taking a stab at trying to deal with some things organizationally that most of the Agile community willfully ignore.

What are You Willing to Change?

I tend to be methodology agnostic. I don’t find this debate super useful.

Every Agile methodology ever invented, was used by some consultant, in some organization, in some engagement and was successful.

These methodologies get codified into practices. Certifications get minted. And we tell everyone this is the way to do Agile or Agile at scale. All these approaches worked some place at some time, and all have very common reference architecture type elements. It comes down to the underlying assumptions about the nature of the enterprise and what aspects of that enterprise are you willing to tackle to make things better.

You have to make changes in most organizations to do small team Agile well. You have to make changes in most organizations to do Scaled Agile well. The problem lies when we take the methodology and apply it in a context where it wasn’t designed to work. We don’t understand why the practices worked, or what changes are required, so we have large groups of people going through the motions and not getting the business benefit of the approach.

Any approach.

Nothing is Perfect

At the end of the day, your Agile methodology is going to be limited by your willingness to make change. It’s going to be limited by what you’re willing or able to dismantle and rebuild.

This is why LeadingAgile focuses on Transformation over methodology.

Most companies struggle to do Scrum or XP by the book, regardless of the size of the organization. Most companies will struggle to implement SAFe given their complexity and the extent to which value streams overlap and interact. Most companies don’t have a good sense for how to organize teams or what to organize them around.

They don’t have the environment to do Agile well. They don’t have the environment to do SAFe very well. And none of the scaled methodologies really solve the problem. You have to have encapsulated teams, and encapsulated organizations, that lead to the ability to operate with some level of independence. Dependencies kill Agile at all levels of scale.

Why would we just train the teams on Scrum and SAFe and let them stub their toe over and over again?

My observation over the past 12 years of leading large-scale, global Transformations is that Transformation is a process. You do what you can do today, while you mindfully change the organization to improve its design and break dependencies, while moving closer to your desired end-state as the organization makes adjustments and improves.

In the presence of poor organizational design, poor technology architecture, sub-standard development practices, and dependencies, you make one set of choices. But, as you improve the ecosystem, you can dismantle some of those decisions, reduce the overhead, and operate with ever greater Agility.

The patterns necessary to do Agile or scale Agile well are well-understood. They just don’t lend themselves to certification or training. They require deep understanding of organizations and organizational design and change management. There is no “easy button” for getting this right.

I think the rub comes when SAFe is promoted as THE WAY to do Agile at scale. SAFe is one way to get started with Agile, while you create the conditions to really make Agile work as designed. At best it’s a transition pattern that can increase Agility while you’re moving toward a dependency-free Agile ecosystem. And as far as transition patterns go; it’s a solid transition pattern. It’s just not my preference as a desired end-state.

The ironic thing is that most companies need more planning and preparation up front when they’re getting started with a Transformation. More planning than SAFe prescribes. But the idea is to deprecate some of the planning and compensating controls as the organization breaks dependencies, gets better at delivery, and learns to trust this new way of working.

As the organization improves, you can lighten up the practices and get closer to the ideal where it makes sense.

That is why this isn’t about the methodology, it’s about orchestrating and leading change, to systematically and intentionally create the conditions you need to operate with ever increasing Agility. Until we realize and understand the underlying patterns. The work required to do the change. And the time and attention it’ll take to get there, I think these debates will continue.

Is SAFe Agile?

So, is SAFe agile?

At the end of the day who cares. It isn’t what the authors of the Manifesto intended, but they didn’t ever anticipate their small team methodologies being applied at the levels of scale we are trying to apply them.

Can SAFe lead to greater Agility?

Sure… it absolutely can. And for many organizations SAFe will be enough. It just isn’t the only way to be Agile at scale, and it probably isn’t even the best way to do Agile at scale. But until we are willing to get serious about breaking dependencies, it’s likely a reasonable compromise.