Dave West: 0:13

Dave, Hello, welcome to the scrum.org community podcast. I'm your host. Dave West, CEO, here@scrum.org and today's podcast will focus on safe and a palm or their long titles, the Agile product operating model and the Scaled Agile Framework. Wow. Anyway, so today I'm joined by Yuval, Yvette PST and safe fellow. Welcome to the podcast, your Val,

Yuval Yeret: 0:41

great to be back again. Dave, it's

Dave West: 0:43

it's great to have a safe fellow and somebody that's heavily involved in the evolution of the Agile product operating model on this podcast, because I got lots of questions. And before we get to that, though, I want to tell our listeners the genesis of this. So this podcast actually came out of a recent webinar, navigate, navigating, navigating, navigating safe with professional Scrum. Those discussions and questions got me thinking about the relationship between a palm and safe, and that's the reason why I asked you, Val to spend some time with me today so I can pick his brain about that. So hope you've, hope you've got your thinking cap on your Val. What is the relationship? This was the question actually from the webinar. What is the relationship between the Agile product, operating model and Scaled Agile Framework. Are they friends? Are they rivals? Are they best buddies? What is the relationship? Can Can you describe it for our listeners? Yeah,

Yuval Yeret: 1:50

the way I like to look at it, and it's inspired what I'm trying to do in the trenches these days is that safe? Can be a way to implement or instantiate an agile product operating model in an organization so beyond the high talk of being customer centric and having empowered product teams and steering with evidence. And moving from projects to products, you need to do something in the trenches. You need to organize into those empowered product teams, and sometimes teams of teams that need to work together, if your architecture, you know, doesn't really allow you to fully decouple the organization. So most organizations, as they're trying to think about, how do we actually make significant steps toward having an edge working in an agile product operating model, they look at some sort of agile approach. They could use Scrum, if they're very small, they could use, you know, different scaling frameworks. Safe is the most popular scaling framework these days, so a lot of organizations are using it for this purpose. The other way to think about it is, if you look at how most organizations have implemented agile until now, including using Save. A lot of those organizations have created feature factories, or, you know, I'm doing some work on the portfolio level, so I call it the mega factory. You might call it the giga factory, if you're a fan of a certain EV brand, fewer and fewer of those these days. But those are factories, while what we're trying to create are labs. We're trying to create an environment where we're actually discovering value and iterating towards value and validating value and the product operating model, and especially the evidence based aspect that, you know, we talk about as part of a POM really helps level up safe implementations. I've used it more than once in the trenches to help organizations see what we're trying to really create with safe beyond the mechanics, beyond the theater.

Dave West: 4:29

I mean, you said so much there, Yuval, and I want to unpack it, I think, for our listeners. So I want to start with the last thing that you said, which was to go from factories to labs. Now that sounds like, you know, a t shirt rather than anything, but it is actually very profound, because ultimately, most organizations want the efficiency and the structure of a factory, and most implementations of safe, I think, echo that where everything goes through Lean portfolio. Leo management teams ultimately are optimized around the work, not around the value. You know, you you see that they want an efficient factory, but, but, but unlike a factory, a factory works on a product that's well defined with very little variability. That's what Lean taught us right Six Sigma, those things, what we're talking about, the product that we're working on isn't one of those. Usually, it's more like what you would be doing in a lab. You have a hypothesis, you define experiments. You deliver them, you try. You know, you and yes, they provide value. You know being delivered. You know the pill helps you or whatever, but ultimately, you observe the behavior and the outcomes, learn, and it refreshes like that. But that's an incredibly different philosophy than most organizations want their technical capabilities or technology or digital capabilities to be delivered under. So I think that's really a profound difference. Do you do when you, when you say that you know and and you know you're not printing your T shirts, though you really should, and that's really cool. That's, you know, should definitely trademark it, but the or copyright it, maybe because you can't trademark a phrase. But anyway, so when you when you say that to the leaders, like the people you're working with at the moment in Chicago or wherever you're getting off every week, what do they say? Do they get it?

