Why good relations inside and outside of a product organisation are key to the success of a Product Owner.
Scrum failures are common
We all have seen failures in adopting Scrum in an organisation. And hey, it’s part of the whole concept to fail fast, use inspect & adapt and correct it the way you think is best. Typically large organisations face challenges in adopting Scrum at a large scale. There are various reasons why agile adoptions do not create the effects you wished for – flexibility in the development, code quality, self-learning development teams and more.
In such cases we normally try to find out on a team level what we can improve. But seldom do we investigate in the Product Owner’s role and how it was lived during the agile adoption.
In this series of 3 blog posts I want to explore how Product Owners behave according to typical patterns and archetypal habits and how to overcome their flaws within the organisation.
The role of a Product Owner
The product owner’s responsibility is to maximize the value of the product resulting from work of the development team(s). Yet, Scrum does not tell how the product owner should act to reach maximum value for her product. This is up to the agile organization to decide how to achieve this.
Also the product owner “owns” the product backlog. He ensures that all product items he puts in the backlog are ordered according to the set goals and value created by each item. The product owner is accountable to make the product backlog visible and transparent and is there to help the development team understand the items they need to implement in the upcoming sprints.
An important principle to note is described in the Scrum Guide:
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.
In large-scale agile organisations a Product Owner must constantly work on five important relationships influencing the success of an agile adoption:
The backbone of the organisation
The Product Owner and his Teams own the product together. In a trust-worthy environment the Teams implementing it product will take on real ownership of the product too.
That of course requires a close relationship between Product Owner and his Teams. A good Product Owner visits the Teams regularly but does not micro-manage the Teams. Instead, he works with them during Refinement. Sprint review and Retrospectives.
The window to the outside
Without involving customers and users a Product Owner would not be able to create real customer value in his product. Even broad market knowledge would not be enough to succeed with a product because the customer gives feedback if the product is valuable or not.
Thus, a Product Owner must closely work together with his customer base. He needs to be transparent about what he is planning to deliver but also listen to his customers in order to learn more about their goals and problems.
Customers also need to be aware that their product is developed according to Scrum. The Product Owner educates his client base about his agile way of working and why this is beneficial to them, shipping every sprint. A good Product Owner in a large-scale development organisation will invite customers to Sprint Reviews or Refinement Sessions with the Teams.
To own or not to own
Higher management must give their Product Owner the accountability and responsibility for his Product’s success. If this is not the case the Product Owner will not have full authority to make decisions critical to the Product, e.g. hard business decisions or decisions about resources.
Nevertheless a future Product Owner must do a self-assessment in order to find out if she is capable to do the job. Even if management lets you, will you take over full ownership of your product? How much do you want to bring about change? And finally, are you the one who makes the executive decision?
If you are confident about the above you will automatically be on eye level with your management and maintain a good relationship with them.
Be frank and listen
The relationship to the Scrum Master(s) is different. It is not about product domain knowledge, it is about how to act as a Product Owner and how to improve on that.
As the Product Owner you need to be frank with the Scrum Master in order to overcome concerns and impediments you might have in your role. The Scrum Master is a coach for the Product Owner, he needs to know what’s bothering him.
On the other side the Product Owner must be open to listen to the advices a good Scrum Master can give him. Reflecting on situations is also a good practice of a Product Owner. This way he is able to tell the Scrum Master about his concerns.
Introduce your Teams
It is a very good practice when Teams talk directly to their customers and users. This helps getting an unfiltered view of how customers see the world. Although this is still unusual for many companies it truly helps the Product Owner doing his job, especially in large-scale developement organisations.
With many Teams to “feed” with feature requests for a big product a Product Owner is quickly overloaded with work. Time spent with Teams is rare to achieve. That’s why the relationship between Teams and their customers is so valuable and important. It helps reducing his work in the product organisation without loosing his main responsibility.
Product Owners must ensure, that this relationship is lived by actively connecting both sides, invite them to business meetings and, if required, educate his Teams how to approach/talk to the customers.
In the second blog post of this series I will focus on different archetypes of Product Owners pointing out their strengths and weaknesses doing their job.