Product Owner: Rolle und Aufgaben

Welche Rolle spielt der Product Owner?

ZUR WEBINAR REIHE
Der Product Owner – das unbekannte Wesen

Das erste, was Organisationen, die agiles Arbeiten und Scrum als Methode einführen wollen, oft in den Sinn kommt, ist das Besetzen der Rollen. Dass agiles Arbeiten viel mehr bedeutet, als Rollen zu besetzten, Sprints und Meetings einzuführen und dass viele Organisationen leider agiles Arbeiten auf diese Dinge reduzieren und hier stoppen, haben wir an anderer Stelle schon hinreichend diskutiert. Hier mehr zum Thema

Aber schon bei der Definition und Besetzung der Rollen tauchen die ersten Probleme auf, die – wenn sie nicht frühzeitig adressiert werden – weitreichende Konsequenzen auf den gesamten Prozess haben werden. Die dabei problematischste Rolle ist zweifelslos die Rolle des Product Owner. Zunächst schon deshalb, weil die meisten Organisationen denken, es wäre die Rolle des Scrum Masters, die besonders schwierig ist und die ganze Aufmerksamkeit verdient. Daher werden in der Regel auch die Scrum Master zu diversen agilen Trainings geschickt bzw. es werden Scrum Master am externen Markt gesucht, während Product Owner in der Vorbereitungsphase oft unterm Radar bleiben.

Welche Aufgaben hat ein Product Owner?

ZUR WEBINAR REIHE

Ich will nicht die Bedeutung der Rolle des Scrum Masters schmälern – beide sind in ihrer Art absolut gleichwertig, aber verglichen mit der Rolle des Product Owner bringt sie doch von vornherein mehr Akzeptanz und Klarheit mit.

Was aber macht die Rolle des Product Owners so problematisch und wie sollte sie angelegt sein, um eine agile Transformation erfolgreich werden zu lassen?

Scrum als Software-implementierungs-methode

Um das besser zu verstehen, zunächst mal ein paar grundsätzliche Überlegungen zum Rollenverständnis in Scrum und zur Einordnung dieser Rollen in der Organisation. Scrum beschränkt sich auf drei Rollen, den Product Owner, den Scrum Master und das Development Team.

Damit bricht Scrum mit der guten Tradition von Projektorganisationen, ständig neue Rollen zu erfinden. Da gibt es neben den klassischen Projektmanager-, PMO-, und Architektur-Rollen oft noch Implementierungsverantwortliche, Release- und Testmanager, Verantwortliche für gute Laune oder für’s Kaffeekochen, usw. Das mag für Projektorganisationen auch immer irgendwie Sinn ergeben und den Gegebenheiten des Projektes gut angepasst sein.

runnScrum: Scaled Agile Projektmanagement für SharePoint

Sit back. Relax.
Let SharePoint runScrum!

Die erste all-in-one scaled Agile Projektmanagement Suite für SharePoint

Dennoch geht Scrum hier den genau entgegengesetzten Weg und beschränkt sich auf genau drei Rollen, unabhängig von allen Projektgegebenheiten. Dies ist zweifellos ein Perspektiv- oder Paradigmenwechsel. Dieser lässt sich eigentlich auch nur damit erklären – und auch das ist eine häufig gestellte Frage, von der wir gleich sehen werden, dass sie mit der Einführung der Rolle des Product Owner sehr viel zu tun haben wird – dass Scrum im eigentlichen Sinne keine Projektmanagementmethode ist.

Scrum versteht sich eher als eine Implementierungsmethode. Ich verfolge diese Disskussion schon eine ganze Weile und beobachte, dass die Welt da etwas gespalten ist. Einige sehen Scrum also Projektmanagementmethode, andere nicht. Selbst im SAFe Guide liest man an einigen Stellen, das Scrum als eine Projektmanagementmethode gesehen wird und es wird dabei kritisiert, dass Scrum selbst nicht skaliert.

Wasserfall wurde übrigens auch nie als Projektmanagementmethode wahrgenommen, warum sollte also Scrum eine sein?

Letzteres stimmt natürlich, aber es liegt wohl eher daran, dass Scrum gar keine Projektmanagementmethode ist, sondern eben nur eine Implementierungsmehtode. Die (skalierten) agilen Projektmanagementmethoden wären dann SAFe, LeSS oder Nexus.

Die Definition der Rollen in Scrum

Für das Rollenverständnis und insbesondere für die Rolle des Product Owners ist diese Feststellung sehr wichtig, wenn auch nicht auf den ersten Blick zu sehen. Also wagen wir einen zweiten Blick und stellen uns die Frage erneut – diesmal aus einer anderen Perspektive – was die Rolle des Product Owners so problematisch macht.

