Five Signs Your Product Owner is Failing the Team with Ralph Jocham

Discover the hidden landmines in the role of a product owner with the wisdom of Ralph Jokum, all the way from the picturesque city of Bern, Switzerland. Imagine transforming potential pitfalls into stepping stones toward success as we unravel the top five warning signs that a product owner may be veering off course. Ralph, with his expertise as a Professional Scrum Trainer, joins me, Mark Metze, to highlight the significance of learning and validation, and the dangers of assuming you have all the answers. Together, we dissect the complex balancing act of effective stakeholder management and the necessity of delivering product increments that truly resonate with customer needs.

The journey through the Agile Within takes a turn into the realm of Minimum Viable Products, where we bust the myths surrounding MVPs. We demystify its role not as a substandard product, but as a powerful hypothesis validation tool. Ralph and I navigate the intricacies of stakeholder engagement, laying out a blueprint for product owners to align their vision with each stakeholder category's unique interests and expectations. We champion the Agile philosophy where tangible working products speak louder than any project metrics, and we share the secrets to harnessing short feedback loops for unparalleled business agility.

Wrapping up an episode brimming with actionable insights, we cast the spotlight on crafting sprint goals that ignite developer motivation and lead to transformative sprint reviews. The art of negotiation within sprint planning is a dance we all must learn, and Ralph and I discuss the vital collaboration between developers and product owners to overcome the inevitable challenges in creating impactful technology. Say goodbye to PowerPoint presentations in sprint reviews and hello to outcome-driven goals. Be sure to tune in for this masterclass on fostering a collaborative environment that puts a human touch at the forefront of technological advancement.

Connect with Ralph!

LinkedIn:
https://www.linkedin.com/in/ralphjocham

Email:
ralph.jocham@effectiveagile.com

Ralph's Company- Effective Agile:
effectiveagile.com

Schedule a Scrum.org course with Ralph:
https://www.scrum.org/classes?uid=110

The Professional Product Owner book:
https://www.amazon.com/Professional-Product-Owner-Leveraging-Competitive-ebook/dp/B07D5ZPJBY

Transcript

Speaker 1: 0:06

Welcome to the Agile Within. I am your host, mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rockin'. The Agile Within starts now. Welcome back to the Agile Within. This is your host, mark Metz. We're in the middle of winter here. So for those in the northern hemisphere, we have winter. Those in the southern hemisphere, you're in the middle of summer we have. Our guest today is Ralph Jokum. He comes from Bern, switzerland. Ralph is a professional scrum trainer with scrumorg. He's co-authored the professional product owner book in the professional scrum series, also by scrumorg. He has worked closely with none other than Ken Schwaeber in the past. So, ralph, welcome to the Agile Within.

Speaker 2: 1:23

Welcome. Thanks for having me, oh yeah.

Speaker 1: 1:26

So, ralph, let me ask you if I was coming to Bern, switzerland, what would you say would be the one thing that I absolutely had to do when I came to visit?

Speaker 2: 1:41

Bern is recognized by the UNESCO as a World Heritage Place. It has this beautiful old city center which is dating back to the 15th century. Think about cobblestone alleys, old buildings, towers. So if you spend about 30 minutes on the so Bern is surrounded by the Aare River, it's a little bit like a peninsula. And if you spend about half an hour on this peninsula just walking around those aisles, you will be amazed with just the richness of building and history you have there in downtown. Well, sign me up.

Speaker 1: 2:31

Do you have a guest room available?

Speaker 2: 2:34

I have one. Yeah, if you ever come over here, I'm happy to host you.

Speaker 1: 2:38

Awesome, sign me up, okay. Well, let's move on to our topic for today. So Ralph is going to talk to us about five signs for failure as a product owner, so I'm really interested to hear about these. So, ralph, give us a little background, okay.

Speaker 2: 3:01

