Anti-Patterns of Product Owners - Part-1
This article highlights PO/PM anti-patterns, describes the repercussions, and suggests a few tips to avoid them.
Join the DZone community and get the full member experience.Join For Free
One of the most important roles in an Agile Project is that of the Product Owner (PO). The Primary responsibility of the PO is to represent the Business, prioritizing business requirements for delivery. This often means that the PO is the one who decides what the Squad does in a Sprint. However, it does not mean that the PO tells them how to do it, when to do it during the sprint, and which team member should do what. Sadly some POs go beyond their key responsibility and start managing the team and the project – the Project Managing PO! These POs find it difficult to move away from Project Management and adopt an approach of trust, collaboration, and empowerment – which is pivotal in an Agile context.
This article highlights the PO anti-patterns, describes the repercussions of these, and towards the end suggests a few tips to avoid them.
I have taken the Scrum model as the reference and have used the Scrum roles and ceremonies for this article. But the anti-patterns could be similar in other models as well.
1. Why Is the Team Not Fully Engaged?
Here the PO wants to ‘load’ the team with work filling their entire capacity. The PO makes certain assumptions and calculations to conclude that the team is not loaded. Often the PO makes statements such as ‘I see some bandwidth available. You should pick up more work’. Here the PO forgets that despite careful planning there will be unplanned work coming in during the Sprint and the team would need the spare capacity to manage that. The PO does not allow the Scrum Master and the team to plan their work based on several considerations that they would be the best to define. This is almost like mandating the team to do what the PO wants them to do.
This anti-pattern results in the team loaded with work ‘to the brim’ and when unplanned but essential work comes in – Eg. Bug fixes or production support issues – the team is left with no bandwidth. They usually stretch themselves to complete them. This results in the team burn out over a period.
2. One Person Can Do This While the Other Person Can Do the Other Thing
Come on, the team will decide that! The PO expects specific individuals in the team to pick up specific pieces of work. They also want the team to share work as per their prescribed percentage. Why would the PO decide this? There are the Scrum Master and the empowered team who would be able to pick up work based on several context-specific conditions such as technology, familiarity, and prior experience. And they are almost always right on their work-sharing arrangement. Should the PO focus on story prioritization or task allocation?
When the PO dictates work distribution the team is constrained to meet the mandate of the PO. Gradually the team members feel less empowered and lose their freedom to make their best choice based on the specific context of the solution, the Sprint in consideration, and the available team skills. In the long run, this leads to frustration and team members may choose to move out of the team or even the organization.
3. What Are the Tasks, and What Is the Status of These?
Here the PO wants to know the task breakdown of each story and understand how each task is progressing – a typical micro-management approach. The PO should just care about what the team has committed and leave it to them to complete what they committed. It is the team’s responsibility to define the tasks needed to complete the stories. The Scrum Master would make sure that the blockers in the team’s progress are removed and dependencies are addressed so that the team could complete the committed number of stories.
When the team sees micro-management they tend to define tasks at an abstract level and paint a rosy picture to the external world. This contradicts the Agile philosophy of transparency and open communication. Eventually, this may burst into the discovery of technical debt and issues related to quality and timeliness. Further, the team would also feel the lack of trust and empowerment rendering them unenthused to be proactive. The Scrum Master feels helpless in this situation because the PO overrides them and the team.
4. If One Person Works For 2 Weeks You Should Clear 10 Story Points!
Story points are relative estimates. Linking them to hours of effort or duration would only present a skewed picture of estimates or progress. However, some POs who come with a traditional project management approach think that a story point is a definite number of hours of work or elapsed days. Therefore they ask the team to pick up work amounting to a fixed number of story points relating them to the number of days and number of team members. They do not realize that there is no linear relationship here and absolute mathematical proportion of effort and duration would only be counterproductive.
With this approach, the PO sets the wrong expectations for the business. The team would be stressed out as they approach the release date. They will most often fail to meet these expectations. This will lead to a lack of predictability and the Business may lose confidence in the team.
5. Why Should You Do That DevOps Task? What If You Don’t Do That?
Tasks related to DevOps and technical debt are an integral part of any Agile team. The team must allocate bandwidth to do those tasks to continuously improve the solution, automate their development, QA, infrastructure, and deployment activities to move towards technical excellence. Some POs are oblivious of this and focus only on business functionality. They tend to question the team on the need to do DevOps activities or other technical debt tasks. They think that they are not on priority and override the team on the activities for technical excellence.
Yes at a given time – say an ensuing critical release – business functionality could be more important. But it cannot be that the team is forced to do only the business stories and never allowed to focus on technical excellence. Not providing adequate time and space to the team will only accumulate technical debt and at some point, it will bounce back as a serious blocker to deliver business priorities. This is will also potentially impact the stability and robustness of the solution.
There are more anti-patterns. Follow Part-2 of this article to read those and some suggestions to address them.
Opinions expressed by DZone contributors are their own.