Lindsay Velecina: 0:00

Patricia, welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Patricia Kong: 0:20

Hello, everyone. My name is Patricia Kong. Welcome to the scrum.org community Podcast. Today I'll be your guest host, and I get to host the usual host of this podcast. Dave West, hello, Dave, hello,

Dave West: 0:35

Patricia. It's really weird to be on the other side. I'm quite at a loss.

Patricia Kong: 0:39

Well, you'll just have to get used to it, because if this works, well, maybe we'll just do more of these. I think we're going to have to do a series on the questions that you were proposed when you did this webinar at the beginning of July, July 9, to be exact, it was called moving to an agile product operating model. So there were a lot of great conversation I heard, and I went through some of the questions, so I thought that today we could start tackling them. That sounds great. Thanks. So that webinar definitely had a lot of the why, and I would say what, of the Agile product operating model. But for those who didn't participate in the webinar, can you just give a quick one sentence, two sentence explanation of what it is.

Dave West: 1:29

So I think, in a nutshell, an agile product operating model is an operating model for each product. So ultimately, it's the emphasis on aligning an organization around a product model, creating an operating model through each product, with each operating model having the ability to respond and change based on learning. I would also argue that it's the next step in the Agile evolution to mainstream in terms of the bodies of knowledge that sort of brings together, builds it's around agility, professional Scrum, obviously, product thinking and modern management practices fused to create an organization that can respond to change in line, to products and services that they deliver to customers and value that they deliver to The world. So

Patricia Kong: 2:21

let's walk right into that, because there were a couple of questions that were basically saying, Hey, why? Why are you talking about this? Now, the promise of agile, as we've seen it, has really under delivered. It's under delivering, and they're only seeing some sorts of hybrid work, where there's some agile and some some waterfall, and frankly, some of the other questions really have the same sentiments that and struggles that we've seen over the past, you know, 1015, years. So, so why this? Why now in terms of evolution?

Dave West: 2:56

And I think that's a very, very good question, and obviously there's a sort of underlying cynicism to those questions as well. Is it just another thing to reinvent agile, to make to sell more stuff again? And maybe there's some truth to that. However, I think why now? So when I was an analyst at Forrester Research, I wrote a piece, gosh, must be 17 years ago. Now, which is worrying area called Water scrum four. And it really described that many organizations are doing it agile, but, but the the planning was in the waterfall model, the release model was, you know, totally separate from from the teams. They had no control over it. And ultimately, they were doing Agile to deliver work. Over the last 15 or so years, I have seen some of that change. However, the reality is that agility hasn't delivered on its on its promise, not because of agility. I think everybody knows that processes like scrum are actually very common sense, you know, how else would you work in a situation where there's a large amount for variability and unknown, and what are the compromises you're going to have to make around that variability? And how are you and how? How can you empower teams? Because you have to, the only way to effectively deliver value in these complex environments is empower teams. So, so ultimately, we I think we know that agility works, because it's just at the end of the day, common sense. However, as you scale that, as you put that into an organization that may be is risk averse, is decision averse, you ultimately find that it becomes harder and harder. And yes, there's been a lot of great scaling ideas, whether it's less, whether it's Nexus, whether it's scaled, agile, even and safe, whether it's there's lots of really interesting ideas. However, at the end of the day, they're all compromises without a fundamental change to the way in which you. You think you you align to the customer and to the outcomes now. So I think ultimately that this product idea, this idea of aligning around a very simple currency in your organization called products, is the time is right. Not only do we have the all the experience we have of agile, not only do we have all this great work being done in the product community about how you can become more customer centric, how you can bring in design thinking, etc, and you've got this growth of management practices, whether it's a Spotify model, whether it's you know, management 3.0, etc, all brought together, but in a constrained and focused manner, which is the product. So I think timing's perfect for that. The other thing is, and I know everybody talks about this all the time, but llms and chat GPT and the technology that's that's really becoming this next generation digital technology, means that ultimately you have to build organizations that one understand who your customer is and the outcomes that you seek, and to have a willingness to deliver things to them frequently and learn by that in that delivery. So I think that the environment at the macro level is right. I think the sort of energy inside organizations and experience of agility product thinking combined with modern management practices is right. So I think the time is right for this agile product operating model, absolutely.

Patricia Kong: 6:32

I mean, I think it's interesting, this whole notion of scaling innovation and the contrast of standard ID, standardization, standardization, standardization that companies have faced has been a problem for the last decade. And talking about an evidence based approach, which is close to my heart, which I know is a big part of this agile product operating model, is interesting, especially as companies are looking to pivot and learn quickly, or at least they need to. So then, in terms of a product, operating model, then, is everything a product? What are the boundaries? How would a company define them? Some companies don't know if they have products, or they are very defined on what their product are. And would that change?

Dave West: 7:19

