Product Owner Anti Patterns
During whole my professional life, people spent hours telling me the importance of good design patterns. I believe all of us bought books about design partners, cookbook recipes or any other type of book that would give you the good practices of the industry. I do not have anything against that and how could I? Myself wrote a book about Agile Retrospectives tools box :). All these books are useful and necessary but during my career I understood that writing about good practices is not enough. We must write about what we should not do, the anti-patterns, the smells like I call them.
During the next few weeks I will be spending some time writing about this topic. I will be writing several blog posts about the smells of different roles in Scrum and about different errors that companies usually do when we implement scrum. I will start this series with Product Owner smells. I already wrote some of the common problems with Product Owners within organisations and that work can be found here, but today I am going to add more issues to that list. If you are interested in “Anti-Patterns” click here, you will find all my blog posts touching on this topic.
No single Product Owner for one team
I see this phenomenon happening quite often in organisations that implemented SAFe (Scaling Agile Framework) in the past, dropped and returned to simple Scrum. In the SAFe framework you have two roles: Product Manager and Product Owner. The Product Manager is the one thinking more in a strategically way, the Product Owner is the one thinking more on the daily activities.
When companies go back to Scrum there is no more two roles, there is only Product Owner but companies do not want to fire anyone so they assign two product owners to the team, even if they still use the same mind set: assigning one person to the strategically part and another to the daily activities I see this as a failure.
I believe its extremely difficult to work with this scenario, you must have one single person responsible for the whole product, like a friend of mine used to say “one single neck”.
Solution:
Companies must understand that is not possible to have this scenario and they must provide an environment where each team has one single product owner.
Interference with the daily work
I saw this happening in several organisations but mainly because of two big causes. First cause the Product Owner in his past was a typical project manager where he was chasing people in order to get job done. Second cause relies on the fact the scrum master is not strong and the Product Owner must step into and do a lot of the activities of the scrum master, taking the role to serious ending up controlling and interfering more than helping.
In this situation is normal to see Product Owners taking a quite active role on the dailies, manipulating the normal process. Another problem that I see quite often relies on the fact of Product Owners track what developers are doing,I saw several examples of Product Owners talking directly with developers asking what they are doing because his name is not assign to any task. Now imagine how developers felt when suffering this kind of control.
Solution:
I believe the solution for this case is to find a strong and experienced Scrum Master. An experienced Scrum Master understands quite well both roles (Scrum Master and Product Owner) and can coach the Product Owner to allow the team to take responsibility of their own tasks. One of the roles of Scrum Masters is to protect the team from intrusions, having a strong and experience strong master within the team will allow the team to remain isolated and protected from un wanted interferences, and at the same time will allow Product Owners to be coached on right behaviours.
Stories built around product layers
This is a tricky topic. Over the last months I have been working with teams that cannot deliver as fast as they could if they would use other approaches. They made a quite typical mistake, they have user stories that are built around layers of the product. As an outcome user stories are dependent on each others causing a lot of delays to deliver a product that can be usable by the customer.
Solution:
In general a good user story should be written covering all the layers of the product. Should be an end to end user story. The solution for this problem is coach the Product Owner and the team about this. For me works quite well when I explain to developers that does not matter if we deliver 200 back end user stories when in reality the customer cannot use them without the front end part. Below there is a picture from Ángel Medinilla that shows in a great way how stories should be built.
No projection of the product backlog
Usually the Scrum Master produces burn down charts showing how the sprint went. This is quite common, what is not so common is the Release/Program burn down or burn up. This is a quite common problem in many of the organisations where I worked for. Not having this kind of information make the life of product owner harder because it gets harder to know if the team is on track or not.
With this kind of information available the product owner can take better decisions about scope in order to deliver the product on time, bringing the biggest amount of value to the customer.
Solution:
The solution here is quite easy. The product owner should build a product burn down/burn up exactly like the scrum master does, but instead of being focused on the sprint, the product owner focus on the release. A possible example can be observed below.
Backlog is filled with a bunch of “Strings” not proper user stories
This problem is by far one of the most commons that I observed during the last years. Most of the times the product owner does not write the stories in a proper format, he just write few key words and that´s it. The problem with this approach relies on the fact that everyone outside of Product Owner head will not understand what the user story is about. And to be honest I saw some examples where not even the product owner knew what he wanted to solve with some of the user stories that he wrote.
Solution:
In order to point out to the solution I am using a blog post from Roman Pichler. “10 Tips to write good user stories“.
Hope you liked it :) During the next weeks I will write much more about these topics :)
Best Regards,
Luis
The post Product Owner Anti Patterns appeared first on Luis Gonçalves.