So there's probably many, many things you can be doing wrong, but for me as a product owner, or talking to other product owners or observing what's happening in the industry, these are the things which I would say stick out the most and for me, kind of just going through them here quickly and then drilling down further later on. Now, if you think you know the answer, you don't. As a product owner, you are the catalystator to make a good product happen, and we look into this later on. Not being really good about stakeholder management, that's the next point. So I really think you should have all of your stakeholders understood and for me, like a headcount wise, I'm looking at 10 somewhere around that Not really being empirical, and this goes back to understanding complexity, complexity theory being driven by experimentation and learning. The other thing this is now shifting a little bit over from product discovery then also maybe to product delivery. Not being able to deliver vertical slices of product done. Increment every sprint house Chrome likes to call it.

Speaker 2: 4:17

And last but not least and that's what I often see is not having a good outcome oriented sprint goal. I see far too often shopping list as a sprint goal.

Speaker 1: 4:29

Shopping list like a grocery list.

Speaker 2: 4:32

Exactly.

Speaker 1: 4:36

All right, well, good, well, why don't we just jump right in? Why don't you talk to us about the first, where you think you know the answer?

Speaker 2: 4:45

Now this goes a little bit back. So Don and I did the book we wrote, so we have it broken down into three main areas vision, value, validation. So it's really about you know, what is it, what we want to achieve, what is our, our main objective, division. And then we try to drill down into what is valuable in that we got valuable in learnings, but also in customer outcomes. What do they really need as features? And maybe also value and learning. How can we find out quickly what is the best thing to do for us, thinking along the lines of linear, x or lean startup, and then, basically, once you have it, how can we validate that it actually is the right thing? And this is really where metrics and measurements come into the picture, not hard evidence.

Speaker 2: 5:37

So now going back to thinking, you know the answer, you don't. I mean, sure, you look at the problem and you have a good idea, but usually your idea might be right, could be right, but often the intuition is right, but the details are not there yet. So there's so many other things you need to investigate, find out, and for me, this really boils down to really understanding your stakeholders, and stakeholders are not just users. There are other people out there as well, and in this regard, right now, it's really looking at understanding. For whom are you working?

Speaker 2: 6:17

And I think you really should be obsessed with the problem you're going to solve, less with the solution. It's like well, this is the thing I'm going to fix, this is the thing by improving and make some people's lives better, and then you engage with them. And once you go ahead with this, it's really when you go into this journey of product discovery and the product discoveries in regards around is the problem I have identified, or thought I have identified. For those users, is it actually worthwhile to fix? Often we have situations where there's really good workarounds in place. Maybe they're even free. So why would people actually purchase something if there's a viable workaround available?

Speaker 1: 7:14

So I got to ask you, Ralph, are there some techniques? What strategies have you used when you've seen product owners in the past that start with a solution? How do you help them turn that around into a problem?

Speaker 2: 7:35

Now I have to say I mean this is going back to the probably overused quote, but I still think it's a good quote from Henry Ford. If I would have asked people what they want, the answer would have been faster horses. And no, the answer wasn't faster horses. I mean, there are so many problems around having horses in the cities and things like that with Aldi, manua and so on. It's really now with the users.

Speaker 2: 8:04

For me, this product discovery and for this there are so many techniques and ways to think out there, like the lean startup and a lean UX.

Speaker 2: 8:15

So essentially, this is when you can really think along what could be a minimum viable product, because you have an idea, you have a hypothesis, and how could I validate this hypothesis as quickly as possible to make sure I'm actually on the right path? And this is where you would then go ahead and collaborate with your users or anticipated users as much as possible to find out how well does this work? Do you like that? And then I get feedback and this is really when I like to think about along the lines of the Constable's truth curve, like how much am I willing to invest in order to learn? I can do a quick paper prototype and show it to someone just to say, hey, how do you think about that? Maybe I say, nah, this is not good. Well, good, I mean, you only lost maybe 20 bucks doing this drawing because you quickly, and then you could maybe go a full featured MVP like a landing page or feature fake or something like that.

Speaker 2: 9:16

And this is more investment, maybe looking at a couple of thousands already, and then they will tell you again nah, it's not really what I wanted. But again you can ask a meeting for conversation why, what would you like to have different? And by doing this you would learn. And then you can kind of you would going along this way, you would then discover kind of what really is the underlying problem understanding the user's perspective. Go ahead, mark. I think you have a question coming up.

