Der sagenumwobene Product Owner

Viele Mythen ranken sich um die Rolle des Product Owner: für die Einen ist der Product Owner beispielsweise der Chef des Teams oder eben der neue Projektleiter, während er für die anderen vor allem das Sprachrohr des Kunden oder sogar der Kunde selbst ist. Manche erkennen auch gar keinen Sinn in der Rolle des Product Owners oder sehen die Aufgabe zumindest nicht als so wichtig an, dass diese in Vollzeit ausgeübt werden müsste.

Definition der Rolle des Product Owners

Im Scrum-Guide heißt es, dass der Product Owner verantwortlich sei, „den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht“ – aber eben auch, dass die Umsetzung je nach Organisation, Scrum-Team und sogar Einzelpersonen abweichen kann.

Sind die verschiedenen Interpretationen der Rolle also vielleicht gar nicht so abwegig?

Tatsächlich lässt die Definition im Scrum-Guide einen gewissen Interpretationsspielraum. Das ist der Tatsache geschuldet, dass Scrum sich nicht als fertige Methode sondern als Rahmenwerk versteht, „innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können“. Daher wird in Scrum selbst nur wenig festgelegt, was die Rolle des Product Owners betrifft.

Aufgaben des Product Owners

Im Vordergrund steht dabei aber vor allem die Verantwortung für die Wert des Produkts und gerade nicht für den Prozess oder die Führung des Teams.

Die Aufgaben des Product Owners sind:

• die Product Backlog Einträge klar zu formulieren

• die Einträge im Backlog so zu sortieren, dass Ziele und Missionen optimal erreicht werden können

• den Wert der Arbeit zu optimieren, die das Entwicklungsteam erledigt

• sicherzustellen, dass das Product Backlog sichtbar, transparent und für alle klar ist und daraus erkennbar ist, woran das Team als nächstes arbeitet

• sicherstellen, dass die Einträge vom Entwicklungsteam im erforderlichen Maß verstanden werden

Dabei nimmt der Product Owner innerhalb des Teams, aber auch innerhalb einer nach Scrum arbeitenden Organisation, tatsächlich eine gewisse Sonderrolle ein.

Der Product Owner verfügt innerhalb seines Teilgebiets über eine Entscheidungsgewalt. Zwar nicht über die Menschen im Team oder den Prozess, aber eben über die Prioritäten fürs Produkt und damit letztlich auch über die Prioritäten des Teams. Dabei sollen seine Entscheidungen auch über Teamgrenzen hinweg respektiert werden; der Scrum-Guide hebt hierbei explizit hervor, dass das Team nicht zur Arbeit an anderen als den vom Product Owner bestimmten Anforderungen gezwungen werden soll. Das ist sehr wichtig, denn ähnlich wie in Kanban ist ein koordinierter Zufluss von Arbeit beziehungsweise Fokussierung (vgl. hierzu die 5 Werte von Scrum) sehr wichtig, damit das Erreichen von Sprint-Zielen nicht zum Glücksspiel wird.

Gleichzeitig ist der Product Owner auch verantwortlich (rechenschaftspflichtig) für den „Wert“ des Produkts, womit letztlich nichts anderes gemeint ist als: stimmt der Ertrag im Verhältnis zum aufgewendeten Nutzen?

Macht es Sinn, den Product Owner mit zusätzlichen Aufgaben und Privilegien ausstatten?

Eine ganz schöne Verantwortung.

Auf einmal wirkt die oben aufgeführte Aufgabenbeschreibung als könne sie dieser großen Verantwortung gar nicht gerecht werden. Gar nicht so abwegig also, den Product Owner auch andere Aufgaben wahrnehmen lassen zu wollen oder gar mit zusätzlichen Privilegien auszustatten. Womit aber Gefahren verbunden sind, derer man sich bewusst sein sollte, und auch der Nutzen durchaus anzuzweifeln ist.

In diesem Zusammenhang fallen mir Aussagen der Dozenten bei meiner ScrumMaster-Schulung ein, wonach es zu den Aufgaben des ScrumMasters gehöre, über die Folgen von Entscheidungen aufzuklären. Das ist eben auch hier so: grundsätzlich kann man alles machen, aber man muss sich eben auch fragen, ob das zweckdienlich ist. Bei der Rolle des Product Owners sollte man sich vor allem fragen, ob die zusätzlichen Aufgaben oder Befugnisse im Einklang mit dem eigentlichen Ziel stehen oder ob dadurch Interessenkonflikte entstehen.

Ein paar Beispiele dafür:

• Wenn der Product Owner gleichzeitig der disziplinarische Vorgesetzte ist, die regelmäßige Leistungsbeurteilung vornimmt oder über Boni entscheidet: wie förderlich ist das für einen offenen Umgang zwischen dem Team und dem Product Owner?

• Wenn der Product Owner nicht nur Prioritäten setzt, sondern gleichzeitig auch entscheidet wieviel das Team in einem Sprint umsetzen muss: wie wahrscheinlich ist es, diese Ziele zu erreichen und trotzdem nachhaltig – also nicht die Gesundheit der Mitarbeiter gefährdend – zu arbeiten?

• Wenn der Product Owner auch technische Entscheidungen trifft oder sich in den Prozess einmischt, wie förderlich ist das für Selbstorganisation und ein Gefühl der gemeinsamen Verantwortung?

Ich verstehe, dass es schwer ist, die Verantwortung für etwas zu übernehmen, wenn man (zumindest gefühlt) nicht die nötigen Mittel dafür an die Hand bekommt. Das ist, als würde man kurz vor dem Startschuss an einen Steinblock gekettet werden und solle mit dieser Last nun trotzdem den Marathon gewinnen.

