Collaborative Leadership Team’s Angela Johnson wrote about the Product Owner role in late 2014 offering good advice to P.O.s everywhere about how to be more effective. In this post, Angela Johnson, Certified Scrum Trainer, offers tips to organizations struggling to fill this important role.
The absence of an empowered Product Owner only leads to trouble when adopting Scrum. Teams are left to guess what features to build and in what order. If they guess right – great! But what if they guess wrong? Is the organization ok with abdicating decision making to the teams? P.O.s order the work based on business value. That implies that our company clearly knows what its mission and goals are with non-conflicting direction provided to those doing the work.
One team at a private client of ours had a little fun in sending a message about an absent Product Owner and created a missing person ad on the side of a milk carton looking for this person. Check out the photo in this post.
Consider the following when attempting to “fill” the P.O. role:
- Don’t Try to Fill the PO Role – Identify Them: In Certified Scrum Product Owner (CSPO) training we note “what the product owner does for their day job makes them the product owner”. The P.O. seeks to maximize value of the product from a knowledge base of customers, the market and the business. Their decisions are informed ones that are not overturned for the product. Trying to force someone into a role where they are not empowered will set them, the team and the organization up to fail and will not deliver business value any faster than traditional system development lifecycles.
- If You Have to Ask for Permission, You Are Not Empowered: The most important quality of the Product Owner is that they are willing to make decisions and empowered to do so. There is a difference between someone who collaborates and gathers input from executives, stakeholders, users, etc. and someone who has to seek permission. If the person in the P.O. role has to seek permission they are not empowered and once again, this causes re-work and delays.
- If Everything is Priority Then Nothing is Priority: By definition priority is a precedence, that something comes prior to something else. The updated Scrum Guide replaced the word priority with ordered in an effort to prevent “scrum abuses” being committed with the word priority. “Oh it’s ALL priority” is what teams are told. With the word ordered there is no question. Something needs to be first, second, etc. Teams can focus delivering higher quality product more quickly in this manner. New work can be brought to that dedicated team in a focused, ordered manner allowing them to get to done before moving on to the next item. Splitting their focus across multiple “high priorities” results in defects, loss of productivity and delayed timelines.
Want to learn more?
Click here to view our upcoming classes and register for our next CSM or CSPO course.