Suche
Eine Rolle, viele Konzepte: Was macht einen guten Product Owner aus?

Der Product Owner: Backlog-Boss und Chaos-Bezwinger

Ann-Cathrin Klose

© Shutterstock.com / siribao

Ein agiles Team führt sich selbst – aber am Ende muss doch jemand den Kopf für das Endresultat hinhalten. Das ist der Product Owner. Er trifft die Entscheidungen über das Product Backlog und ordnet das selbstorganisierte Chaos. Wie füllt man die Rolle am besten aus?

Der Product Owner ist der Vertreter des Auftraggebers im agilen Team: Ihm gehört das Produkt. Und was heißt das genau? Die Rolle des Product Owners ist ein Bestandteil des agilen Frameworks Scrum. Somit entstammt die erste Definition, die zum Verständnis der Aufgaben eines Product Owners herangezogen werden kann, dem offiziellen Scrum Guide: Der Product Owner ist verantwortlich für die Organisation des Product Backlogs, also der To-Do-Liste des agilen Projekts. Er kann die notwendigen Arbeitsschritte zur Backlog-Pflege durch das Projektteam ausführen lassen oder selbst durchführen; am Ende trägt er aber die alleinige Verantwortung für das Backlog.

Der Scrum Guide: offizielle Definition des Product Owners

Der Product Owner kann die Interessen einer Gruppe von Stakeholdern oder eines Ausschusses vertreten, der über bestimmte Aspekte der Produktentwicklung berät. Am Ende ist jedoch der Product Owner derjenige, der die Entscheidungen trifft. Dafür hat er auch die größte Entscheidungsgewalt im agilen Projekt: Das Wort des Product Owners ist Gesetz. Niemand darf seine Entscheidungen hinsichtlich das Product Backlogs überstimmen; niemand darf also die Prioritäten anders sortieren, als es der Product Owner für richtig hält. Das heißt: Gemacht wird, was der Product Owner will.

Konkret definiert der offizielle Scrum Guide die Aufgaben des Product Owners im Rahmen des Backlog-Managements wie folgt:

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed.

Das ist jedoch nicht die einzige Definition der Aufgaben des Product Owners, die sich im Netz finden lässt. Bereits der Scrum Guide verweist darauf, dass die Rolle des Product Owners durchaus auf vielfältige Weisen ausgefüllt werden kann. Die Vorschläge im Netz zur Ausgestaltung dieser Scrum-Rolle müssen also nicht zwingend im Konflikt mit den offiziellen Vorgaben stehen – auch wenn es manchmal so scheint. So umfassen die verschiedenen Konzepte der Rolle des Product Owners auch Vorschläge dazu, dass das gesamte Team sich diese Rolle teilen sollte oder die Idee einer skalierten Product Owner-Rolle für große Projekte, die die Verantwortung erneut auf verschiedene Stufen verteilt.

Praktisch Angewandt: der Fels in der Brandung

Eine interessante Ausarbeitung zu den Aufgaben des Product Owners hat Adam Pahlevi vorgelegt. Er fasst die Zuständigkeiten des Product Owners so zusammen:

The most important aspect of the job description of a product owner: to manage chaos.

Damit meint Pahlevi, dass der Product Owner alle Unklarheiten beseitigen sollte – er stellt die Schnittstelle zwischen Team und Stakeholdern dar; er vertritt die Kundenmeinung im Team. Ist nicht klar, wohin die Reise gehen soll, muss also der Product Owner ansprechbar sein, um dem Team die Orientierung zurück zu geben. Das oberste Prinzip lautet dabei natürlich, Werte für den Endnutzer zu schaffen – und somit auch für den Auftraggeber.

Außerdem verweist Pahlevi auf einen weiteren wichtigen Aspekt in der praktischen Ausgestaltung der Rolle des Product Owners: Der Product Owner ist der einzige, der dazu berechtig ist, fertige Features zu akzeptieren oder abzulehnen. Er darf das Deployment entwickelter Inkremente zurückstellen, wenn er glaubt, dass sie nicht der Definition of Done oder den Akzeptanzkriterien entsprechen oder wenn er andere Konflikte identifiziert. Somit liegt schlussendlich auch die Produktqualität in seiner Verantwortung.

