Successful Product Owners are Leaders, Not Managers!
Until Product Owners master leadership skills, it will be impossible to release the Scrum Team's highest potential.
Until Product Owners master leadership skills, it will be impossible to release the Scrum Team's highest potential.
Why do many developers have constant arguments with Product Owners? In my opinion, the lack of leadership skills ensures numerous conflicts between the Development Team and the Product Owner.
Many Product Owners misunderstand how to behave in this role. I’ve observed multiple times Product Owners behaving as the manager of the Development Team. Some common misconceptions are:
The Product Owner assigns tasks directly to the development team.
The Development Team don’t start the Daily Scrum because the Product Owner is unavailable.
The Product Owner has to approve all tasks done by the Development Team.
The Development Team receives Product Backlog items to implement without knowing why that is important.
Product Owners are not managers. Product Owners are leaders. Until you learn how to behave as a servant-leader, you will not reach the highest potential as a Scrum Team.
Let me share some of my learnings of how a Product Owner should behave as a leader.
What does leadership mean in Scrum?
Scrum has no hierarchy within the team. Every role is a peer to each other. Command and control behavior has no space in a self-organized team. Therefore, you should learn what a leader means being.
Let’s have a look at what the Scrum Guide says about the Scrum Team. In bold, you can read the key aspects.
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
— The Scrum Guide, November 2017
To succeed as a Product Owner, you need to learn different leadership styles. Sometimes you need to make the decisions not to overwhelm the team. But also sometimes you need to help the team to make the decisions. Understanding how to behave in each situation will help you succeed as a Product Owner.
I consider the following to be the essential leadership styles to learn:
Facilitator: you help the team to move forward. You help the team to solve the conflicts that hold them back from progressing. You make no decisions; your role is to facilitate the interactions.
Mentor: the team knows you are available for them. Whenever they need advice or guidance, you can assist them.
Negotiator: you analyze the advantages and disadvantages of each possibility. Then, you evaluate which trade-offs to make. Once you have the goal in mind, negotiating won’t be a hassle.
Leader: you understand when to step in as well as when to step out. The leader knows when to make a decision alone and when to make it collectively.
Observer: you interpret the situation and can understand the atmosphere. You know when something needs to change.
Now let’s explore how and when to apply each leadership style within a Scrum Team.
Refinement Sessions
As often as needed, the Scrum Team refines the Product Backlog items to clarify they will build what matters the most. During these sessions, the Product Owner brings new items to discuss with the Development Team. But how the session goes vary widely on the leadership skills of the Product Owner.
To have meaningful refinement sessions, the Product Owner should adapt to the negotiator style. The main point of the refinement is to build a shared understanding. Therefore, the Development Team needs to understand in-depth the problems. Then, it’s possible to define right-sized solutions for the problems.
The hard truth is, you always have more wishes to fulfill than time and capacity. Trade-offs are part of your reality. Product Owners should help the team identify what to do and what not to do. You don’t want to build a bazooka to kill a mosquito. The negotiator style will help you as a Product Owner to make better decisions with the Scrum Team.
During the refinement session, the leadership style may change. At some moments, the Product Owner needs to decide what to do and what not to do, being more as a leader. Also, sometimes the Product Owner is an observer while the Development Team discusses to gain clarity. The refinements are vital to build shared understanding; without that, you cannot build meaningful products.
Sprint Planning
What is the goal during the next Sprint? That’s the most important part of the Sprint Planning. Yet, many Product Owners insist on starting the Sprint without a goal. In this case, be aware that a feature factory trap is inevitable.
During the Sprint Planning, the Product Owner is the leader. The Product Owner should come with a vision in mind. Then, the whole Scrum Team crafts the Sprint Goal. Let me be clear here; the Product Owner shouldn’t define the Sprint Goal alone. This is the responsibility of the whole Scrum Team. Without that, the Development Team may not commit to the goal.
The Product Owner sets the direction, while the Scrum Team will define how to reach the goal. That’s why it’s vital to define a compelling Sprint Goal instead of tasks to execute. The Scrum Team should have room for creativity.
“The very essence of leadership is that you have to have vision. You can’t blow an uncertain trumpet.”
-Theodore M. Hesburgh
I’ve observed a widespread misconception is defining a set of tasks for the Sprint, and then the goal is to deliver all tasks by the end of the Sprint. Such scenarios cannot be called Scrum because it removes the space for self-organizing teams. If one person is solely defining what the Development Team does, developers will be frustrated; they will feel like mere code-writers.
The Product Owner should be a leader who inspires the team to be on a mission.
Daily Scrum
The Daily Scrum is an event for the Development Team. Although the Product Owner and other stakeholders can attend the Daily Scrum, they are mere listeners.
The Development Team uses the Daily Scrum as a chance to re-organize and plan their work for the day. Unfortunately, I’ve observed many scenarios where the daily doesn’t start until the Product Owner is available. This is a misconception and should not happen.
The Daily Scrum is a 15-minute time-boxed event for the Development Team. — Scrum Guide, November 2017
The question is: should Product Owners attend the Daily Scrum? In my opinion, yes, but with the right behavior. Great Product Owners are available for the Development Team, being part of the Daily Scrum is a chance to do so. As Product Owners, during the Daily Scrum, you should:
Be a listener: observe how the Development Team is interacting. Evaluate if something you, as the Product Owner, could do to help the team move forward. For example, maybe the team misses some details which you could provide.
Be available: act as a mentor. You are available for the team if they need you. If the team doesn’t ask anything from you, it’s fine. Once the team needs your guidance, they will ask.
The Product Owner has to understand the Development Team is self-organized, and they do not need instructions on how to organize their work.
The Daily Scrum is neither a status report to the Product Owner nor a moment for the Product Owner to define who does what.
Sprint Review
The Development Team is in charge of running the show. They proudly present what they built during the Sprint. The stakeholders provide feedback and interact with the Scrum Team. That’s how the Sprint Review should be, but many times it’s not the case. Many Product Owners love taking over the presentation, while the developers are only listeners.
The Development Team demonstrates the work that it has “Done” and answers questions about the Increment. — The Scrum Guide, November 2017
If Product Owners behave as the Development Team manager, the Sprint Review becomes a boring one-person show event. Product Owners who take all the credits will inevitably lead the Development Team to underperformance. The developers will not engage since they are no more than executors.
During the Sprint Review, the Product Owner should be mostly an observer and sometimes a participant, but not the event leader. The Development Team presents the result, while the Product Owner observes the stakeholders reactions and interactions with the developers. By observing, it’s possible to learn a lot and give the Development Team space to thrive.
“To acquire knowledge, one must study;
but to acquire wisdom, one must observe.”
― Marilyn vos Savant
Sprint Retrospective
After each Sprint, the Scrum Team stops to evaluate how the Sprint went to become a better team for the upcoming Sprints.
The Sprint Retrospective is not a moment to search for someone to blame or someone to glorify. It’s simply a moment to reflect on what went well and what needs to improve. The Scrum Team identifies what to improve and agree on actions to take for the next Sprint.
To reach a meaningful outcome for the Sprint Retrospective, every team member has to behave as a peer to each other. If someone tries to behave differently, the event will lose its sense. Unfortunately, many times Product Owners forget they are part of the Scrum Team. Then, they behave as if they are above the team, which is a massive misunderstanding.
In Scrum, hierarchy has no place. The Sprint Retrospective is powerful when this simple rule is respected. In this case, Product Owners must behave as participants in this event.
Summary
Situational leadership is key to success as a Product Owner. Once you learn how to interpret a situation and apply the most appropriate leadership style, you can avoid numerous drawbacks and increase productivity.
Backlog Refinement: be a negotiator. Help the team to make the required trade-offs.
Sprint Planning. be a leader. Set a vision and lead the team to a mission.
Daily Scrum: be a mentor. You observe what is happening, but you don’t act until the team asks for guidance or advice.
Sprint Review: be an observer. You let the Development Team run the show while observing the stakeholders reactions and interactions with the team.
Sprint Retrospective: be a participant. Take the Sprint Retrospective as a chance to evolve as a team.
Do you want to write for Serious Scrum or seriously discuss Scrum?