SAFe is Agile scaled vertically more than horizontally | Leading Organizations

A decade and a half ago or so, Agile made its big splash in business management circles, riding on the back of the increasing importance of software development culture in business.

Since then, many words have been written about Agile, for or against, hype or reality, cult or rigorous method, and so on. However, one thing that has been constant is the growth and omnipresence of Agile as a core methodological concept in the world of software development. While Agile/Scrum dominates the implementation landscape, there are many flavors, variants, frameworks and so on, and as any Agile coach will tell you, there is no standard Agile, there's only the best Agile implementation for you. That way they can sell their next Agile coaching gig :)

Shortly thereafter, however, arose the problem that, even if you like Agile a lot, you will quickly run into the Agile scaling problem. Namely, Agile is an organizational mindset that is heavily biased in favor of small (5-10 ppl), nimble and independent teams. It favors trust in cohesive human groups efficiently solving well-stated problems in short timeframes, rather than individuals performing goal-less tasks in isolation that someone else assigned them for months at a time.

So while the Agile core is very effective, if you have a software environment requiring work on a scale that involves many Agile teams, you have to solve the problem of figuring out how to deliver a large system in a way that is coordinated and efficient across multiple small independent teams delivering different pieces of it.

The initial solution to this problem was done through SCRUM, using Scrums of Scrums, which is a delivery mechanism where the scrum master of each Agile team would have one or several meetings at every sprint, in order to coordinate the user stories delivery of their respective teams. In my experience, and I suspect that I'm not alone in this, the Scrum of Scrums usually ends up being a reactive and problem-chasing tool, rather than a proactive coordination tool. Frameworks have been developed to formalize this scaling somewhat, such as LeSS and Scrum@Scale.

Regardless of the variant, one key blind spot that I've always found with Scrum, and the reason why I like SAFe, is that Scrum makes far too many assumptions about the role of Product Owner. In Scrum, the PO is a magic function that resolves all the complexities of business management into a backlog, and this is where Scrum starts. The blind spot is the whole mess that happens upstream of the PO, that is hidden from the process, and that it doesn't care about. It's the PO's job to figure out how to get stories to the backlog, and Scrum woefully underestimates the complexity of this vast business process.

Scrum's PO role is quite explicitly a way to shield an idealized development process from the messy complexities of business development and management, where the definition of expected business value gets generated.

In the reality of large implementations, the only really effective and scalable coordination that makes the development problem tractable happens between product owners of various pieces of the backlog. Learning from this experience, eventually arose SAFe, which is the topic of this post.

SAFe means "Scaled Agile Framework".

It's a process and organizational framework that addresses this problem of scaling Agile both horizontally across Scrum teams and vertically up into the organization and the value definition process. It relies on the key realization that the need for coordination at the level of delivery is best minimized by coordinating the upstream decisions about what value needs to be delivered in priority, and to have a process to iteratively break down this value into pieces manageable by individual Agile teams working in parallel without losing the forrest for the trees.

The key challenge of scaling Agile to teams of dozens or hundreds of stakeholders, is that there is obviously some anthropoligical limit to the size of human groups that can maintain the ability to spontaneously self-organize. Scrum officially places that limit at 10 and recommends 5, and nobody really disagrees with that.

So how does SAFe attempt to solve that?

Fundamentally, SAFe stipulates that beyond a certain scale, the problem is no longer a delivery coordination problem, but rather a requirements definition problem. Meaning that the problem is not how to split and coordinate a backlog of known work across many teams, but it's to have an effective way to break down what work needs to done into manageable and valuable chunks that teams can then autonomously figure out independently.

SAFe essentially adds a dimension to Scrum. Scrum is two-dimensional.

Scrum = time-boxing x self-organization. SAFe adds the vertical dimension of Value management. SAFe = time-boxing x self-organization x Value management.

SAFe as a framework accepts to take on the burden to recognize that, before user stories get to a backlog that a PO can manage, there's a whole difficult organizational and human process that needs to happen, that involves discovering customer needs, managing a legacy product portfolio, market segments and customer offerings, arbitration between Value-generation opportunities, doing business cases to get funding from finance, managing conflicting organizational interests and priorities and so on. And that if you have dozens of teams that need to collaborate on large complex solutions, then neither asking a PO to resolve these tensions and shield the team from that, nor "just talking" to synchronize work will cut it.

