Proxy Product Owner – a Scrum Antipattern?

Have you ever looked for the term ” Proxy Product Owner” in the Scrum Guide 2020? It does not appear in it. Since the guide “only” names three responsibilities with Scrum Master, Developers and Product Owner, this is of course not particularly surprising. “The Product Owner is one person, not a committee” is a central statement in the guide. One person, not a committee.

This person is responsible for maximising product value and effective product backlog management, including developing and communicating the product goal, creating, ranking and communicating backlog items, and ensuring that those involved understand the product backlog. In theory, this sounds like a manageable amount of work, but in practice it often means a great deal of work. It is good that the Scrum Guide acknowledges this and formulates: “The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable”. And to whom could the Product Owner delegate the above-mentioned activities and at the same time retain responsibility for the results? To the Proxy Product Owner.

What is a Proxy Product Owner?

The term “proxy “¹ comes from the Latin term “proximus” and means “the nearest”. The proximate is a substitute, replacement or representative. And thus a Proxy Product Owner is nothing more than a representative of the Product Owner. (In some situations it is also an intermediary, more on that later).

Of course, there are dogmatists who argue that the Proxy Product Owner is a Scrum antipattern. “What is not in the Scrum Guide is not Scrum!” Some also speak alternatively of a Scrumbut: “We use Scrum, but with a Proxy Product Owner”. Yes, it is probably both an antipattern and a Scrumbut. And now? With a little shoulder-shrugging reference to “Inspect and Adapt”, I would like to shed some light on the motives, the usage scenarios and the challenges in practice. And then you can decide for yourself whether the use of a proxy PO – please do not abbreviate as PPO² – might make sense in your organisation.

Motives for using a Proxy Product Owner

There are various reasons for using a Proxy Product Owner. Here is a small selection:

• There is a risk of losing the overview of the product or software development or the product.
• There is a multitude of individually acting, important stakeholders with intrapersonal and interpersonal goal conflicts.³
• The product backlog is so large that it is difficult for one person to work on it.⁴
• Development takes place in different locations and possibly in different time zones.

In short, the workload is too big for one person or the work organisation is difficult. With the help of the Proxy Product Owner, both can be improved. In concrete terms, a proxy could, for example help

• with stakeholder communication,
• in Backlog Refinement,
• in the Daily Scrum or
• in preparing the participants of the sprint planning.

Different operational scenarios

Two typical deployment scenarios for a Proxy Product Owner can be derived from the above-mentioned motivations:

1. a large-scale, centralised and
2. a decentralised, distributed product or software development.

Interestingly, the LeSS Huge Framework, which addresses agile product creation in complex environments and larger organisations, explicitly defines the role of the Area Product Owner for these deployment scenarios, whereby the Product Owner focuses on the overall optimisation of the product and the various Area Product Owners form a Product Owner Team⁵.

Other deployment scenarios are conceivable:

3. business unit and IT as well as
4. client and contractor.

In many organisations there are discussions about where the Product Owner sits: in the business unit or in IT? Many organisations impose the PO in the business unit, arguing that it must “set the direction” and the IT unit must ensure that everything “necessary” is taken into account in order to place the “customer focus” above the “system focus”. Provided that the stakeholders interpret the role of the Proxy Product Owner as a intermediary and not as a representative, the use of a Proxy PO in such a setting could be worthwhile.

In the deployment scenario of client and contractor, the Product Owner on the contractor side usually communicates with the client – possibly with a dedicated contact person, a representative of the technical department, a product manager or even a Product Owner. And what happens if the Product Owner on the contractor side is not available? Rumour has it that some Product Owners are even entitled to take a holiday and others drop out now and then due to illness. The answer is clear, of course: here, too, the use of a Proxy PO can make a lot of sense. Namely as a representative in the direction of the client and as a intermediary in the direction of the Scrum team at the contractor.

Last but not least, there is another scenario:

