Agile Frameworks sind voll im Trend. Seit der Veröffentlichung des Agilen Manifests, arbeiten unzählige Unternehmen mit Scrum und Kanban und weichen immer mehr vom Wasserfall Modell ab. 

In der Praxis zeigt sich allerdings immer wieder, dass die Rolle des Product Owners unterschiedlich gelebt wird und es teilweise kein klares Verständnis über die damit einhergehenden Aufgaben, Verantwortungen und das Mindset gibt.

Daher möchten wir in diesem Beitrag einige Anti-Patterns darstellen, die wir in unserer Tätigkeit als Dienstleister im Bereich agiler Softwareentwicklung immer wieder beobachten konnten. Bevor wir allerdings darauf eingehen, werfen wir vorweg einen Blick auf die Definitionen dieser Rolle.

‍

Was ist die Definition des Product Owner und was sind seine Aufgaben?

‍

Der Scrum Guide sagt: “Der Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren, der sich aus der Arbeit des Entwicklungsteams ergibt. Die Vorgehensweise kann je nach Organisation, Scrum-Team und Einzelperson sehr unterschiedlich sein.”

Der Product Owner ist somit der “Botschafter” der Anwender. Im Idealfall ist er auch selbst Anwender und somit Experte der fachlichen Anforderung des zu entwickelnden Produkts. Er stellt in seiner Rolle durch seine enge Zusammenarbeit mit dem Entwicklungsteam sicher, dass der Geschäftswert des Produktes und somit sein Nutzen für den Endkunden maximiert wird. Er definiert in Abstimmung mit den Stakeholder das “Was” und die Prioritäten der Anforderungen.

Was sind nun die in der Praxis am häufigsten anzutreffenden Defizite im Rollenverständnis des Product Owners?

1. Der Befehlsempfänger: nimmt Anweisungen entgegen und leitet diese direkt an das Entwicklungsteam weiter.
2. Der Teammanager: verhält sich, als ob er der Vorgesetzte des Entwicklungsteams wäre und betreibt aktives Mikromanagement.
3. Der technische Architekt: definiert nicht nur das “Was” sondern auch das “Wie” und das Entwicklungsteam hat keine Stimme bei Architekturfragen.
4. Der Backlog Eremit: das Product Backlog wird einzig vom Product Owner verwaltet und ist ansonsten unter Verschluss.

‍

1. Der Befehlsempfänger

Bei diesem Rollenverständnis ist der Product Owner nicht der “Herr” über die Priorisierung des Product Backlogs. Stattdessen erhält er die Anforderungen oder Wünsche von den Stakeholdern, schreibt das entsprechende Product Backlog Item und gibt dieses an das Team weiter, ohne die Notwendigkeit bzw. den Geschäftswert zu challengen. 

Dieses Vorgehen ist in der Praxis durchaus verbreitet. Viele Unternehmen sind der Ansicht, dass die Implementierung von Scrum im Wesentlichen aus einer Reihe von Rollen, Zeremonien und Artefakten besteht und haben daher einen lediglich technokratische bzw. prozessualen Zugang dazu. Die Kernpunkte Mindset und Werte rücken in den Hintergrund oder sind oftmals nicht ausreichend transparent. Man spricht daher in der Praxis auch gerne vom “Proxy PO”. 

Aufgrund dessen treten eine Vielzahl von Problemen auf. Wenn die Stakeholder in der geübten Mentalität des traditionellen Ansatzes (“Command & Control”) verharren, ist der Konflikt mit dem Scrum Vorgehen vorprogrammiert.

Die Herausforderung besteht also darin, Scrum korrekt im Unternehmen zu implementieren und zu verstehen, dass hinter dem Begriff Agile mehr als nur technokratische Frameworks stehen. 

Es ist eine Denkweise der Zusammenarbeit in Teams und der Maximierung des Unternehmenswertes. Das muss daher auch vom Management bzw. von den Stakeholdern getragen werden. Der Product Owner muss die Anforderungen challengen und zum Visionär des Produkts werden, in dem er das große Ganze im Blick behält und versteht, was Sinn macht bzw. Geschäftswert produziert.

Er ist somit in erster Linie dem Erfolg des Produktes und der Maximierung des Geschäftswertes verpflichtet und nicht den “Anforderungsanweisungen” des Managements oder der Stakeholder. Anders ausgedrückt: der Product Owner ist nicht der “Briefträger” der Anforderungen, die aus seinem Umfeld an ihn herangetragen werden sondern der Experte der fachlichen Anforderung des Produktes mit entsprechender Entscheidungskompetenz. 

Die Auswirkungen die sich auf Basis dieses falschen Rollenverständnisses feststellen lassen sind in der Praxis häufig folgende:

• das Team arbeitet an der Abarbeitung der Aufgaben und nicht an der Maximierung des Geschäftswertes.
• Es gibt keinen Fokus.
• Alles hat Priorität.
• Die Stakeholder sind unglücklich, weil jeder alles will.
• Das Team weiß nicht, wofür es kämpft.

‍

Wie Sie die Kommunikation mit dem Entwicklungsteam verbessern.

Diese 8 Punkte sollten Sie dafür bei der Erstellung von User Stories wissen!

‍

2. Der Teammanger 

Das in der Praxis zweithäufigste Phänomen ist, dass sich der Product Owner in der Verantwortung für das Team sieht und die Rolle des Teammanagers und manchmal auch Product Managers einnimmt.  Das ist natürlich so nicht vorgesehen, denn der Product Owner ist eigentlich selbst Teil des Scrum Teams. In Scrum sind keine Hierarchien angelegt. Product Owner, Scrum Master und Umsetzungsteam sind Experten in ihrem Gebiet und arbeiten daher als Peers auf Augenhöhe.