Programmierer oder Manager?

Muss er dazu aber programmieren können? Ob diejenigen Teammitglieder eines Scrum-Teams, die nicht am Schreiben des Codes beteiligt sind, Entwickler sein müssen oder nicht, ist hochgradig umstritten. Mancher findet, dass Scrum Master und Product Owner nur dann wirklich verstehen können was das  Team tut, wenn sie über fundierte IT-Kenntnisse verfügen. Das sehen aber nicht alle so.

Häufig haben Product Owner einen Business-Hintergrund; manche waren zuvor Produktmanager und sollen nun im agilen Umfeld eine neue Aufgabe ausfüllen. Das kann zu Problemen führen, immerhin unterscheiden sich die Aufgaben eines Product Owners und eines Produktmanagers signifikant voneinander! So hat der Produktmanager immer auch die langfristige Produktentwicklung im Sinn, während der Product Owner primär an den nächsten Sprint, das nächste Release denkt. Tiefer Einblick in die geschäftlichen Vorgänge erleichtert es allerdings durchaus, die Interessen der Kunden und Endnutzer richtig einzuschätzen. Insofern können ehemalige Stakeholder oder Produktmanager durchaus sehr gute Product Owner abgeben. Eine Vermischung der Aufgaben muss aber vermieden werden.

Lowell Lindstrom meint außerdem, dass es durchaus hilfreich ist, wenn ein Product Owner programmieren kann – wer sich als Teil des Entwickler-Teams versteht, könne bessere Entscheidungen treffen, meint Lindstrom. Allerdings ist diese technische Expertise auch für Lindstrom nicht die einzige Kompetenz, die ein Product Owner braucht. Vielmehr muss er außerdem ein guter Geschichtenerzähler sein, um seinem Team die Anforderungen zu vermitteln; er muss in der Lage dazu sein, deeskalierend in Konflikte eingreifen zu können. Ein guter Product Owner muss aber auch klar Stellung beziehen und darf die Auseinandersetzung mit dem Management nicht scheuen, wenn es zu Problemen kommt.

Verantwortung der Product Owners verteilen?

Außerdem, so Lindstrom, könne der Product Owner Arbeit delegieren und ein Team um sich versammeln, das ihm bestimmte Arbeitsschritte abnimmt. Dass das Entwicklerteam in den Prozess der Backlog-Pflege einbezogen werden kann, sagt ja bereits der Scrum Guide; Lindstroms Idee geht aber weiter. Seiner Meinung nach sollte ein informelles Team rund um den Product Owner zwar durchaus Entwickler aus dem Scrum-Team umfassen, aber auch fachliche Experten für Bereiche, die außerhalb des Wissensgebiets des Product Owners liegen.

Stephen Frein glaubt ebenfalls, dass die Verantwortung des Product Owners auf mehrere Schultern verteilt werden sollte – am besten auf das gesamte Entwickler-Team! Er kritisiert, dass die Rolle des Product Owners die einzige Aufgabe in einem Scrum-Team sei, die von einer einzelnen Person ausgefüllt werde. Das führe zu einer Art von Erwartungshaltung, die nicht gut für das Team wäre:

Since the PO is responsible for requirements and prioritization, the team treats the PO as a living specification document.

Selbstorganisation nicht behindern

Statt selbst mit den Stakeholdern oder Kunden kommunizieren zu müssen oder sich Gedanken über die Anforderungen zu machen, würde das Team das alles vermeiden. Sie haben ja ihren Product Owner, der all diese Dinge für sie übernimmt. Somit könnten sich die Entwickler in ihren Wohlfühlbereich zurückziehen und nur noch Code schreiben, statt wirklich agil zu arbeiten. Dies könne aber verhindert werden, meint Frein, indem sich das gesamte Team die Rolle des Product Owners teilt.

Was Frein damit eigentlich meint, ist, dass der Product Owner, ganz im Sinne des Scrum Guides, gewisse Aufgaben ans Team abgeben soll. Nicht jedes Gespräch muss er selbst führen, nicht jede Entscheidung alleine treffen. Tatsächlich könnten daraus, das Team zu sehr aus der Verantwortung zu nehmen und im Unklaren zu belassen, sogar Probleme entstehen. Trifft der Product Owner jede Entscheidung selbst, kann das in einer Art von Micromanagement ausarten. Das wäre dann nicht mehr agil. Insofern ist eine gewisse Aufgabenteilung dringend nötig, um den Job des Product Owners gut auszufüllen.

