Pattern of the Month: Proxy Product Ownership

Product ownership is the art and science of maximizing the empirical delivery of value. A Product Owner must be able to express clear accountability for a value stream and ought to be competent to represent the interests of all of its stakeholders to those teams which perform the work. In Agile practice, empiricism is achieved by the frequent and incremental release of valuable work done. The cumulative value delivered to stakeholders by the evolving product can thus be inspected, and the team backlog of work adapted accordingly. Although multiple stakeholders can be represented by a Product Owner, the role itself cannot be allowed to degenerate into a committee. Having a Product Owner as a single point of contact provides essential clarity when the scope of work is emergent and in need of frequent revision. 

Finding a Product Owner who has the above competencies and the time to invest in the evolution of a complex product is a significant challenge for some organizations. There can be many stakeholders in a single organization who do not have the time to represent their interests. The best-qualified individual can often have seniority and may be unable to make the commitment. A proxy is frequently resorted to in such cases. This pattern of proxy Product Ownership can manifest itself in various ways.

For example, a supplier might provide a proxy Product Owner as part of their service to a client. Product ownership resides with the customer, but the proxy is authorized to represent the product on the client’s behalf. If there are multiple customers being served by the product, then a proxy will be required to arbitrate between them and to liaise with the delivery teams. Each customer must cede a measure of authority to the proxy. In this model, the proxy must be respected and recognized as having executive authority regarding product ownership so as not to be undermined.

Within a single organization, the best-qualified Product Owner might have other responsibilities and be too busy to effectively represent the interests of product stakeholders. This proxying model is often found at enterprise scale where legacy subsystems are being rationalized and replaced with a common architectural component. Each stakeholder expects the component to work but may have little incentive to actually own it. Multiple proxies will be used instead, each of whom can represent certain product capabilities at an operational level, thereby shielding the Product Owner and minimizing their involvement. Again, great discipline is needed for this to work.

Proxying can, therefore, be reduced to either a single proxy or multiple proxies facing the team (see illustration). This is quite complex and a strong case can be made for regarding such proxying arrangements as an anti-pattern. After all, if genuine Product Ownership is hard to establish, then perhaps the risks are too high — or the value too low — for any work on it to be authorized.

Proxy Product Ownership

• Intent: Authorize a suitable stand-in should a Product Owner be indisposed.

• Proverbs: There are no small parts; only small actors.

• Also known as: Stand-in.

Motivation

A Product Owner will often have multiple responsibilities and can be accountable for many products. He or she may not have the time to represent a product to a Development Team and might not be co-located with them. A proxy is needed who can represent product ownership adequately on the PO’s behalf, and liaise with a Development Team on an operational day-to-day basis.

Structure

A Product Owner authorizes one or more Proxies to represent product ownership to one or more Development Teams. Each Development Team will only have one Proxy, such that product ownership is unambiguously represented. Each Proxy will be able to explain and prioritize the items on the Product Backlog to a Development Team, to negotiate a Sprint Backlog with them, to review, accept, and release the increments produced every iteration, and to liaise with the Product Owner as necessary and in a timely manner.

Applicability

Proxying is useful when product ownership is clear, but the Product Owner is not able to represent the product at an operational level. Proxying cannot be done for a notional or unclear Product Owner, or when product ownership is weak, divided, or absent.

Consequences

Proxying allows a Development Team to deliver meaningful increments of value without the direct involvement of the Product Owner, who is thereby freed for other activities. Note that the Product Owner remains fully accountable for the product, and for its Return On Investment, even when a Proxy is in place. The Product Owner will need to liaise closely with his or her Proxies in order to ensure that product interests are competently represented. Note also that although proxying is a viable model, it is difficult to implement well and is often associated with certain antipatterns (i.e., "too busy" and "unresolved proxy"). There is a further danger that proxying will degenerate into product ownership by committee, the symptoms of which are weak decision making and unclear accountability.

Implementation

In Extreme Programming, the Customer Representative may effectively represent product ownership by Proxy. In DSDM, the Business Ambassador, Business Visionary, Business Analyst, and Business Advisor each proxy in certain respective matters for the Business Owner. Scrum does not address the matter of product ownership by Proxy.

See Also

• Product Ownership
• Too Busy
• Unresolved Proxy
• Common Product Owner Traps by Roman Pichler.
• Product Ownership in Practice The Agile Zone.
• Product Owners, Not Proxies by Ken Schwaber.