Die Rolle des Product Owners in Scrum

Der Product Owner (PO) ist die Person im Scrum Team, die dafür verantwortlich ist, den Wert des Produktes, der aus der Arbeit des Entwicklungsteams entsteht, zu maximieren. Somit ist er auch für den ROI (Return on Investment) verantwortlich und vereint die Interessen der Stakeholder mit denen des Entwicklungsteams. Wie dies geschieht, kann je nach Organisation, Scrum Team und Einzelperson stark variieren. In der Praxis lassen sich häufig Szenarien beobachten, in denen sich Product Owner vom eigentlichen Zweck ihrer Rolle weit entfernt haben. Anstatt dass sie sich der  Wertmaximierung widmen (können), agieren sie als Backlog Administratoren oder sehen sich fälschlicherweise als “Chef” des Entwicklungsteams.

 

In Folge #44 gehe ich daher speziell auf den Product Owner ein. Ich erläutere die Intention hinter seiner Rolle und leite daraus die Qualitäten eines guten Product Owners ab. Abschließend biete ich anhand einer Checkliste die Möglichkeit, sich selbst in der Arbeit als Product Owner zu reflektieren.  

Die Intention hinter der Rolle des POs

 

Welche Funktion ein PO in Scrum übernimmt, wird besonders deutlich, wenn man sich vor Augen hält, welche Probleme ein gutes Product Ownership lösen soll. Ich verweise in diesem Zusammenhang sehr gern auf ein Video von Jeff Sutherland. In diesem Video erläutert er schrittweise die Entstehung von Scrum. Überraschenderweise zeigt sich dabei, dass der PO nicht von Anfang an Teil des Scrum Teams war. Diese Tatsache führte damals zu einer Reihe von Dysfunktionen, die es durch die Besetzung der Rolle des POs zu beseitigen galt. Einer dieser Missstände ließ sich bei den Stakeholdern beobachten:

 

In den meisten Umgebungen gibt es eine Vielzahl an Stakeholdern, die ohne die Anwesenheit eines Product Owners selten “aligned” sind. Darüber hinaus kann gesagt werden, dass es in Sprints häufig unterschiedliche Meinungen und Annahmen darüber gibt, was genau gebraucht wird oder passend ist.

 

Ein weiteres Problem, das durch die Abwesenheit eines Product Owners entsteht, liegt in der Doppelfunktion, die das Entwicklungsteam dadurch übernehmen muss: fokussiertes Arbeiten am Inkrement bei gleichzeitigem Weitblick auf die Vision. Das Entwicklungsteam konzentriert sich normalerweise auf die Entwicklung des Produktinkrements und sorgt dafür, dass Dinge richtig umgesetzt werden. Es ist eine sehr herausfordernde Aufgabe, sich parallel zu diesem starken Fokus stets mit dem “Großen und Ganzen” zu befassen. Die Einführung der Rolle des Product Owners sollte genau bei diesen Problemen Abhilfe schaffen.

Die Aufgabe des POs ist es also, dafür zu sorgen, dass das gesamte Team gut aufgestellt ist, diesen Herausforderungen zu begegnen. Seine Aufgaben lassen sich wie folgt zusammenfassen: 

  • Der PO arbeitet den Kontext auf, damit das Entwicklungsteam in der Lage ist, fokussiert Wert schaffen.
  • Er schafft eine übergreifende Orientierung, beispielsweise durch die Product Vision.
  • Der PO baut einen Fahrplan mit allen Themen, die aktuell gesehen werden, um diese Vision umzusetzen.
  • Der PO sorgt dafür, dass aufkommende Themen die passende Granularität besitzen: Themen in naher Zukunft sind detailreicher als Themen in weiter Ferne.
  • Er sorgt dafür, dass Themen kurz vor Beginn des Sprints die richtige Größe besitzen, um dem Team erstens genügend Optionen zu bieten und zweitens sicherzustellen, dass mehrere Themen in den Sprint mit aufgenommen werden können. 
  • Der PO sorgt dafür, dass Themen eindeutig priorisiert sind, sodass klar ist, welche Dinge wichtig sind und zuerst gemacht werden sollen 

