Join the Mastering Agility Discord community!
In a previous article, I discussed how Product Owners are often restrained from reaching their full potential and are not empowered to do what they are accountable for; maximizing value. In this follow-up article, I’d like to dive into that situation and make things more practical.
There’s one assumption from reading beyond this point: the Product Owner stage has gone beyond the point of business representative and we’re now trying to evolve to Sponsor and Entrepreneur levels from the “model” created by
“Model” is between quotes, as it’s not an official model. It has helped me to identify improvement areas.
Restraints that I’ve often experienced while coaching Product Owners and organizations that are discussed in this article:
- The real decision-making is ultimately done by (higher) management
- No budget control
- Little trust/high fear in the wider organization
Visual mapping for autonomy expansion
You’ve been Product Owner for a little while now, and you know how to manage the Product Backlog effectively. You’re talking to our stakeholders on a frequent basis and taking their feedback into account. Backlog refinement is done proactively, and collaboratively with the developers.
Here’s where things get a little trickier. Most organizational structures are still silo-based. There’s the HR department, sales, IT with a million sub-departments (Java, .Net, UX, etc), this list goes on.
The issue that arises with this departmental structure, is the people are responsible for their own respective parts in the organization, and lose sight of the collective goals. We work for a single organization, yet many organizations operate as many individual entities.
My therapist is so annoying (read: correct) to say that when we want our situation to change, we have to start with ourselves. As we want and need to get more autonomy to truly maximize value, let’s start with visualizing the areas where we can grow.
This might feel a little arbitrary, but it helps in the journey. Ultimately it’ll become muscle memory to operate on the corporate battlefield. For now, some tools might be useful to navigate our way through. It might be useful to collaborate with your Scrum Master here, as he/she is accountable for causing the removal of impediments. As you’re experiencing an impediment to maximizing value, the Scrum Master should be involved as well.
How and how many details you want to visualize, that’s up to you. I’ve used a single flipchart before and posted stickies on there with the identified areas of improvement. But I’ve also worked with Product Owners that felt a more elaborate Mural environment was more useful to them.
One of the tools that I created to help Product Owners create clarity amidst chaos was the DONUT chart. This chart helps to map where you as a PO have decision-making authority.
This is not just for growing POs, but just as well for creating more transparency in the organization. This became a great conversation starter, that ultimately helped to move authority where it should be: with the POs.
Details changed for NDA reasons.
D(elegated): Here’s a practical tip about the decision-making of a PO; you don’t have to decide over every single nitty-gritty detail. By delegating some parts that don’t require your time urgently, you can focus on those things that do require your time.
O(wned): areas in Owned are already part of your autonomous operation in the organization. No need to do anything with this, other than potentially over time inspect if you can/need to delegate the items in here.
N(eeded): contrary to the items in Owner, you don’t have the authority over these items, yet need to in order to maximize value. The example shows Budget and Architecture. In this specific situation, the direction and design, development, and implementation of the architecture of the product were still made by the Architecture department. The consequences were that a lot of discussions were needed between the Scrum Team and the architects, as well as limited options for the PO to adapt the Product Backlog related to the architecture.
Photo by Javier Allegue Barros on Unsplash
U(nable): some things you don’t have control over, which makes it a dependency. In the example, the process of a supplier is used. The same goes for legislation, and vendors for instance.
T(acit): I’ve seen many organizations that had official processes citing that higher management had the final call about the direction the product was heading in. In practice though, POs still made the actual call. The pesky thing with this is that the POs decisions could theoretically be overruled. Tacit authority needs to be mitigated as well.
Knowing where you stand guides the process
Authority and autonomy can be very tacit by themselves. Mapping it out as described in this article can be useful to guide the way to the next step in that PO evolution.
My experience is that visualizing the current state like this creates a dialogue about what options there are, and what the most impactful improvement could be. This is just one tactic, and by no means fits every organization. Where do you stand? Are you fully authorized to make every decision autonomous?