Speaker 1: 9:51

More of an observation. So one of the I guess one of the aspects of hosting a podcast that I really enjoy are the observations that I can steal and the ideas that I can steal, okay, and use later. And I like the term investment because so when I think of investment, I think of investment. You know, I'm thinking of, like my retirement, and I'm thinking, you know, how do I want to invest for my retirement? Do I want to make a big bet or a big investment in one area, in one stock, in one fund, in one area? No, no, I want to test several different areas to see which one that I want. So I'm going to use that term. Going forward about investment, what kind of investment do we want to make, upfront, to learn? Do we want to make a large one? And if we're wrong, well, guess what? That wasn't a very good investment.

Speaker 2: 10:57

Exactly. It's like putting all your retirement money into one stock and if this thing, whatever tanks, you have lost a lot of money. And if you think along those lines of running those experiments, you can run several, probably also in parallel, and then you would see okay, this looks good. Oh no, this didn't work out at all. Let's just park this for now. Let's drill down further over there.

Speaker 2: 11:22

And by doing this you really kind of established this feedback loop we are looking for and for me the important thing is I just want to clarify one thing and this is something which is dear to my heart, because I really like MVPs but the majority of the people do not really understand what an MVP is all about. I often think it's the crappiest product you could get away with, and it is not that. It's just a vehicle to validate our hypothesis you have. It could be a video, it could be a paper prototype, it could be a feature fake, it could be so many things, but it doesn't mean it is a full feature product you're going to release.

Speaker 1: 12:01

Well, it's up to us and how we advertise and how we market an MVP. So we should be clarifying what an MVP is to our stakeholders, because if we just assume that they understand what an MVP is, they may have a and I've seen this, I know you have seen this. Mvp means you're done right, it's shippable, and stakeholders are happy with everything, and now it's just a matter of cleaning things up around the edges. So clarifying what you mean by an MVP is imperative.

Speaker 2: 12:45

Absolutely. I mean this goes back to leadership kind of, because it's all about creating clarity. Maybe it would be a good meeting to sit down with stakeholders and say you know, we probably used the word MVP or maybe some other acronyms or terms, and let's just agree on what we really mean with that. Otherwise we would listen to each other, understand, would hear each other, but we wouldn't understand each other really what we are talking about.

Speaker 1: 13:13

Well, I think it's a good segue to get into your second failing there about the empirical process.

Speaker 2: 13:22

Yeah, but before we do that, let's just have a quick talk about the stakeholders here quickly, because at the end of today, I think as a product owner, you are there to make your stakeholders happy and usually the way you can think about it is therefore categories of stakeholders. You have users, obviously, but then you have also people. They have a big influence into your product. They could be internal, important people, but also external influences, as we use them to term often today. Then the next category is provider. So these are could be internal, external as well, where we depend on up from them. If they wouldn't deliver, we would have a problem. It could be a technical component, it could be maybe some other skills we need, and so on.

Speaker 2: 14:10

And then governance. These days we have so many laws and regulations we need to follow Saban's Oxley. Data protection in Europe is very big, but maybe you have internal governance as well, where you need to provide certain numbers every month. So maybe at the end of every spend and in the end of the day, it's really finding out where are my stakeholders Maybe we really sit down and write down the name of the person. What then? And maybe even think about, along the stakeholder metrics, what is the interest in what we are doing? Is it high, is it low? And what is the influence Is it high or is it low? And then maybe come up with a good stakeholder strategy for those individual people and make sure that you cope with them accordingly, so that they hopefully won't step you in the back or something like that, that you have them on your side.

Speaker 1: 15:05

Figuratively speaking right.

Speaker 2: 15:07

Yes, yes, yes I mean, but sometimes you have some people that just don't like what you're doing with your product and you're just waiting for the opportunity. And if you think about it the way, you can hopefully be more proactive about it. And so, essentially, if you take this together, like vision, value validation, so you don't know what you really need to do yet, and then thinking along the lines of your stakeholders, so you would basically try to bring all of that together. And now this is really then when the empirical process, control Comes into the picture, and this empirical essentially means guided by experimentation and learning. And this really brings us back to those quick feedback loops we really want to establish, because I believe that as an organization, you have to take risks.

Speaker 2: 16:04

If you don't take educated, good risks, you will just disappear in the big lake of mediocrity. But those risks there should be worthwhile to undertake. And for me, one of the important elements if you think about business agility is to make sure, or agility overall. But now, in regards to business agility is to if we manage to compress the time between making a failure, making a mistake and learning from that. If this is really a short time frame, then it becomes cheap and then we can experiment more frequently and by doing that we can adjust as we go. And this is then really where it takes you out of out of your project mindset into a product mindset, because you will build the product. It's what if an incremental, sprint by sprint, and not have this project plan you need to follow, because somebody wrote down a year ago this is what you do three months into the project.

Speaker 1: 17:12

Reminds me I like of the 12 principles from the agile manifesto. I'm not quoting it word for word, but I really like the, the principle that says that that the ultimate measure of product of progress is a working product, not a Gantt chart. Right where 60% done, how many projects have you been in the past where you're 90% done? In that last 10% takes a majority of the time to get to be completed? Right, exactly yes.

Speaker 2: 17:47

Yeah, working product and this is really something I was tried to really other route. It's like working product is the only honest, true measure of progress.

Speaker 1: 17:56

It doesn't lie. Well, I guess it can. You could have some levers and switches in the background where you're not not telling, but but yeah, it really is You're. You're proving that you've done what you said. You've done, yeah, what you said you've done yeah.

Speaker 2: 18:18

One of the other part about yeah, sorry I was interrupting you, mark. Good, no, but for me kind of like this is because one of the other points is that you're not able to deliver vertical slice of product Essentially every sprint, and because this is the, the piece of functionality. It's not the whole product but it's one one slice, kind of really from the top to the very bottom, kind of connecting all the Technologies which are involved, let's say user interface, business logic, domain logic, database or whatever you build the idea.

Speaker 1: 18:56

So wish to say so, ralph, let me ask you and I'm just basing this off my own experience, but I'm a former developer and I feel like I've been a developer for a while a developer like 19 years and I've been in management and in a scrum master role for Twelve years 13 years so I think I have a decent amount of experience, and it seems like this is a tough hurdle for developers and engineers to get over slicing work vertically. Why is that?

Speaker 2: 19:42

This is a I'm just mean. I used to be a programmer as well, so I have experienced as well, and I think there's several forces at play. So one is mindset, the mental model of the developers because you have probably been educated, trained when you were studying, going to university about this is how you do you divide in conca and then you integrate. Then suddenly integration takes longer than the original development or something like that, and I think this is one thing is kind of become, this is mental ballast in that regard that we believe. And then also organizational structures is often counter to that as well. You might have a database team and then you have a front end team or department and something else. And if you, if you go, really go to to vertical slices, that requires you have to have a cross functional team, you have to have all those skills working together, collaborating, and if you don't have that, you won't get to vertical slices. And then it seems hard if you think about it, a vertical as a project manager, essentially what you do is you do horizontal integration. You bring the different Elements from the different departments together To form that product, and this is the same thing I think was vertical slices. You have to have this one. In this case it would be vertical integration. But you have to make sure all of those things work together.

Speaker 2: 21:13

And if you bring in all those skills together and if you and I think this is where training comes into the pictures well, if those developers you just need one developer just know, guys, your time just doesn't work Now. You just don't know how it works. Yet I'll show you and you have this one person and they show it to the developers how this works. And this is this big Eureka moment where I get big wow, this is cool. I never saw this before, but it's really awesome, amazing. And then, once you have them on that hook, they able to do that, going forward.

Speaker 2: 21:47

And Once you have this Achieved, essentially, by doing this you help the team to become cross functional, or, if they already got, but how do? How they can collaborate on a cross functional way. But then also this is the beginning point because suddenly you realize, oh, engineering practices we have under the hood as well, they're not as great For working in that way. And then suddenly you start to set up maybe your first continuous integration system. You build pipelines, you have your test automation in place and all of that, and this is only possible because this is only doable now, having really kind of a build pipeline set up if you work in vertical slices.

Speaker 1: 22:37

So how about those teams, ralph, that would that come up and say, okay, I understand the concept of building vertical slices, but it's going to take a lot longer for me to develop that. It's much easier for me to to focus and, let's say, just develop the entire API, the entire database layer, or the develop the entire database, or do all of the front end work together, as opposed to me having to split this up to do all this to work together incrementally. It takes longer to do that. What would you? I'm kind of setting you up here we didn't talk about this before but what would you tell teams that that have that response to you?

Speaker 2: 23:35

Well, there's, there's out there so many things I can talk about. So you have two kinds of efficiencies. You have resource efficiencies and that's what I'm hearing here right now, while it's not efficient if I do this and this and this in parallel, kind of. But then you have also flow efficiency. Now, flow efficiency is what provides customer outcome. Otherwise, you just have shelves or hard drives or whatever you have these days full of inventory. You know, partly done work.

Speaker 2: 24:06

So the first thing you always need to get optimized is flow efficiency. I have a great idea how long does it take until the customer has it in their hands? Now we're taking days, weeks, month. Now once and this is this is really when you run into all of those, those comp problems you have like, oh well, we have all those different departments and we wait for them. Okay, maybe we should just sort of people together into one team room and they can start to collaborate. And then, and once you have the flow efficiency understood and that works well, then move up and try to optimize your resource efficiency.

Speaker 2: 24:44

But it's a second thought, not your first thought, and usually in every organization with resource efficiency always comes first. So you have and there's Akhov, he's a really used the past, but either in one of his books he writes about three observations, three facts. Basically like if you optimize a system, you optimize one, this optimize or sub optimize one of its components or more. If you optimize all the components, you will sub optimize the system. And then there's the third rule that basically every component can behave, be large enough that it follows the same rules. Again like this recursive thinking here.

Speaker 2: 25:28

So, the first rule which you need to follow, basically by into, is the rule number one is that you need to optimize the system, even at the price of sub optimizing one or maybe more of those subsystems. Maybe in this case it could be a component. And if you do that, if you realize that, you will be open for flow efficiency and then you suddenly quickly the delivering customer outcome, value, company impact, making money, and once you have that, you can think about okay, how can we now streamline this whole process and make it much more resource efficient?

Speaker 1: 26:05

So, would you say, is it a valid question, then, in this situation, to ask if you have a team that does have that attitude, to ask well, who are we optimizing for? Are we trying to optimize for ourselves, or are we trying to optimize for our stakeholders and our customers?

Speaker 2: 26:27

I think that would be a fair question, and I would probably answer this question also with the sprint review. So who's going to show up at our sprint review? Is it the end user or is it the people from the other teams which are depending on our work? Because we are just one small element in a whole longer stream of steps and processes. Now, again, if you have scrum set up correctly, you would hopefully have customers, users and other stakeholders invited for your sprint review.

Speaker 2: 27:00

Now, suddenly, this is an unpleasant feeling for a developer to be there and basically have nothing to show, because you just did some database tables.

Speaker 2: 27:10

And so I have one really simple rule for my sprint reviews no PowerPoint. Unless you work for Microsoft and you build PowerPoint, then you show it for sure, but no PowerPoint. Now this changes the game, because what do you show if you don't show how well you can work with that tool? Maybe you should show working product which people can really play around with and do something. And then you tell you this is not everything yet. This is just this one small slice of functionality, but we want you to experience it. We want you to tell us what you like about it, what you hate about it, so that we can take that information and improve our decisions down the road. That brings us basically back to really using an empirical process control being guided by experimentation and learning, and by doing this again, we compressed the time between making a mistake, learning from it and being able to fix it down to the length of one sprint in say two weeks.

Speaker 1: 28:13

Nice, okay, I think we're. Are we at our last sign of failure as a product owner?

Speaker 2: 28:25

Yes, so that's for me and it's really a trivial one, but there's so much, there's so much meaning to it. Like, if I see a sprint goal which is a shopping list, it's usually an indication that so many other things are wrong. For me, this is really the tip of the iceberg, and then you can really kind of start to roll down, and what I often see is that the sprint goal is a shopping list is that this is not really about outcomes. This is more about outputs. We do this and this and this, and that is usually often the reason because this team is not really dedicated for one product, and that opens a totally different kind of worms, essentially because what I often see is that things are labeled as a product even though they aren't.

Speaker 2: 29:21

They're a component and, for me, a product. It really is something which is customer facing and has a P and L. Everything else is a component or a platform. In the end of the day, if you think about it, a component is just a tiny platform. If you think about it Now.

Speaker 2: 29:42

If this is the case, then this one team would probably have to work on several components in the same sprint. Now, if this is the case, they can't really commit to one sprint goal because they would say normally say well, by the end of the sprint, we want to be able to invoice past services automatically via PDF sent to the customer by email 30 days after we provided the service. Now, this is value, instead of doing this manually. We just know the system is not doing this automatically, maybe even updates us that something has been sent out and it wasn't paid in a specific timeframe. This is outcome. It makes our lives easier. But now, if you see a sprint goal, well, let's do something over there, let's fix this over there, and then this product, we do this. This is often, then, the indication that they have to do many, many things in parallel, because they can't really commit to one customer outcome. Now, how do you measure something like this. Well, then you go ahead like well, if we do a relative estimation, we can do that. Say 30 story points per sprint, and suddenly you start to measure velocity. Now velocity is output focus, not outcome focus. I can deliver every sprint 30 points and still fail as a company If I built the wrong things, if it's not the right event all over the place. This is really.

Speaker 2: 31:11

Then when you start to think in the sprint goal as outcome oriented, then the measurement should be more along the lines Well, we thought that if we automatically generate those invoices and send them out, we would get paid early, on average by hand days. That means our cash flow would improve by so many things. Then these would be the things you would be measuring. Then you would know yes, we achieved what we were aiming for. Great. Or you would learn from it. Oh well, it was only so many percent, so it wasn't really bad, but not as effective as we thought it would be. What can you learn from that? Is there anything else we want to do about that?

Speaker 2: 31:54

But then the other thing if you think about it, if you don't have a clear sprint goal, now in Scrum we have the Scrum values. One of them is commitment. Now, developers will not commit to a shopping list. They will probably because they know already this is a shopping list for so many different things we have to do in parallel, and this will change throughout this sprint anyway. So let's get ready with our excuses, maybe to think about this along sprint planning already, but if you have a good outcome, they will commit to that, say this is cool, this is. Let's make that happen. Once they're committed, get out of their way and let them focus on other Scrum values so that they can really do a good job in what they're going, what they're trying to achieve Now and then, if these developers walk into this sprint review and they show their audience, the stakeholders, what they have created and they're like wow, this is cool, you did it in one sprint, you're good. This is so much rewarding, this is really powerful.

Speaker 1: 33:07

So I'm going to make a statement and let you critique or let you either validate or correct me. So I'm channeling my inner Martin Dalmine, if you know who I'm speaking about. He talks a lot about sprint goals and we like to come into sprint planning with a draft sprint goal, something that we think this could be something that we want to complete by the end of the sprint. Like you say, it's outcome oriented, not output oriented. Then, whatever measure we use whether we use story points and velocity, or if we're using throughput, whatever you use you use to try to figure out how much work can be pulled in. So you use your draft sprint goal, you figure out how much work can you can bring in, and then this is the point of negotiation that comes into play.

Speaker 1: 34:17

Well, we said our sprint goal was going to be we're going to allow for a secure sign-in to our site, but not sure, based on our throughput, how much work we can bring in. So let's negotiate what the sprint goal really should be, and maybe it's well. We're only going to allow a secure sign-in for this type of user, because these other three users, they're going to be much more complicated. So we're going to have to tackle that in a future sprint. That's the practice that I normally follow, and what the the any pattern that typically comes into play that I'm having to ward off is let's see what work we can bring in, and after you figure out what work can bring in, okay, now how can we craft a sprint goal based on the work that we're going to bring in? That usually is a case for chaos.

Speaker 2: 35:21

Okay.

Speaker 1: 35:24

So I think we that was a long-winded, that was a pretty long-winded statement, wasn't it Exactly?

Speaker 2: 35:31

And it was a long question and I have the question kind of what you're asking for understood correctly. Now, what's so? The sprint goal is, for lack of a better word, for me here right now, it's like a negotiation between developers and product owner. Now, as the product owner, you cannot just demand I want this, I don't care how you do it, make it happen, because the developers, they, will not commit to that. So it's like I have this problem. How could we fix that? And then we talk about this, and now you mentioned this draft sprint goal and, yes, I think I personally like this as well. And but this goes even a step further, and this is really for me. When you have to establish a good product backlog refinement, when you talk about this, like again going back to this empirical process control, let's say we are in this sprint right now and, assuming everything works out, what would be the next valuable outcome we could create while we could do?

Speaker 2: 36:28

this thing on sign on, okay, great, so let's talk about this, while we have five different categories of users, and okay, what does this mean? Well, actually, this one here, this group, seems to be easiest to do. Okay, good. So, work wise, how well, that should fit into a sprint. Maybe a little bit more, but right now it should. Yeah, this one, we think we can commit to that. Great, let's break it down a little bit, let's get a better understanding about that so that we don't have to cross every T and dot every I. It's more like it feels like our professional experience tells us well, it looks very, very likely that we can complete that.

Speaker 2: 37:09

Now, this is the mindset. I want to go into a sprint planning and once we have that, we just essentially have to make sure everything is still valid in the same way we we assumed when we talked about it. Maybe something has changed in the meantime. Okay, let's look at this. What is the impact of that? Does this change anything? Because we work in the complex, so we have always the unknown, unknown, so things will go wrong. Maybe we had the sprint review just the evening before and somebody else brought some valid point up and just say, gosh, we didn't think about that. Yeah, we need to now considering that in the sprint planning again. You would talk through that.

Speaker 2: 37:56

And this is really the, I think, the really important aspect the strong collaboration between developers and product owners. And this could be a little bit of haggling. We could do this, we could do that, but it should always be driven by the same motivation, by the same goal we want to achieve. And this is how you discover that, instead of this, we could do that, and this is not as good as this solution we are aiming for, but it's only half the work, and if we do this, this would still work, and then later on we might go back if we see a need, and then polish it up, make it much, much, make it perfect. Right now, this is good enough.

Speaker 1: 38:35

That negotiation. I want to stop and just talk about that for just a minute, ralph, because that doesn't always come naturally, in my experience, from the developers, and maybe it's a learned behavior. I'm not sure, but more times than not, developers can seem to have an order-taker mentality from the product owner, and even when it's presented as OK, this is a draft, what do you think it's like? Ok, I'm just here to make you happy, so if that's what you think we should do, then let's go for it. Maybe talk to us about some ways to stimulate the developers so that they are comfortable with negotiating and speaking up for what makes sense.

Speaker 2: 39:37

Now in this Chrome guide it states all the things the program is doing and then the product owner what was the phrase exactly? Again, so the product owner may do the above work or may delegate the responsibility to others. Regardless, the product owner remains accountable. And this is really something I think is such a powerful sentence in this Chrome guide. Because, as a product owner, yes, in the end of the day, when something goes wrong with the product, it's your neck sticking out. Essentially you are the only one accountable for that. But if you manage to delegate responsibility in a meaningful way and this goes back to when I even think along the lines of product leadership because as a good product owner, you provide the clarity that people understand why this product is so important, through the vision of the product, through a clearly crafted product goal and the things you will be looking out for, the measurements you are hoping for once all of this has been implemented and released into the hands of the user. Now, once they have that understood the developers they are much more. They have a better understanding about the product. They're not just auto-takers anymore, they participate in that, and this really ties them all the back with the refinement Say hey, people. I have this problem. I have some ideas, but before I share my ideas with you, what do you think? What would you do Now?

Speaker 2: 41:00

Developers are very intelligent and they have often a really good understanding about the domain because they're reverse-engineered for years. They see how things are intertwined and connected and they can really leverage that. So talk to them. And now we use often user stories, but nobody really knows the definition of a user story. It's a promise for a conversation to take place.

Speaker 2: 41:24

So the narrative behind every feature, or maybe even the narrative behind the product, is so powerful. And narratives are a really good way to cope with complexity, because complexity cannot really put into a box with rules and descriptions. It's really about context. Context is king in that situation. So provide the context, empower the developers, go into a conversation with them, challenge them, but also make it clear that you want to be challenged in your thoughts and everything like that. And I think for me, the final really powerful thing you can do in that regard is to say, hey, are these conversations, as a product owner, to your developers, are these conversations really valuable? And maybe they'll say, yes, this is great, this is really good, this helps us. So why don't you write anything down Now? Have the developers create the product backlog items themselves.

Speaker 2: 42:15

Because, they need to read them. The next story they sprint after and understand what it meant. And this really goes back to the definition of a user story. It's a promise for a conversation. The card is the placeholder. Think about it like a photo from a past vacation. If I look at this photo, I remember that very day. If I show it to someone else, they see a beach and a boat and a country. But if I look at this, I remember the funny smell in the air that we got a sunburn. We went to this restaurant in the evening. And this is the way I think about product backlog items. They're really there to trigger the memory of the developers Because we collaborated so much about it beforehand that everything is understood. We have this cognitive alignment as a whole scrum team about what needs to be done and then we do it. And if we need some documentations and other things in place for compliance and governance and so on, this is then when you would, in scrum, put your definition of done into practice.

Speaker 1: 43:16

I like the symbolism of a photo, because a photo tells a story, as opposed to trying to detail in words every single last point. Well, ralph, this has been absolutely wonderful. Five signs you're failing as a product owner. I really enjoyed this, so why don't you recap the five signs for us as we close out here?

Speaker 2: 43:54

OK, so thinking you know the answer, you don't. You, as a product owner, you are the catalysts to bring the right people, technologies, processes, whatever it takes together to make the right product happen. And it's a discovery process and then a delivery process as well Stakeholder management. Really think about who will be interested in what you be doing apart from your users. Think along the lines of users, influencers, providers and governance. Not having an empirical mindset, not really leveraging an empirical process.

Speaker 2: 44:31

Control, where we say we have to be guided by experimentation and learning so that we get out of this project mindset where we think linear, plan everything and execute on it, but get into this iterative and incremental development of the product and as it grows, sprint by sprint, through those vertical slices. Essentially and that's the next point here you, as a product owner, you should really be focusing on having those vertical slices of product, and this really entails everything, everything which is part of your product, let's say, in a software like user interface, business logic, domain logic and then persistence underneath. So you would really bring all of this together. Now, being able to do those vertical slices really requires you that you have cross-functional teams, proper setup, technology advice and all of the things. So aiming for that will really make other good elements and practices emerge and make the team work much, much more efficiently effective down the road.

Speaker 2: 45:36

And then, last but not least, sprint goals. As a product owner, I think you should always look at your sprint goals. Is this a good sprint goal? Because, if you really think about it, let's say you have a team of 70 developers and they work for two weeks. If you just look at their salary, that's lots of money you're going to spend. Do we spend it to work on a shopping list or do we work on something important which is really adding value or outcome to our users?

Speaker 1: 46:07

Great, that's awesome. All right, ralph. So as we're coming to an end here, I want to give you a chance. If our listeners want to follow up with questions or just want to connect with you, what's the best way for them to do that?

Speaker 2: 46:21

Well, I'm always happy to be contacted, so don't be shy, please reach out to me. Well, effectiveadjcom is my website, so there's lots of information on there as well, and it's also listed how you can contact me by email. And I think these days LinkedIn is also very popular, so you can find me on LinkedIn as well. Yeah, so don't be shy.

Speaker 1: 46:46

All right, we'll put that information in the show notes for everybody, make it easily available and we bring this episode to a close. So, ralph, thank you immensely for coming on and being a guest. I found this particularly helpful. I hope you all did too, and for now we're going to sign off. So until later. This has been Mark Metz. Ralph Jochum from the Agile Within. We'll see you later. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, mark Metz.