Exploring All Things Flow with Yuval Yeret

Today’s episode about flow with Adam and SPCT and SAFe® Fellow Yuval Yeret covers a lot of ground. The two discuss topics, including why now is the time to introduce flow properties and accelerate flow at multiple organizational levels before launching Agile Release Trains. How flow metrics don’t just benefit organizations at an advanced level of Agile maturity. Why it’s critical to connect people with the development value stream who have an intimate understanding of operational work. And why Agile is carrying some baggage that’s not useful.

Hosted by: Adam Mattis

Transcript

Announcer: Welcome to the SAFe Business Agility Podcast. This is the place to get advice, stories, perspectives, and updates about safe and related topics to help you work differently and build the future. Thanks for listening, and be sure to subscribe to the show wherever you get your podcast.

Adam Mattis: On today’s episode, we talk with my good friend, Yuval Yeret from Agile Rising. We talk about all things flow and get his perspective on SAFe 6.0, both as an SPCT and SAFe Fellow, and professional scrum trainer. He’s got a lot of great experience, a lot of great ideas, and I hope you enjoy this one with Yuval Yeret. It’s good to see you.

Yuval Yeret: Good to see you, Adam.

Adam Mattis: How is your first quarter wound up?

Yuval Yeret: Pretty busy. Lots of work in pharma, helping them figure out how to use SAFe to achieve agility at scale in it. So, pretty busy.

Adam Mattis: Well, if there’s an industry that seems like they have to have the ability to adjust quickly, it’s got to be pharma. I mean, a lot of the cool things that we learned through vaccines and those technologies and, you know, the ability to recognize and respond to new stuff quickly. It’s pretty cool.

Yuval Yeret: Yeah, it is. You talk to some of the pharma people and at this point, they’re thinking they’ve been a bit maybe too Agile during the vaccine rollout, so they now are trying to figure out some discipline into it.

Adam Mattis: Sometimes fast is too fast. That’s what my dad told me when I was 16 and driving way too fast. <laugh>, yes. At any rate, Yuval, it’s good to see you. Would you mind telling the people who you are?

Yuval Yeret: Yeah, I guess I’m one of those weird SPCTs, Fellows that spend a lot of the different Agile communities. I’m both an SPCT and a [SAFe] Fellow, as well as a professional scrum trainer. So that brings interesting things into the mix. And I also used to be called Mr. Kanban Israel, so I have a lot of connections to that world. And that was actually one of the first things that really attracted me to SAFe was that it pulled in both Kanban and flow and Reinertsen’s work as well as classic, Scrum-based agility. So I come from a background of product development back in Israel in technology startups, then started to use Agile back in 2006 or so. And then starting to help more and more organizations leverage it using a variety of techniques. And try to bring in my thinking of low focus and invitation-based, kind of involving people and using the Agile and Lean principles for Agile implementations themselves as part of the SAFe community and the Agile community.

Adam Mattis: So. like many of us, you’re a nerd of many trades. Yeah. It’s all part of the fun.

Yuval Yeret: I also play volleyball and ski and snowboard, which, coming to Masterclass and anytime it’s Boulder in the winter, it’s an opportunity to.

Adam Mattis: Absolutely.

Yuval Yeret: To get away from the ice coast in the Boston area where I live right now.

Adam Mattis: Yeah, skiing up in the Boston area, even like in Vermont, it’s not the same. I mean, I grew up in that part of the country, and it’s ice-sliding. It’s not skiing. You come out here, and you just realize that it’s a whole different game.

Yuval Yeret: Yeah, I mean, there are crazy days where it is powder on the ice coast, but they’re far

Adam Mattis: Few and far between <laugh>. Volleyball is fun too. That’s an aggressive sport in my house. My wife and her best friend were both state champion volleyball players, and I’m not, so when it’s the two of them against her friend’s husband and me, it’s just, it’s a blood bath. It’s ugly. I enjoy it until they get overly aggressive, and then I just quit because it’s just not fun. <laugh>. So, let’s talk a little bit about flow. So, I know at the Nashville Summit, you have a pretty good talk in there where you’re kind of diving into the flow a little bit. One of the biggest evolutions in SAFe 6.0 was bringing flow more toward the forefront. And I think, as you mentioned, it’s always been there, but I think as the Framework evolves and time passes, and more organizations get better at embracing Lean-Agile principles and those ways of working, certain things become more relevant at different times.

