Scaling Done Right 08: Product Ownership in Scrum@Scale

Speaker A: Hello and welcome to the Scaling Done Right podcast. I am Kiu and this podcast is a companion to the book I wrote with Geryon. So what are the attributes that you expect from a good product owner? I'll give you three. Empowered, available and qualified. There are many challenges to product ownership. In my experience, I see lots of organizations investing a considerable amount of time, people and resources in their product delivery teams and infrastructure. Far less effort is applied into the product organization that leads to an experienced product ownership. Large amounts of waste. About 75% of features in a product nobody uses or seldom does. Lots of decision latency. When the product owner is not empowered, he or she has to go ask the business what he or she can do. Invisible work, things that are not in the backlog, but they are being worked on. And of course that all leads to poor return on investment. It is unfortunately very common to see product owners being given a parachute and dropped into a war zone. Their only weaponry. Well, they can write user stories. I always tell my clients that a, uh, great product owner will make the best even of a novice team. But a bad product owner will make a great team. Produce stuff like I said before, that nobody wants to buy. There is also our obsession with output. Just because you have hundreds of features in a product, it doesn't mean that you are actually achieving the main outcome, which is to have happy customers. We should strive to achieve the maximum outcome with the minimum output. I'll give you an example. I write a lot. I create lots of slides. I'm a trainer and a consultant. And I am so surprised that I end up using just a few features of both my word processor and my slide creation tool. I think how much money was involved in creating those features that I don't use, others don't use. As a matter of fact, I know very few people who do use more than maybe 15% of what's in there. So again, we were too preoccupied with output and we forgot the outcomes. All these problems that I listed, they can be easily solved. That's because they are valuable tools and methods for product ownership. The bad news? Well, they don't seem to arrive when they're the most needed in the hand of the team. Product owners, those on the front lines, they often need those tools, but they feel left alone with the same old tools that do not get the job done. And because all these dysfunctions just grow exponentially at scale, we need an efficient, professional, empowered product owner organization that will understand how these things lead to poor return on investment, low levels of satisfaction and frustration. For the teams. While Scrum at scale creates a very efficient communication structure and ways to order, decompose and refine a product or portfolio products. Scaling the product ownership will not work without knowledge of proper techniques and and principles of product ownership and product management. Unfortunately, these are usually limited to a few individuals or completely missing even in large organizations. Let's talk a little bit about something very common. They're called stretch goals. They sound cool, right? Why not be courageous and try a bit more? Promise. Stretch goals is instead of motivating the teams, they will, over time eliminate the team motivation. It will not be long before this undue pressure will cause a drop in team happiness and therefore in quality. But you can bet that will increase technical depth. Strategy goals are just good old command and control. Instead of trusting a team or group of teams to do their best, let's apply pressure on them. Unfortunately, that will backfire because it's assuming that it's possible to control other people. A far better idea than stretch goals is to use yesterday's weather. If you're not familiar with that, yesterday's weather is basically pick up the number of points that you completed in the last sprint and use that to predict how many points you're going to deliver in the following sprint. For a good measure, take the average from the last three to five sprints. If you establish this pattern very early in the minds of stakeholders, you can avoid all these discussions later on. And uh, be aware, teams that finish early accelerate faster. So you're not only going to make everybody's life much easier, but also more productive. Let's talk about technical debt. What is technical debt? Not everybody knows what it means. Well, basically it's what gets created when we do things the quick and dirty way. Why do you care as a product owner? Well, because eventually, like any debt, you have to pay for it and that creates extra effort. In other words, it's going to slow you down. It's often said the problem is not that you have technical debt. The problem, like any debt, is you accumulate too much of it. So you're going to spend a lot of time in future development fixing things that should have been done right to start with. So let's emphasize that technical debt is anything that causes rework that applies to either software, hardware or any industry that's using Scrum. In engineering, it's important to stay focused on what we call first time. Right. And limit time spent on reviews and quality control. Technical debt can be inadvertent. We didn't know how to do better. If you are a product owner in the software industry, be very aware of postponing the fixing of defects. Every time you do that you are borrowing against your future velocity. If a uh, defect is detected during a sprint, don't even bother estimating it, just fix it. It's quick, simple and uh, it will increase the quality and the velocity. I always ask my product owners when they work in the software business, do you prioritize paying the technical debt? Do you support a strategic and regular code refactoring? Do you emphasize automated testing for your teams? Do you promote continuous integration and deployment? You foster things like pair programming, all those things product owners should be very aware of that they're being done. All of them reduce technical depth and therefore increase velocity let's talk about some of the Scaled Scrum events let's start with the metascrum event. The Meta Scrum is a meeting that takes place at least once every sprint. It's a forum where chief product owners meet with leadership and key stakeholders. Those stakeholders control the critical resources such as personnel, funding and who owns the customer relationship. The metascrum exists to align on priorities, preferences and budgets. The metascrum event is run by by a terminal chief product owner, the most senior product owner in the organization, and focuses on funding, aligning the enterprise around a single backlog and which products to create or retire. As a consequence of these decisions, the organization may also have to be refactored, with teams being moved to where they are needed the most. There is no set time box for the metascrum, but when you think that most organizations have a dismal state of strategic product ownership, it makes sense to have longer meetings so there can be enough depth to the strategic decision. If you liked this podcast and you want to learn more, you can order scaling done right@scalingdoneright.com or wherever books are sold. I hope you have enjoyed our podcast for consulting, training or coaching in Agile and Lean. You can reach out to kyu@raskere.com and to geryonflow.net thank you.