Zunächst mal macht es sie problematisch, dass sie keiner kennt. Diese Rolle gab es früher in Organisationen schlicht nicht. Das gilt zwar auch, oder vielleicht noch mehr für die Rolle des Scrum Masters, aber diese ist dann doch wieder so neu und so anders und eben durch die neue Methode begründet, dass sie viel leichter akzeptiert wird (was leider aber nicht automatisch bedeutet, dass die Menschen, die diese Rolle übernehmen leicht akzeptiert werden, aber das ist ein ganz anderes Thema).

Scrum Prozess: Risikomanagement
Scrum Prozess: Wertschöpfung und Risikomanagement
Wie in Scrum – verstanden als Risikomanagement Methode – schnell eine konkrete Zeit- und Kostenschätzung gegeben werden kann.

Richtig problematisch wird die Rolle des Product Owners dadurch, dass viele Organisationen denken, sie wüssten was damit gemeint ist. Für die einen Organisationen steht die Rolle dem klassischen Business Analysten sehr nahe, für andere steht sie dem klassischen Architekten sehr nahe. Beides ist gleichzeitig falsch und richtig und ich meine damit nicht ein bisschen falsch und ein bisschen richtig, sondern ich meine damit es ist ganz falsch, wenn auch irgendwie verständlich. Verständlich, weil es tatsächlich eine Nähe der Rolle Product Owner zu Architekten und Business Analysten gibt. Ganz falsch, weil die falsche Interpretation dieser Nähe fatale Folgen für das Projekt hat. Und das müssen wir jetzt aufklären.

Zunächst werfen wir dazu noch einen kurzen Blick auf die drei Rollen in Scrum.

Dabei interessiert uns jetzt mal nicht die Definition der Rollen, sondern ihre Zahl. Es sind drei, es sind nur drei und es sind immer nur drei. Dieser in Organisationen oft wenig beachtete Umstand, hat aber weitreichende Konsequenzen. Denn wenn die Implementierung eines Projektes (nicht das ganze Projekt selbst, den Scrum ist ja „nur“ die Implementierungsmethode) – egal welcher Größe und Komplexität, egal welcher Technologie, egal welcher Organisation und in welchem Setup – sich nur auf drei Rollen stützt, dann ist eines von vornherein klar.

Die Rollen sind derart mit Verantwortung aufgeladen und gleichzeitig mit Aufgaben und Zuständigkeiten bestückt und müssen derart perfekt aufeinander abgestimmt sein, dass man sich hier in der Definition der Rolle und der Positionierung innerhalb der Organisation keinerlei Nachlässigkeiten erlauben kann.

Beziehungsweise jede kleine Nachlässigkeit wird über kurz oder lang große Folgeschäden im Projekt verursachen und die „über lang“, also die, die man nicht sofort sieht, werden die Teuren sein.

Und das gilt in der Tat am Meisten für die Rolle des Product Owners. Denn erstens kennt die Rolle niemand und deshalb werden hier Fehler gar nicht so schnell sichtbar, auch schwere Fehler oder Unzulänglichkeiten nicht. Zweitens ist es ohnehin schwer, Menschen auf diese Rolle gut vorzubereiten, wie wir gleich noch sehen werden.

Und schließlich ist die Rolle des Product Owners so exponiert, dass ich aus meiner Erfahrung aus vielen Dutzend Projekten sagen kann, dass ein Product Owner alleine über bis zu 50% der gesamten Team Performance entscheidet, nur durch die Art und Weise wie der die Storys schreibt und wie er sie priorisiert. Ein Product Owner kann mit wenigen (falschen) Handgriffen, ein Projekt komplett zu Fall bringen. Er trägt eine enorme Verantwortung und die lässt sich kaum deligieren.

Klaus Riedel - Agile Coach

Klaus Riedel

Scrum Coach und Agile Transformer Klaus Riedel teilt hier sein Wissen über Agile Scrum

Wer eignet sich am besten für die Rolle

Kommen wir nun zur Rolle selbst. Und auch hier starten wir mit einem Negativbeispiel, weil ich dieses in inzwischen doch einigen Organisation wiederholt gesehen habe. Und da ich hier nicht an Zufall glaube, sehe ich den Grund dafür in der oben beschriebenen Schwierigkeit von Organisaitonen, die Rolle des Product Owners in Abgrenzung zum Business Analysten oder zum Architekten richtig zu positionieren.

Ich sehe oft zwei Variante. In der einen Variante wird ein Product Owner bestimmt und er wird von Business Analysten unterstützt, die im Scrum Team mitwirken.