Yuval Yeret: 6:34

I haven't used that metaphor enough so far. I'm working on using it more but, but they're getting it in classic product development worlds. People are getting that. You know, the feature factories don't make sense the the conversation at the but it's really important to take the conversation from the theoretical slow t shirt slogans to what you actually do and like we like we talk about in evidence based management and in product discovery, shaping work items, around bets, around an hypothesis, around an outcome, and keeping what you actually deliver flexible. A lot of the work that I do right now is on working, let's say, with leaders of portfolio and looking at their Kanban boards, with all of the initiatives on that Kanban board, and trying to discern which of these initiatives are describing a body of work, what we call output, or even activities, sometimes, and which of them describe outputs that are more what we would like to see in a product environment, because those outcomes with leading indicators of are we actually seeing traction or evidence towards those outcomes? Now let product teams figure out a way. Now we can give those product teams a lab environment where they're saying, This is what we're trying to find. Let's try different things to find the right solution. Now, we're really in a new product development environment, rather than, you know, a manufacturing environment, a feature factory. But that's

Dave West: 8:31

the key thing. So I think that's the thing that's so interesting. You know, I have a little bit of experience with labs, from working with a few organizations that do it. And actually, my wife sold genetic tests for a while, and I learned a lot about genetic tests and doctors, which was super interesting. And sort of my experience of labs is the variability and the ability to change. You know that there is some level of efficiency in it, like they have set number of processes. However, they are continuously monitoring those processes to improve them. Because ultimately, the the processes affect the outcomes, and the outcomes affect the processes and blah, blah, blah. So I think that's really interesting, because one of my challenges to say, for my observation of how it's been implemented, is they take it as though they're not building a lab, they're building a factory. They take all the practices, they take every and they apply it. I don't want to say Route, Route, Lee, you know, as per, as per, the training classes, the materials for, you know. And there we go. And this is it. And that, I think, is a criticism that I think is fair when it's leveled against safe. By the way, I know that safe itself says no. You shouldn't do that, but, you know, it's hard.

Yuval Yeret: 10:04

