Most people think that the Product Owner being the one-point-contact (mediator) to talk to stakeholders is a great way of reducing wastage and unnecessary discussions. While, apparently it might look like a helpful  pattern but actually it turns out to be an anti-pattern .This way of working has more negative consequences than positive.

Why do people feel that the Product Owner is a mediator?

• The Scrum Guide says “The Product Owner may represent the needs of many stakeholders in the Product Backlog”. When people read this sentence, they may  feel that the Product Owner is the only person  that is allowed to interface with the Stakeholder and no one else can interface with them.
• Fear of a “Customer” or a “Stakeholder” escalating to the management has always kept the developers away from the “Customer”. Some of the common fears that hold back a developer are –

o   “What if I understand incorrectly?”,

o   “What if the customer escalates to my manager?”,

o   “What if the customer laughs at me?”,

o   “What if the customer thinks I don’t know things?”

o   What if there are any contractual implications to what I agree?

• The reluctance of the Developers (Technical teams) to interact with Stakeholders has made the Product Owner a mediator or a middle-man/woman. The developers expect that the product owner will always talk on their behalf to the stakeholders.

Negative Consequences

• Product Owner may not be able to convey what exactly Developers views

o   Developers have a unique point of view about any solution. Information may be lost when the Product Owner conveys.

o   Developers know the technical feasibility of any solution to a business problem. Product Owner may not know all the details of technical issues

• Information may be conveyed incorrectly and thereby increasing misunderstanding between stakeholder and the technical teams
• Product Owner may become a bottleneck and overloaded with work related to conveying information back-and-forth between Developers and Product Owner

 Recommendations

• The Developers should talk directly to the Stakeholders while keeping the Product Owner informed about the discussions
• Let Product Owner be the final decision maker; however, the details can be discussed directly thus preventing the overload on Product Owner
• Developers should not take decisions directly by talking to the stakeholder. Once discussion with a stakeholder is done, they can update the PO and abide by the decision taken by PO
• Trust between Stakeholder and Developers should be increased. This may be possible if the Stakeholders do not keep escalating against the developers and don’t ridicule them for their mistakes and misunderstandings. Stakeholder must understand that the technical teams are good in technology and may not be able to understand business concepts easily
• Product Owners should not have a controlling mindset. Sometimes  Product Owners who are used to the traditional way of working may initially want to control all the requirements. That usually does not work. Scrum emphasizes on maximizing the value. The Developers may have a unique point of view which may provide a better value to the product. Therefore, Product Owner can consider this as a good way of getting better value by having the Developers talk directly to the stakeholder
• Likewise, sometimes a Product Owner who is used to erstwhile command and control leadership may  feel  insecure or out of control  when  developers talk directly to the stakeholders. In such a scenario, the Product Owner may need to be coached to focus on maximizing the value . Many brains are better than one brain.

The post Antipattern – Product Owner as the mediator between Developers and Stakeholders appeared first on World Of Agile.

A generally used process, structure of pattern of action that initially appears to give effective response to a problem, however it turns out to give more bad response than good. Wikipedia

Anti patterns are generally acceptable solutions to common problems where the solution is not very effective and may result in not-so-good consequences. An antipattern is different from myth or a bad practice. Antipattern initially looks to give a good result or at the face of it looks good, however, it has undesired consequences – Agile Alliance

Read the following Antipatterns published on this site

• Hardening Sprint Antipattern
• Sprint ZERO Antipattern
• Scrum Master the solver of all impediments antipattern
• Scrum Master the overprotector

The post What is an Antipattern? appeared first on World Of Agile.