Proxy Product Ownership

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 (e.g. Too Busy, 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.