Yeah, I think we have, I think there are three loops of learning, of improvement that we need to think about. Yeah, there's the actual manufacturing floor, the actual product. And when we're in the digital world. We don't really need to manufacture that product. It's there, yeah, that's where a lot of you know, this metaphor breaks down. But if we were making, I don't know, orange juice, like my my father was, you know, as the head chemist for, you know, a factory in Israel, or POM Granat juice, more recently, there's actually making the juice. You want zero variability in making the juice, and you want to have very formal ISO certified, whatever production lines that you know from time to time, you want to be able to change. You want to be able to improve the production line, and you want to play around with different recipes for the juice that make it more addictive, healthier, whatever, whatever you're trying to optimize for. That's new product development. That's what's happening in the lab, where people with the white coats are well, the production floor is running in the lab. You use different processes. You want faster feedback times. You're okay with variability. You're okay with today, we'll try something, and there's a good chance that it would not work. Now there's a third level that I think you're talking about, which is creating the right lab operating system. Yeah, and are we can we actually turn around faster in the lab? Can we use new equipment that makes us more effective, more efficient. Can we reduce waste? Can we do more with the same people? Can we use AI to find, you know, recipes out of the 1000 possible or millions possible recipes, which are the ones we should start with, like our friends in you know, the biotech industry in the Boston area are trying to leverage AI for these things, yeah, developing those capabilities and changing, you know, the interactions between the people and the different steps in the lab is also something that you want to change. I think your criticism for safe is about is safe itself dynamic enough that it would allow you to change your lab as frequently as you'd like? I think there's valid that that's valid criticism, both for safe and for Scrum, that something in the way we deploy these approaches and the industrial complex around them has made it very hard for people to see that they can actually use them as frameworks and not methodologies, Even though both are called frameworks, Scrum is a framework, and safe is a framework. They both should be starting points. They both should be, you know, adapted for your needs as an organization. But it's hard for organizations to realize that. It's much easier to apply them consistently across 1000s of people that that's i Yes, that's a thing for sure. I think if you another interesting question that we might we could do some thinking about, I've done some thinking about it is out of the box, does safe as a framework, support an agile product, operating model, or do you need to? Are there major incompatibilities that we need to do something about? So can it? So what I've seen is that it mostly can. Like there are, there are some gaps. If you look at safe portfolio level, it does talk about outcome orientation. It does talk about an epic hypothesis. It does talk about the MVP cycle. If you look at agile product development in safe which is what you do at the edge of release train level. It does talk about product management and empowering product owners, and, you know, having a benefit hypothesis for the features that you choose that allows you flexibility in what are the stories that you'll actually choose to implement for that? Feature, having said that the fact that you focus on features rather than outcomes is an issue. So that's something I'm working on. What might safe look like without features, or what could replace or how, at a minimum, what I'm doing right now is making sure that the features, even though that's the name of the entity, are mostly outcome oriented. That's the minimum viable change, you know, without changing too much. And of course, when people go into pi planning, you know, the planning, increment quarterly planning, that's such a core part of safe a lot of the time, what they plan is outputs, and they go way too deep into planning outputs, for sometimes a good reason, like the genesis of this is we want to have enough understanding of the dependencies and what we will need from each other to have a realistic plan to improve the predictability of organizations that are often totally unpredictable with very low trust from the rest of the organization. So quarterly planning, the safe style, improves that but needs to be reimagined for, you know, a truly product oriented organization, I can share that. What I'm seeing in the trenches is that a lot of times you talk about product orientation, and you want to aim towards that, but your business stakeholders, the people that are going to leverage those products they first, you know, want to build the trust that you have the capability to deliver. You talk to them about trust us, we are able to deliver those outcomes, or tell us what outcomes you want, not you know, what are the projects that you really need? And they're not at that level of trust, to really empower you to hunt those outcomes they want first, to see that you can actually deliver that's like a chicken and egg problem that you face when you're implementing product orientation.

Dave West: 17:18

I do want to, I mean, I see that all the time, that ultimately the trust, whether it be explicit or implicit, is kind of missing, which requires this level of planning you're describing. It requires you know, the understanding of dependencies, the understanding of critical path, which ultimately makes it more like works being done at the team level, less value is being delivered. But I just you talked about income is safe incomplete, and you highlighted some areas particularly not incomplete, but doesn't sort of takes you in the wrong. Maybe features takes you in the wrong direction. Maybe the portfolio playing process could be a little bit more outcome centric and less rigorous. You know, did it? Did etc. There's also things missing from safe, you know, in terms of, they don't talk about incentives, they don't really talk about, well, to my knowledge, and obviously, you're a safe fellow, Yuval, and you can put me right here, but what I am thinking increasingly is you have to approach each product holistically and build an operating model that supports that. So things like incentives need to be in place and aligned. You need to ensure that governance processes that aren't the delivery processes or the development or the discovery processes, governance is something different need to be well understood, you know, and appropriate measures put in place. You need to think a lot about organization structure, and you know, how do you do that? You know, particularly if you're building cross functional teams, you need to think of that. Now, I know that there's, there's lots of case studies and other materials that talk about those things in the context of safe but, but that sort of holistic chain unit of change approach, I think, is missing from what I've observed, certainly from the way I've seen it implemented. Most people implement it in their existing organizations, with their existing incentives, with their existing governance processes, and then shoehorn it in, as opposed to making a I don't want to say it is a significant change to change to a product operating model, but what's your experience? There? Am I wrong? And I'm just, you know sort of

Yuval Yeret: 19:38

you're not wrong that most organizations are implementing safe theater. You're not wrong that. I mean, I'm not seeing that as very different than the scrum theater I'm seeing out there.

Dave West: 19:52

No, completely agree. Don't say any different. I wouldn't

