Lindsay Velecina: 0:00

Music. 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. Hello everyone. Thanks for tuning in to the scrum.org community podcast. This is Lindsay valisena here@scrum.org welcome. I just want to give a quick recap of last week's episode. This is a part two of an episode recapping questions from a recent webinar that Dave West hosted on the Agile product operating model. Last week, Dave gave an explanation of the Agile product operating model and answered a few questions, including looking at challenges and opportunities and scaling agile, defining and boundaries of products, managing multiple projects in focus. Dave also took a look at value streams versus the Agile product operating model and the differences there. And Dave also discussed transitioning to an agile product operating model from a legacy system. So this next episode, which is also moderated by Patricia Kong, as she did so well last week. We'll cover some more questions from the audience of that recent webinar. I hope you enjoy.

Patricia Kong: 1:29

All right, so let's move on to the next set of questions. There were a lot of great thoughts on the process and what an agile product operating model could look like, the notion of forming teams around you. Talked about a group of people forming around products customer outcomes to solve problems and the skills that they need. Now, a lot of the questions from the from the webinar were really about the role of product management and the role of product owners. And, you know, is there still delivery management? Is there still a delivery organization? I think that that goes back for us as scrum.org about like the role of the product owner versus Product Manager, which you've done a ton of information about. So how do you see that living in the apon model.

Dave West: 2:22

So I think there's a universal need in organizations to improve their competency around product. And I'm avoiding the word management, ownership or leadership, that the sort of the that I think we need to become more verse in the ideas around product, the ideas of minimal viable product, the ideas of, you know, under the things like lean startup, in terms of understanding customer adoption and usage, the ideas of design thinking, the ideas of customer centricity, the ideas of experiments, value hypothesis, you know, the truth curve, All of these things, I think we we universally need to become better at understanding this, because that's how we're going to exploit the next generation digital technology. Then, okay, so then they're moving that into into an organizational construct, you know? So what about product management? What about product ownership, what about delivery management? I am in the in the webinar, I drew a slide. I had a slide that had quite an I thought was quite interesting. I'm sure others may, may have thought not is that this balance between product ownership, product management, and delivery management? I do not believe that you that there's a hierarchy. I hate the high idea of a hierarchy. I also don't believe that product management, product owners hand things over to delivery teams and off they go with them. I believe there's a cross functional team built around products, of which the product leadership, owners, managers, whatever you want to call them, exist together, working at that, and working together on that. I think that then they are supported by delivery management, Scrum Master, who's, you know, just to use something you love, EBM, you know, a scrum master concentrates on ability to innovate, time to market. A product owner concentrates on unrealized value and current value, and then they all worry about quality, governance, ethics, culture, that kind of stuff. So you've got that focus on market value from the product leadership and focus on organizational capability from delivery. Or we'd call them scrum master, and they come together in pursuit of ultimately delivering that value to customers and to the organization over the long term. Now, what the titles of these people are? I don't know. I don't I think that titles, job titles, are a product of the industrial aid. Age and and I, and I know they're necessary, because how else are we going to hire people if we can't say, oh, but really, what we're looking at is capabilities. So we need somebody, or some people in the team that can clearly understand market value and drive that. And that could be internal market value, which is very different from external market value, or is it that's also an interesting philosophical question, and then you need some people in your team that care very deeply about organizational capability and delivering on that. And you know, in EBM, we would use particular measures ability to innovate time to market for that organizational capability. And we would you just talk about unrealized value and current value from a market value perspective. But there's other metrics of our ideas. And I'm not I though obviously we care deeply about EBM. There are other ways of thinking about this. But at the end of the day, if you want to build a great cross functional product team, and I think you do need to. You cannot go back to this, the product. People write the requirements and hand it over to a delivery organization. You cannot go to that and you can't use the excuse. Well, there's too much for them to do if they work with delivery. You've then the delivery team can help the product people make those good choices. They can help build experiments. They can work with customers, they can work with stakeholders. They should, you know, and yes, they can be mentored and coached by the product people to do it effectively. But that the notion of product management and being separate from delivery is an outmoded motion notion, in my opinion, and we should avoid that. So I'm I'm quite passionate about that. I believe in empowered, cross functional teams that ultimately have the skills necessary to deliver the value, and that have different specialisms and orientations, yes, but have them as a team, and I think then that avoids this massive debate about, oh, well, you know, product product owner versus product manager, who cares? What the title is, what care, what we care about is effectively delivering value and using the the cross functional team to do it, and having those, those skills necessary to do it in that team and that saying that, though, I do believe every organization needs to learn more about product and and I think you know, whether it's looking at design school, looking at all the great stuff, you know, the Lean UX stuff that looking at all the great work that's out there around product and how to build and divine and understand and understand customers, and that, I think, is a skill that we all, or many organizations, are lacking, and it's a responsibility of everybody, not just the product manager.