Indeed, SAFe starts with portfolio management at one end and self-organizing Scrum teams at the other. It aims to coordinate programs of up to hundreds or thousands of people working to develop a set of systems that make up a portfolio, and it has done the work of discovering much of what can go wrong and lead to wasted development and missed opportunities, and to find smart ways to mitigate that. In today's world of ecosystems, APis and microservices, and where customers expect that at the very least all the systems sold by any given organization will work together seamlessly, and that UX will be fluid and consistent, the need for a deliberate solution design workflow cannot be ignored.

A SAFe implementation will touch every aspect of an organization, from software development all the way up to executive management.

In my experience, you can't expect to implement SAFe effectively without changing the structure of the organization.

Because SAFe goes above the role of the Product Owner, this is even more true of SAFe than it is of any other Agile framework implementation. In any case, if you do another type of Agile framework implementation, then you will not have touched half of the business roles that SAFe embarks in its scope. Without SAFe, these roles will barely need to be aware of the Agile implementation. The PO will take all the mess to sort out on their shoulders, so that the dev teams can do Agile in peace. All the product managers and marketers asking why there's no gantt chart to plan the next release, asking about the laundry list of features that will be in it, complaining that there's no requirements document that they can look at, the CFO asking for when the project will end so that they can figure out how to amortize it, all of this and so much more, Scrum considers that it's the PO's problem to make sure it doesn't disturb the dev team, it's not the Agile implementation's job to address this.

SAFe is different. At least in theory.

One of the issues with SAFe is its relative success as a buzzword, where every executive now has heard about it and thinks it could solve their problems. Yet, as far as they're concerned, anything that has "Agile development" written on it, is the CTO's problem. It's up to them to organize how the dev teams deliver on time, on budget and at quality – this is the reason why most Product Owners today live in the dev organization. Other "business" execs can continue to focus on business as usual. Other marketing, product management or operational leaders will have their own LEAN initiatives going on too, which they see as just their problem. It's "the business"' responsibility to figure out how to discover customer needs, or improve customer satisfaction, after all, isn't it?

Somewhere in the middle of this, you'll have the UX department, alternatively pulling their hair out or experiencing sweet schadenfreude at how nobody understands what UX really means.

I want to share some insights that I gained from the SAFe implementations that I've done or been involved in, in large legacy organizations. I want to highlight the elements of the framework that I see as pitfalls, with the goal to show the consistency of the framework.

I did this in the mindset of a warning to leaders considering a SAFe implementation in their enterprise, that SAFe is not a framework for organizing development teams and maintaining a backlog – previous Scrum frameworks do that very well. The specificity of SAFe is that it pushes Agile management up into sections of the organizations that were hitherto relatively untouched by previous Agile framework implementation generations.

I want to make the point that if you run a legacy business and don't use SAFe as an opportunity to candidly discover and address whatever legacy organizational toxicity and structural waste of effort and talent, and don't radically change your business organization's dynamics and functional silos, then don't bother. You'll just waste resources creating a bureaucratic nightmare: your legacy organization will struggle with the SAFe requirements for flow of information and decision-making. They'll have to add new meetings on top of new meetings and other behind-the-scenes management backstage quarterbacking, on account of the fact that you won't be getting rid of the legacy information and decision-making bottlenecks and turf-protection mindsets inherent in traditional management structures.

SAFe really is Agile at scale, because it's Agile beyond the engineering teams. It's designed to operate in business teams and senior roles that typically don't have a rational engineering culture to start with. They are not the intended audience of the Agile Manifesto.

To that end, I created an 8-slide "SAFe in a nutshell" primer (link will download).

• If you're an executive, it will tell you enough about SAFe to get a sense of how you might want to consider changing your organization to support the new framework.
• If you're someone in any way involved in product development or that requires software to be developed, it will tell you enough about SAFe to envision the new kinds of workflows that you will be supporting or participating in and start to think about how this could change your daily work.

This primer is based on the SAFe implementations that I've been involved in, my SAFe PM/PO certification, in addition to many cumulative hours reading, thinking and doing over the years as I was implementing various versions of Agile in my teams. If you have a decent Agile culture and have the cognitive ability to adapt theory to your reality, then this primer will give you enough knowledge to start imagining how SAFe could change your organization.

Let me know if that helped or not.

If you want to delve deeper into the SAFe framework, the www.ScaledAgileFramework.com site is a very good resource.