Red Flag: Powerless Product Owner

Red Warning Flag On Beach

Stuart Miles – FreeDigitalPhotos.net

Every attempt at transition can have issues. Some issues are fairly common regardless of who attempts the transition. No matter who tries to cross the Sahara there will be a lack of water available during the trip. These common issues are often called red flags.

Every desert crossing attempt is unique. The people and methods involved vary. Some may be making the trip over the course of week, others in just a few hours. In each of these circumstances the best way to address the lack of available water is very different.

In Agile transitions there are also red flags. Just as with crossing the desert each Agile implementation is different. As such there is not a proper way to address every issue every time. The more similar organisations are the more similar the solutions may be, but even that is not a given. Today we are looking at the Agile red flag of a Powerless Product Owner.

I’m not talking about the Product Owner (PO) who represents multiple interests. In fact, that would be a healthy PO. I’m talking about the PO who does not have the final say. The PO who gets overridden constantly.

If the PO is overridden by upper management then their team will lose faith in them. Instead of trusting that what the PO tells them the priorities are the team will always be shy of getting priorities changed partway through an iteration. Soon they will start to plan a period of shifting priorities into their work. Overall effectiveness will decrease. Even when the PO is in the right the team will approach the decisions as temporary. Perhaps they will patch together a solution that can be easily removed instead of creating a robust solution that will stand the test of time. If upper management needs to refocus the PO they need to do it in the context of the structure and process in place around the team, protecting that relationship.

If the PO is overridden by the team the customer will lose faith in them. What the PO promised for delivery will slip. Released features may not work as expected, or at all. The customer will resolve this problem by seeking a new provider in some way. This is a loss for the whole team. A team needs to provide input to the PO, but the final decisions on the product are not the teams responsibility. The team has a responsibility to deliver the solution, not define it.

If the PO is overridden by the customer then they lose effectiveness within the organization. Upper management will prefer to interact directly with the customer, as will the team. The PO will become little more than a figurehead. The value delivery chain is likely to be slowed as the team and customer start to chase the small pieces together without looking back up at the big picture. Upper management will defer to the customer without regard for how it can negatively impact the team. Part of why the PO is there is due to the customer not always being right.

Any of these situations can chip away at the effectiveness of the Product Owner to the detriment of the product, the team, the customer, and ultimately the entire organization. Identifying them early and preventing them is the job of the Agile Coach/Scrum Master/Agile Project Manager. This is why it can be a problem to have these roles combined with the Product Owner.

What other indications have you seen of a Powerless Product Owner? How have you resolved these problems?

Leave a Reply...