Skalierte Rollenzuweisungen

Ein weiteres Konzept zur Rolle des Product Owners entstammt dem Gebiet der skalierten agilen Frameworks. Nun ist der Product Owner natürlich zu allererst eine klassische Scrum-Rolle und somit jede Adaption in ein anderes Framework automatisch davon abzugrenzen; ein Blick über den Tellerrand lohnt sich dennoch auch für diejenigen, die klassisches Scrum anwenden. Immerhin ist Agile, wenn es richtig gemacht wird, nie an starren Regeln orientiert, sondern richtet sich nach den Bedürfnissen des Teams. Auch Scrum darf also angepasst werden!

Skalierte Frameworks setzen bei der Differenz zwischen Produktmanager und Product Owner an, die bereits benannt wurde. SAFe, ein agiles Framework, das auf die Arbeit mit vielen Teams parallel ausgelegt ist, sieht ein Stufenmodell der Backlog-Pflege vor. Dabei werden beide Funktionen, Produktmanager und Product Owner, integriert. Ein Produktmanager ist für die Roadmap, also die langfristige Planung, sowie das Backlog für das gesamte Programm zuständig. Auch liegt die Definition der Akzeptanzkriterien für vollständige Features in seiner Hand – eigentlich eine klassische Aufgabe des einen, einzigen Product Owners.

Die einzelnen Product Owner sind hingegen fest in ihre Teams integriert und tragen die Verantwortung für das Team-Backlog. Sie definieren die Ziele für die einzelnen Sprints des Teams, formulieren die Stories, die bearbeitet werden und die Akzeptanzkriterien für die zu entwickelnden Inkremente. Sie sind aber auch an der Ausarbeitung des Program Backlogs und der Product Vision beteiligt, die in den Verantwortungsbereich des Produktmanagers fallen. Ihre primäre Aufgabe liegt jedoch bei den kleinen Entwicklungsschritten, nicht auf Ebene des gesamten Produkts.

Der optimale Product Owner?

Eine solche Aufgabenteilung ist im großen Maßstab unverzichtbar. Ein zentrales Charakteristikum des Product Owners ist nämlich auch sein Kontakt zum Team: Genau wie ein guter Scrum Master muss der Product Owner ständig für die Teams, mit denen er zusammenarbeitet, ansprechbar sein. Mancher fordert sogar, dass ein Product Owner an jedem agilen Meeting der Teams teilnehmen muss! Das bedeutet jedoch, dass er täglich Zeit mit jedem seiner Teams verbringen müsste. Das ist nicht zu leisten, wenn ein Product Owner mehr als ein paar wenige Teams betreut.

Wie genau die Aufgaben und der Zuständigkeitsbereich eines Product Owners aussehen, ist also durchaus unterschiedlich definiert. Am Ende handelt es sich beim Product Owner um die Person im agilen Team, die die Verantwortung für den Projektverlauf tragen muss, ohne dem Team die Freiheit zu nehmen. Wie auch der perfekte Scrum Master muss ein Product Owner ein servant Leader sein, um seine Rolle richtig gut auszufüllen. Er muss klare Vorgaben machen und sich zugleich aus den Dingen heraushalten, die das Team selbst entscheiden muss – das ist eine anspruchsvolle Aufgabe. Am Ende muss also jeder Product Owner selbst herausfinden, wie er seine Aufgabe am besten ausfüllen kann.

Verwandte Themen:

Geschrieben von
Ann-Cathrin Klose
Ann-Cathrin Klose
Ann-Cathrin Klose hat allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz studiert. Bereits seit Februar 2015 arbeitete sie als redaktionelle Assistentin bei Software & Support Media und ist seit Oktober 2017 Redakteurin. Zuvor war sie als freie Autorin tätig, ihre ersten redaktionellen Erfahrungen hat sie bei einer Tageszeitung gesammelt.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.