Matthijs de Booij — August 7, 2019 — August 7, 2019
A very common pattern I see among Product Owners is that dependencies heavily influence the order of their Product Backlog. Think for example about other teams that need to do something before you can continue (or vice versa). Or availability of vendors or partners. Imagine that the top or your Product Backlog consists of a significant amount of these kind of items. How effective are you then at maximizing value? What is the impact of dependencies on complexity and agility? Are you empowered to reconsider or negotiate the order of these items? Or are you just told to execute them? These questions illustrate the impact dependencies have on the core of the role of Product Owner.
Where do dependencies come from?
Dependencies come in all kinds of sorts and shapes. But most of the time they originate from the same cause: the way your organization is structured. As I have explained in more detail, many organizations inherited their current organization structure from the most dominant management thinking of the previous century: Taylorism. Typical aspects are:
- Organization units based on specialization
- Division of labor
- Improving efficiency
- Focus on labor productivity
- Standardization and best practices
- Knowledge transfer via tools, processes and documentation
Taylorism makes sense when work is repetitive, predictable, and relatively simple to execute. But when we consider knowledge work, we are facing a high degree of variation and unpredictability. And on top of that, a higher need for cognitive competences to get the job done. This complexity requires a different kind of management thinking.
What can you do about dependencies?
The Scrum Guide partly answers this question:
“Development Teams are cross-functional… …Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”
In other words, eliminate dependencies. So instead of dividing labor and put it in specialized silos, put everyone who is needed to deliver value together. But in practice this is where it often becomes difficult. Because it means we have to change our current organization structure. And that impacts a lot of people, including key decision makers. When I cover this topic during my training courses, my students always ask at the end “can you please explain this to our management?”. And that is exactly what I would recommend you to do. Start with creating awareness among key decision makers. Awareness about what the strengths and limitations are of the current paradigms, structure and way of working. And awareness of possible alternatives that will help minimize dependencies. When you use Scrum, I expect the Scrum Master to take ownership of this.
Strategy to remove dependencies
It’s important to acknowledge that the current organization structure has led you to where you are today. So it most likely has been quite successful to some degree. And this is a very important reason why key decision-makers can be reluctant to let go of it. It takes a lot of courage to let go of something that made you successful. The trick is to create a fail-safe experiment that has enough management buy-in to get it off the ground, but without sacrificing cross-functionality. So instead of reorganizing the complete organization, start with one or a few cross-functional teams. Give them the environment and support they need. And trust them to get the job done. When the added value of these teams becomes apparent over time, it will increase the chance of support for creating more cross-functional teams. And this helps reducing dependencies even further.
Conclusion
In order to maximize value as a Product Owner, you need to minimize dependencies. From a Scrum perspective, the Scrum Master can help create awareness throughout the organization and coach along the way. This will help increase the chance for an experiment with one or more cross-functional teams. And from there, inspect and adapt.
Business & Finance Articles on Business 2 Community
(103)
