Proxy Product Owner – ein Scrum Antipattern?

Haben Sie im Scrum Guide 2020 schon mal nach dem Ausdruck “Proxy Product Owner” gesucht? Er taucht darin nicht auf. Da der Guide mit Scrum Master, Developers und Product Owner “lediglich” drei Verantwortlichkeiten benennt, ist das natürlich nicht sonderlich überraschend. “The Product Owner is one person, not a committee” lautet eine Aussage im englischen Original. Eine Person, kein Gremium.

Diese Person ist verantwortlich für die Maximierung des Produktwertes und ein effektives Product Backlog Management, inklusive Entwicklung und Kommunikation des Produktziels, Erstellung, Reihung und Kommunikation der Backlog Items, und der Sicherstellung, dass die Beteiligten das Product Backlog verstehen. In der Theorie klingt das nach einer übersichtlichen Menge an Tätigkeiten, in der Praxis bedeutet dies oftmals sehr viel Arbeit. Gut, dass der Scrum Guide dies anerkennt und formuliert: “The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable”. Und an wen könnte der Product Owner die genannten Tätigkeiten delegieren und gleichzeitig die Ergebnisverantwortung beibehalten? An den Proxy Product Owner.

Was ist ein Proxy Product Owner?

Der Begriff “Proxy”¹ geht auf den lateinischen Ausdruck “proximus” zurück und bedeutet “der Nächste”. Der Nächste ist ein Stellvertreter, Ersatz oder Repräsentant. Und damit ist ein Proxy Product Owner nichts anderes als ein Vertreter des Product Owners. (In manchen Situationen handelt es sich auch um einen Vermittler, dazu später mehr.)

Natürlich gibt es Dogmatiker, die argumentieren, dass es sich beim Proxy Product Owner um ein Scrum Antipattern handelt. “Was nicht im Scrum Guide steht, ist kein Scrum!” So mancher spricht auch alternativ von einem Scrumbut: “We use Scrum, but with a Proxy Product Owner”. Ja, vermutlich handelt es sich sowohl um ein Antipattern als auch um ein Scrumbut. Und nun? Mit einem kleinen schulterzuckenden Hinweis auf “Inspect and Adapt” möchte ich gerne die Beweggründe, die Einsatzszenarien und die Herausforderungen in der Praxis beleuchten. Und dann können Sie für sich entscheiden, ob der Einsatz eines Proxy PO – bitte nicht als PPO abkürzen² – in Ihrer Organisation sinnvoll sein könnte.

Beweggründe für den Einsatz des Proxy Product Owners

Es gibt verschiedene Beweggründe, einen Proxy Product Owner einzusetzen. Hier eine kleine Auswahl:

• Es besteht die Gefahr, den Überblick über die Produkt- oder Softwareentwicklung bzw. das Produkt zu verlieren.
• Es gibt eine Vielzahl an individuell agierenden, wichtigen Stakeholdern mit intrapersonellen und interpersonellen Zielkonflikten.³
• Das Product Backlog ist so groß, dass es für eine Person schwierig ist, es zu bearbeiten.⁴
• Die Entwicklung findet an verschiedenen Standorten und ggf. in verschiedenen Zeitzonen statt.

Kurzum: die Arbeitslast ist für eine Person zu groß oder die Arbeitsorganisation ist schwierig. Mit Hilfe des Proxy Product Owners lässt sich beides verbessern. Konkret könnte ein Stellvertreter bspw.

• bei der Stakeholderkommunikation,
• dem Backlog Refinement,
• im Daily Scrum oder
• bei der Vorbereitung der Teilnehmenden des Sprint Plannings

helfen.

Verschiedene Einsatzszenarien

Zwei typische Einsatzszenarien für einen Proxy Product Owner lassen sich aus den genannten Beweggründen ableiten:

1. eine umfangreiche, zentrale und
2. eine dezentrale, verteilte Produkt- oder Softwareentwicklung.

