# Exploring All Things Flow with Yuval Yeret *Editorial note: Transcribed and lightly diarized from video captions for readability.* # Exploring All Things Flow with Yuval Yeret ## The Problem with Mandated Transformations and Transformation Theater **Yuval Yeret:** Let's get real for a minute. Most transformations flop. It's not because people are lazy or allergic to change; it's because the whole thing is usually forced upon them. Welcome to Scaling with Agility. I'm Yuval. I'm a management consultant who has been helping people navigate transformations, whether it's Agile, product, or AI transformation. Recently, I've seen way too often the organic pilots that create an island of transformation that works great, but then someone declares, "We're going to scale this," and it becomes an imposed mandate. The result is way too often—or almost predictably—resistance, box-checking, and a whole lot of transformation theater where nothing meaningful changes. You might see vanity indicators like people trained and certified—and you know, I've been part of that in the past. It's a comfortable life training and certifying people and helping people install tool templates like Jira, rolling out a shiny new framework. But when you scratch the surface, it's the same old organization. If we look, for example, at the typical Agile transformation, you would have things that are called stories, but they're actual technical slices that teams use to manage their work, and they still prefer to do everything that they need in a certain area before they go up for air. You might see people called Product Owners, but it's actually engineers and project managers that have been told, "You are now the Product Owner." At best, they own technical solutions and integrations, not customer outcomes. You meet these people in training workshops, and they have a lot of good questions around, "We're not really empowered to own a customer-centric outcome. We can't really make a change in a product that our customers—even internal customers—care about." So these people are really frustrated with the guidance that we're trying to give them. What's happening here is that because this organization is mandated to transform at pace, people just slap on the new names, the new framework—call it Scrum, call it SAFe, call it whatever—as lipstick on a pig, and hope through some magic they won't have as many dependencies. The spoiler is: this approach doesn't change much. At this point, the leaders start to think that this whole transformation is a sham, that Agile is a sham, that AI is a sham, that Lean is a sham, whatever, and the search for the next big fix begins. ## Treating Transformation as an Internal Market **Yuval Yeret:** Here's what I found: sustainable change doesn't come from mandates. Maybe faster change comes from mandates, but it's not sustainable. Sustainable change comes from treating transformation like an internal market. Instead of inflicting change, you invite leaders and their teams to adopt new ways of working. You're trying to sell it to them. Think about Geoffrey Moore's *Crossing the Chasm* approach. There will be early adopters. There will be laggards. You will have these people in the organization. There will be people who jump to try your new approach. Typically, by the way, those are the people who tried it in the pilot and made it work despite the fact that it wasn't fully ready yet. When you take the thing that worked for these people and copy-and-paste it to people who are the mainstream in your organization—who are looking for working solutions and don't want to figure everything out on their own—things don't work that well. And when you try to accelerate, when you try to inflict this change, then it's even worse for these people. They're forced to use a solution that's not working well for them. In my engagements, whenever we stopped enforcing these frameworks and started showing teams how these practices could actually help—when we helped them through a "why" conversation: "Why might this be useful? How might it be useful? When's the right timing for it? How might we adapt it to our needs?"—that's when things changed. When I started coaching a transformation team to deal with each different group in the organization like I work with a new client... I cannot force a new client to do something. All I can do is help them steer, help them navigate through what it is that we might want to do. When we started to have these conversations internally, adoption took hold because teams started to apply practices and patterns that resonated with them, that they had agency around using. You might think about it as treating the Agile journey with agility, or treating any sort of transformation with agility: empowering people, orienting around outcomes rather than rituals, giving people the optionality to figure out their own ways, aligning on principles—what does success look like?—but not forcing people to use a rigid set of practices. ## Core Principles for Sustainable Transformation **Yuval Yeret:** So, here are some principles to think about if you're tired of this transformation theater that's so common around us: **Focus on outcomes, not rituals.** Talk about outcomes. Lead through outcomes. Interest people in outcomes, not the rituals. The rituals might be useful, but they're not why you're doing something. Don't do something just as a ritual; do it because it's useful. Even the language of "rituals" creates the wrong mindset. You want to consider whether it's useful for you, do it if it's useful, and get better and better at it. Build consistency and reps around it if it's useful—not because somebody told you it's useful. **Organize around value.** You want to really think about how to organize around value. The fastest path to apply an Agile transformation is to just paste it onto the legacy org chart, but that typically doesn't allow you to deliver value. It just reinforces dependencies and creates the need for more and more structure. So if you have a scaled-up organization with a lot of teams, the pattern that you might want to start with is to descale in order to create an environment where you bring together real product teams—teams that are able to deliver value, give them the decision rights that they need, the resources that they need, and give them context, intent, and clarity on their purpose. What are they focused on? That's where outcomes come into play. **Structure risky investments as experiments.** Structure your risky, high-potential investments like experiments. That's core to agility. Every transformation is risky. It has high potential, but it also carries the risk of: "Is this the right thing for us? Are we thinking about it the right way?" So structure your transformation as an experiment. What's the hypothesis? What's the riskiest assumption in this hypothesis? How are we going to discover? You might say, "We've done a pilot, and the pilot has proven that this works. Now we're going to roll it out." But again, at that point, you go back to the desirability challenge. It was maybe desirable to a small group, probably early adopters or people who had a very, very tough problem. You still need to validate that this change is desirable for others. The way to test desirability is not to force people to do it; it's to market it to them, to sell it to them, not force it. ## Conclusion **Yuval Yeret:** In an upcoming episode, we'll go upstream to identify one of the root causes of this transformation theater. But until then, you can ask yourself: Are you running a transformation, or just putting on a show? If you're curious to explore an alternative approach, you can check out my Scaling with Agility free email crash course. Thank you for listening in today. Hey, I hope you'll join me again for the next episode of the Scaling with Agility podcast. Bye for now.