Fight Zombie Product Ownership with the Product Ownership Evolution Model
Through our studies, we have found that a lack of true product ownership is one of the main causes of Zombie Scrum. This is puzzling as the Product Owner role as such is clearly described in the Scrum framework. However, you would be hard-pressed to find a company that comes even close to living the role the way it was originally intended. Not because these companies successfully set up the Product Owner role as required by the Scrum Guide and then found out that strong product ownership doesn’t help them solve their problems. For numerous, often very understandable reasons they go a quarter of the way and settle on fitting the Product Owner role into their existing organizational structure.
The result is a powerless Product Owner that acts on other people’s decisions and represents one link in a long hierarchical chain. The focus is most often technical and operational, almost never strategic. The core responsibility — maximizing the value of the product — gets lost.
The Development Team
And yet, the Product Owner is only half the story. Development teams really owning a product, with all the freedoms and responsibilities that come along with it, make a tremendous difference. Scrum’s feedback loops come alive when teams are directly connected to a unifying purpose and are able to see how they contribute to it every day. With real product ownership, Sprint Goals start making sense and the Review becomes a necessity instead of a repetitive waste of time. The people involved don’t just go through the motions, they actually depend on the feedback gathered during Scrum events.
Unfortunately, most companies put a big buffer between development teams and the source of the need the product tries to address. Product Ownership usually gets distributed along with various roles until the only thing the development team receives is overly detailed “user stories” that lack both user and context.
The Product Ownership Evolution Model to the Rescue!
The question is: how do you tackle this issue? Now, I’m a sucker for tools and methods. There are few things I love more than working with a client in a challenging situation, pulling out an idea, a diagram or a drawing, and seeing realization wash over their faces. “That’s it!” they often exclaim. Something was made visible or explicit that had been hidden before. They now have a new perspective on their problems and can work on their own solutions right away. It’s magic!
Every now and again I come across a gem. Something that is surprisingly simple but seems to move mountains. This year it happened to me when I ran into a former colleague of mine, Oliver Winter, at the Scrum Gathering in Minneapolis. We talked about the lack of attention to Product Ownership in companies. There are billions of classes for Scrum Masters and Agile Coaches. But Product Owners are usually painfully neglected. As a result, the whole development process suffers.
In order to address this issue, Oliver and his friend Tim Klein developed the Product Ownership Evolution Model (or POEM for short). POEM is a deceptively simple model that helps companies make sense of their current approach to product ownership and identify opportunities for development.
How to Use the Product Ownership Evolution Model
Lack of clear product ownership generally leads to one or more of the following issues:
- Trouble prioritizing items
- Miscommunication, which in turn leads to things being developed that don’t address the original issue
- Long delivery times
- Lack of innovation
- Lack of ownership on behalf of the teams
Check with the people involved in making decisions on a specific product whether any of the issues mentioned above are giving them trouble. If they enthusiastically scream yes, get those people together in a room and use the POEM.
The heart of the POEM is the visual overview: product ownership is spread out on a scale from “strategic” over “tactical” to “operational”. Below the scale, we find specific tasks people might engage in that makeup product ownership as a whole, such as crafting a Sprint Goal and writing user stories. These can be adapted to your specific context.
As a first step, the participants individually place the PO horizontally on this scale (in the “actual state” section), according to how much authority he or she actually has. So if your PO can autonomously decide on roadmap scope without consulting anyone else, that’s where you put him or her on the scale.
In a second and third step, everyone places the development teams and additional roles like Business Owner / Chief Product Owner / CEO / Management on the POEM.
After the participants have created their personal overview of the actual state of product ownership they can then start contrasting it with the target state. For this, the participants simply place the roles in question on the corresponding part of the POEM according to where they believe the role should move.
You are then ready to share the individual results with the group. This is best done by simply hanging all the sheets up on a wall and asking the attendees to look at them. What do you notice? Are there disagreements about the authority of a role? Do you all agree on the current way these roles are defined in your organization? Where does everyone think these roles should move? Is there agreement on the target state?
Finally, you can ask what is needed to make the target state become real. For this, you can use the fields “coaching demand” and “coaching offer”. Compare how much coaching you are offering at the moment and what would be needed to help the roles in the POEM move further to the left. This can include coaching through Agile Coaches, Scrum Masters, other more experienced POs, or external trainers.
What It Shows
One pattern that the creators of the POEM often see, and that we have independently verified as a reliable indicator of Zombie Scrum, is an abundance of roles coupled with a PO and the development team to the far right on the scale. This means neither the PO nor the development team is actually empowered to make crucial decisions on their product. Other people in the organization often pull the strings. That overview itself is often a really helpful first step. However, if you want to break out of Zombie Scrum structures, you will also need to make actual changes.
A Call to Action
With a short discussion using the POEM you can trigger deep conversations that can lead to big changes. It’s a catalytic tool in the ongoing fight against Zombie Scrum. Use it!
If there is no desire for change, you will need to spend a lot of time creating awareness first. As always, we recommend surfacing real problems. “We don’t do Scrum by the book!” is usually not a convincing argument. “Did you know that it takes us an average of 14 months to ship a regular feature? Doesn’t that give our competitors a huge advantage?” is often a much better way to start a conversation. Take people seriously, show deep empathy, but also be relentless when it comes to surfacing dysfunctions! Maybe you can find a cure for your Zombie Scrum infection. The POEM can be a big help on the way.
You can find more information and download the model here: https://www.productownership.de/en/