5. Mentoring with PO and Proxy PO

This scenario is often overlooked, but from an organisation’s point of view it makes sense to gradually introduce Product Owners to the responsible work. Good Product Owners don’t just fall from the sky and it takes time to build up necessary skills such as technical understanding, decision-making competence, communication, leadership or solution-oriented thinking. Some organisations choose junior positions for this – caution: scrumbut – others minimise the economic risk and transfer the responsibility of smaller product developments⁶ and some try mentoring with PO and proxy PO.

Limits and challenges of using a Proxy Product Owner

Of course, there are also limitations and challenges to using a Proxy PO. The limitations include “one-off” aspects such as

• the definition of the product goal,
• the definition of the product strategy to achieve the product goal,
• the alignment of the organisation with the product goal and strategy, and
• the authority to cancel a sprint,

which the Product Owner may not delegate. Control of the product budget is certainly not delegated either.

The challenges can be manifold:

• Proximity to the Scrum team could suffer or even be lost. And this could lead to decisions by the Product Owner no longer being respected.
• The interaction with the Scrum Master may need to be adjusted, as in practice there may be shifts or overlaps of activities. For example, if desired, the Scrum Master should promote cooperation with stakeholders, help establish empirical product planning for a complex environment and support the team in understanding the Product Backlog entries.
• There may also need to be alignment of roles and responsibilities with other roles in the organisation – business analysts, requirements engineers, systems analysts – especially if the Proxy PO is acting not just as a representative but as a intermediary.
• There must be clarity internally (and externally) as to when the “original” and when the proxy is addressed, and how long the representation or intermediation lasts (short-term or permanent, temporary and situational or continuous).
• There should be regular exchange (or even mentoring) but no micromanagement between PO and Proxy PO.
• Regular exchange between different Proxy POs is also useful.
• Understanding the processes in the organisation, getting to know the people involved and, most importantly, building trust can be a long process. If the trust of the technical department or the external client in the process, the product development or the work of the Proxy PO suffers, then the use is counterproductive.
• A typical dysfunction is that the Product Owner takes credit when developments go smoothly and the proxy is “blamed” when things do not go well. This quickly leads to a negative dynamic in the Scrum team that is difficult to stop.

And last but not least, the organisation may clarify what the temporary representative does when he is not active as a substitute or intermediary. A role in the Scrum team as a developer, for example, is of course not recommended.

Conclusion

The use of a Proxy Product Owner can make sense for an organisation if it succeeds in overcoming the challenges that come with it. If it is successful, the Product Owner is relieved and the Scrum Team, the specialist department or the external client are given another contact person who is often easier to reach. In addition, agile product development can be better organised in a complex environment or in larger organisations, and the representative or intermediary can contribute his or her capabilities and at the same time expand his or her skills, depending on the deployment scenario. From my point of view, this is a win-win-win-win situation and that despite being a Scrumbut and Scrum antipattern.

Notes:

If you like the post, feel free to share it with your network or leave a comment.

[1] The term proxy is also used in computer networks or in requirements engineering with the so-called Proxy User.
[2] Among other things, PPO stands for a high-temperature resistant plastic called Polyphenylene Oxide and for the enzyme Polyphenol Oxidase or the Personal Protection Officer in the Metropolitan Police Service. In the context of a Proxy PO, it therefore makes sense not to use this abbreviation. Here you can find further explanations of PPO.
[3] Overview of different types of conflicting objectives
[4] If a backlog is too extensive, it might make sense to eliminate requirements.
[5] Here you can find an article about Product Owner Teams.
[6] Again and again there are discussions in practice about whether the PO has the overall responsibility for a product and is responsible for the success of the product and ultimately also for marketing, sales, development, operations and support. There is probably no universal solution to this discussion.

Michael Schenkel has published further articles in the t2informatik blog, including

t2informatik develops and modernises software as a service provider. Click here to learn more.