So lässt sich im Allgemeinen feststellen, ob der Product Owner die Rolle des Vorgesetzten einnimmt: 

• Die Product Owner lebt “Command & Control”, überwacht den Fortschritt des Teams und setzt das Team während des Sprints unter Druck.
• Er führt Einzelgespräche mit allen Teammitgliedern.
• Stakeholder und Management sehen den Product Owner als Teamleiter.
• Der Product Owner interessiert sich für die individuelle Leistung der einzelnen Teammitglieder.
• Der Product Owner muss Entscheidungen des Teams genehmigen.

Das Verhalten des Product Owners als Manager ist kritisch, da er vertrauensvoll auf Augenhöhe mit dem Entwicklungsteam zusammenarbeiten muss, um das Sprint-Ziel zu erreichen. Es ist daher nicht die Aufgabe des Product Owners, das Entwicklungsteam oder gar das Scrum Team zu managen. 

Stattdessen führt er das Team, mit einem nach Geschäftswert priorisierten, Product Backlog in Richtung der Product Vision. Das Entwicklungsteam trifft seine Entscheidungen selbständig und autonom zum Wohle der Produktes bzw. des Kunden.

‍

Zusammenfassend: Der Product Owner ist Teil des Scrum Teams und nicht sein Teamleiter.

‍

3. Der technische Architekt 

Das dritte Problem im Rollenverständnis, das in der Praxis häufig auftritt ist, dass der Product Owner keine klare Sicht auf die Abgrenzung seiner Rolle und jener des Entwicklungsteams hat. 

Der Product Owner präsentiert dem Entwicklungsteam das “Was”, sowie die Herausforderungen und Opportunities und eröffnet somit eine Diskussion. 

Das Entwicklungsteam verantwortet die (technische) Umsetzung und somit das “Wie” als Lösung für die Anforderungen, Probleme und Herausforderungen, die vom Product Owner präsentiert wurden. Insbesondere Product Owner, die Kenntnisse im Bereich der Umsetzung, also des “Wie” mitbringen, tendieren dazu im “Feld des Umsetzungsteams zu wildern”.

Woran lässt sich in der Regel erkennen, ob der Product Owner seine Rolle so angelegt hat?

• Der Product Owner erscheint zum Refinement Meeting mit vollständig vorbereiteten User Stories, in denen die Lösung bereits definiert ist. Das Entwicklungsteam erhält keinen Raum, darüber zu diskutieren.
• Das Entwicklungsteam ist frustriert, weil es nicht gestalten und entscheiden kann, sondern nur ausführen darf.
• Es gibt keine Diskussion über Epics oder über entsprechende Herausforderungen bzw. Problemstellungen.

Auch hier ist das Mindset bzw. die Sicht des Product Owners auf das Entwicklungsteam entscheidend. Dieses ist nicht die verlängerte Werkbank des Product Owners die als “Datatypisten” Code nach Anweisung schreiben, sondern ein Team von Umsetzungsexperten, die ihr Handwerk verstehen. 

Wenn das Entwicklungsteam diesem Anspruch auch gerecht wird, wird das beschriebene Verhalten des Product Owner zu massiver Frustration im Entwicklungsteam, mit den zu erwartenden Konsequenzen, führen. 

Der Product Owner soll daher seine Anforderungen, Probleme und Herausforderungen dem Entwicklungsteam präsentieren und darauf vertrauen, dass dieses die beste (technische) Lösung im Sinne des Kunden bzw. des Produktes findet.

‍

4. Der Backlog Eremit 

Der letzte Punkt betrifft die Verwaltung des Product Backlogs. Einige Product Owner sind der Auffassung, dass sie die Einzigen sind, die das Product Backlog verwalten dürfen. Deshalb lassen sie niemanden neue Backlog Items einfügen. 

Der Product Owner ist zwar für das Product Backlog verantwortlich, dies bedeutet aber nicht, dass er der Einzige ist, der neue Einträge eintragen darf. Vielmehr ist das Product Backlog ein lebendes Artefakt für das Product Owner, Entwicklungsteam und auch die Stakeholder proaktiv beitragen sollen.

Die Verantwortung des Product Owners für den Product Backlog bedeutet:

• Jedes Item bzw. jeder Eintrag im Backlog muss verstanden werden.
• Die Priorisierung der Einträge erfolgt entlang des Geschäftswertes.
• Die Verfeinerung der Items bis diese zur Entwicklung gemäß der “Definition of Ready” bereit sind.

Scrum ist ein kollaboratives Framework. Das bedeutet, dass das Team mehr ist, als die Summe seiner Individuen. Der Beitrag aller Teammitglieder zum Product Backlog ist nicht nur gewünscht, sondern erforderlich. Es ist die Aufgabe und Verantwortung des Product Owners, alle Einträge zu verstehen und zu bewerten, wie relevant diese für das Geschäft bzw. das Produkt sind. Er entscheidet daher, ob und wann diese Eingang in einen Sprint im Sprint Planning finden.

Dass der Product Owner das Product Backlog “besitzt” ist daher ein Mythos. Dazu empfehlen wir weiterführend den Beitrag von Christiaan Verwijs.

Auf Scrum.org wurde ein ähnlicher Artikel im Kontext falsch verstandenes Rollenverständnis des Product Owners veröffentlicht, der als ergänzende Lektüre empfehlenswert ist.

‍

Sie wollen Anforderungen und Wünsche erfolgreich an Entwickler kommunizieren?

Hier geht's zum Whitepaper „8 Punkte, die Sie bei der Erstellung von User Stories wissen sollten."