Um diese Aufgaben zu erfüllen, nutzt der PO das Product Backlog. Dieses Scrum Artefakt ist sozusagen sein Hilfsmittel, der Verantwortung der Wertmaximierung durch Priorisierung, Sortierung und Verfeinerung der einzelnen Items gerecht zu werden. Darüber hinaus dient das Backlog im Sprint Planning dazu, sich auf Items für den anstehenden Sprint festzulegen. Das Team wählt dabei seine Items aus, während der Product Owner die Ownership übernimmt und im Gegenzug erwartet, bei Rückfragen mit eingebunden zu sein. Somit hilft der PO dabei, den Wert des zu erstellenden Produktes zu optimieren, indem er mithilfe des Product Backlogs ein Alignment zwischen allen Beteiligten herstellt, durch Priorisierung den Wert des zu schaffenden Produktes maximiert und die wertvollsten Optionen für den kommenden Sprint vorbereitet.

 

Die Qualitäten eines guten Product Owners

 

Damit das Zusammenspiel zwischen PO, Scrum Team und Stakeholdern gut funktioniert, muss ein PO folgende Qualitäten haben

  • Verfügbarkeit
    Ein guter Product Owner muss verfügbar sein. Er verfügt über ausreichend Zeit, das Backlog zu pflegen und steht sowohl Stakeholdern und ganz besonders auch dem Team für Rückfragen stets zur Verfügung. 
  • Autorität
    Der Product Owner braucht eine gewisse Autorität, um Entscheidungen treffen zu können. Dies ist besonders wichtig, um dem Team klare Antworten auf Rückfragen zum Umfang im Sprint zu geben und dadurch (teure) Verzögerungen zu vermeiden. Darüber hinaus muss ein Product Owner ausreichend Autorität besitzen, um trotz unterschiedlicher Meinungen der Stakeholder ein eindeutig priorisiertes Backlog zu schaffen, dass dabei hilft, den Wert zu optimieren.
  • Domänenwissen
    Neben dem Entwicklungsteam braucht auch ein Product Owner ein Verständnis und Wissen von der Kundendomäne. Dies bedeutet nicht, dass er alles bis ins letzte Detail wissen muss, jedoch benötigt er ein ausreichendes Verständnis, um mit Stakeholdern und dem Entwicklungsteam sprechen und interagieren zu können.

 

Für mich sind alle drei Punkte sehr wichtig, Jedoch beobachte ich in vielen Umgebungen, dass man sich sehr stark auf das Domänenwissen fokussiert und vom Product Owner  erwartet, als “wandelnde Spezifikation” stets Allwissend zu sein. Dies ist meiner Meinung nach eine übertriebene Auslegung der Anforderungen an das Domänenwissen eines Product Owners. Der entscheidende Faktor, der aus einem Product Owner einen guten Product Owner macht, ist für mich allerdings die Autorität. In der Praxis wird dieser Punkt häufig als Teil der Persönlichkeit betrachtet: Man hat sie, oder man hat sie nicht. Hat der Product Owner diese Autorität nicht, hat man eben die falsche Person eingestellt. Im Gegensatz dazu erlebe ich auch oft, dass erwartet wird, diese Autorität von der Organisation in einer  Ritterschlag ähnlichen Zeremonie verliehen zu bekommen. Beides halte ich schlichtweg für falsch.

 

