Deconstructing SAFe's Intent, Design Choices, Strengths, Weaknesses and Controversies

I started working with agile in product development as a practitioner in the trenches back in 2006 or so. Like many other people, once I saw that it worked nicely at the team level, I started to feel the need to figure out how to improve agility for teams of teams working on bigger products, bigger solutions, trying to work together across multiple functions. I played around with multiple things, trying to bring in Scrum, Kanban, some mashups, looking at feature-driven development and other approaches, and just did that in the trenches for a couple of years.

I became aware of Dean’s work on scaling requirements, and the things that eventually became SAFe, right around that time, because that had interesting inspiration. And finally went and learned SAFe from Dean back in, I think, 2013 or so. The thing I really liked in what I saw was the assumption, the realization, that agile cannot just happen by working with teams. It really needs leadership support and leadership engagement, and their reliance on modern change-management practices as part of it, moving from pigs and chickens to actually involving leadership as part of your agile journey.

A big reason why I think SAFe has a lot of potential, and why it is really succeeding out there, is because it tackled the change-management challenge. And the right way. There are a lot of problems with SAFe.

I would say I’m probably an SPCT and a SAFe Fellow. I kid sometimes that maybe it’s because I’m willing to challenge SAFe. Maybe it’s despite it.

Maybe it makes sense to actually start with what changes were made, so we understand the why.

The biggest change between the Scrum Guide Scrum Master, the professional Scrum Master, and the SAFe Scrum Master is that the SAFe Scrum Master is more of a focal point. They’re expected to do everything the professional Scrum Master is expected to do, have all the choices, operate from all of the stances of a coach, a mentor, a teacher, all of that is great. Beyond that, the SAFe Scrum Master is more of a focal point for the team. You could even say more like a technical lead, a manager for the team.

What SAFe did, what a lot of organizations do, if we’re honest about it, they struggle to figure out this weird role, the Scrum Master role. It is a weird role. And in most organizations the Scrum Master takes on more than just removing impediments for the team. Takes on some active leadership, active project-management roles for the team, whether we talk about it in the Scrum Guide or not. That happens in the trenches. And what SAFe did is it actually brought that real-world practice from the trenches into the definitions in SAFe.

I wasn’t there when that decision was made, but like many other decisions, SAFe is trying to streamline the path of change for organizations that are trying to become more agile. SAFe is taking the approach of evolution rather than revolution. If you remember, back in the day there was this huge argument around what’s the right approach to change management, the Scrum “burn all your ships” approach, versus Kanban’s more evolutionary approach of start with what you have, respect the current way things are working, respect the current roles, but agree to pursue evolutionary change. SAFe is actually closer to Kanban from a change-management perspective, and I think a lot of Agilists don’t really realize that.

SAFe is respecting the way things are done, to a fault, sometimes. And if you’re respecting the way things are done too much, and not challenging the comfort zone, you would not change.

The focal point is one of the biggest gaps that I see. In SAFe, the Scrum Master is the team’s representative for the Scrum of Scrums, for example. They’re the focal point in PI planning. When you make those choices you put these people into a mode of leading the team, and the team actually relinquishing some power to these Scrum Masters rather than being self-managed. For me, that’s the biggest gap.

I’m not sure I have such a big issue with the elevated stance itself. What I would like to see is the transparency behind that decision. It would be interesting if SAFe would just come out and say: look, a Scrum Master in a scaled agile environment is a delivery manager. So grab a delivery manager and teach them how to be a Scrum Master, because this is what we need, given that we have PI planning, we have the ART syncs, we have Scrum of Scrums. This is what we need to facilitate all of these other layers. I think then, at least, we could look at it and say okay, that’s what they’re doing, and the rest of this, while we may not agree with it, makes sense.

I could see a world where the Scrum Mastering in SAFe was not called Scrum Master. Where they were called Scrum leader, Agile team lead, team captain, whatever. Just call it an agile delivery manager, because that’s honestly what they’ve defined.

Of course, for any one of these things, there’s always the question: why do they keep the Scrum Master name? I think it’s clear why. The name has a lot of value, in a lot of contexts, behind it. So it’s, do we leverage what everybody knows about Scrum Master, and bring all that value into a SAFe environment, but tweak it a bit to make it work in our environment, or do we use a different name and lose all of the value, both business value and actual know-how and expertise that people associate with the role.