Yuval Yeret: 19:56

the way I look at it, a lot of the questions and. Aspects that you're talking about. Safe does have a perspective on them. Safe does talk about governance. It does talk about the choices that you can make around organizational topology. Let's call it that it, you know, allows you flexibility on organizational structure. And I think that makes sense. It talks about the dual operating system, and the fact, yeah, in order to create a product oriented organization, it doesn't call it that, but it talks about the value oriented network. And organizing around value is a key part of of safe moving away from traditional funding models and governance models towards leaner, more product oriented ones are part of safe they just come with so much other stuff that a lot of organizations are missing. You know, the connection between product orientation and what's there in save and it's also some of the things that are harder to implement than, you know, pi planning, although a conversation with you know, a lady at the big bank yesterday reminds me how hard it is to get people into a room, even a virtual one, and spending time together. So let's put that aside. But there are harder things about becoming a product oriented organization. Those are typically also the harder things about Scrum and the harder things about safe. So I think what we need to acknowledge is the dynamics in the market the you know, there's a series of organizations and the consulting ecosystem around those organizations that has tried to implement Scrum, to help those organizations become more agile and to make money along the way, that got those organizations somewhere and made those consulting firms quite a bit of Money. Also, the certification bodies have benefited as well, but that hasn't gotten organizations to really be agile because they were afraid of making some of those changes. They you know, those are hard changes. So there was another round, the round of scaling agile safe, you know, was brought in to do that other organizations use this Spotify model or large scale Scrum, or scrum at scale. Everybody tried to build the thing that will be used in, you know, in that, in that more recent cycle. But even that didn't really get us the results that we need. Because organizations, again, we're looking for a silver bullet, not to really reorganize around value, not to really change their governance model, or to break the silos between the business and the product organization. Some organizations at that point, you know, implemented a lot of prop or introduced a lot of product owners to their organization, but didn't really have a product organization. I have P I have organizations which have, I'm working with organizations that have hundreds of product owners but still don't have a chief product officer for the organization because they haven't really made that change? Yes. And now there's the new thing, which is, okay, another round. We can sell another consulting gig, you know, to these organizations. We can't sell a scaled, agile gig anymore. We can potentially sell, you know, let's go product oriented. At this point, I think there's a lot of potential in that. I want to be the optimistic and, you know, realize that change for these mega organizations that have so much history so many systems. It's hard. It's just natural that it takes those organizations time to implement these changes. And you know, the way, you know, we can manage that change that will take, I don't know, a decade for an organization to really transform is, you know, to do it through three different cycles. One cycle is the team level agile. Another is the Agile led scale and the you know now it's the product, and maybe we'll need another round, and that is okay. What what we should try to avoid is for this new round of. This product oriented, product operating model to be just another layer of veneer on top of the things we really do, if on the other end, it does, you know, get us one step further on the journey a bit more outcome oriented, a bit more empowered, a bit more evidence oriented than empiric, then I'm all for you know this, this latest stage in the in the journey of organizations, I'm all on board. Yeah,

Dave West: 25:35

I'm more optimistic than pessimistic. You know, the pessimist in me goes well. We tried it with Scrum. We tried it with scale. Now we're trying it with product. It's all the same old thing. It will fail. The optimist, which is more my natural bias, believes that actually, at team level, we did some amazing things. People actually deliver stuff. Now, you know, done is maybe not 100% done, but it's pretty close, better than it was testing is that, you know, testing, there are separate testing organizations, maybe in the IV and V area, independent verification and validation, but at the team level, you we wouldn't we mix those disciplines. Now, when I started work, testing was a whole different department with different people who were no fun at parties, usually. And now it's all more integrated, integrating the fun, I guess, or whatever. So, you know, and then scaling has actually helped in places, you know. I think that what you're talking about, you know, pi planning, even though it drives me mad that we, that teams, that most of the work that teams do come from pi planning, which drives me insane. And that's something I know, you and I both agree on, but it has actually unified and given a cadence and taken some complexity out of out of the situation. You know, some of the the release train thing has definitely helped, you know, in terms of integrated releases, that when it, when you've got 1000s of people, or hundreds of people working on 1000s of systems, you know, there's that we definitely evolved. And I think the product is, is definitely the next evolution on that, which I am also optimistic that will break down that divide between business and technology will simplify the alignment of people to outcomes, will optimize the sort of like the focus of a lab rather than factory mentality, as you called it. I'm very optimistic about that. Do you though, do you think that you talked about trying to make some changes to the to safe with that regard? Do you think that safe is going to start taking more of the product model nomenclature up, you know? Or do you, you know, the last release was, from what I understand, is all about simplification, which was, which is great and needed, and I appreciate that work. But do you think that that, that it, that it will,