In den seltensten Fällen wird eine verliehene Autorität einen Product Owner vor Druck aus benachbarten Abteilungen schützen. Darüber hinaus ist es meiner Meinung nach nicht hilfreich, darauf zu warten, bis eine Person auftaucht, die scheinbar ausreichend charismatisch und durchsetzungsstark zugleich ist – denn das passiert höchstwahrscheinlich relativ selten. Ich halte es vielmehr für essentiell, dass man sich als Product Owner stets im klaren darüber ist, dass dieser Autoritätsaspekt eine wichtige Rolle bei der erfolgreichen Ausübung seiner Rolle darstellt. Anstelle jedoch auf einen Ritterschlag oder eine Gabe zu vertrauen, rate ich lieber dazu, an dieser Autorität zu arbeiten – beispielsweise im Rahmen eines Trainings. Dies ist meiner Meinung nach der wirkungsvollste Weg, sich als guter Product Owner nachhaltig in seiner Umgebung zu positionieren.

Was ein PO nicht ist

 

Der technische Experte

In Scrum ist das Entwicklungsteam die zentrale Einheit. Durch sie wird aus leichtgewichtigen Anforderungen ein wahrer Mehrwert für den Kunden geschaffen. Sie übernehmen die Expertenfunktion in puncto Technik. Es ist daher wichtig, dass der Product Owner als Kundenvertreter agiert und nicht in die Rolle des Technikexperten schlüpft. Als Technikexperte wird er zum Vorarbeiter für das Team. Er trifft die Entscheidungen und verhindert, dass sich das Team als selbstorganisierte Einheit findet und aufbaut. Das Team übernimmt in diesem Szenario fälschlicherweise nur noch die Funktion eines Delivery-Teams. Ownership und Motivation gehen dadurch verloren. Damit der Product Owner nicht als Vorarbeiter agiert, muss sichergestellt sein, dass das Entwicklungsteam seiner Funktion als Technikexperten ohne Einschränkungen und unabhängig nachkommen kann. Ist dies der Fall, ist ein Micromanagement seitens des Product Owner nicht notwendig. 

 

Der Allwissende

Vor Scrum wurde wurde zum Beginn eines klassischen Entwicklungsprojektes eine umfassende Planung vorgenommen und jedes Detail festgelegt. Beim Wechsel zur agilen Arbeitsweise kann daher leicht die Erwartung an den Product Owner entstehen, dass dieser die Formulierung  einer umfassenden Spezifikation übernimmt. Es wird vergessen, dass selbst der Product Owner in einem dynamischen Umfeld nicht Allwissend sein kann. Auch er ist Teil einer empirischen Vorgehensweise – Lernen gehört also auch für ihn mit zum Prozess. Seine Aufgabe besteht darin, die Kundensicht zu vermitteln und dadurch die bestmögliche Lösung zu finden. Es ist wichtig, dass dem Team bewusst ist, dass der Product Owner nicht der Allwissende sein soll. 

 

Der Antreiber für das Team

In Scrum herrscht eine Art Gewaltenteilung, die sicherstellen soll, bestmögliche Ergebnisse hervorzubringen. Der Scrum Master ist dafür verantwortlich, dass eine motivierte Umgebung entsteht, in der das Entwicklungsteam versucht, sein Bestes zu geben. Das Team übernimmt dabei die Verantwortung für den Sprint. Der Product Owner ist für die Backlog Pflege und das Einbringen der Kundensicht zuständig. Wird der Product Owner zum Antreiber, stört er bestehende Gewaltenteilung. Zwängt der Product Owner seinem Team unrealistische Pläne auf, resultiert daraus häufig das Problem, dass Sprints unrealistisch geplant werde. Fehler oder Hindernisse können dadurch zu spät aufgedeckt und beseitigt werden. Es ist daher wichtig, dass die Unabhängigkeit des Entwicklungsteams geschützt ist.

 

 

Ein guter Product Owner braucht immer auch einen guten Scrum Master

 

