A deeper understanding on…
The Product Owner
Road to PSM III — Episode 8
In this article, I will cover the relationship between the Product Owner, the Development Team and Stakeholders. The art of ‘Backlog Management’ and ‘Maximizing Value’ I’ve covered in more detail in upcoming articles.
Domains
Although the role of Product Owner is indeed a very powerful role, it is also somewhat restricted. Those restrictions, however… are strangely liberating. Scrum can be like that. I’ll try to explain how this is.
Although the ‘power’ of product ownership involves granting the Stakeholder their wishes, Scrum also keeps this power in check by leaving it up to the Development Team to organise their own work. The Scrum Master is invested with the responsibility and means to facilitate and enable.
The popularity of the role of Product Owner transcends Scrum, so these dynamics will differ from organisation to organisation and team to team.
In organisations where these three ‘powers’ so to speak (self-organizing, facilitation and product ownership) are not balanced out (or respected), they will hardly experience any of the benefits of empowered, creative, self-organizing teams.
If that is the case, teams will often lack the ability to adapt adequately to changing conditions. They might lack the creative freedoms to work out better approaches or work autonomously through tough challenges. It will be less able to deliver timely. Due to a lack of empowerment, they might not feel as committed and will lose a sense of overall responsibility to achieving collective goals.
These dynamics matter.
Maximize Value
“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” — The Scrum Guide
The above quote from the Scrum Guide has lead to many assuming that the Product Owner is the sole person responsible for (the value of) the Product.
Although the primary focus of the Product Owner is to maximize the value the Development Team performs, that isn’t to say the Development Team should have no awareness or responsibility towards maximizing value.
Consider for a moment what it means for the Development Team, collectively being the (product) value creators, to not be recognised as such.
Stating that the Product Owner is responsible for maximising value, doesn’t imply the rest of the team isn’t.
“There are too many toxic Scrum implementations in which the Development team ends up serving the Product Owner instead of the product, or the users of the product.”
I’ve heard students and professionals remark that “Product Dictator” would be a more suitable name once they’ve read up on the role of the Product Owner (rather than “Value Maximiser” as Scrum puts it).
I can see why, as many won’t read the fine print, and don’t really understand how this authority relates to the rest of Scrum.
The Product Owner and the Development Team
Don’t get me wrong though. The role of Product Owner is pivotal. For someone in the team to be focussed and dedicated to optimizing value is precious. The most powerful value optimizing ‘means’ the Product Owner has available to him or her… is the Development Team.
The Development Team pulls in work. Against popular practise, this should not be dictated by the Product Owner. The Product Owner doesn’t decide what the Development Team pulls in, but can (and should) influence this as best he or she can. The Product Owner develops ‘purpose’ for the team: “This is why we do what we do. This is what we are aiming for.”
The Product Owner will need to work with the Development Team and put in the effort to explain the value of what it should work on next. This way, to some extent, The Product Owner and Development Team can make transparent what the team will likely work on next in the Product Backlog.
Think about how this relationship between the Product Owner and Development Team promotes creativity, productivity, and agility. Think about how this increases the value the team produces.
I personally met a lot of resistance and experienced some conflict regarding the relationship between the Product Owner and Development Team in Scrum. This is mainly due to the persistent legacy habits that are inherited from the traditional relationship of a Project Manager with a Development Team. Just adopting new roles or titles has little impact on existing habits and power structures. One example of such a ‘facade’ is the widespread existence of ‘Proxy’ Product Owners (often the case with digital agencies).
In many cases I witnessed Product Owners, together with Stakeholders, creatively determining what the Development Team should produce, like a page, pop-up, modal, button, form, box, bar, etc. In other organisations the ‘discovery’ is done by a completely different team, hinting at persistent Waterfall legacy. This will rob the Development Team of an opportunity to creatively construct better approaches. Remember that the best approaches emerge from cross-functional, self-organizing teams.
If a Product Owner in such a setting truly desires to ‘Maximize Value’, they could consider investing in creative expertise within the team to unlock this value.
PBIs (Product Backlog Items) should, at first, only mention what ‘needs’ are to be addressed, and what the value is of meeting those needs. Only in collaboration with the Development Team they should be refined with ‘how’ those needs could be met. This could also be reserved for the Sprint and that Sprint’s Backlog and iterate from there.
Naturally, the Product Owner (and even Stakeholders) should work with the Development Team to explore possible approaches a Development Team may take. The Product Owner should, I believe, step back at times to utilize the creative thinking of the Development Team.
The Product Owner will try to understand the market, the users and Stakeholders as best as possible, in order to be able to determine what would be most valuable to them.
The Product Owner doesn’t have to do this alone. There should be Development Team members who will help the Product Owner collect feedback and measurements on the use of the Product.
I often refer to the book ‘Service Design Thinking’ and refer to the website Service Design Tools as these contain many collaborative practices that could be applied by Scrum Teams to better their understanding of the market, or creatively design approaches to facilitate a need or solve a problem. In addition, techniques like A/B testing can help validate what approaches yield better results.
The Product Backlog
“The Product Owner is the sole person responsible for managing the Product Backlog.” — The Scrum Guide
Note, now, the explicit use of the term ‘sole’.
The Scrum Guide follows this up by stating:
“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.” — The Scrum Guide
The Product Backlog is often a (long) list of needs. How the Product Backlog is ordered, is up to the Product Owner, so it doesn’t have to be a prioritised list.
“For the Product Owner to succeed, the entire organization must respect his or her decisions.” — The Scrum Guide
The above quote relates to the Product Backlog.
Note though that the Product Owner isn’t responsible or accountable for the Sprint Backlog. The Sprint Backlog is managed by the Development Team. The Product Owner doesn’t decide what goes into the Sprint Backlog (though he or she will guide and support the Development Team in this), neither does the Product Owner determine the priority or order in which the team works on items in the Sprint Backlog.
As every one respects the Product Owner’s decisions regarding the Product Backlog, likewise, the Product Owner must also respect the Development Team’s autonomy over the Sprint Backlog.
The Product Owner does however:
“discuss the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal”
— The Scrum Guide
There is no point to set goals the team won’t really get behind. Thus, establishing a Sprint Goal is a collaborative exercise. It may also validate potential value at reasonable effort.
Managing expectations
Throughout development new insights and feedback is collected. Due to changing conditions in the market and the complex nature of product development, the Development Team, and thus its planning, needs to be adaptable.
Let’s face it, we like to know when we can expect what. Stakeholders may depend, to some extent, on future output of the Scrum Team. These Stakeholders may or may not work in an empirical way. When they aren’t, they will insist on learning what to expect when, so they can plan accordingly in their own roadmaps. Two worlds are at odds.
Product Owners might under such conditions, be inclined to provide dates, timelines, deadlines, estimates, trend lines and/or forecasts. Note that these projective practices set expectations. Those expectations could reduce a team’s agility. Having set these expectations, the Product Owner will feel responsible for meeting them. How this translates to behavior naturally depends on the Product Owner’s character.
“Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.” — The Scrum Guide
The best way a Product Owner can keep Stakeholders informed and involved, or enable them to influence development, is to participate routinely in Sprint Reviews. Here they can inspect actual progress.
“Working software is the primary measure of progress.” — The Agile Manifesto
So when Stakeholders are persisting on getting target dates or setting deadlines. Tell them the truth. It might be better to let someone down early than postpone this till it’s too late. Who knows, this way, when it comes to it, your team might even be able to exceed expectations.
Often tradeoffs will need to be made to either meeting expected target dates (like organising events) or adapting tactically to conditions. Teams should be able to remain agile; fixing dates will make them rigid. Changing direction can be valuable, but can result in frustrations.
Surviving the role of Product Owner
The role of Product Owner is a hard role to take on. As a Product Owner you likely can’t satisfy everyone and you will, like it or not, be involved in all sorts of persuasive play. You will constantly be tempted to engage in projective practices. You have a big responsibility, maximizing value. You will be at odds with both Stakeholders and Development Team members at times, and heck… even the Scrum Master. It truly is an art to get out of this alive so to speak. Note though, that you are part of a team. Your team is there to help you, and you them. Share your challenges with the Scrum Master. You too participate in the Retrospective. Remember that you don’t just represent the Product, you also represent your team. You are in this together.
There is much more to cover on the role of the Product Owner, like the authority to cancel Sprints. This I will cover in upcoming articles in this series.
The Road to PSM III is being reformatted to The Road to Mastery!
Part I: Down the Rabbit Hole is now available.
Continue to the next episode:
Thank you for taking the time to read seriously. And special thanks to Willem-Jan Ageling for always being so kind in taking the time to review and share his thoughtful insights and experience.