Some people implement SAFe to avoid really changing. Some people implement a Kanban board to say, yeah, we have a Kanban board, we don’t have to go through the hard job of implementing Scrum, which also means you’re not really changing, you’re not really improving. I think most frameworks, whether it’s Scrum, Kanban, or SAFe, they’re going to identify problematic areas. And then we have to decide: do we address those, or not. That’s ubiquitous, across all implementations.

The professional Scrum Master class is probably the best introduction to Scrum and empiricism out there. No question. The SAFe Scrum Master class is sometimes people’s introduction to the world of agile. It focuses much more on the team-level agility practices, the activity, the responsibilities, the characteristics of a Scrum Master, both with team-level agility, but also how does that apply to scale. Beyond team-level activities, what’s your role when it comes to the ART, to PI planning, to coordinating with other teams? That’s not really a conversation topic in the PSM class.

A person coming out of a PSM class would leave with a very deep understanding of empiricism and agility. I’m not so sure that they would come out of a SAFe Scrum Master class seeing transparency, inspection, adaptation as clearly.

First, let’s talk about SAFe’s perspective on this, and then we can talk about the why, and the impact, and what we see in the trenches.

SAFe’s approach to product ownership is to look at the organization and say: okay, there are multiple layers. There’s the team layer, there’s the team-of-teams layer, there’s even teams of teams of teams at the portfolio. And for each of these layers, product ownership is crucial. There’s no argument there.

SAFe’s choice is to basically say, for each of these layers, we have a slightly different role in the product-ownership domain. At the team level we have the Product Owner. At the team-of-teams, ART, program level we have what’s called Product Management. If you go even higher, you have Solution Management, and Epic Owners at the portfolio.

This is an area of SAFe where I think a lot of people, myself included, would provide some criticism. This is a contentious spot. What we’ve seen in a lot of organizations, when we install professional Scrum, is they have this structure in place already. They have product managers, and then they have business analysts who are writing the user stories, and then we have this proxy-product-ownership issue. There’s delay in decision-making, there’s lack of true ownership.

I struggle with this, to be honest, both as a SAFe guy, a SAFe Fellow, and a professional Scrum trainer. I see exactly it, and that product-owner-proxy, business-analyst-just-being-called-a-product-owner is definitely a problem that I see.

My take on it, and you might argue that’s my view, and most other SAFe practitioners don’t subscribe to it, that’s a different conversation, is SAFe takes the evolutionary approach here. There’s the risk of just putting lipstick on a pig, calling people a different name and moving on. There’s also the opportunity to actually use this to make sure we’re creating healthier product ownership at the team level, while acknowledging that it’s going to be too hard for the organization to really settle for one product owner, one agile product manager working directly with a hundred, a hundred fifty people.

What we need to acknowledge is that in the real world, that desire to have one product owner is noble, and it’s a good direction to push toward. The risk of just saying, product owners at the team level, just identify somebody, put the hat on somebody. It’s risky. I hope all SAFe practitioners understand where we want to go with this, and try to push the team-level product owner farther and closer to having a real product that they own.

I take issue with classifying this as burying that person under layers of management.

The lines are not black and white here. It’s not the product manager sits on top of the product owner. It’s a lot of collaboration. It’s involvement of product owners when we make prioritization decisions at the ART level, at the program backlog. It’s a team that has product management on the team, product owners on the team, and they work together to identify product vision, product priorities. There are different focus areas for the different people on the team, but it’s a team that collaborates, rather than a very square, limited box in which the product owner is jailed or buried. That’s how SAFe talks about it, that’s how it should be.

There are organizations where product owners at the team level don’t consider themselves entrepreneurs, experimenters, influencers, customer representatives. When you have these people, they turn very quickly into what they know how to do, which is to take orders, manage people.

It takes a very servant-leadership type of product management, very enlightened product management, with the right sort of coaching, to make sure it’s not “I make the big-picture decisions and you just go build stories,” but more of a collaboration. That’s definitely a risk. It’s definitely a risk in this structure, I would acknowledge that.

Having a fully empowered product owner that owns the budget, the strategy, the tactics, and everything else about a product is very difficult to achieve in a professional Scrum setting, too. That’s going to manifest here as well.

The RTE isn’t a function in making product decisions. They have a voice, they’re a stakeholder for product decisions, but, like the Scrum Master and the product owner, the RTE is the chief Scrum Master for the ART. They have no product accountability, so let’s bring them out of the picture.

Eventually it’s the product manager that makes a decision when it’s a decision at the ART level. If it’s a decision within the scope of a feature an agile team is working on, the product owner is empowered to make decisions around what should be the scope within that feature. There could be contention around should the feature look like this or that, do we spend three sprints on this or one, the product manager will be involved in that.

