PO-Proxy – der nicht immer stille Helfer

• Die Rolle des Product Owners ist komplex und herausfordernd.

• Es hat sich in unseren Projekten als sinnvoll herausgestellt, diese Rolle durch einen PO-Proxy zu unterstützen - entweder dauerhaft oder für eine gewisse Einarbeitungszeit.

• Gemeinsam können PO und PO-Proxy das Projekt fachlich und methodisch zum Erfolg führen.

Im Scrum Guide kann die Welt so schön sein. Bestes Beispiel ist der Product Owner (PO) eines agilen Entwicklungsprojekts: Der hat eine entsprechende Ausbildung und ist immer für das Team verfügbar. Die Realität sieht allerdings meistens anders aus: Viele POs haben zwar Business-Erfahrung und eine Produktvision, sind aber mit dem Thema Produktentwicklung nicht eng vertraut und haben viele zusätzliche Aufgaben bzw. Termine. Die Folgen können für das Projekt fatal sein. Doch es gibt eine Lösung für dieses Problem: Ein PO-Proxy.

Wir haben bei Zühlke sehr positive Erfahrungen mit diesem Konzept gemacht und damit vielen Kunden zu guten Ergebnissen verholfen. Grundsätzlich empfehlen wir, einen erfahrenen Ingenieur oder Berater als PO-Proxy zu benennen. Dieser fungiert als Schnittstelle zwischen dem Product Owner (PO) und dem Entwicklungsteam. So können wir nicht nur sicherstellen, dass die Scrum-Regeln eingehalten werden und das Projekt on time und im Budget abgeschlossen wird. Der PO entgeht so auch einer möglichen Überlastung und kann weiterhin seine sonstigen Aufgaben im Unternehmen erfüllen.
 

Was macht der PO eigentlich alles?

Der PO ist für die Wertmaximierung des Produkts verantwortlich. Er entwickelt und vertritt die Produktvision, basierend auf einem tiefen Verständnis der Anforderungen der Stakeholder und der Geschäftsprozesse einerseits, und andererseits der Fähigkeit, diese Vision nach außen zu vertreten. Er hat eine Idee, wie das fertige Produkt aussehen könnte, wer es wann mit welchem Ziel nutzen wird, wie es mit bestehenden Prozessen interagiert, und vor allem, wie daraus ein Mehrwert für die Firma entsteht.

Um die Idee zur Produktreife zu führen, muss sich ein PO drei Herausforderungen stellen:

• dem Stakeholder-Management,
• dem Produktmanagement und dem
• Steuern eines Entwicklungsteams.

Stakeholder-Management

Ein Produkt hat viele Stakeholder, z.B. Endnutzer, Fachabteilungen, QA, IT, Rechtsabteilung, Marketing, Entwicklung. Jeder dieser Stakeholder hat Anforderungen an das Produkt. Je größer das Produkt und je verteilter die Stakeholder, desto unterschiedlicher sind die jeweiligen Anforderungen, und desto häufiger stehen sie zueinander in Konflikt.

Im Dienste der Wertmaximierung hat der PO die Verantwortung, diese heterogenen Anforderungen zu sammeln, zu strukturieren und daraus eine Produktvision abzuleiten, die von allen mitgetragen werden kann. Hier ist einiges an Methodenkompetenz gefordert, denn es müssen Workshops moderiert, Konflikte gelöst und Kompromisse herbeigeführt werden.

Produktmanagement

Einige der Aufgaben eines PO können als ein Teilbereich des Produktmanagements verstanden werden: Definition von Personas und Features, Ableiten einer Entwicklungsroadmap, aktives Management des Product-Scopes. Dies umfasst unter anderem das Schreiben von User Stories, die Pflege und Priorisierung eines Backlogs nach Business Value, sowie die Planung von Releases. Auch dies ist ein anspruchsvoller Tätigkeitsbereich, den man nicht von heute auf morgen erlernen kann.

Steuerung eines Entwicklungsteams

Schließlich muss auch der Wert der Arbeit des Entwicklungsteams maximiert werden, idealerweise durch ein methodisches Vorgehen in der täglichen Zusammenarbeit. Entscheidend ist, dass der PO gegenüber den Entwicklern sowohl die Produktvision kommunizieren kann, als auch das, was konkret gebaut werden soll. Er sollte die Bestandteile der „Agilen Zeremonie“ kennen und produktiv für sich nutzen können: Sprint Review, Team Retrospektive, vor allem das Sprint Planning.