So while flow has always been there, it was hard to talk about flowing anything when we were still talking about two-year release cadences and all of those other bottlenecks that we had. And I feel like a lot of our organizations, as they mature, they’re pushing the IP, right? And they’re kind of moving as fast as they can, given the current constraints of the model. And I really feel like bringing flow to the forefront and focusing on that and giving good tools for what that means and bringing good conversations to the surface about how organizations can flow and be even better and smoother and faster and more just in time. I think it’s a really cool thing. And I think it’s just in time; I didn’t mean to make that pun, but I guess I just did.

Yuval Yeret: So, I’ll make a potentially controversial statement.

Adam Mattis: Oh, sto,p Yuval. Nobody will believe you, of all people, is going to be controversial.

Yuval Yeret: I fully agree that now’s the time for teams and organizations that have reached a certain level of maturity to accelerate flow, but I also feel like there’s an opportunity with emphasizing flow to actually help people that aren’t at that maturity level yet. If you look at, let’s back up 10 years ago, maybe more, maybe less, and the whole Scrum versus Kanban conversation that was out there in the community. A lot of Scrum people said, yes, Kanban is great, but when you reach a certain maturity with Scrum. But what we noticed with practicing Kanban in the trenches is that it’s actually a great starting point for people because it doesn’t require going full Scrum, and you can actually get a lot moving using an evolutionary change method.

Adam Mattis: You know, that’s interesting. And you bring me back to, I mean, but I guess, like you said, 10 years ago, when you first start talking about Agile ways of working to people, one of the first things you would introduce is the idea of a personal Kanban. And that, for many of them, was where it really started to all make sense. And, you know, you also mentioned kind of this friction between Scrum and Kanban, and I guess I find that interesting because I’ve never been really pure to any one method or another. And I think every time I’ve ever stood up a Scrum team, in hindsight, it’s been a scrumban team because, you know, we embrace all that Scrum is and then visualize the work and managed flow with Kanban. I guess from my perspective, I’ve always seen the two go together, and I’ve never really seen the conflict.

Yuval Yeret: Yeah, I’m with you. But the communities didn’t see it that way, especially the Scrum community. And, you know, eventually, scrum.org started to bring in Kanban. I helped create that class. And now, you talk to professional Scrum trainers, and most of them are on board with Scrum with Kanban and flow metrics. And the conversation is SAFe 6.0 talking about flow metrics the way we’re talking about them in professional Scrum with Kanban, or is it some other version of flow metrics? It’s like the arguments around how to do weighted shortest job first, you know, like Reinertsen is saying, yeah, there are many ways to do weighted shortest job first. The important thing is that SAFe introduced weighted shortest job first to tons of other people that weren’t aware of it before SAFe introduced it. So for me, the important thing is we’re doing flow metrics, whether it’s this version or that version, but back to my

Adam Mattis: Your controversial statement.

Yuval Yeret: Yes. To the potentially controversial statement. I think we should leverage the fact that we have flow properties and flow accelerated in SAFe to look at organizations that don’t necessarily want to take the full leap to Agile Release Trains with all of the Scrum and Agile practices and help them get started. Similar to how we talk about introducing some Lean portfolio techniques at the beginning of the journey. Now we should be talking about … we should be looking at opportunities to talk about flow properties and accelerating flow at multiple levels of the organization before we even launch Agile Release Trains. Before we even train everybody on full SAFe.

Adam Mattis: I have one concern about that, and it’s historical. It’s not, I guess, theoretical. I seem to remember a lot of clients I would walk into, and maybe this was 10 years ago, 15 years ago, and I couldn’t say the word Lean in the presence of executives because, at some point, they had been sold the idea of Six Sigma and in hired consultants to come in to optimize the minutia before they ever understood how their organization flowed; before they understood what value was and how it flowed and how it flowed through their organization. So I think that there’s a good opportunity there as long as we can align … we need to agree on what value is and how it flows before we start trying to optimize for flow. And again, I just, I remember being thrown out of a woman’s office. She was an executive vice president at an education company, and I said the word Lean, and she looked at me and said, “Get out.”