Same as in Scrum, even when we say there’s one product owner for the product, there’s somebody else who probably has an opinion about that product, who might be able to overrule that product owner, unless the product owner is the real CEO in that organization. It’s going to be unhealthy if they do that all the time. Same in SAFe.

Business analysis and product management provide two very different sets of challenges for coming into the product owner role. The main risk with business analysts is that they’re so used to just consider what the customer says as requirements. They used to be order-takers, they struggle to say no, to think strategically about what should be in the product. It’s still an issue but less of an issue with product management. Product managers coming into the agile product-owner role need to understand agility, empiricism, taking on the experimenter stance, which is relevant for business analysts as well.

Product increment planning. I don’t think it’s all-around evil. I think there are some interesting challenges that come when you’re trying to plan that far ahead. When we go that far out, I think it’s interesting to play “what if”. I think it’s good for a product owner to look at her product backlog and say, what if we have the most amazing five sprints, what kind of progress could we make toward our product goal? But when it comes to dedicating full days to thinking about “what if,” I get nervous, only because after the first sprint, most likely everything’s going to radically change.

I don’t know how stable SAFe implementations are three, four, five, six sprints out. Just having a sprint backlog that looks reasonable can be difficult enough, and now we’re trying to do that five, six sprints out, which could be twelve weeks out. It just seems like it would lead to a lot of waste and rework. I’m not even certain within SAFe how you’d trigger that reassessment of the PI, and whether executives expect what’s established in the PI to be consistent. What I have seen is that once the PI is locked in, there is an expectation that it stays locked in.

So: is it all-around evil? No. Does it have elements of anti-agile thinking? Probably. Is it all big-upfront-design? I don’t think so. I don’t think every product backlog item is fully fleshed out at the end of PI planning. They’re framed out, and then we’re trying to figure out six sprints ahead.

A couple of things to keep in mind. The planning-horizon onion was not invented by SAFe, and it’s not exclusive to SAFe. Scrum teams have been doing release planning at some level, organizations have been doing release planning as part of agile at some level, for ages. PI planning is an evolution of that concept.

What are we trying to do with PI planning? We’re trying to come up with a good understanding, across a team of teams that has some dependencies, some coordination they need to hash out among them, of what reality might look like. What we might be able to accomplish in the next 8 to 12 weeks. The real magic in PI planning is how it involves everybody throughout all of the teams that are working together toward these goals, to align on what’s important and what’s possible.

What PI planning is not is detailed planning for five or six sprints ahead. We go into what might happen in each iteration to flesh out the details, sort of a setup exercise, but the result of PI planning is not which stories are going to happen in which iteration. The outcome of PI planning is objectives that we believe are realistic for each team and for the ART, similar to a Sprint Goal being different from the Sprint Backlog. The Sprint Goal stays stable throughout the sprint, the Sprint Backlog does not. The PI objectives are expected to be stable throughout the PI; the iterations are not.

If you and I would go and visit organizations running PI planning, implementing SAFe, in a lot of them it would look more like detailed multi-sprint planning than what the theory says, which is an issue. A big issue, in my view. No matter how much, as a SAFe Fellow and SPCT, I can talk about this approach to PI planning in training, and even in organizations that I work with, there’s the gravity of: we feel more comfortable with defining the details. People struggle to follow the principles. SAFe principle number three says we assume variability and we preserve options, which means let’s focus on objectives, let’s keep the detailed backlogs open, let’s not commit to these things, they might change throughout the PI. There’s a big gap between the theory of SAFe and how it’s practiced in the trenches, which is a gap we need to work on closing.

SAFe is taking the evolutionary path. Organizations, project managers, PMOs, leaders have been doing plan-versus-actual for ages. One approach would be to say, we’re in an evidence-based world of empiricism, just break that habit cold, stop. That’s one way to do it. Predictability is not that important, it will be done when it’s done. But predictability is a big topic for business leaders. It is absolutely. I can totally see the point.

The context of predictability, though, is what I think is important. When someone says, can we predict down to the person what they’re going to do in a sprint, the answer is no. Can we predict down to the product backlog item what’s going to happen in a sprint, the answer is no. Can we, from a predictability standpoint, say that each and every sprint we will commit to a Sprint Goal and achieve it?