Im Rahmen der Gewaltenteilung entsteht ein Spannungsfeld zwischen Stakeholdern und der Arbeit des Entwicklungsteams. Als Product Owner sollte man sich daher auf die anspruchsvolle Arbeit innerhalb dieses Spannungsfeldes konzentrieren können. Dafür braucht es zum einen ein Team, dass seiner Verantwortung im Sprint gerecht wird sowie Interaktionspunkte, in denen das Team effizient und fokussiert eingebunden werden kann. Genau hier sollte ein guter Scrum Master als Servant Leader helfen, die dafür notwendigen Rahmenbedingungen zu schaffen und sicherzustellen, dass das Entwicklungsteam unabhängig und eigenverantwortlich arbeiten kann und oben genannte Dysfunktionen nicht entstehen. 

 

Die Aufrechterhaltung dieser Gewaltenteilung wir in vielen Umgebungen oft unterschätzt. Nicht selten stellen sich Organisationen die Frage, warum ein Scrum Master eigentlich notwendig ist (mehr zur Rolle des Scrum Masters als Servant Leader findest du hier). Einen guten Scrum Master im Team zu haben, ist jedoch essentiell. Denn: Selbst wenn die Umgebung eigentlich passend scheint, kann das Gleichgewicht dennoch ganz leicht und unbewusst gestört werden. Beispielsweise ist es nur allzu menschlich für einen Product Owner, aus einem entstehende Lieferdruck und dem damit verbunden Wunsch der Stakeholder schneller fertig zu werden, den Sprint-Umfang in einem “schwachen” Moment hinterfragen oder beeinflussen zu wollen. Dennoch hat es zur Folge, dass das die Unabhängigkeit und damit auch Ownership im Team verloren gehen. Es ist daher die Aufgabe des Scrum Masters, dieses Gleichgewicht aufrecht zu erhalten indem er Events überwacht und prüft, ob Team und Product Owner ihre Funktion bei der Ausübung ihrer Arbeit richtig leben (können). Es liegt ebenfalls in seinem Verantwortungsbereich, Gegenmaßnahmen zu ergreifen oder  dementsprechend Feedback zu geben, sollte dies nicht mehr der Fall sein. 

 

Wie diese Unterstützung konkret aussieht habe ich in dem gemeinsamen Artikel Wie hilft der Scrum Master dem Product Owner? mit Tim Klein ausführlicher ausgearbeitet.

Wo finden wir passende Kandidaten für den Product Owner?

 

Die Frage, wo sich passende Kandidaten für die Rolle des Product Owners finden, lässt sich nicht einfach beantworten. Man kann meiner Meinung nach nicht pauschal behaupten, dass ein Product Owner der Kundendomäne entspringen muss. Die richtige Antwort lautet daher: Es kommt drauf an. In einigen Umgebungen macht es Sinn, in anderen wiederum nicht. Es gilt, den Kontext näher zu betrachten. Warum es nicht sinnvoll ist, den Product Owner pauschal auf Kundenseite zu suchen, möchte ich im Folgenden anhand von mehreren Beispielen näher erläutern. 

 

Nehmen wir einmal an, es gäbe drei Abteilung, die zusammen ein Produkt entwickeln. Man könnte nun auf die Idee kommen, dass einer der Bereiche (beispielsweise der größte Bereich) den Product Owner stellt. Dies wäre allerdings nicht sinnvoll, da der mächtigste Bereich die anderen Bereiche unter Umständen in gewissen Situationen “unterwirft”. In diesem Fall würde ich eher empfehlen, die übergreifende Rolle von einem erfahrenen Projektmanager übernehmen zu lassen.

Ein anderes Beispiel, warum es unter Umständen keinen Sinn ergibt, den Product Owner auf Kundenseite zu suchen, ist die Arbeit in einem Agenturumfeld. Hier werden viele Projekte gleichzeitig bearbeitet und natürlich verfolgt man innerhalb einer Agentur nicht nur die unterschiedlichen Kundeninteressen, sondern versucht unter Umständen auch, Synergien zu schaffen. Entspringt der Product Owner auf Kundenseite, ist es nicht möglich, diese Synergien zu nutzen. Es wäre auch in diesem Fall besser, einen Product Owner innerhalb der Agentur zu finden. 