Yuval Yeret: I’m with you. It happened to me as well. It starts to happen around Agile as well. These days Agile is getting some baggage that’s not very useful. I think we need to be careful about how we do it. I think that looking at operational value streams, development value streams, applying flow to the right place to mainly development value streams in the context of what we’re doing of, you know, improving creative work and knowledge work and the variability that’s part of that and complexity that’s part of that. I think that’s an important distinction. But I think it can be a useful evolutionary change management approach, especially, I would say, in non-tech, in organizations on the business side. Historically, I’ve seen teams on the business side that struggle with the full engineering discipline and rigor that come with SAFe that is needed in technology and engineering organizations in product organizations.

Adam Mattis: Do you think it’s time we send the box of chocolates to our friends in business architecture? Because what I hear you saying makes me think of the work that BAs traditionally do with the C-suite and the top levels of the organization. And one of the things I’ve always struggled with is I’ve had great interactions with BAs. I’ve seen amazing BA work. The value streams at that level; the capability landscapes that they create to really understand what it’s going to take to start executing top-level strategy across the organization. There’s some really good stuff there, and I think there’s a gap between that really good work and the work that we do within developmental value streams and within—to some context—operational value streams. So I think what I hear you saying is that— or maybe I’m just manufacturing this because it’s a conversation I want to have—is that maybe this is the time; maybe this is where we start when we start talking about introducing these concepts to business, and we start wrapping our arms around those folks and creating the organization that is the digitally integrated organization. We’ve got to bring those folks to the table because they have a lot of the pieces that are missing that will make those business conversations really meaningful.

Yuval Yeret: Yeah, that resonates for me. It wasn’t what I was thinking about, but it definitely resonates with me that we need to find more people that can really help us nail operational value streams and development value streams. And talking just to the technology people about that is not going to be enough, right? They’re not business experts. They need to understand the business. They need to understand the business much more than they do in order to be customer-centric and apply product ownership. But whoever the people are in the organization that really understand the business, whether it’s business architecture people or other people in the context of product companies, those are the people that we need to build a common language with.

Adam Mattis: You know, and I think as you said it, it really hit me that the problem isn’t different in a tech-native company, right? Because the people who engineer the solutions are still very much disconnected from the strategy and the big picture of things that people interact with, right? So if you go to—to pick on a tech native—if you say like a Tesla, the people that are building the regulators that warm a battery that regulate the discharge of batteries in certain temperatures, their work is important and detailed, but it’s very far removed from this strategy of how you take a Model S to market.

Yuval Yeret: Yes. I mean, when we really do our job well to organize around value streams, hopefully, the connection between the job to be done of helping drivers get the most out of their EV in those weird winter states where it’s cold when you’re trying to charge it. Hopefully, we get to the point where the engineers working in teams relate to these problems and see the connection between what they’re doing and what the customer needs. But it is hard to maintain this connection.

Adam Mattis: Yeah. And the reality is the solutions are complex, right? No matter how hard we try to maintain visibility, when we start building these large, complicated, integrated systems, there’s only so much that automation and clean architecture can do to clarify the landscape. They can make it a lot better. But the nature of a big complicated solution is that it’s big and complicated, and it’s really hard to be an expert in all of the things while also maintaining customer centricity. And I really think that’s where people like you and I try and play; we try and work with those big systems because they’re fun and they’re complicated, and it’s interesting. And there are a lot of other folks that have a different perspective, a different set of experiences, and they really believe that, and rightfully so, that the engineers should be intimately involved with the customer and the solution day-to-day. And there’s some point where that just starts to fall apart because of how complicated the things are. It’s not that we shouldn’t strive to be as Lean and clean as we can, but it’s also important to acknowledge that not everything can be solved by a two-pizza team.

Yuval Yeret: I guess. What I really like in SAFe is the fact that the principles enable us to have these conversations and adjust the practices to the context and understand the different forces that are at play that we’re trying to optimize. We need to keep in mind, you know, how far we are from the customer and the purpose, but also what’s the cognitive load that we put on people if we ask everybody to be aware of everything.