Yuval Yeret: 28:13

yeah. I mean, if you look at the recent, simplified big picture, it does emphasize product innovation and flow to feedback and some aspect that you can tie more closely to the product world. And I wouldn't be surprised to see that that trend continues to save people. We can say a lot of things about them, but they're connected to their market. They understand what's valuable to their customers, and they're accelerating their feedback loops as well. So yeah, I think it's definitely gonna be part of the taxonomy of safe. I think a more interesting question is, how much of the essence of safe is gonna be reimagined to be more product oriented. Are we gonna see significant changes to pi planning, yeah, and features and what we actually manage in the backlogs, in safe especially in the art and team level, I hope, I mean, I'm certainly going to do My part to provide some more and more thinking and guidance on what that looks like. My customers are pulling me to do that work. I have multiple organizations right now that you know are asking to reimagine what pi. Planning looks like to be more outcome oriented, more enabling us to be more agile and more empowered during the PIs. So that's definitely something I'll be spending time on. And interestingly enough, it's also very similar to some of what another type of organizations are asking organizations that are using OKRs to manage a company or to manage more than product development, they're also struggling with quarterly planning. They're also you know, feeling like they need to plan too much up front, and they spend too much time doing this, and it doesn't leave them enough flexibility to do the right thing along the way, to really seek outcomes, even if those outcomes are not product outcomes to seek outcomes during the quarter. So a lot of things are converging. It's, yeah, book somewhere, the

Dave West: 31:11

probably is a book. Well, there's going to be at least a white paper, just listeners. It's not out yet, so you maybe listen to us before it's out. But it's something that Yuval and I were working on yesterday and and it may end up with a becoming a product@scrum.org not that I'm, you know, so future, and we can't make these predictions. My lawyers hate that, but I think it's very likely that this, this challenge of managing a portfolio, is something that is manifest both in organizations doing Scaled Agile, but doing less, doing whatever. I think it's just a natural problem. Yeah, even Nexus. Well, yes, even Nexus, which is good. So the last question I've got, really, is, all right, for people that are listening, that are doing Scaled Agile, maybe doing some professional Scrum, and they want to become more product centric, what's the next thing? What's the first thing? The next thing? What should they do next? I guess they should probably

Yuval Yeret: 32:15

start to think about, what does it actually mean for us to adopt a product operating model. If what they're looking at is portfolio level, product operating model or applying product orientation to the portfolio level, then they can definitely take a look at an email course I created called portfolio agility trail map that essentially talks about, you know, some concrete, yet small, practical steps towards applying product orientation at the portfolio level. And first of all, why should you even care? It's probably a good start. They should look at, you know, materials that we're releasing about the Agile product operating model and compare that to what they're actually doing. One of the things that that I've done with clients is crystallize the product operating model to a set of principles that you need to align to how you do that in your context might vary, but those principles are really things to to consider, and you can apply them at the portfolio level. You can apply them at the product level or even at the team level, things like, are we empowering our people to to actually make decisions along the way? Are we steering using evidence? Are we aligning to what's strategic without micromanaging those kind of principles? They're not anything new. And to be honest, it's a minimum. An organization that is implementing safe, for example, would do well to go back to the safe principles and assess how they're doing on those principles. The technique that I really like is the echo cycle, and I learned it the phase first time in you know, the advanced professional scrum master workshop, which is like a liberating structure party, more than anything else