Interessanterweise definiert das LeSS Huge Framework, das eine agile Produkterstellung in komplexen Umgebungen und größeren Organisationen adressiert, explizit für diese Einsatzszenarien die Rolle des Area Product Owners, wobei sich der Product Owner auf die Gesamtoptimierung des Produkts konzentriert und die verschiedenen Area Product Owner ein Product Owner Team⁵ bilden.⁶

Denkbar sind weitere Einsatzszenarien:

3. Fachbereich und IT sowie
4. Auftraggeber und Auftragnehmer.

In zahlreichen Organisationen gibt es Diskussionen darüber, wo der Product Owner sitzt: im Fachbereich oder in der IT? Viele Organisationen verordnen den PO im Fachbereich und argumentieren, dass dieser „die Richtung vorgeben“ und der IT-Bereich dafür sorgen muss, dass alles „Notwendige“ berücksichtigt wird, um den „Kundenfokus“ über den „Systemfokus“ zu stellen. Unter der Voraussetzung, dass die Beteiligten die Rolle des Proxy Product Owners als Vermittler und nicht als Stellvertreter interpretieren, könnte sich der Einsatz eines Proxy PO in einem solchen Setting lohnen.

Beim Einsatzszenario Auftraggeber und Auftragnehmer kommuniziert üblicherweise der Product Owner auf Auftragnehmerseite mit dem Auftraggeber – evtl. mit einem dedizierten Ansprechpartner, einem Vertreter der Fachabteilung, einem Produktmanager oder auch einem Product Owner. Und was passiert, wenn der Product Owner auf Auftragnehmerseite nicht verfügbar ist? Gerüchten zufolge haben manche Product Owner sogar Anspruch auf Urlaub und andere fallen ab und an krankheitsbedingt aus. Die Antwort ist natürlich klar: auch hier kann der Einsatz eines Proxy PO viel Sinn ergeben. Und zwar als Stellvertreter in Richtung Auftraggeber und als Vermittler in Richtung des Scrum Teams beim Auftragnehmer.

Last but not least gibt es noch ein weiteres Szenario:

5. Mentoring mit PO und Proxy PO.

Dieses Szenario wird gerne übersehen, dabei ist es aus Sicht einer Organisation sinnvoll, Product Owner schrittweise an die verantwortungsvolle Tätigkeit heranzuführen. Gute Product Owner fallen nicht einfach vom Himmel und es braucht Zeit, benötigte Skills wie technisches Verständnis, Entscheidungskompetenz, Kommunikation, Führung oder lösungsorientiertes Denken aufzubauen. Manche Organisationen wählen dafür – Vorsicht: Scrumbut – Junior-Positionen, andere minimieren das wirtschaftliche Risiko und übertragen die Verantwortung von kleineren Produktentwicklungen⁷ und manche versuchen es mit einem Mentoring mit PO und Proxy PO.

Grenzen und Herausforderungen beim Einsatz eines Proxy Product Owners

Natürlich gibt es auch Grenzen und Herausforderungen beim Einsatz eines Proxy PO. Zu den Grenzen gehören “einmalige” Aspekte wie

• die Definition des Produktziels,
• die Festlegung der Produktstrategie zur Erreichung des Produktziels,
• die Ausrichtung des Unternehmens auf das Produktziel und die Produktstrategie und
• die Befugnis, einen Sprint abzubrechen,

die der Product Owner nicht delegieren darf. Auch die Kontrolle des Produktbudgets wird sicherlich nicht übertragen.

Die Herausforderungen können mannigfaltig sein:

• Die Nähe zum Scrum Team könnte leiden oder gar verloren gehen. Und das könnte dazu führen, dass Entscheidungen vom Product Owner nicht mehr respektiert werden.
• Das Zusammenspiel mit dem Scrum Master muss ggf. justiert werden, da es in der Praxis zu Verschiebungen oder Überschneidungen von Tätigkeiten kommen kann. So soll der Scrum Master bspw. auf Wunsch die Zusammenarbeit mit Stakeholdern fördern, bei der Etablierung einer empirischen Produktplanung für ein komplexes Umfeld helfen und das Team unterstützen, die Product Backlog Einträge zu verstehen.
• Ggf. muss auch mit anderen Rollen der Organisation – Business Analysten, Requirements Engineers, Systemanalytiker – ein Abgleich der Aufgaben und Verantwortlichkeiten erfolgen, insbesondere dann, wenn der Proxy PO nicht nur als Stellvertreter sondern als Vermittler agiert.
• Es muss intern (und extern) Klarheit herrschen, wann das “Original” und wann der Stellvertreter angesprochen wird, und wie lange die Stellvertretung oder Vermittlung andauert (kurzfristig oder dauerhaft, temporär und situativ oder kontinuierlich).
• Es sollte einen regelmäßigen Austausch (oder gar ein Mentoring), aber kein Mikromanagement zwischen PO und Proxy PO geben.
• Auch der regelmäßige Austausch zwischen verschiedenen Proxy PO ist sinnvoll.
• Das Verstehen der Prozesse in der Organisation, das Kennenlernen der Beteiligten und vor allem der Aufbau von Vertrauen kann ein langer Prozess sein. Leidet das Vertrauen der Fachabteilung oder des externen Auftraggebers in den Prozess, die Produktentwicklung oder die Arbeit des Proxy-PO, dann ist der Einsatz kontraproduktiv.
• Eine typische Fehlfunktion besteht darin, dass der Product Owner die Lorbeeren einheimst, wenn Entwicklungen reibungslos verlaufen, und der Stellvertreter “Schuld” ist, wenn es nicht gut läuft. Dies führt schnell zu einer negativen Dynamik im Scrum Team, die schwer zu stoppen ist.

Und zu guter Letzt darf die Organisation klären, was der temporäre Stellvertreter tut, wenn er nicht als Ersatz oder Repräsentant aktiv ist. Eine Rolle im Scrum Team bspw. als Entwickler empfiehlt sich natürlich nicht.

Fazit

Der Einsatz eines Proxy Product Owners kann für eine Organisation sinnvoll sein, wenn es ihr gelingt, die damit einhergehenden Herausforderungen zu meistern. Glückt es, wird der Product Owner entlastet und das Scrum Team, die Fachabteilung oder der externe Auftraggeber erhalten einen weiteren, oftmals leichter zu erreichenden Ansprechpartner. Zudem lässt sich die agile Produktentwicklung in einem komplexen Umfeld bzw. in größeren Organisationen besser organisieren und der Stellvertreter bzw. Vermittler kann je nach Einsatzszenario seine Fähigkeiten einbringen und gleichzeitig seine Skills ausbauen. Aus meiner Sicht ist das eine Win-Win-Win-Win-Situation und das, obwohl es sich um ein Scrumbut und Scrum Antipattern handelt.

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk.

[1] Der Begriff Proxy wird u. a. auch bei Rechnernetzen oder im Requirements Engineering mit dem sogenannten Proxy User genutzt.
[2] PPO steht u.a. für einen hochtemperaturbeständigen Kunststoff namens Polyphenylenoxid, für das Enzym Polyphenoloxidase oder die Prüfungs- und Promotionsordnung im Schweizer Hochschulwesen. Im Kontext eines Proxy PO ist es daher sinnvoll, auf diese Abkürzung zu verzichten. Hier finden Sie weitere Erläuterungen zu PPO.
[3] Verschiedene Arten von Zielkonflikten im Überblick
[4] Ist ein Backlog zu umfangreich, könnte es Sinn ergeben, Anforderungen zu eliminieren.
[5] Hier finden Sie einen Artikel über Product Owner Teams.
[6] Neben Inspect and Adapt ist Skalierung ein gutes Argument im Dialog über Scrum Antipattern.
[7] Immer wieder gibt es in der Praxis Diskussionen darüber, ob der PO die Gesamtverantwortung für ein Produkt trägt und für den Erfolg des Produkts und in letzter Konsequenz auch für Marketing, Verkauf, Entwicklung, Betrieb und Support verantwortlich ist. Eine allgemeingültige Lösung für diese Diskussion gibt es wohl nicht.

Michael Schenkel hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.