I think that that, and that is probably the most interesting thing that every organization needs to start thinking about, is everything a product. I have no idea. However, what I do know is that there's some products that are very simple to understand. You know, they are this capability that we package and we sell a software product, you know, like Word or Excel, or whatever. That's pretty easy to think about in terms of product. However, in an organization like Bank of America, fidelity, investment, State Street, all these big financial institutions, what are the products? You obviously got a series of financial products. Are they the products? Are those financial products actually a collection of products provided by the organization to serve those outcomes, some of them being things that you buy, you know, like whether it's Salesforce or some sort of infrastructure or messaging platforms, whatever, or and some that you build yourself, those are the products that you then assemble into these into These solutions, you know. So I think that the decision that an organization needs to make about where, where are the boundaries, ultimately should be driven by value and driven by customers and users, people that consume and the value around it. If it's if it doesn't have value and doesn't have customers, it becomes less easy to define as a product. So what I would do, if I was in an organization today, is I would think about the portfolio things that you're working on, the combination of projects, applications, systems, initiatives, all that. And I would try to think about that from you sort of change my perspective. Think about it from a product lens. Okay, let's look at the customers. Let's look at the outcomes they're seeking. Let's start doing some sort of affinity mapping around those and start looking at how we serve those customers. Now that means, in the short term, it's probably going to be a little bit messy as you, as you, as you work through it. There's going to be some things that were obvious and some things that are less obvious, start with the ones that are obvious and slowly, incrementally, move to this model. The other thing that this gives us, particularly for the internal system type elements of any product model, maybe you're an insurance company and customer, you've got this very clear customer capability, and it becomes a product that you, in inverted commas, sell to a series of other products that are then ultimately delivering services to customers on the on the outside. But this gives you the ability to clearly make those buy, build, you know, type, type decisions. It also builds you. Know, allows you to build an infrastructure that maybe you resell the classic AWS example, right? That was infrastructure that Amazon used for its own capabilities. It productized it inside its own organization, and then ultimately used it in an effective way. But the key to product, the key to thinking about what's a product and what isn't is this customer and the value that they that they provide, and the outcomes that they seek and the opportunity we have, because then you can start really thinking about innovation. You can start thinking about rapid learning. You can start understanding their their motivations, rather than their features, as it were, and I think it can lead you to a really good, at least conversation about the stuff you're doing, on the value of delivering now

Patricia Kong: 10:52

the customer outcomes. Or thinking about that is a great way also to translate for like you're saying, service organizations, or even platform organizations, the ability to group those, think about them in a portfolio, and use the product as a way to deliver value to them. So So that's interesting. However, now we have to address the questions that when you are, you know, have all these products, the organizations are, they're typically having people, there was a there was a comment about resource management, but, but generally just people working on multiple projects, so as people are trying to make this transition, or even if they were starting in Greenfield, how would that work in the Agile product operating model? How would you think about this notion of decreasing multitasking on multiple projects, is that a thing? Is that not? I

Dave West: 11:46

guess the bottom line is that this is whether it's projects or products. Organizations need to do less, and that sounds rubbish. To do more, you need to do less, meaning you need to serialize the work. You need to think about focus. You need to make decisions. And that's the reason why we have a backlog, right? The great thing about a backlog is it, it is, I guess, two dimensional. It is, it is a list. And a list has a top and a bottom and middles, and, you know, and so you can really clearly see order. It isn't a Gantt chart. It isn't a, you know, we don't treat it like that. Though you can obviously show it like that. We tend to think of it as a list and and I think making and focus is is awesome, and that what's really cool about the the Agile product operating model is that it gives us the power to actually do this. Because, imagine you got a product team, a product, you know, or teams, they have a clear single backlog. They there's, there's a bunch of projects running across multiple products to deliver value to customers or whatever. Maybe there's GDP, stove, udpr stuff. Maybe there's some stuff around, I don't know, California privacy. Maybe there's some stuff around the Olympics. Maybe we've got a big initiative about the Olympics. I know that's almost over now, but you know, whatever those projects are and but it allows the product teams to make decisions about priority and focus based on their own backlog, their own needs, their own understanding of the customer, their own understanding of the you know, the outcomes and the economics and value that your decision. And then make that transparent and allow leadership, executive leadership, to make those okay this, these are the choices my product teams have made based on the objectives that we set at the start of the year. Are they still valid? You know, have have we seen something else as you know? Are we doing something different now and and I think that's the power of a product operating model. And if you make it agile, the power is you make it transparent. Backlogs are really obvious. You make it visible, you you have clear product goals, yeah, and, and, and then they can change. But when they do change, you have the ability to escalate them and and make those, make those things transparent. So I think, I think this ultimately, if done properly, can get us away from that, you know, that big, continuous list of projects that you're working on at any moment, but it does mean that you have to make choices. It does mean that the product owners that run each of these products have to make choices, and have to say no or maybe not no, but not now, which is a much easier thing to say, just for the record. Um,

Patricia Kong: 14:47

no, that's not yes, you you

Dave West: 14:49

do. You obviously don't live with my children. Yes, it's much easier to say not now. But it turns out that they've worked that out now, and they say not now means no, right? Dad. I'm like, Well, I.

Patricia Kong: 15:00

Yeah, oh boy, oh boy. But I think what you're talking about is important in terms especially around the focus and context switching, which hurts. So it's not just you know, your ability to go from multiple meeting to meeting, but the context switching really hurts that focus. So a follow up question from here was about the way that you've described it. Is this just a value stream model is a palm just a value stream model.