Adam Mattis: Absolutely. And I think that’s a good point that you bring up is that the intent of the Framework isn’t that everybody do all of the things, right? It’s that you start figuring out what tools in the Framework make sense to solve the problems that you have, right? It’s not the goal that everyone starts launching solution trains and doing all of the things if that doesn’t make sense for you. And for a lot of organizations, that doesn’t, but it’s not about being all things for all people. It’s about bringing—as you said with WSJF and that great body of knowledge—it’s about bringing these great ideas to the surface and presenting them to people and letting them decide what subset of these tools, which configuration makes the most sense for what I’m trying to solve.

Yuval Yeret: So, one thought is to bring it back to flow as a change management.

Adam Mattis: That’s where I was going to go. You read my mind.

Yuval Yeret: The way I’m looking at it and the way I’ve used flow with some very large-scale enterprises was, let’s start with flow. Let’s start with visualizing the development, figuring out what’s the development value stream, visualizing it, starting to see the flow, not even limiting the amount of work in progress. Just see the flow properties of the system to use the recent SAFe 6.0 language. And then start to apply flow accelerators. SAFe or Agile Release Train, weighted shortest job first, solution train, all of this could also be seen as flow accelerators of a certain magnitude that you might feel you need. If you start to see, oh wait, there are a lot of things that are getting stuck in my flow in very large batches, or, you know, I see a lot of blockage due to I’m waiting for dependencies. How can I do this better? Oh, maybe I need to reorganize around value in order to let things flow. So this is the way I’m looking at things.

Adam Mattis: So, could you talk to me about the change management perspective that you have? I mean, that, that’s another one of those things that, for me, I’ve always been kind of passionate about. I know we talk a lot about change leadership, but there’s a difference between change leadership and change management. So when you talk about using flow to accelerate change management, can you dive more into what your thoughts are on that?

Yuval Yeret: Yeah, I don’t know that it fits into formal change management, but what I’m thinking is introducing flow visualization and then flow acceleration; let’s call it a minimum effective dose of change, right? It’s like we’re developers turning on the debug mode to see what’s going on in our software. That’s some change to what we do. It’s not going to change much, but it’s going to show us what’s going on. I’m a networking DevSecOps person in my background. Turning on sniffer on the network shows you what’s going on and enables some conversations, but it’s not changing the network dramatically in itself. It creates opportunities for change that are now going to come in pull mode. Because if you have the right sort of leadership in place that is aware of what’s going on and interested in seeing problems and solving problems, now they are going to say, “OK, now I have a more concrete understanding of the problem that I have or the opportunity that I have. Let me look at what are my options for dealing with this. And maybe let’s pull in cross-functional teams. Let’s pull in something like PI planning. Let’s pull in something like weighted shortest job first, or whatever SAFe principle or practices, or non-SAFe principle or practice, that makes sense in this context in order to try to get me to better flow.

Adam Mattis: So what I think I hear you saying is that flow is a great tool to help us better understand the problems so that we can clearly define our why before introducing a change or a solution or SAFe, whatever it might be. And that’s kind of an opposite perspective of when we typically have a tipping point conversation—where it’s either someone is proactive in terms of leadership, or there’s a burning platform. So it’s taking a more scientific approach to say, let’s understand our system and what the problems are and then figure out what is the best solution to those problems.

Yuval Yeret: Yeah, exactly. You could also think of it as mini-tipping points. You don’t even need a big tipping point when the way you start is with flow. I’ll give you an example. I was having a conversation with the senior VP for a thousand people that were developing software for one of the big telcos that are now big SAFe clients, which starts with an A. And I didn’t really sell them on Agile too much. All we talked about was, let’s look at the flow; let’s start to manage the flow. We did a Kanban board on the whiteboard in the SVP’s room, and they said, you know what, let’s do it. After a couple of weeks, the Kanban board was in place. We saw thousands of features, epics, whatever you want to call them, flowing or not flowing, a big swamp in that process. Looking at the work of a thousand people, it didn’t break the waterfall right then, but it started the chain of tipping points that eventually led to this organization being a SAFe case study a couple of years later.