So what’s the predictability score measuring? It’s measuring PI objectives. Remember, the backlogs are not the output of PI planning. We don’t even look at them, from a theory standpoint. At the end of the PI we look at that plan of record, the PI objectives, and we look at how did we do with these objectives. There’s an additional level of granularity, which is each PI objective, both at the beginning and at the end of the PI, gets some sort of business-value score on how much impact we believe this objective has on the business, or we believe it will have, and at the end of the PI, how much are we seeing, before we even release it. That enables us to get an understanding of: are we even in the ballpark? If teams commit to PI objectives and hit 25% of them, are we smoking something good when we’re planning the PI? Or is it 88, 90, 70. Are we more or less in the ballpark? That means something. It’s not about the PBIs.

SAFe does try to achieve predictability, some predictability of what the business might expect. In many environments with Scrum we try to achieve some predictability as well, despite the uncertainty and risk. We use Scrum, and SAFe, to manage risk, manage uncertainty, in a way where despite all of the uncertainty we can have some predictability. You cannot have full predictability of everything that will happen. What you can do is prioritize. You decide those are the things that are really important to me, I know a lot is going to shift, but that’s my core, that’s the main bone through this PI that we’re going to focus on, and we’re going to throw a lot overboard in order to protect this core stuff.

Ken is pointing out the roots of SAFe, that Dean Leffingwell, who created the Scaled Agile Framework, also created the Rational Unified Process ahead of that, which isn’t very agile. That’s a fair criticism, that’s a fair perspective on what’s going on in the market.

I guess the key question is: these people had history in the Rational Unified Process. Is that a problem? I didn’t have history in RUP, I got into SAFe from being an Agilist. I appreciate some of the discipline, some of the full-solution thinking that’s going into it. Some very influential people in this professional Scrum world have a lot of experience in the RUP world as well, not to name names.

The key question is: as part of the RUP people getting into the agile world, did they do that with a real understanding and appreciation for Lean/Agile thinking, or are they doing this as, you know, a dirty trick? From what I’m seeing in the SAFe community, people are real about agile. They might have come from RUP, but they’re real about agile. Same as our colleague professional Scrum trainers who came from being project managers are great Agilists.

For these people, I judge based on what’s going on with SAFe. What are the principles, what are the practices. He’s definitely making a super strong connection here between SAFe and RUP, which is not a flattering comparison. I’m not sure the RUP connection is really that damning of an argument. I don’t think it means people can’t adopt an agile practice, but I do think he’s definitely making a strong connection.

Some of the metrics Ken’s preferring all evolved into evidence-based management, which is an excellent measurement framework. And SAFe has evolved since 2013 as well. There’s more and more stuff you’d find familiar from an evidence-based-management perspective in SAFe. It’s measure and grow competency, looks at outcomes, looks at flow metrics. It also looks at the competency of the organization, but emphasizes that’s not necessarily the most important thing, or the one thing you need to look at. You need to balance competency and maturity with: are we achieving outcomes, are we improving customer satisfaction, employee satisfaction.

I really respect Marty’s work for product leadership and product management, and I recommend any self-respecting product owner or product manager be familiar with his work on empowered product teams. Everybody that’s designing organizations should be thinking about how to design around empowered product teams. Since I’m following his work, it’s somewhat interesting to see his perspective on SAFe.

I think it’s neat that he definitely calls out a pain point. Producing technology at scale in a lot of areas generates a lot of pain. There’s this gap about doing big things at scale that Scrum and Kanban and other frameworks just did not touch, and I think even Marty’s getting to that point.

That relates to where we are in the adoption cycle for agile concepts. Big tech is full of a lot of people who understand agile principles as well. People in big tech have been doing things with that mindset forever, whether they use capital-A Agile or not. If you look in depth, what you’ll find in the successful companies is you’ll find agility. In the companies that are stagnant and don’t really succeed, you’ll find less agility.

The interesting question isn’t why SAFe. It’s why don’t we see SAFe in any of these companies. The answer, for me, is pretty simple: they don’t need it. They’re not the target audience. They’ve already figured agility out. They have the technical prowess to enable teams to be empowered like Marty talks about, without too many coordination mechanisms. They were able to descale the issue. If you have the situation Facebook talks about, where an engineer can deploy whatever they need to production multiple times a day, you don’t need SAFe.

I wouldn’t use that as a data point for what’s going on elsewhere in the industry. If you have the technical prowess that Google, Facebook, Amazon, Spotify have, and you have people that are experienced Agilists throughout the organization, you probably don’t need SAFe.