Dave West: 34:34

we do, like our liberating structures, like

Yuval Yeret: 34:37

our liberating structures, but take Those principles and put them on an eco cycle and see which of those principles your you feel are mature in your organization, which of those you still need to do some work on. Are there principles that don't make sense? Maybe add the Agile Manifesto principles along the way and. And you know, see how you're doing. That's probably not a bad way to start to think about product orientation either. The last thing I would suggest is there is a lot of a lot of overlap between what we talk about in evidence based management and product discovery and validation and the product operating model. So if you're interested in becoming more product oriented, becoming more evidence based, and treating your work more like product bets and experiments and navigating the truth curve rather than just building stuff is, you know, probably not a bad place to start either. Yeah,

Dave West: 35:48

it was a really hard question, because it depends on where people are at in their in their journey. But I think whatever happens, you know, the the looking at your current work to make sure it's more outcome centric. Look at your the principles that are driving the change that you implemented, save Scrum, whatever, and seeing where there is a disconnect between that, whether it's at the team level, the portfolio level or the organization level, depending on who you are, I think, is great wisdom and something that we we should all, we should all learn from thanks for your time. We try to keep this short which is which is completely impossible on a topic as interesting, as far ranging as this. So we've only really gonna sort of like the surface, unfortunately. But thank you for taking the time to share your your perspective with our listeners. Happy

Yuval Yeret: 36:46

to Dave, maybe one last thought is, as I was thinking about the answer to your to your question, I think there's even a simpler answer, if your product owners are the right people, and they're empowered to do great product ownership, you're probably well off on the journey towards being a product oriented organization. The answer for most organization will be that that's not the case, not necessarily because you have the wrong people, but because the ecosystem doesn't enable them to be but what you can do is you can take a look at the misunderstood stances of product ownership, the preferred stances, and assess where do we stand on these things, and just trying to make an incremental improvement towards Some of the preferred stances is probably going to help you drive towards a more product oriented organization. We talked yesterday about the product ownership capabilities workshop. That's an ideal setup for actually having these conversations around, you know, are we set up around products? Are we set up in a product oriented fashion? It's,

Dave West: 38:09

it's, it's really funny. You bring it back to that, that workshop, because part of the reason why I started writing about a palm agile product operating model was because I was delivering that workshop, working with others on that workshop, and finding that it highlighted so many dysfunctions in the organization that it required us to sort of say, No, this is what good looks like, and because the product owner, as you rightly said, is the intersection of the pain, of the challenges of becoming, of really being a product owner in an organization that's not that's designed around projects. So it's funny that it all goes back to that, because it's almost comes full circle. Wow, cool. Well, thank thanks for joining us. Thanks listeners. Thanks for joining us today. We were with Yuval. Yuval yuette, he's been on this podcast maybe almost as many times as me. It feels like a PST and safe fellow talking about how a palm the Agile product, operating model and Scaled Agile Framework safe can live together, and hopefully it's been useful. We We went on a on a journey, talking about some of the challenges, some of the things that people maybe misinterpret around safe implementations. And we talked about one thing that I just want to remind everybody, you know, factories, let's be labs, not factories, which is you may see on a t shirt in the future. Maybe it's a really good sort of description of the change that we're seeking in the product operating model and building an operating model to sustain that kind of lab practice and fund those labs appropriately with a portfolio planning approach and. Um, I think super, super interesting. So if that's one takeaway, maybe that's the takeaway you should you should take and thank you listeners for listening today to the scrum.org community podcast. If you liked what you heard, please subscribe, share with friends, and, of course, come back and listen some more. I'm lucky enough to have a variety of guests, yes, sometimes you veil, often Yuval, but other people as well, talking about everything in the air, professional Scrum, product thinking, and of course, agile, thank you and Scrum on you.