Today we dive into Chapter 4 of  Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller. I have argued that the role of the Product Owner is the hardest in Scrum. The role is difficult for many reasons. For example, the role is often foreign to those implementing Scrum or agile, so they draft proxies to play the part or it becomes a part-time role. The voice of the customer is kept at arm’s length because they are seen as outsiders even though they are critical to value delivery. I wonder if it was because of the criticality of the role that Todd and Ryan tackle seven of the most pernicious antipatterns of product ownership in Chapter 4 of Fixing Your Scrum. Compromising Scrum by accepting any of these antipatterns will need other compromises which will increase the overhead needed to deliver value. That, in turn, will hurt the business. 

Part of the issue with product ownership in many organizations is the view that the role is a go-between between the business and software and operations teams. Scrum (and every other framework I am aware of) expects the role to be a decision-making position. When organizations redefine it as a glorified go-between, further adaptations such as having a part-time product owner or a committee of product owners are easy steps that sound safe but lead to slower decisions and compromises where compromises are the wrong answer.

One of the “Joe asks” call-outs (Todd and Ryan’s approach to sidebars)  in the chapter tackles the idea of measuring “backlog health.” Todd and Ryan state that backlog health measures are a red-herring and a signal that the organization has adopted a proxy product owner structure. Proxies are easy to spot, for example, one way to spot the real product owner is to identify who has profit and loss responsibilities. Part of the issue often is the many organizations do not have a good handle on their value chains and therefore what is a product or part of a product. Product owner committees can be a reflection of outputs of individual processes being confused with the outcomes of value chains.

One of the antipatterns in the chapter that I have been observing more often in recent years is the Commander and Chief (I use the term dictator — Todd and Ryan are more diplomatic). Vision is one of those critical attributes that a product owner must have and be able to share with the team. The word share is important because sharing evokes the possibility of collaboration about the direction of the product. Product owners must synthesize vision based on the market needs, their perception of the future, the needs of the business, and the technical possibilities. To deliver a moving vision requires leadership. Without leadership, both stakeholders and team members will disengage or fight against the shared vision. Trying to dictate a vision reflects a lack of leadership. 

The product owner’s role is hard which can mean that it is hard to sell to decision-makers in an organization that already have a full-time job (or several). When this happens and a proxy can’t be found, the role is often added to another existing role. This is a form of proxy product ownership. Todd and Ryan address the Scrum Master/Product Owner (SM/PO) chimera. Their counsel is useful even if your organization has found a different product owner chimera. One of the strangest role mixtures I have seen recently was the combination of product owner and test architect. While they performed the role admirably, the decision-making process they had to create was tortuous. Every role on a team will have a fundamentally different perspective. Each of the three roles in Scrum speaks in a very specific voice. The product owner is the voice of the customer, the Scrum Master is the voice of the team, and the technical members represent the voice of the functionality.

The final piece of advice in the chapter is to reflect on what can happen if the product owner role is not elevated to the correct level. If adopting Scrum or any agile framework is about delivering more value to the business and customers then failing to have the right people playing the product owner role is leaving value on the table.

If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems 

Previous Installments

Week 1: Re-read Logistics and Front Matter – https://bit.ly/3mgz9P6 

Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad – https://bit.ly/37w4Dv9 

Week 3: Breaking Bad Scrum with a Value-Driven Approach – http://bit.ly/3stGc9Q