Die Beispiele zeigen, dass die Auswahl eines geeigneten Product Owners kontextabhängig ist. Darüber hinaus ist es meiner Meinung nach essentiell, sich bei der Auswahl des geeigneten Product Owners darauf zu besinnen, dass es sich hier um eine Profession handelt und nicht um eine Tätigkeit, die einfach mal eben nebenher erledigt werden kann. Die bereits erläuterten Qualitätskriterien (Verfügbarkeit, Domänenwissen, Autorität) spielen daher eine große Rolle bei der Entscheidung. Darüber hinaus sehe ich auch die Erfahrung als ein wichtiges Kriterium. Ein sinnvoller Weg ist es meiner Meinung nach auch, mögliche Kandidaten bei der Vorbereitung der Product Ownership in die Prozesse mit einzubeziehen. In dieser gemeinsamen Arbeit zeigt sich häufig sehr deutlich, welche Rolle die richtige ist für die einzelnen Personen. Zum Start kann dann meist sehr genau festgemacht werden, wer in eine Stakeholder-Rolle schlüpft und wer die Rolle des Product Owners übernehmen kann und auch möchte. 

 

Woran muss ich arbeiten, um ein besserer Product Owner zu werden?

 

Es gibt viele Praktiken, Techniken und Modelle, die man als Product Owner aufgreifen kann, um seine Rolle zu verbessern und gut zu leben. Allerdings sind die eingesetzten Mittel von Kontext zu Kontext unterschiedlich. Es ist daher meiner Meinung nach wichtig, sich über die Intention seiner Handlungen im Klaren zu sein. 

Anhand eines Self-Assessments möchte ich Product Ownern Impulse zur Reflexion geben, um potentielle Möglichkeiten zur Verbesserung aufzudecken. Anhand einer Liste habe ich Idealsituationen aus Sicht der Stakeholder, des Entwicklungsteams und des Product Owners aufgeführt. Ziel ist es, zu erkennen, wo und wie stark der eigene Kontext von der Idealsituation abweicht. Die Liste stellt eine gute Basis dar, um zu reflektieren und sich zu fragen, was aus Product Owner Sicht dazu beigetragen werden kann, um bestimmte Situationen zu verbessern. Auf diese Weise entsteht eine klare Intention, sich als Product Owner zu verbessern –  ohne dabei gleich eine Methode als Allheilmittel aufgreifen und umsetzen zu müssen.

Zusammenfassung

Der Product Owner war anfangs nicht Teil des Scrum Teams. Aus den daraus entstehenden Dysfunktionen zeigte sich, dass es in einer dynamischen Umgebung eine klare Aufstellung braucht, die dem Team dabei hilft den Wert des Produktes zu optimieren. Die Einführung de Product Owner Rolle sollte dies sicherstellen. Oft wird der Product Owner jedoch in der Praxis als Vorarbeiter oder Antreiber gelebt. Neben dem Product Owner ist daher auch ein  guter Scrum Master essentiell, der dabei hilft Scrum gut zu leben. Die Entscheidung, wer als Product Owner geeignet ist, ist abhängig vom Kontext sowie den Qualitätskriterien Verfügbarkeit, Domänenwissen und Autorität. 

Hast du Fragen oder Anmerkungen? Ich freue mich immer über Feedback.

Alle Folgen kannst du dir auch über meinen Podcast “Scrum meistern” anhören. Besuche auch meinen YouTube Channel “Scrum meistern”.

Dort findest du alle Interview-Videos.

Übrigens: Solltest Du interessiert sein, dich im Rahmen eines Trainings noch einmal genauer mit den Scrum Events oder Rollen theoretisch sowie praktisch auseinanderzusetzen, empfehle ich das Certified Scrum Master Training. Speziell für Product Ownership empfehle ich das Certified Porduct Owner Training.