Nur geht es dem Team oft genau so.

Nun ist Scrum zwar kein Sport, aber wenn es einer wäre, dann wäre es ein Teamsport. Der lebt weniger vom Heldentum einzelner Personen (auch wenn es sicher gerade beim Fußball oftmals so wirkt ;)) sondern von einem dynamischen Zusammenspiel, in dem jeder Einzelne seine Fähigkeiten einbringen und entfalten kann. Dabei könnte ein Product Owner oder eine Product Ownerin eine Führungskraft im besten Sinne sein, nämlich eine die Andere erfolgreich macht, indem sie etwa die technischeren Tätigkeiten durch gute Vorarbeit leichter macht.

Tatsächlich kann es auch eher hinderlich sein, wenn der Product Owner den anderen Teammitgliedern hierarchisch übergeordnet ist, da es eine Distanz zwischen Product Owner und dem Team schafft, die für die Erfüllung seiner Aufgaben nicht unbedingt immer hilfreich ist.

Eine etwas realistischere Aufgabenbeschreibung

Bei näherer Betrachtung hat die Aufgabe des Product Owners auch einen größeren Umfang als man denkt.

Letztlich obliegt dem Product Owner nämlich das gesamte Anforderungsmanagement: das heißt er muss die Anforderungen sowohl ermitteln, als auch von allen beteiligten Personen die notwendigen Informationen zur Präzisierung (und Machbarkeit!) einholen, das Backlog Refinement selbst und eine Kosten-/Nutzen-Abwägung durchführen. Der Product Owner muss für Rückfragen sowohl der Stakeholder als auch des Teams zur Verfügung stehen, Akzeptanzkriterien festlegen und natürlich die Sprint-Ergebnisse prüfen.

Wenn der Product Owner für ein Produkt verantwortlich ist, das auf dem freien Markt bestehen muss (im Gegensatz zu einem rein internen Produkt), beinhaltet seine Arbeit auch Marktbeobachtung und Marktanalyse, um zum Beispiel Trends zu erkennen auf die bei der Priorisierung reagiert werden muss.

Bei all diesen Aufgaben kann der Product Owner das Team einbeziehen und je nach Fähigkeiten sogar Aufgaben ans Team abgeben.

Vergleich mit der Rolle des Projektleiters

Oft wird die Rolle des Product Owners mit der eines Projektleiters verglichen. Tatsächlich weicht die Rolle aber in vielen Punkten davon ab.

Zuallerst kommt einem da wohl mal die Tatsache in den Sinn, dass der Product Owner gar nicht für ein Projekt sondern ein Produkt und dann auch noch für dessen Geschäftswert und nicht bloß für das Erreichen der vom Auftraggeber gemachter Zielvorgaben verantwortlich ist. Das macht es erforderlich, sich stärker inhaltlich mit dem Produkt und zu erreichenden Zielen auseinander setzen und ist (eigentlich) eine längerfristige Angelegenheit als ein Projekt.

Ein guter Product Owner muss eng mit dem Team zusammenarbeiten – wahrscheinlich enger als das beim Projektleiter der Fall ist.

So ist bei Scrum explizit vorgesehen, dass das Team entscheidet, wieviel in einem Sprint erledigt wird. Die Planung erfolgt also gerade nicht durch einen Projektleiter sondern muss immer wieder neu „ausgehandelt“ und an die Erkenntnisse aus den letzten Sprints angepasst werden. Nicht zuletzt deshalb ist bei einem agilen Vorgehen wie Scrum gewünscht, dass sich alle Teammitglieder verpflichten auf ein bestimmtes Ergebnis – in der Regel ein gutes Produkt – hinzuarbeiten. Das fällt leichter, wenn die Leute im Team auch tatsächlich Einfluss auf das Produkt und den Prozess haben und ihre fachliche Meinung nicht ungehört verpufft. Außerdem hängen für den Product Owner wichtige Faktoren wie der notwendige Aufwand für die Entwicklung von Features (und damit die Kosten-/Nutzen-Rechnung) in hohem Maße auch von technischen Aspekten ab, über die mit dem Doing betrauten Mitarbeiter üblicherweise den besten Überblick haben.

Last but not least macht es natürlich auch einen Unterschied, dass bei Scrum ja gerade nicht „up front“ sondern aufgrund empirisch gewonnener Erkenntnisse geplant wird.

Fazit

Die Aufgabe des Product Owners verlangt kommunikative Fähigkeiten, ein Verständnis fürs Produkt, und ein gewisses Talent fürs Anforderungsmanagement. Dabei gilt es zu bedenken, dass das erforderliche Einfühlungsvermögen, um sich in die potenziellen Kunden zu versetzen, nicht jedermanns Sache ist.

Ob ein Product Owner benötigt wird, der sich voll auf die beschriebenen Aufgaben fokussieren kann oder diese Aufgabe auch im Team aufgehen kann, muss jeder selbst entscheiden. Meine Erfahrung ist nur die: wenn Anforderungsmanagement nur so nebenbei oder zu einmaligen Zeitpunkten gemacht wird, erzeugt das oft unnötige Reibung und damit Zeitverlust. Der Worst Case ist, wenn Tickets im Ping-Pong-Verfahren hin und her gehen, obwohl die Anforderungen schon am Anfang eines Produktzyklus geklärt hätten werden können. Deshalb denke ich, dass wohl alle Beteiligten davon profitieren würden, wenn sich jemand zu einem signifikanten Teil seiner Zeit diesem Arbeitsbereich widmen kann.

Übrigens: Ich finde die Bezeichnung im Hinblick auf die angestrebte Team Ownership – und dass agil eigentlich nichts für einsame Helden ist – reichlich blöde, aber was will man machen.