Der Product Owner

1.  ZIELE DES PRODUCT OWNER IM SCRUM TEAM

2.  WARUM BRAUCHT ES DENN EINEN PRODUCT OWNER?

3. WIE ARBEITET DER PRODUCT OWNER?

4. WELCHE EIGENSCHAFTEN BENÖTIGT EIN PRODUCT OWNER FÜR DIESE AUFGABEN?

5  AUFGABEN EINES PRODUCT MANAGERS

6      PRODUCT OWNER TRAININGS

6.1        Unterscheidung zwischen Problem- und Lösungsorientiertem Denken

6.2        Vision telling

6.3        Backlog Priorisierung

6.4        Verständnis der Product Backlog Einträge sicherstellen

6.5        Umgang mit Wünschen und Forderungen von Stakeholdern

6.6        Zusammenarbeit mit Entwicklerteam und Scrum Master

6.7        Entwicklungsfortschritt transparent machen

Das Ziel des Product Owner ist es, den Wert der Arbeit, die das Entwicklungsteam leistet, für den Kunden zu maximieren. Dazu legt er fest, an welchen Themen / Aufgaben / User-Stories gearbeitet wird. Diese Entscheidungskompetenz macht die Besonderheit dieser Aufgabe aus.

2  Warum braucht es denn einen Product Owner?

In einer Organisation gibt es viele Interessensgruppen, die an den Ergebnissen der Entwicklungsarbeit von Scrum Teams interessiert sind. Diese sind die Stakeholder (Kunden, Nutzer, Unternehmensleitung etc). Sie haben alle ihre eigenen Ziele und sind nicht nur dem Produkt verpflichtet.

Der Product Owner ist dagegen die einzige Person, die nur dem Erfolg des Produkts verpflichtet ist. Daher ist er auch die einzige Person mit der Autorität zu entscheiden, was entwickelt wird.

3  Wie arbeitet der Product Owner?

Durch die Rolle des Product Owners wird die Produktivität einer Organisation erhöht, denn

• Er filtert alle Ideen der Stakeholder, in dem er diese zunächst wie ein Experiment betrachtet und bewertet, ggf. ablehnt.
• Er bündelt alle Entscheidungen über Produktfeatures, was zu einer schnelleren Entscheidung führt.
• Die Entscheidungsbefugnis des PO sorgt dafür, dass die Menschen, die mit ihm zusammenarbeiten motivierter sind, da sie sehen wie ihr Input zu dem Projekt diese unmittelbar verändern kann.
• Er sorgt dafür dass nur relevante Features zum Entwicklerteam vordringen und damit indirekt für die Produktivität der Entwickler.

Dazu ist auch eine Visualisierung der Arbeit notwendig. Diese erfolgt über das Product Backlog, das für alle Beteiligten jederzeit sichtbar ist. Es ist eine geordnete Liste aller Arbeitspakete, die – als noch nicht zugesagte Arbeit – die zukünftige Arbeit zeigt. Die Reihenfolge und damit die Priorität bestimmt nur der PO.      

Das Product Backlog ist somit der Puffer zwischen den Wünschen der Stakeholder und dem Entwicklungsteam. Das Team arbeitet ausschließlich an Arbeitspaketen aus dem Product Backlog.

Im Scrum Guide heißt es zur Verantwortung des PO:

“The Product Owner is the sole person for managing the Product Backlog.”

4   Welche Eigenschaften benötigt ein PO für diese Aufgaben?

• Autorität:

Er hat die alleinige Autorität über das „Was wird entwickelt“ für das Entwicklungsteam. Er darf aber kein Despot sein, sondern soll für Vorschläge von Außen offen sein. Durch die iterative Herangehensweise von Scrum kann der Fokus bei Bedarf regelmäßig angepasst werden.

• Entrepreneurship:

Der Produkt Owner muss unternehmerisch handeln, d.h. er muss ökonomisch und wirtschaftlich orientiert handeln.

• Storyteller:

Der Produkt Owner muss die Anforderungen an das Produkt in eine Vision für das Team transformieren und alle anstehenden Aufgaben in den Kontext dieser Vision stellen.

• Netzwerker und Beziehungsmanager:

Für die Entwickler ist es essenziell, genau zu verstehen, was sie entwickeln sollen. Daher ist eine Aufgabe des Product Owners, Stakeholder und Entwickler zu dieser Klärung zusammen zu bringen um ein tiefes Verständnis des Produkts zu erlangen. Er sorgt also für ein gemeinsames Verständnis des Ziels der Produktentwicklung. Damit erzeugt der PO ein Commitment des Teams mit dem Produkt.

Der PO muss in ständigem Austausch mit den Stakeholdern stehen. So kann er die Kommunikation auf sich und das Backlog zentrieren um das beste Produkt zu erhalten. Weiterhin ermöglicht der PO des Stakeholdern, die Priorisierung zu verstehen.

• Übersetzer:

Der PO muss in der Lage sein, in der Problem Domäne zu denken, um dem Team keine Lösungsvorschläge nahezulegen. Daher muss er die von Kunden gewünschte Lösung in Anforderungen übersetzen.

Daraus ergeben sich die

5   Aufgaben eines Product Managers

• Unterscheidung zwischen problem- und lösungsorientiertem Denken
• Produkt-Vision vermitteln
• Priorisierung des Product Backlog‘s
• Verständnis der Product Backlog Einträge sicherstellen
• Entwicklungsfortschritt transparent machen
• Umgang mit Wünschen und Forderungen von Stakeholdern
• Zusammenarbeit mit Entwicklerteam und Scrum Master

Um diese Aufgaben gut erledigen zu können, müssen die Fähigkeiten dazu erworben oder verbessert werden. Wie trainiere ich nun diese?

6   Product Owner Trainings

Um diese verschiedenen Fähigkeiten zu vermitteln gibt es verschiedene methodische Ansätze, die mit Unterstützung der online Scrum Simulation PlayAgile sehr gut auch remote trainiert werden können.

6.1    Unterscheidung zwischen problem- und lösungsorientiertem Denken

Der Product Owner sollte in keinem Fall dem Entwicklerteam eine Lösung vorgeben. Um das zu vermeiden und um nur die gesammelten Anforderungen weiter zu vermitteln, muss der PO lernen, zwischen problem- und lösungsorientierten Denken zu unterscheiden. Formuliert der Product Owner die Anforderungen aus der Problemsicht spornt er das Entwicklerteam zu kreativen Lösungsansätzen an (es werden mehr Lösungsvorschläge entstehen) und wertschätzt zugleich die Lösungskompetenz der Entwickler.  

Strukturiertes Denken in der Problem-domäne lasst sich anhand unterschiedlicher Methoden in meinen Workshops erlernen. Die bekannteste Methode hierfür ist das Design-Thinking.

6.2    Vision telling

Je emotionaler und einprägsamer die Produkt Vision vom Product Owner vermittelt wird, umso mehr prägt sich das Team diese ein. Das Team bzw. die Zuhörer müssen sich in die Geschichte hineinversetzen können. Diese Vision muss alle Beteiligten im Projekt leiten. Daher wird der Product Owner diese Geschichte immer wieder erzählen, je nach Rezipienten Kreis unterschiedlich, in auf den Zuhörerkreis angepassten Ausschnitten oder je tiefer das Team in das Projekt eintaucht, detailreicher. Die dazu notwendige Fähigkeit nennt man Story telling.

Die Vision ist der rote Faden, Wegweiser und der Rahmen für die Arbeit des Teams und der Organisation. Sie hilft insbesondere auch bei der Selbstorganisation der Beteiligten. Um Story telling zu üben und zu erleben, was davon wie ankommt, gibt es sehr effektive Trainingsmöglichkeiten mit Hilfe von PlayAgile. Ihr könnt dies in diesem Workshop erlernen.

6.3    Backlog Priorisierung

Der Product Owner hat als Kernaufgabe, den Wert des Produkts zu maximieren. Daher orientiert sich die Priorisierung des Backlog’s am Wert der unterschiedlichen Aufgaben. Oder genauer gesagt am wirtschaftlichen Ergebnis. Die kann sich über eine sofortige oder zukünftige Umsatzsteigerung, eine Kostenreduzierung oder verringerten Risiken ausdrücken. Ein sehr gut geeignetes Konzept für die Priorisierung ist daher der „Cost of delay“ Ansatz. Dieser Ansatz mach insbesondere bei größeren Themen Sinn.

