Breaking Down SAFe: Strengths, Weaknesses, and Controversies

Help me think through how this episode applies to my situation. Start by asking what I am trying to change. Separate the episode's claims from your suggestions, and say when the notes do not support a claim. Use the transcript to find passages, then check the audio before quoting. Transcript: https://yuvalyeret.com/podcast/episodes/breaking-down-safe-strengths-weaknesses-and-controversies/transcript.md ## Published episode notes In this special episode of No BS Scaling w/ Agility, Yuval shares an AI-generated highlight of the Breaking the SAFe video series created with Ryan Ripley. As a SAFe Fellow, SPCT, and Professional Scrum Trainer, Yuval brings a unique inside-out perspective, able to both defend and critique SAFe based on real-world intent and outcomes. This episode explores some of the most hotly debated elements of SAFe: why it’s so popular, where it goes off the rails, and how leadership, structure, and context shape whether SAFe is a recipe for real agility or just another case of process theater. * “Are we putting agile lipstick on a waterfall pig?” * “The question isn’t whether SAFe is good or bad, it’s how it is used, and to what end.” * “Structure helps at scale, but only if it doesn’t choke the principles you’re trying to scale.” * “If you’re not living and breathing agile principles, the framework doesn’t matter.” * “You have to actually do the work. The mindset. The principles. Otherwise, it’s just theater.” * “SAFe is a tool. Like any tool, it can be misused, or used in context to create real value.” * “It’s supposed to be evolution, not revolution. But sometimes that evolution just reinforces old habits.” Chapters (00:00) Introduction to Scaling with Agility and SAFe(01:06) Why SAFe Is So Popular (and Why That’s Not Always a Good Thing)(02:02) Critiques and the Waterfall Rebrand Debate(03:54) PI Planning: Powerful Tool or Planning Trap?(06:58) Leadership’s Role: Are You Chasing Cheaper or Embracing Change?(07:59) Scrum Master Controversies: Servant Leader or Project Manager 2.0?(09:41) SAFe's Response to the Command-and-Control Critique(11:55) The Product Owner Fracture: Customer Focus or Confused Ownership?(14:33) When SAFe Helps, And When It Hurts(15:09) Final Thoughts: Agility Is a Mindset, Not a Framework Want more than the highlights? Check out the Breaking the SAFe video series 🔥 Are you looking for a way to safely scale with SAFe?→ Start with Yuval’s free email course: Scaling w/ Agility Crash Course Yuval Yeret helps leaders maximize outcomes through strategic, nuanced agility. As a product/scaling/agility-focused management consultant, he guides organizations beyond agile theater and feature factories toward product-oriented agility, drawing on deep expertise as a SAFe Fellow, SPCT, and Professional Scrum Trainer. 📍 Follow Yuval on LinkedIn To hear more, visit yuvalyeret.substack.com Deconstructing SAFe's Intent, Design Choices, Strengths, Weaknesses and Controversies – https://yuvalyeret.com/blog/breaking-down-safe-strengths-weaknesses-and-controversies ## Transcript This transcript was edited from automatic speech recognition for readability. Speaker turns may be wrong or absent, and it may contain recognition errors. Check the audio before quoting or attributing a passage. Episode: https://yuvalyeret.com/scaling-ai-podcast/breaking-down-safe-strengths-weaknesses-and-controversies/ ## The friction around safe / scrum Is safe good? Is safe agile? What are safe strengths, weaknesses? Welcome to Scaling with Agility. Where typically, I, Yuval, your host, explored the nuances of scaling without the process deal. Today I have a special episode for you. A while ago, Ryan Ripley and I recorded Breaking the Safe, series of videos that dissect deconstruct safe tackling some of the fear, uncertainty and doubt that people spread about it, some of the perceived notions about it, and me as a safe fellow, SPCT, but also a professional ground trainer, trying to provide some of the rationale, some of the intent, trying to explain some of the different choices, as well as challenge some of the different choices that safe is me. If you don't have time to watch the full season, here's an overview of the highlights. This audio overview was the I generated using notebook column. Check it out. So today we're doing a deep dive on scaling agile. And specifically, we're going to be looking at safe. So the scaled agile framework, right? And we're going to be looking at it through the lens of a couple different agile experts. namely, you've all year it and Ryan Ripley. And we're going to be kind of looking at their takes on it. What's interesting about safe is that it's something that's like, it's everywhere. You know, we see it in a lot of different companies. It's very popular. Yeah, very, very popular. But it's also something that's very hotly debated, I would say, within agile circles. It's one of the things that I think people have very strong opinions about one way or the for sure for sure and I think that's what makes it so interesting to talk about right yeah is it really agile or is this just waterfall yeah it's this rebranded waterfall yeah like a lot of people like to say yeah so I think to get us started it would be good to just kind of understand like why is safe so popular to begin with yeah because it's not like this is some niche thing no you know it's everywhere there's a reason why people are talking about Yeah, and I think one of the big reasons is because it gives you that recipe. Here's how you do it. It gives you those roles, it gives you those ceremonies, it gives you those kind of different cadences to get things done. And so when you're in a large organization and you're used to that kind of recipe, here's how we do work, it feels very comfortable. Right, and it's giving you that roadmap, which a lot of people. Yeah, especially when they're first starting out with Agile. Because it can be kind of daunting for sure for sure. Where do I even start? Especially if I've got hundreds of developers and you know all these different. You've got multiple product lines. How do you even begin to wrangle that? Yeah and executives are asking you how are we doing? What's the progress? Link, can we expect this? Right, exactly. And they want to see it on a gaunt chart. They want to understand those dependencies. So I think that's a big part of the appeal is that it just gives you that that recipe that a lot of organizations are looking for. And it seems to check that box of being agile. But also having that structure. But the question that becomes, is that actually agile? Or we just kind of slapping a new label on something that's fundamentally the same as what we've always done. Are we putting agile look stick on a waterfall pig. There you go. There you go. And that's where those critiques of it being rebranded waterfall start to have some weight, I think, it can create this environment where you're so focused on the structure that you lose sight of those agile principles. So you mentioned this idea of structure. And I think that's something that we see very clearly in and safe approach to things like PI planning, program increment planning. And for folks who might not be familiar, that's safe way of basically getting all your teams on the same page. Aligned, aligned, yeah. On a shared plan. Right, so you're taking this big time box, which is often like three months. Right, typically. And you're trying to figure out, okay, how do we coordinate all these different teams to work together? Yep, and that can be really powerful, especially when you've got all these dependencies. But it also introduces this risk of doing too much upfront planning. Right, and that's where some of the critics come in. And they say, like, hold on a second. Like, Agile is all about being adaptable, being flexible, responding to change. Responding to change. And if we're locking ourselves into these big three month plans, are we really doing that? see examples of this playing out in the real world. I mean, you look at what happened with Southwest Airlines last year with their holiday meltdown. The holiday travel meltdown. I mean, obviously, there were a lot of factors that play there. Their technology was outdated. A lot of people pointed to their use of safe. They did. As a potential contributing factor. Because they had potentially planned themselves into a corner. They weren't able to adapt when things inevitably went wrong. ## What is really happening in the system they did go wrong. And I think, you know, to be fair, to kind of play Devil's Advocate here, yeah, even proponents of safe would say that, you know, you shouldn't be treating these plans a set in stone. They're not. It should be a guide. It's a starting point. It's not the end all be all. And so there's this emphasis on continuous improvement. regular checkpoints, feedback loops. But I think- It's all about that inspect and adapt. That's cordial. And Safetly says that they're trying to embrace that as well. So it's just a matter of are you using it the way it's intended to be used? And how much of that is, you know, realistic in practice? Because you can have all the mechanisms in place. But if you're not actually using them, if you're not actually embodying those principles, Then it's just kind of- And it's just theater. Yeah, it's just for show. And so I think that's, you know, one of the big questions with Safe is, how do you strike that balance between having enough structure to coordinate effectively? But not so much structure that you lose that adaptability. It's that delicate dance of finding the right amount of process in for your context. It is for sure. And that's gonna be different for every organization. And it might even be different for different teams within the same organization. Absolutely. And I think that kind of leads us to this bigger question of like the role of leadership in all of this. Because it's one thing to have a framework. It's another thing to actually implement it in a way that embraces those agile principles. That enables those agile principles. Not just as it does. And that's really where the rubber meets the road. It is, yeah. safe is how much are those leaders bought into the why? The why behind agile. Are they just doing this because it's the latest buzzword? Is it a way to get something faster? Are they just chasing cheaper? Or are they actually trying to create a culture? Are they trying to change the way they think about work? Fundamentally. And I think that's something that we'll see come up again and again as we kind of unpack some of these other more controversial aspects of safe, like the redefined role of the Scrum Master. And the fractured product owner, both of which have caused a lot of debate. A lot of debate. A lot of strong opinions. Yes, very much so. We'll dive into those right after this. So we're back and ready to unpack some of those more controversial aspects of Saze that we kind of hinted at. And I think a good place to start is with the role of the Scrum Master. Okay, because this is one where safe. Yeah does things a little bit differently than what you might see in yeah Then kind of traditional scrum. Yeah traditional scrum. Yeah, and this has led to a lot of Controversy controversy. Yeah, because you know the term project manager in disguise Gets thrown around a lot it does and you can understand why When you start to look at like what is a scrum master and save yeah like give us the rundown like what are they actually doing? Yeah, so you know in scrum, the scrum master is really there to serve the team to remove impediments to help the team kind of gel as a unit. And really embrace those scrum values. To be that coach, to be that facilitator. To be that shield almost from the rest of the organization. Ticking the team. But in safe, they take on some additional responsibilities. Like what kind of stuff are we talking about here? So they might be responsible for coordinating with other teams. They might be responsible for facilitating some of those larger safe ceremonies. Like PI planning. They might even be responsible for managing up to some degree. Interesting. So, you know, shielding the team from outside interference, but also kind of managing those expectations. So there's this element of like reporting and... Yeah, there's definitely a reporting element. And so you can see where that starts to feel a little bit. Yeah, it's a lot more than just serving the team. It's a lot more project management. And so for a lot of people in the agile community, they see that and they say, hold on a second. Like that kind of goes against the whole point of self managing team. Yeah, like if we're trying to create these teams that are empowered to make their own decisions, why are we giving them a project manager in a different guys? It's like we're taking a step back exactly and set it forward. And it creates this weird tension where the Scrum Master is kind of caught in the middle. Is it about serving the team or is it about adhering to the safe structure? ## The practical shift Are you the coach or are you the referee? You know, and it's hard to be both. So how does safe kind of address that criticism? Because I'm sure they've heard that before. They have. And I think their perspective is, you know, we're trying to meet organizations where they are. And the reality is a lot of organizations aren't ready to just flip the switch. And suddenly have these completely self-managing teams. It's too much of a culture shock. It's a huge culture shock. And so they see this as kind of a stepping stone. Like we're going to give you this role that might feel familiar and might have some of those traditional management responsibilities. But over time, the goal is to coach those scrum masters. To step back. To empower the teams and to really embody that servant leader approach. Just like a gradual kind of evolution. It's supposed to be an evolution, not a revolution. I can see that, but I can also see how that could easily backfire. Oh, absolutely. You know, like if you've got, yeah, if you've got someone who's, you got someone who's more comfortable in that command and control mode. It's very easy to just revert back to that. And that's a valid concern. And it just highlights the importance of having the right training, the right guidance, the right support with those scrum masters. Otherwise you're just reinforcing those old habits. Right, exactly. It's not enough to just check the boxes and say, yeah, oh yeah, we're doing safe. Now we're agile. We're good. We're good. Like you have to actually do the work. And that requires a real understanding of the principles behind it. And a willingness to challenge the status quo. And this is something that we see come up again when we start talking about safe's approach to product ownership. Which is another one where they've kind of gone their own way. It's kind of thrown a wrench and things. They said, you know what? We're going to do this differently. We're going to shake things up. So for folks who are familiar with agile, you know, the product owner is like, they're the North Star. They are the North Star. They're the voice of the customer. They're the ones who are ultimately accountable for the success of the product. But safe introduces this concept of like fractured product ownership. Which sounds a little scary. It does a little bit, right? So, instead of having that one clear voice, you now have what a whole chorus of product owners. You've got product owners, you've got product managers, you've got solution managers, you've got epic owners, all with their hands in the pot. So we've got all these different people with different titles, different levels of authority, and potentially even different priorities, all kind of vying for control over the product. Yeah, and that can create a lot of confusion. Like who's actually in charge here? Who is the buck stock with? And I think that's one of the big concerns with this fractured approach. And more importantly, I think it kind of dilutes that customer focus, which again, if we go back to those agile principles, it's supposed to be customer centric. It is all about like, okay, who are we building this for? What are their needs? What are their pain points? How do we deliver value to them? Are we solving their problem? Are we building the right thing? but when you have so many layers between the team, it's so easy to get lost in translation. And the customer is very easy for that message to get muddled along the way. Yeah, absolutely. So how does Safer go address that? Because that seems like a pretty big. Yeah, it's a big one. And I think- A pretty valid criticism. It is, and I think their response is, you know, again, we're trying to meet organizations where they are. And the reality is a lot of these large organizations already have these layers. They have these hierarchies in place. They've got these existing decision-making structures. Right, so it's less about like, let's blow it all up and start from scratch. And more about like, how do we work within the existing system? Which, I mean, I can see the logic there. It's pragmatic. It is pragmatic. ## What leaders should pay attention to But the question then becomes like, at what cost? Right, like, are you really embracing agile? We just kind of pull it. We just slapping a new label on the same old thing just with more steps. And I think that's something. And that's the thing that's hard to answer. Because it's context dependent. It is very context dependent. Every organization is going to be different. And it's something that, you know, anyone who's considering safe, right, really needs to kind of grapple with. Yeah, you really need to understand like what are we trying to achieve here? What are your goals? And how does this framework? Is this the right tool? or hinder those risks for the job because it's a tool. It's not a magic bullet. It is absolutely a tool and like any tool, it can be used effectively or it can be used ineffectively. It can be misused. It can be misused. Absolutely. I think that's a good place to kind of start wrapping things up. You know, as we've been talking about safe, it's a powerful framework. It's very comprehensive. It's got a lot of different components. Yeah, there's a lot to it. It can be really helpful. It can be for organizations that are trying to scale agile. Especially if you're in that environment where you need some of that structure, you need that recipe. Where you need to be able to kind of point to something and say, yeah, here's how we're doing it. This is agile. This is agile. We've got the certifications to prove it. Yeah, I've got the training. We've got the certification. Doing the thing. We're doing the thing. But it's important to remember that it's not just about right checking the boxes. Yeah, It's not about just going through the motions. It's not about just like putting on the safe hat and suddenly everything's better. And assuming that that's going to solve all your problems. It's about the mindset. It's about understanding the principles, being willing to challenge the status quo. Challenging those assumptions. And continuously learning and adapting. Continuous improvement. Yeah, because that's what Agile is all about at its core. That's the heart of it. And if you're not doing that? Yeah, if you're not living and breathing that. it doesn't really matter. Yeah, it doesn't matter what framework you're using. Is it matter what certifications you have? It's not going to magically transform your organization. It's not a silver bullet. So as you're out there navigating the world of scaling Agile? Keep exploring. Keep asking those questions. Keep learning. Keep experimenting. Don't be afraid to try something new. And most importantly, keep those Agile principles close at hand. Those are your guiding lights. They are your guiding lights. And they'll help you find the path. They'll keep you on the right track. That works best for you. Absolutely. So, with that, I think we'll wrap it up there. Sounds good. Thanks for joining us for this deep dive on Safe. Thanks for having me. Until next time, keep on Ageling. Keep on Ageling. Keep on Ageling. ## Source boundary These are the published show notes from the podcast feed. They are a starting point for discussion, not a verbatim record of the conversation. The transcript is machine-generated and may contain errors or unlabeled speakers. Check the audio before quoting anyone.