Da Scrum Teams der Definition nach cross-funktional sein sollen wird das gar nicht als Problem erkannt, sondern die Organisation glaubt, dass sie im besten agilen Sinne handelt.

In der zweiten Varianten wird der Business Analyst zum Product Owner gemacht, weil grundsätzlich das Verständnis ist, dass der Product Owner die Aufgabe hat, das Requirement Engineering zu betreiben und dabei auch das Stakeholder Management macht.

Die Business Analysten sind genau das gewöhnt und daher prädestiniert für die diese Rolle.

Beides falsch, wenn auch irgendwie verständlich oder auf den ersten Blick sogar vernünftig oder naheliegend. Aber auf dem zweiten Blick haben beide Varianten fatale Konsequenzen

Es gibt natürlich noch weitere Varianten, in denen z.B. Architekten zu Product Ownern gemacht werden oder die Product Owner Rolle sogar auf mehrere Personen – dann in der Regel wieder Business Analysten als sogenannter „fachlicher Product Owner“ und Architekten als sogenannter „technischer Product Owner“, auf die ich hier nicht alle eingehen möchte. Die ersten beiden Varianten genügen, um die Rolle des Product Owners anschaulich zu erklären. Daraus kann man dann leicht ersehen, warum auch solche weiteren Varianten wie hier kurz gelistet, ebenfalls nicht gut oder sogar völlig abwegig sind.

Scrum Prozess: Risikomanagement
Scrum Prozess: Wertschöpfung und Risikomanagement
Wie in Scrum – verstanden als Risikomanagement Methode – schnell eine konkrete Zeit- und Kostenschätzung gegeben werden kann.

Um zu verstehen, warum die erste Variante meiner Einschätzung nach nicht gut ist, werfen wir einen Blick auf den Entwicklungsprozess im Allgemeinen selbst. Der sieht doch ganz grob so aus: Geschäftsprozess (Fachlichkeit) -> Funktionalität (Produkt Feature) -> Technik (implementierte lauffähige Version).
Es wird also zunächst ein Geschäftsprozess beschrieben. Dies geschieht auf der Organisationsebene, sei es im Rahmen eines Demandmanagement Prozesses, oder unmittelbar danach. Wenn die Organisation sich entschieden hat, diesen Geschäftsprozess zu implementieren, dann werden daraus bereits als Teil der Umsetzung die Funktionalität beschrieben. Genau das ist die Aufgabe des Product Owners. Anschließend wird die beschriebene Funktionalität vom Development Team implementiert.

Die Business Analysten sind diejenigen – sofern es sie in einer agilen Organisation überhaupt noch gibt – die die Geschäftsprozesse analysieren und beschreiben. Das für sich genommen kann je nach Thema schon ein ziemlich komplexer Prozess sein. Bei einer großen Bank, die beispielsweise in ihrer mobile App den Geschäftsprozess ApplePay einführen wollte, hatten die Business Analysten einige Monate zu tun, alle Rahmenbedingungen für die Einführung dieses Geschäftsprozesses abzuklopfen:

Ist die Organisation darauf vorbereitet, müssen AGB’s geändert werden, wer trägt welche Verantwortung, wie wird das gegenüber der BAFIN reportet, welche Risiken trägt die Bank, etc.

Alles Fragen, die mit dem Produkt zunächst noch nichts zu tun haben. Business Analysten bereiten die Themen vor, die später in Funktionalität gegossen werden. Sie arbeiten damit also auf Organisationsebene und nicht im Scrum-Team. Wenn sie im Scrum-Team bleiben, würde ein Teil des Teams immer sehr asynchron arbeiten, denn sie sollen ja künftige Themen vorbereiten, von denen auch immer nicht klar ist, ob sie überhaupt in das Produkt einfließen werden. Auch wird es schwer, die Teamgröße klein zu halten und oft kommt es sogar dazu, dass sie an Stelle des Product Owner die Storys schreiben.

Zentrale Aufgaben des Product Owner

Damit sind wir schon bei einer zentralen Aufgabe des Product Owners. Er ist das Bindeglied zwischen Projektorganisation mit ihren Stakeholdern und dem Development-Team, die das Produkt implementieren. Er ist der „Eigentümer des Produktes“, nicht des Geschäftsprozesses.

Er beschreibt die funktionalen Anforderungen des Produktes, nicht die fachlichen Aspekte des Geschäftsprozesses. Es kommt hier auf die Unterscheidung von Fachlichkeit und Funktionalität an. Denn die Funktionalität muss nicht nur den Geschäftsprozess implementieren, sondern gleichzeitig auch noch Rücksicht auf viele andere Faktoren nehmen, wie zum Beispiel nicht funktionale Anforderungen, Compliance Anforderungen, Governance, Security, usw.