Adam Mattis: I think that’s a great point. I think that in and of itself is an interesting case study, which is probably why you’re presenting it at Summit. I really like that approach and perspective. I think to your point; people are sick of hearing the “A” word. People are sick of hearing the infighting around that word. You know, this is, and that isn’t, and all those sorts of things, when the reality is we’re here to solve problems, right? We’re here to help organizations deliver high-quality value faster that delights customers. And there are a lot of tools that we can use to do that. And so I think your approach that you’re suggesting really is an objective, problem-solving-style approach to figuring out, you know, hey, instead of walking in and saying, I know what your problems are, here’s the solution, let’s go. It’s taking more of that coaching stance and saying, well, let’s together figure out what’s going on here. And then, once we understand what’s taking place in the system, we can kind of co-create the solution that best makes sense for you. And sometimes that’s going to be SAFe and Lean-Agile principles in a lot of cases. You know, those ways of working, those philosophies, they are the right solution, but it’s a byproduct of having understood the system and the problems as opposed to assuming we know on the day we walk in.

Yuval Yeret: Yeah, I mean, there are environments in technology and IT where it’s really helpful to come in with that mindset. There are other environments where it’s going to be a waste of time, to be honest, because there’s clarity on where we want to go, and there isn’t time to learn what the problems are. We kind of know.

Adam Mattis: Well, and sometimes people just have interesting personalities as well.

Yuval Yeret: I think the place where I really see the potential for this in the now is as we expand words, you know, business teams, business trains, people that don’t immediately buy into the “A” world and, you know, SAFe and all of the practices. And where we might need some more humility as we go in and try to help them. And some more buying and an evolutionary mindset. And that’s why, you know, I kind of make the connection between the fact that SAFe 6.0 is talking both about flow as well as, let’s get real about business agility at the level that we haven’t done before.

Adam Mattis: Sure. And one of the things I’m really hopeful for as we start going down this path and getting more mature in this space is that the us and the business language start to go away. I mean, everyone says it. I used to think it was an IT thing, right? When I was deep in IT, and they would always talk about the business, it bugged me, but it was fine. I got it. But then, as I started working in other areas of the organization, and I heard marketing say it, and I heard HR say it, and everyone else says it, and you realize when you say “the business,” you’re talking about your customer. And it really creates that wall, that us and them. And it drives me bonkers because all of those enterprises are there to do something together.

And that language, I mean, it creates that division. And I guess it goes back to when it was first brought into enterprises, and it was kind of—and it still is in some organizations—like a standalone service entity, like an independent operating company than the rest. But the more we can start bringing people together and not treating certain categories of people in the enterprise differently based on the kind of work that they do, I think it’s going to be a lot easier for us to behave as one organization. So if IT is not in another building that requires special permission to badge into our building, little things like that will start making it easier to have a business that can behave with agility because we haven’t created these unnecessary barriers within our own enterprise—the same organization that’s delivering value to the same customers.

Yuval Yeret: And we do. And even though we’re talking about this evolution, we’re prone to talk this way a lot because we’re working with IT organizations. So it’s going to take a lot of effort on our side as well to change the language. You know, I see a lot of promise in the business agility patterns that we now have in SAFe 6.0. I think figuring out who needs to be in the development value stream from a holistic perspective and a real understanding that development is not just we develop software, but we develop business solutions. And that includes, I don’t know if we’re a healthcare, an orthopedics network, that means, you know, nurses would be on the development value stream and finance controllers would be on the development value stream. And whoever is needed to figure out how we do M&A in our environment, how do we move to more remote-based, tele-based health during the pandemic? That’s the sort of development vow dream that we need.

Adam Mattis: Absolutely. So my entire family, aside from me, is in medicine. And I see this a lot, and to me, the problems that they face just seem like they’re such easy fixes. But to your point, the folks that are doing the work are so far removed from the people that are building the system. And when I mean the system, I’m talking like the hospital system, right? It’s not just the systems that they use, that part’s pretty good, but the decisions that they make and the barriers they put in place, you can tell they don’t have people consulting on the solution. I mean, again, the developing organization, whether they’re developing policy or whatever, and it’s little things like my wife runs a nursing unit at UNC, and there are dumb rules. Like you can’t drink water at the nurse’s station in the hospital, but you’re on your feet for 14 hours a day running around like crazy.