Dave West: 15:27

Um, I think it definitely builds on it's a bit more than value streams. Obviously, the people that created value streams and talk about value streams will think it's a bit less than value streams. And so I guess we all come in my own biases, but isn't it interesting that all of these bodies of work, whether it's design thinking, whether it's the work of people like Marty Kagan and Mr. Perry, whether it's agile, whether it's modern management practices, management three, oh, Jurgen, oppolo, etc, whether it's even complexity theory by Snowden and that all of us are kind of moving to the same we use different words, we use different boundaries. We you know, some of us disagree about whether we compromise and where we don't, but, but ultimately, we're all leading to this consistent, hey, you have to define your organization around the value that you're trying to deliver, and then you need to understand it. You need to optimize it, and you need to continue. You need to have people focused on making sure that it flows right, and make it visible, make it transparent, optimize it. Now, we believe in agility, that you make small bets, so ultimately, those those value streams are continuously delivering incrementally. We also believe that each value, each offer, each product, will have its own model. There isn't a universal model that in an organization, a product that's at the end of its life cycle may have a very different way of working. In incentives, organization, structure, roles, you know, all of the things that you know that there are part of a an operating model will be maybe unique. Now, organizations hate that. They're like, we need everything the same. We need to deliver on the same cadence. We need to the same planning cycles. We need to but how can you have the same planning cycle? It's like, if I'm an oil company, planning for an oil rig is significantly different from planning for an update to the website. You there's just no way they would be the same, you know. So if you're delivering, you know, or a new incentive program to your distributors, you know, BP or shell or something that has a different kind of product to delivering a new pipeline to Siberia or whatever. It's different. It's going to have a different cycle. It's going to work differently. It's aligning differently and so. So I think that we have to accept that, even in the digital, electronic world, we have to accept that products are different, and they'll have a different operating model. So to answer your question, I think very similar. I think that based on some, you know, similar ideas, I don't see it fundamentally different. However, I, you know, I'm, I'm, I'm more familiar with the ideas that we're thinking about than than those ideas. Okay,

Patricia Kong: 18:22

so then let's get into the final cluster of questions that that support that. So let's say we believe that, we believe, you know, that, that we should be moving to an agile product operating model. We believe in an evidence based approach. We believe this is the way to to move forward and to sustain our organization. So we think about products. We think about how to focus but unfortunately or fortunately or just real life, we have legacy systems. So we live in a company that is not optimized for us customer outcomes, but probably have systems that were optimized around costs in their delivery processes and applications. So, so what does that look like when an organization believes in this and they're saying, Hey, we're going to move from this model to this model so we know that there's certain there's a certain boundary of you must start from scratch, versus you start from where you are, and kind of make the small adjustments you can. What do you think that looks like?

Dave West: 19:28

I think that's a really tricky question. Trish, as you as you well, know every situation is different. There's a few things though that I've you know that are truisms that I think a sort of universal truth. Number one, you can start today thinking about the work you're doing in terms of customers and outcomes. Yes, you're not adopting an agile product operating model yet, but you can at least start thinking and reframing your backlog or your JIRA or. Or whatever you're using to drive how you work, thinking about it in terms of customers and outcomes. And if you start doing that, that can be really almost revolutionary to the way in which you approach the work. Talk about the work, review the work, test the work, you know, etc. So I would encourage everybody to do that in material of the organization constraints that you're in. Now, if you want to think about, Okay, we are starting to think more about customers. We're starting to think more about outcomes. We're starting to move from this sort of more projecty, work, task based world to something a little bit different. How can we then take it to that to the next level? And because we've got all these constraints, we have built an organization, and we have built applications, you know, around a set of a set of constraints and ideas that are no longer true. So how can we do that, well, I would say, let's look at a customer opportunity, and it would have an initiative that has a clear, direct parallel to a product capability that we want to deliver. And I would find a group of people that have the skills that can deliver it, and I would trust them and empower them to solve these problems, you know, and it could be the fact that everybody can change code in an IT and software setting. It could be, you know, that you have an open source in source, open source model, where you have everybody can make changes to every system, but you have a group of people that sort of maintain the integrity of those systems and make sure that those changes are great through either code review, peer review or or pairing or some other way. I would encourage you to build teams that actually, instead of being dependent on other groups take ownership of the things that they're changing. Obviously, I'm painting a very black and white story, and it isn't always quite as black and white, but I would encourage that, because then you know, those dependencies can ultimately destroy the model and destroy your success. So I think that you can start by thinking about customers, thinking about outcomes, build some boundaries and have a go and learn from it. And I actually do initially, the product model, operating model, or the product model, will be an overlay to your existing organizations and existing systems and existing projects. Over time, it will move to the organizing paradigm and but I think you can do it.

Lindsay Velecina: 22:51

Thank you, Dave and Trish, hello everyone. This is Lindsay valisena from the scrum.org community podcast. Thank you so much for tuning in today, be sure to tune in next week. We are going to continue this conversation. There were a lot of great insights in today's discussion, and it spilled over to another episode. So please tune in next week and get more answers from Dave about the Agile product operating model you