Scrum Training

Agile in a Day

Wir trainieren Ihr Team, coachen Ihre Stakeholder und führen Ihr Projekt zum Erfolg!

Als Bindeglied ist der Product Owner eine Art Anwalt des Kunden. Er vertritt die Interessen der Stakeholder in Bezug auf die gewünschten Geschäftsprozesse, aber gleichzeitig auch die Interessen seiner eigenen Kanzlei, sprich seines eigenen Entwicklungsteams. Er wird also die Funktionalität so setzen, dass der Geschäftsprozess gut implementiert ist, aber die Software wartungsfähig bleibt und überhaupt mit überschaubarem Aufwand erstellt werden kann. Alle, die schon mal diese Rolle hatten, wissen, wie viele Kompromisse man da ständig eingehen muss. In der hier beschriebenen Funktion ist der Product Owner für die Wertmaximierung des Produktes verantworlich. Auch das sollte nicht mit der Wertmaximierung des Geschäftsprozesses verwechselt werden.

Somit kommen wir jetzt zur zweiten Variante. Den Business Analysten zum Product Owner zu machen, ist ebenfalls keine gute Idee. Denn die Rolle des Business Analysten bleibt wichtig auf der Organisationsebene.

Und der Product Owner arbeitet wie gerade gezeigt auf einer ganz anderen Ebene, nämlich auf der Produktebene und nicht auf der Geschäftsprozessebene.

Mit dem Stakeholdermanagement und der Transformation von aller Anforderungen in Funktionalität und er Etablierung einer effektiven Kommunikation zwischen allen Beteiligten haben Product Owner ohnehin schon genug zu tun. Wenn sie sich jetzt auch noch so tief in die Geschäftsprozesse einarbeiten sollen, kommen regelmäßig ihre originären Aufgaben zu kurz. Die Software wird zu Feature-lastig entwickelt und baut viele technische Schulden auf, oder die Teams werden nicht mehr optimal betreut, was zu Lasten der Velocity geht.

Die Rolle der Kommunikation für den erfolgreichen Transferprozess

Diese Überlegung führt uns zum nächsten zentralen Aspekt der Product Owner Rolle. Kommunikation. Die Rolle der Kommunikation im agilen Prozess habe ich hier als „wechselseitige Einladung in einanders Wirklichkeit“ beschrieben, also als einen essentiellen Transferprozess von Produktvisionen in technisch implementierte Features in kürzester Zeit.

Der Product Owner ist der Organisator dieses Transferprozesses, ihm muss es gelingen, seine Produktvision so schnell wie möglich in die Köpfe der Mitglieder seines Entwicklungsteams zu bekommen, damit diese sofort und in kleinen Paketen in kurzen Iterationen komplexeste System entwickeln können.

Der Product Owner ist vor allem anderen ein Kommunikator. Er muss also weder ein Fachexperte für die Geschäftsprozesse sein, noch ein Architekt, der die technische Architektur der Anwendung im Detail kennt. Er muss natürlich Zugriff auf beide – und natürlich auch noch auf einige andere – haben und er muss natürlich die funktionale Architektur der Anwendung kennen.

Es wäre also gut, wenn er weiß was Software ist und wie sie grundsätzlich aufgebaut ist, denn das ist der Gegenstand, den er beschreibt. Aber eben aus einer funktionalen- und nicht technischen Perspektive.

Um all das tun zu können, benötigt er ein paar Rahmenbedingungen. Und diese Rahmenbedingungen entsprechen der Beschreibung der Rolle, wie sie im Scrum Guide aufgeführt sind. Er trägt die alleinige Verantwortung für das Product Backlog, also für den Inhalt und die Reihenfolge der Backlog Items, ganz gleich ob es sich dabei um User-Storys (Features), Enabler-Storys (Technical Depts), Bugs oder andere Aufgaben handelt.

Diese Verantwortung kann er nicht deligieren, aber natürlich kann er sich Hilfe holen wie z.B. bei der Beurteilung von Technical Depts. Vor allem soll das Entwicklungsteam ihn gut beraten können, weshalb die Kommunikation, also der Transfer der Produktvision in das Bewußtsein der Team Mitglieder so wichtig ist. Denn nur wenn sie diese Vision gut verstanden haben, können sie ihn auch kompetent beraten und alle gemeinsam diese in dem Produkt entwickeln und darin zum Leben erwecken.

Leave a Comment

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.