And the only time you have to drink water is when you’re passing by the nurse’s station. And so there’s a policy somewhere that talks about protecting consumables from fluids and all these different things. And just like so many other policies, right, it’s diluted. Like every person it passes through has to add their own fingerprint to it. And what that comes down to is, well, nurses can only now drink water in the locker room. Except they don’t have time to go to the locker room. So, as a result, you have dehydrated nurses that are thereby impeded in their decision-making, and the more dehydrated they get throughout the day. And it’s just crazy. And so you don’t advocate that you would have every ER nurse on an ART, but you need an ER nurse on an ART making those decisions to make sure we’re making the right decisions. And I think that’s a great point when we talk about integrated business agility value streams and ARTs considering the entire solution; you need to have those voices. They might not be full-time team members, but you need to have somebody you can call.

Yuval Yeret: Yeah. And what I’ve seen when working with similar teams and kind of playing with some of the patterns that are now in SAFe 6.0 is it’s tempting to say, let’s apply Agile patterns and Agile Release Trains to everything in the work, right? Let’s have the nursing unit use SAFe to manage their work. I think that’s a slippery slope.

Adam Mattis: I think it’s a treacherous east coast ski mountain in late March is what I think it is. It’s very slippery.

Yuval Yeret: Yeah. And I think we need to, as we’re working to leverage these business agility patterns, be extra crisp on operational value streams, operational work versus development work, and what’s the interaction between them. You really need those people that have intimate—you gave a great example—you need that intimate understanding of the operational work in order to build the system, the business solution, the processes, the software systems, and cyber-physical systems that serve people in the operational work. That’s what we do, right? We should have passion about it, and people in the development value stream should probably go and spend time in the operational value stream, but they’re not the same.

Adam Mattis: Sure. You know, and to your point, we need to be careful that well-intended people who are consulting in the operations space don’t try and make the solution. They’re familiar with a one-size-fits-all approach. You’re absolutely right. I’m a firm believer that there are things from the Lean-Agile principles that can help everyone do better work in any context. Now, that doesn’t mean that everyone’s on an ART; everyone’s on an Agile team. Maybe it’s just that for your nursing unit, you bring in a Kanban board, and you say, let’s do our best to manage flow in our workday, and you value the principles, but that it takes maturity in a consultant. It takes maturity in a change agent to really look at things to ask, what makes the most sense in this context? And, you know, there are a lot of well-intended, excited people that don’t have that experience, and they inadvertently cause some damage, right? They try and do too much without having the experience to really guide their decision-making, and it leaves people feeling funny. But I think, as you know, as we talk about these things more and it’s a more open conversation. Hopefully, those things start to resolve.

Yuval Yeret: Yeah. We don’t want SAFe to become the new Lean Six Sigma, right? We do not want people in the operational value stream to feel like people pushed SAFe on them like we would feel if Lean Six Sigma was applied to development work.

Adam Mattis: And let’s be clear too, I’m not throwing shade at Lean Six Sigma. I mean, it’s great. I think the things that GE did with it back in the day were amazing. But I think because GE was so successful, everyone took that as an opportunity to sell it everywhere. And again, it was well-intended people not understanding the consequences of their recommendation. That kind of created some anxiety.

Yuval Yeret: Yeah.

Adam Mattis: Well, Yuval, this has been a good chat, and I am excited to see your presentation in Nashville. Do you have a formal title that people can be on the lookout for when the agenda’s published here in a few weeks?

Yuval Yeret: Using flow, identification, and acceleration to drive your agility journey.

Adam Mattis: Excellent. Yuval, people want to connect with you, ask you questions, and follow any of your thoughts. How can they do that?

Yuval Yeret: YuvalYeret.com is where I blog. YuvalYeret.com. I’m pretty active on LinkedIn as well.

Adam Mattis: All right, Yuval. Hey, it’s been a good one. We’ve known each other for a lot of years. I don’t think we get to spend nearly enough time talking. Hopefully, we can do so over a beer at Summit. But hey, I really appreciate you taking the time on a Friday. We’ve been trying to pull this together, and I’m super glad that we did.

Yuval Yeret: Good to see you, Adam. See you before the Summit.

Adam Mattis: Probably. Absolutely. Cheers, my friend. Cheers.

Announcer: Thanks for listening to our show today. Be sure to check out the show notes and revisit past episodes at scaledagile.com/podcast. Relentless improvement is in our DNA, and we welcome your suggestions for the show. If you have something to share, send us an email at podcast@scaledagile.com.