Patricia Kong: 7:53

Well, I think I just heard goals well said. I think I just heard goals alignment, collaboration and accountability, however you want to organize in the words that you use to, you know, describe roles or things. It's really about developing those capabilities and skills around product, because there are a lot of those, those great ideas and the theories and the strong product thinking mindset. And then there's the execution of it. And that's where you really need the people to think about what that is. And that's, that's what hasn't happened, is it?

Dave West: 8:29

And I think the point that you're raising is important. I think when you don't have, when you do have that, when you have a very clear handoff, and outsourcing of some amplifies this handoff, the most successful teams that I've seen and and I've worked in a few have been, have been very coupled, meaning the product thinking and the delivery that sort of, they talk continuously. They've got ideas. They're they're slacking each other mess. Well, we didn't use Slack back in the day, but we used to use, my God, Yahoo Messenger, if you can remember that. But the you know, we were Yahoo messaging continuously. When I was a product manager working with a product team, we were, we were joined at the hip, and we and we all cared about the customer, and we all held us each other accountable for that. There's many times I've gone in with, Hey, this is, I think this is, should be our roadmap, and they'll be like, Well, why does that? Why does the customer care? You know, I've got developers on the team asking that and that that's awesome, though a little annoying at the time, but awesome to do that. And I think we need to build these cross function teams, because the technology that's available to us today allows us to rapidly learn. I mean, the technology that we're that we have access to today gives us the ability to simulate. It gives us to the ability to so not only do we don't even have to. Stuff. Now to learn, you know, we have, I don't know if we're using Salesforce, marketing cloud here@scrum.org and you can literally simulate campaigns based on previous experience. I mean, it's just great. You can test ideas continuously and and then you can sort of increase the the you know, the proficiency of the data by actually releasing things and testing it on small sample, AB testing, and then you can grow it and learn, etc. So we have that power today. And I think that if we build organizations that are very hierarchical, where decision loops are incredibly long, where knowledge is considered to be power. I know about the customer, you have to come to me to learn that, then you're going to undermine our ability to take advantage of this technology, which is maybe fine, but if your competitors do a better job of it, then you're going to be in serious trouble,

Patricia Kong: 11:00

right? I was actually going to tag you on the next set of questions, which is around leadership, but just for fun, because you brought up outsourcing, how? How does that, or does it fit in to this model, third party outsourcing, even procurement. What does that look like? Oh,

Dave West: 11:19

gosh, well, procurements a whole different thing. Yeah, so procurement is the, I don't know, the Achilles heel of most large organizations, adoption of agility, because you end up, and I think that the I talked about the Boeing project as an example, the, you know, Boeing versus SpaceX in the webinar to illustrate mindset and the importance of mindset and alignment, etc. And I'm not dissing Boeing because they're an amazing engineering organization that you know, I fly on those planes every day, so not every day, but very frequently. And so I respect them greatly. However, I think mindset and alignment undermine their ability to execute, with respect to the to the space program, and with respect to, you know, getting Archimedes and getting to the moon, etc, but, and you could the contract in the pieces that I've read about the program. And obviously I'm not on it. Sorry, I don't I'm only reporting based on public available information. But the the the they actually call out the procurement process around the that original $4 billion contract as one of the reasons, because of the way in which payments, milestones, payments were created that undermine their ability to actually execute. And I thought that was really, really interesting. So procurement, as outsourcing, all of it needs to be aligned to customers outcomes and progress towards the goals of the organization and and with an acceptance that the work is going to be unknown long term, because we're going to learn stuff as we go, it is altogether possible that what we thought we'd be doing is going to be slightly significantly different to what we actually do based when we actually deliver stuff. Now obviously in a space program might not be quite as different as a as a new web experience, or a new software product, or a new a new financial capability that we're delivering, you know, in the finance world, um, because you have so many options to do stuff, space, ultimately, rocket science hasn't changed much since the 40s, but the but, but at the end of the day, you know, you've got to build outsourcing, procurement, contracting vehicles around the outcomes that you're trying to achieve and the product and it's best if you basically put people into product teams and have them share the same, same incentives that the product teams are on, and then you just happen to be building, bringing in skills that you haven't got for whatever reason into your organization to do that. The other model, obviously, is outsource the whole product and but measure it and pay for it in regard to the to the capabilities and the value that the products creating, it could actually, yeah, and cross your fingers, I don't know. I mean it Potentially, it could actually simplify the whole contracting model. I hadn't spent a great deal of time thinking about that. I mean, ultimately, products are measured by usage. Products are measured by value generated. Products are measured by their you know, the the the challenges that they solve, right? So if you outsource that, so you use an outsource vendor to deliver and maintain and provide that, then measuring the value of it could be relatively simple, and therefore the payment could be relatively simple, and the contract, the SLAs, everything like that, could be relatively simple, but it means that you have to change that conversation. In with your with your partners, with your suppliers, so that you actually share those outcomes. One thing that about the Boeing or the it was reported in the press that Boeing uses a massive amount of subcontractors, and they the subcontractors are working to their own plans. Boeing was and then with like, two sets of books, you know, the actual project plan, and then the project plan you share with the partner. And I've worked in situations like that and back in in the 90s, and it's just awful. It just it's rubbish, because it that that transparency is crucial to effectively delivering value and and making sure you're going in the right direction. So we can't afford for that, and also it costs a load of time. It's pantomime process, pantomime and yeah, I we do really can't so I think that we have to bring our partners into this model and into this approach.

Patricia Kong: 16:03

So that level of conversation really does make me think about product leadership, right? So there are questions about who leads this product organization, and, you know, where do these people fit in? And you You hinted to that and and some of the other answers you gave previously. You know, project manager, Scrum Masters, product owner. But when we're talking about these things like outsourcing and and, you know, these different decisions that might be around building bridges, you talk about So partnerships or acquisition, right, and how that might benefit, how do you see that working? So we have all these decisions that need to be made, and we're talking about cross functional teams, but it is not just the teams make these decisions. So what does product leadership, or what does leadership in general, look like in Agile product operating model?

Dave West: 16:53

I really do believe that ultimately, if you do Agile product model, evidence based approach, effectively, you do align everything around products and and you deliver them, you build operations, or you operate them, you maintain them all in this way and leadership or drives that. But there is a there's a couple of important fundamentals that we still are wrestling with in the last probably 30 years, the world has moved from the oil and mass production age to the digital age, right? And the reality is that digital is a fundamental responsibility of everybody in an organization now, not just a small group of people that you know used to play Dungeons and Dragons and didn't go out much. It is now mainstream. And the distinction, you know, when is it? Forrester Research talked about BT Business Technology. Stop talking about it. It's not information technology. It's business technology. The distinction between technology and the business is still, in many organizations, very distinct for lots of reasons, you know, around cost, around risk, around just those people are weird, and we don't want to invite them to our parties. The we can't afford that to happen. And I really hope you know whether maybe this is just a false desire that we can bring everybody into this and using product as a unifying mechanism, so that we have people that do specialize in maybe, maybe working for a bank, financial, finance stuff, understand derivatives, understand all of that stuff that I really don't or have a cursory understanding of, and we bring those together with technologists that have a great understanding of the technology that we can use to redeploy that, and then people that have a great understanding of how to build products for customers, and a great understanding of UX and design and a great understanding of data and analytics. We bring those all together in pursuit of value and and I think that leadership ultimately has to understand technology and digital to be effective in this modern age and and it's funny when you I get the opportunity to meet a lot of leaders, and you see organizations that ultimately have that their leaders are invested in the technology that supports the products that they're delivering and then ones that aren't. And I think that the decision making processes in those organizations are much slower. But ultimately, leadership has to have a good understanding technology and then set goals direction strategy in those effective ways, and then push down as much of the day to day as possible based on those goals, and not get involved in things that it shouldn't. So you need to have a very clear sort of separation of of goals and strategy Direct. Action from execution. Yes, these, but they need to and then they need to report together, and then they need to all be going in the same direction, but they're influenced by each other. Because we have a rambling answer, not sure I answered it, but we still still going to have leaders. Leaders need to get technology. Need to work in goals and provide direction. Teams need to be empowered to make decisions, I think is the clip notes,

Patricia Kong: 20:23

yeah, I think you were talking a lot about vision and thinking about what happens in the future, and working with teams to create a manifestation of that vision. Yeah,

Dave West: 20:32

yes, exactly, and but empowering them to make the decisions on that, not you know, like even.scrum.org Imagine me telling you what to do Trish, it would be an impossible task. I can, however, as proven on a day to day basis, I proved that, but, but, but having clear directional goals is is crucial to us being able to effectively work together and deliver value to the scrum.

Patricia Kong: 21:02

And I think, I think, you know, beyond scrum.org but also in Agile. And of course, Scrum, we have the notion of of boundaries. And so that's what, where you talk about the teams working together and thinking about those products, you are talking about setting products, product boundaries, but even within the process of working. That's why we have sprints. That's why we have a definition of Done. That's why we have these other things that let us say yes or no, and that's where what that's how boundaries help, and that's something that leadership can certainly help with in setting parameters. So Dave, what's next for your thoughts on the Agile product, operating model?

Dave West: 21:45

Gosh, I don't know. I mean, it seems to have been received quite nicely across many different people and lots of great feedback. My next job is to try to distill some of this feedback and keep writing about it, and keep asking the questions, and keep visiting companies that are doing elements of it, all of it, bits of it. There's a lot of amazing companies in this world that are doing elements of it. You know, I didn't invent any of this. I just sort of harvested it from, you know, lots of different experiences or that I'd seen. I think it's important that we start building effective bridges to the product product management community, because I think we can work together in solving these problems and delivering more value to our customers, our joint customers. I think it's important that we start improving and refining our understanding of exactly what are the elements of this model, what are the, what are the I don't think we can actually say it's this, but I think what we can say is it has to conform to these principles, or you're going to have these issues. You know, whether it's like decoupling work management from people management, that seems to be a principle that seems to be working very effectively in organizations. Why is that important? Well, for you know, for these reasons around when we build a cross functional team that doesn't have all the skills you have to support organize, and I'm not going to go into details, but, but the bottom line is, we've got starting to build these principles, these ideas. We need to validate them, and then over time, refine them and improve them, and then ultimately, all of us need to come together and make progress towards it and and the only way we do that is empirically for experience.

Patricia Kong: 23:28

On that note, thank you everyone, and thank you Dave for answering all these questions from your webinar about the Agile product operating model. But thank you everyone. Thank you Dave.

Dave West: 23:40

Thank you. You.