If we think about the technology adoption life cycle, the sort of thing Jeffrey Moore talks about, agile at this point is in the Main Street. The people currently trying to transition toward agility, they’re the majority, early majority, late majority, even some of the skeptics are now trying to become agile. Those people need something different. They need much more than the principles of the Agile Manifesto, or something like Scrum at the team level that they’ll figure out how to scale. They need a full solution. Jeffrey Moore talks about needing case studies, a business model, a business movement around it, partners, certifications. All of these things are needed to help the Main Street move. That’s the target audience for the Scaled Agile Framework.

I think he’s right. Empirically, in the industry, we see a lot of organizations that don’t push past that point, which is a real problem.

The SAFe Program Consultant is the mechanism to scale SAFe. It’s the person who learns the most about SAFe as part of the organization’s journey, the person who can come from outside, and if you’re working with the right sort of person, who understands the principles, has experience with agility, they’d be able to help you implement the practices with a good understanding of the principles, and not stick too much to specific practices for too long.

What we see out there in the market is, because SAFe is so successful, it’s very attractive to people. You see a lot of people coming over from worlds that are dying, the world of the Rational Unified Process, classic traditional project management for software development. Some of them are doing great. They really get it, and they become some of the best Agilists out there. But there are a lot of people that you can take out of RUP and traditional project management, and still not take RUP and traditional project management out of them.

Just because I took a four-day course on SAFe does not mean I’m a qualified SPC who should go in and install this in companies. I spent the better part of 15, 20 years working to build up a body of knowledge that qualified me to teach. What the course shows you is a professional learning path you need to start heading down over the next three, five, seven years to really come into your own as an Agilist.

I was thinking about Nokia and Scrum. There’s a Scrum test named after Nokia. I think Nokia is an example of what Marty talks about. I’m not an expert on what was going on there, but for me the main thing they lacked is an understanding of the real customers, the real market. They did not create empowered product teams. They had a lot of Scrum but not empowered product teams. My knowledge of a lot of these public cautionary tales, in all fairness, comes from the New York Times and YouTube videos, so I’m not an insider. Everything I say there is allegedly, kind of, sort of, maybe right. But it could be any company on the planet. I can’t tell you how many companies have come and said, we want to do a total transformation, and we say, great, let us look under the hood. Why don’t you spend the money on the tech first and then come back. And they all just say, that’s not what we want. I personally wish they would invest in the tech and the architecture and the build pipelines and then come back. But I’m not king of the world.

SAFe is a framework created by a for-profit organization. They want to improve the world’s ability to deal with complex product development, but they also want to make money doing it. The Scrum Alliance and Scrum.org are in a similar bind. It’s always a balance of what do we do with the bar for people who’d be empowered to implement this framework. If the bar is too high, the framework won’t scale quickly enough in the market. If the bar is too low, it’ll scale too quickly, to the point that a lot of people are abusing it.

As a person that trains SPCs, I’d be more comfortable if people who passed the SPC class would not immediately go and be authorized to do everything related to implementing SAFe in the trenches. What we’re seeing in the market is organizations learning that it makes sense to expect some more experience, some depth, beyond the acronym on your LinkedIn. That would slow SAFe adoption, which I think is a good thing. It would make the organizations that are serious about SAFe more successful, and make life harder for people just trying to use SAFe to make money without experience in agile.

If you’re not watchful, the process can become the thing. This can happen very easily in large organizations, the process becomes the proxy for the result you want, you stop looking at outcomes and just make sure you’re doing the process right. That can happen in Kanban, it can happen in Scrum, it can happen in SAFe. Whichever product-centric development path you’ve chosen. It’s an important thing to keep your eye on: are we trying to be the perfect SAFe implementation, or are we trying to deliver frequently and delight our customers.

Elsewhere, Marty also talks about a practice Amazon uses that isn’t in that quote: Amazon relies heavily on first principles. That’s the piece, in Scrum and in SAFe, that Marty doesn’t acknowledge, and, to be fair to Marty, a lot of practitioners don’t acknowledge either. There’s a lot of conversation about principles in these classes. Almost a full day that talks about the principles of SAFe, and bringing it back to the principles in every section afterward.

To me that’s the important thing when you’re implementing any agile framework or process: it’s the principles. I’d invite Marty, and other people bashing SAFe, to look at SAFe’s principles and see how much alignment there is, or look for misalignment, between those principles and theirs. I don’t think there’s much misalignment. I think SAFe’s principles are very aligned with what we talk about in the Scrum world, with what Marty talks about with product-centered thinking.

And the principles are more important than the practices.

Prefer to watch the full discussions? Check out the complete playlist from our Breaking the SAFe series with Ryan Ripley: