Scaling Done Right 07: Where There Is Unity, There Is Victory

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. Let's talk a little bit about ocd. Um, not that one. By OCD I mean organizational coordination disorder. What do I mean by that is? Leadership puts enormous amount of effort in devising strategies that will enable the organization to thrive, well, survive. They lay out those big visions and it's almost painful to behold. They gather all sorts of resources to make that vision a reality and, and they try their best to support that endeavor. So what happens? Well, you probably know the answer, right? If you're lucky, nothing. If you're not lucky, probably some really bad stuff. But overall, that's the result. One would be forgiven for thinking this is what decentralized decision making would look like. But that's the opposite of what we want. We want to to push decision making as far as possible to the front lines. Because it's only there that enough context and bandwidth exist to make quick and appropriate decisions. However, we also need a harness that ensures that the decentralized decision making aligns, uh, with what the organization is aiming to achieve. Moving in unit becomes even more urgent if we truly aim to achieve business agility. It is only when we can harmonize the decentralized decision making in the teams with the intent of senior leadership that we can achieve real business agility. Imagine an organization that moves like your body. You hear unexpected noise in the environment, your whole body turns into that direction to assess, uh, the situation and address possible threats. How great would be if your organization did the same? Isn't it flexibility? Reacting to changes in the environment without friction, discussion or delay. Just a seamless, unnatural, uh, response. Would that not be true agility? This is the promise of Scrum at scale. And it's easy to grasp how powerful business agility is. In Scrum at scale, several components of the product owner cycle work together to achieve this objective. Leadership sets a strategic vision where it would like to see the organization go. Guided by that vision, the same leadership team then prioritizes its strategic initiatives at a very high level. The most important ones are then decomposed, um, and refined over several steps that will result into ready user stories that the teams can work on. This process is critical in connecting leadership with the teams doing the work. Without it, teams will not be pulling in the same direction. And even worse, they may not be pulling at all or pulling in opposite directions. Everything should start with uh, a vision. Think about Kennedy, early 60s. We will land a man on the moon and return him safely to the earth. Big Vision it lays where leadership sees the organization in a couple years is a reflection of ambition, context of markets, competition and environment. The fact is vision is needed to harmonize leadership intent and merely engaging on the process of developing a vision is often very beneficial. Let's talk a little bit about strategic backlog prioritization. There is a Russian proverb that says if you chase two rabbits, you'll not catch either one. With a AH vision in hand, leadership has now to prioritize the strategic initiatives that will allow the organization to realize that vision. That's where leadership tends to fail. It's very common to see dozens, if not hundreds of products and initiatives to be pursued at the same time. Prioritization requires a lot of discipline and is very hard to do no matter if you are a frontline product owner or a product manager at the very top. I have some bad memories from a time past when out of a list of 50 priority items I got 47. 47 I kid you not marked as priority one. Since that day I have been adamant about not using the word prioritization. I prefer ordering or ranking at the highest level of the product owner organization. There is a SCRUM team named EMS Executive Meta Scrum and that team is led by a terminal Chief Product owner. The Executive metascrum is what we meant by all the references to leadership early in this podcast. The EMS creates the overarching product vision and generates a single backlog for the whole organization. From that backlog product flows all the way to individual teams. The EMS team is the most influential in all of Scrum at scale. They decide which products to launch and which ones to retire. They also decide on funding the initiatives and products as well as refactoring in the organization so those priorities can be achieved. Who should be part of the EMS depends entirely on its function and your specific context. By now, since you have more insight on what the EMS is responsible for, it becomes clearer. Who should be on it? Do we need the Chief Financial Officer on the team? Absolutely, as financing the initiatives is critical. Should we have People Operations HR leadership on the team? Maybe not. It would probably make more sense for the Head of People operations to be in the EAT Executive Action team. It's also important to note once more that we're not really married to the naming convention. Use the name that works better for you. I have encountered things such as AH Portfolio Team, Executive Product Team. As long as the function is being performed, the naming is up to you. We now know that the highest instance of the product owner organization is the EMS which is a cross functional team being led by the terminal Chief Product owner. At the other end of the spectrum, the role of the team product owner has not changed. They're still responsible for setting priorities, managing the backlog and being the non stable interface of the team towards the stakeholders. Due to the fractal nature of Scrum at scale, every team of teams also is a Scrum team and therefore is going to need a product owner. That product owner will coordinate the work of all of the teams in his or her team of teams and that product owner is referred as the Chief Product Owner cpo. We can repeat this pattern as many times as needed to either add a team or teams of teams. The larger the organization and the higher the Chief PO is in the network of teams, the broader the view where the Chief PO of a Scrum of Scrums team of teams might work with his or her product owners to decompose epics into user stories. The Chief Chief Chief Product Owner of a Scrum of Scrums of Scrums of scrums might work on decomposing a product into components to what we have seen on the Scrum Master side. Since we are talking about the same teams after all, we will have product owners with increasing levels of teams. These are often denoted as Chief Chief product owner or level 2PO or PO2. As always you may use different names as long as the function is fulfilled. By properly aligning the organization around leadership's intention, we avoid the organizational coordination disorder and we can move as one. 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 kyo@raskere.com and to geryon@teamflow.net. thank you.