Dazu muss allen Beteiligten immer klar sein, was die Priorisierung für Konsequenzen hat – das nicht priorisierte Themen später (im nächsten oder einem noch späteren Sprint) umgesetzt werden. Daraus folgert die Frage:

Was kostet es uns, die Bearbeitung eines Themas um einen Sprint (z.B. vier Wochen) zurückzustellen?

Bewerten wir alle PB-Einträge mit Hilfe dieser Methode werden diese vergleichbar. Wobei die Kosten natürlich qualifizierte Schätzungen sind und nicht exakt. Letztlich kann niemand den zukünftigen Nutzen mit hoher Präzision vorhersagen. Es genügen hierfür die Größen-ordnungen.

Wir können diese gemeinsamen Schätzungen auch dazu nutzen, nach Implementierung des Features die Schätzung zu verifizieren, um in Zukunft genauer zu werden.

Wie gehen wir nun aber mit der Priorisierung kleinerer Einträge um? Hier lässt sich der Po in der Regel von den Vorschlägen der Entwickler im Rahmen des Product Backlog Refinement leiten. Der PO wir dann eher entscheiden, welche der Vor- und Nachteile die Vorschläge der Entwickler haben, um sich auf eine Lösung zu fokussieren.

In unserem Workshop machen wir mehrere Scrum Simulationen so dass Raum besteht, dieses Thema zu üben.

6.4    Verständnis der Product Backlog Einträge sicherstellen

Eine weitere zentrale Aufgabe des PO ist es, den Entwicklern zu ermöglichen, gemeinsam mit den Stakeholdern ein detailliertes Verständnis der PBE zu erlangen, in dem er diese Gruppen zusammenbringt. Um diesen Austausch möglichst effektiv zu gestalten, muss der PO diesen facilitieren.

Dafür hat sich ein Format als sehr wirkungsvoll erwiesen, bei dem die Stakeholder die gewünschten Eigenschaften des Produktes anhand von Beispielen beschreiben und die Entwickler daraus die Spezifikationen selbst ableiten. Nach Abschluss der ersten Runde können die Nutzer anhand eines weiteren Beispiels überprüfen, ob die Entwickler das Wunschverhalten wirklich so verstanden haben, wie vom Stakeholder gewünscht.

6.5    Umgang mit Wünschen und Forderungen von Stakeholdern

Auf der anderen Seite gibt es eine weiter Facilitation Aufgabe. Die unterschiedlichen Stakeholder mit Ihren Wünschen, Ideen und Bedürfnissen zusammen zu bringen und daraus eine gemeinsame Richtung festzulegen.

 Dazu gibt es unterschiedliche Methoden (zu finden unter innovationgames.com), wie z.B.

• Business value poker
• Prune the product tree
• Buy a feature

6.6    Zusammenarbeit Product Owner mit Entwicklerteam und Scrum Master

Für den Erfolg eines Projekts ist die Zusammenarbeit des Entwicklerteams mit dem PO ganz wesentlich. Die Klärung dieser Interaktion, deren Bedeutung für den Projekterfolg kann sehr gut mit Hilfe der online Scrum Simulation PlayAgile von allen Teilnehmern erfahren und erlebt werden. Dieser Aspekt wird in eine umfangreichen Simulation in. Unseren drei Tage Product Owner Workshop mit umfassender Reflexion herausgearbeitet.

6.7    Entwicklungsfortschritt transparent machen

Zur Visualisierung der noch verbleibenden Arbeit schlägt der Scrum Guide das (Release) Burn-Down Chart vor. Dieses kann aber auch genutzt werden, um Prognosen zu bestimmten Deadlines im Projekt zu machen. Welche Umfang an Features bis zu diesem Zeitpunkt implementiert sein?

Der Product Owner aktualisiert das Chart regelmäßig zum Ende des Sprints. Damit schafft er Transparenz und somit Vertrauen in die Arbeit des Scrum Teams. Es kann z.B. früh im Projektverlauf zeigen, ob ggf. im Team reagiert werden muss weil ein bestimmter Meilenstein nicht rechtzeitig erreicht werden kann. Diese Transparenz ist ein wesentlicher Aspekt von Scrum und äußerst wünschenswert.