Was macht ein Product Owner?

 Gestern entdeckte ich (via Gerrit Beine), dass es von Henrik Kniberg – einem agile Coach bei crisp.se und bekannten Buchautor – ein tolles 15-minütiges Video „Agile Product Owner in a nutshell“ gibt. In diesem Video erklärt er, was ein Product Owner alles macht. Auf ein paar Punkte will ich hier näher eingehen.

In diesem Video (zu finden am Ende des Artikels) lässt sich die Arbeit in Projekten mit Mayflower für Kunden sehr gut nachvollziehen: Projektarbeit im Team mit dediziertem Product Owner, um den bestmöglichen Wert für den Kunden dauerhaft zu erzeugen/erreichen, ohne dabei zu viele Projektstunden „zu verbrennen“. Wenn Sie mehr darüber erfahren möchten, so freue ich mich über eine kurze Nachricht. Ansonsten finden Sie hier die wichtigsten Punkte, die mir in diesem Video aufgefallen sind:

• eine der wichtigsten Funktionen des Product Owners (PO) ist es, auch mal „Nein“ gegenüber den Wünschen seiner Stakeholder zu sagen
• zu viele „Feature Pakete“ (User Stories) in einem Sprint erledigen zu wollen, führt zu Demotivation, schlechter Qualität und weiteren schlechten Dingen im Entwicklerteam
• eine wichtige Aufgabe des PO ist es, gegenüber den Stakeholdern Expectation Management (ab ca. Minute 12:30 im Video) zu betreiben: „Welche Features bekommen wir bis Weihnachten?“, „Können wir diese Features bis Ostern bekommen?“, „Welche Features bekommen wir bis zum Ende des übernächsten Sprints?“
• Backlog Grooming hilft, die Anforderungen regelmäßig zu schärfen und zu sehen, wie groß (komplex) eine User Story ist. Im Beispiel trifft sich der PO einmal pro Woche mit dem Team für eine Stunde, um über kommende User Stories zu sprechen. Bei Mayflower haben wir auch gute Erfahrung damit gemacht, zum Beispiel jeden Tag ein bis zwei User Stories aus den kommenden Sprints durchzusprechen
• kurze Feedback-Loops sind wichtig
• Product Ownership is all about communication
• der PO sollte zusehen, dass jeder die Vision seines Produkts/Projekts versteht
• Risikomanagement: Business, Social, Tech, Cost+Schedule
• wenn Unsicherheit hoch ist, dann ist der Fokus auf „Knowledge Akquisition“, erreichbar durch zB Spikes
• warum sind Spikes bzw. „Knowledge Akquisition“ trotzdem für den Kunden wertvoll, obwohl sie keine direkt sichtbaren Features bringen? Sie reduzieren Risiko! Und bringen somit ein Stück mehr Sicherheit. Das ist wertvoll.
• irgendwann sind alle „sehr wertvollen“ Stories erledigt. Das Projekt pendelt sich auf einem hohen Wert/Zeit ein. Nun könnte man durchaus das Projekt beenden, denn alle wichtigen Features für dieses Projekt sind erledigt. Oder man widmet sich der Pflege des Projekts. Kniberg weist darauf hin, dass es schwierig ist, ein Produkt als Projekt zu betrachten, denn Projekt heisst immer dass es ein Ende gibt. In der Realität sieht das meist anders aus: ein Ende gibt es nur bei „End of Lifetime“, ansonsten wird man Produktpflege betreiben und damit das Projekt weiter betreiben
• somit wandelt sich das Product Backlog eher Richtung Team Backlog: Featurepflege am alten Produkt/Projekt und zusätzliche Features für ein neues Projekt, oder neue Features am alten Produkt/Projekt aus einem ganz anderen Bereich
• Value = Knowledge Value + Customer Value
• „short term vs long term thinking“: sollen wir zunächst diesen wichtigen Bugfix machen oder eher das Platform Upgrade oder tolle neue Feature? Tradeoff! short team = reactive work (fire fighting), long term = proactive work (fire prevention)
• Building the right thing: dies ist Aufgabe des Product Owners
• Building the thing right: dies ist Aufgabe des Development Teams
• Building it fast: dies ist Sorge und Verantwortung des Scrum Masters
• idealerweise will man alle drei :-)
• wenn man das perfekte Produkt mit der perfekten Architektur bauen will (building the right thing + building the thing right), verpasst man möglicherweise das market window, da man zu lange braucht
• wenn man das perfekte Produkt sehr schnell bauen will (building the right thing + building it fast), also via Prototypen, dann ist die Gefahr da, dass man technische Schulden anhäuft, die zu einem späteren Zeitpunkt die Geschwindigkeit des Teams verlangsamen und dafür sorgen, dass neue Features immer länger dauern. Wir meinen: prototypengetriebene Entwicklung ist äußerst sinnvoll, um schnell an den Markt zu kommen, benötigt jedoch ein verantwortungsvolles Dienstleister-Team und die Bereitschaft des Kunden, zwischendurch auch in nicht-sichtbare Feature-Entwicklung (Refactoring) zu investieren, um technische Schulden abzubauen!
• es lohnt sich, Wert auf Geschwindigkeit zu legen, denn kurze Feedbackzyklen sind von Vorteil, um zu lernen, was das „richtige Ding“ ist und wie man „es richtig baut“
• Forecasts sind nie exakt. Deswegen ist es die Aufgabe, Expectation Management zu betreiben und den Korridor des Ungenauen möglichst klein zu halten
• less is more: die Aufgabe ist nicht, möglichst viel Output zu erzeugen (AKA Projektstunden zu verbrennen), sondern mit dem Minimum an Output möglichst den von den Stakeholdern gewünschten Outcome zu produzieren. Output ist das, was am Ende eines Sprints herauskommt (fertig gestellte User Stories). Outcome ist das, was die Stakeholder sich als Ergebnis wünschen

Alles in allem ein sehr sehenswertes Video:

Achtung, YouTube!

Datenschutz ist uns wichtig! Daher müssen wir noch kurz etwas los werden … Um das Video direkt auf dieser Seite angezeigt zu bekommen, musst Du leider folgende Cookies akzeptieren: statistik, Marketing.