Zusätzlich muss der PO auch dazu beitragen, die Akzeptanzkriterien in User Stories zu formulieren – ein unverzichtbarer Bestandteil für die Abnahme fertiger Software-Inkremente. Darüber hinaus koordiniert der PO auch UX- und Design-Tätigkeiten und diskutiert technische Belange mit dem Team: Architektur, Testautomatisierung oder DevOps sind nur einige der Beispiele . In den meisten Fällen kann sich der PO in diesen Bereichen zwar auf die Kompetenz seines Teams verlassen. Dennoch sollte er genug Wissen haben, um konstruktiv beitragen und auch kritisch hinterfragen zu können.
 

Wo kommt der PO-Proxy ins Spiel?

All diese Aufgaben und Ansprüche können für einen neu benannten PO ziemlich herausfordernd sein. Selbst wenn er in Vollzeit am Produkt arbeitet, braucht er zumindest zu Beginn einen Coach, der ihm zur Seite steht. Viele PO haben aber gar nicht genug Zeit, sie können dem Produkt vielleicht ein bis zwei Tage pro Woche widmen.

Deshalb schlägt Zühlke häufig vor, dem PO einen Stellvertreter, genannt „PO-Proxy“ zur Seite zu stellen. Dies ist ein erfahrener Ingenieur oder Berater, häufig aus dem Requirements-Engineering- oder User-Experience-Bereich. Es handelt sich um eine klassische Beratungsaufgabe – wichtig sind Kommunikations- und Methodenkompetenz, ein strukturiertes Vorgehen und viel Eigeninitiative.
 

Was macht der PO-Proxy konkret?

Der PO-Proxy bildet mit dem Product Owner ein Team. Zwei der wesentlichen Vorteile dieser Art der Zusammenarbeit sind: der Product Owner lernt die für die Rolle nötigen Methoden kennen und kann gleichzeitig den PO-Proxy in die fachliche Domäne einführen. Gleichzeitig ist die PO-Rolle in Person des Stellvertreters für das Entwicklungsteam durchgängig ansprechbar.

Der PO-Proxy ist der Sparringspartner des PO. Er erarbeitet und klärt zusammen mit dem PO die Produktvision, so dass er, wenn es die Projektsituation zulässt und das nötige Vertrauen etabliert ist, gewisse Entscheidungen auch stellvertretend treffen kann. Voraussetzung ist dafür ist, dass er die Haltung des PO genau kennt und die Vision gut verstanden hat. Dessen ungeachtet hat der PO-Proxy jedoch niemals die Produktverantwortung – diese verbleibt zwingend beim PO und damit beim Kunden.

Wie kann das aussehen?

Der Zweck der PO-Proxy-Rolle sollte allen Beteiligten klar sein, und viele Projekte fallen in eine der beiden folgenden Kategorien: PO-Coaching oder PO-Vertretung.

PO-Coaching hilft in Projekten, in denen der Product Owner fachlich sattelfest ist, genügend Kapazität und eine klare Produktvision hat, aber keine Erfahrung mit den PO-Tätigkeiten hat. In diesem Fall berät der PO-Proxy den PO in allen methodischen Fragen mit dem Ziel, sich mit der Zeit selbst überflüssig zu machen. Irgendwann hat seine Begleitung den PO in die Lage versetzt, seine Rolle alleine auszufüllen.

PO-Vertretung ist dann sinnvoll, wenn der vom Kunden benannte PO die Rolle zeitlich nicht ausfüllen kann und Unterstützung in der täglichen Arbeit braucht. Hier ist die Rolle des PO-Proxy auf Dauer ausgelegt, und es ist essentiell, dass dieser möglichst schnell die Produktvision versteht, um die täglichen PO-Aufgaben zu übernehmen. Der PO-Proxy muss sich trotz begrenzter Verfügbarkeit des PO regelmäßig mit diesem abstimmen, damit die Produktentwicklung jederzeit mit der Produktvision übereinstimmt.

Wir bei Zühlke erleben die PO-Proxy-Rolle als eine sinnvolle und pragmatische Ergänzung der von Scrum vorgeschlagenen Rollen, die viel zum Projekterfolg beitragen kann und die sehr gut zu einem wichtigen Grundprinzip agiler Arbeitsweisen passt: die Entwicklung komplexer Systeme als einen andauernden, teambasierten und stark kommunikativ geprägten Lernprozess aufzufassen.