In diesem Artikel erklären wir dir, alles Rund um den Product Owner in Scrum. Unter anderem klären wir auch folgende Fragen:
Was ist das richtige Mindset für einen Product Owner? Was macht einen guten Product Owner aus? PRODUCT Owner statt PROJECT Owner – ist das Zufall? Und was sind eigentlich die Verantwortlichkeiten des Product Owners?
In der letzten Folge haben wir erklärt, wie Scrum und Empirie zusammenhängen, was Empirie bedeutet und warum Empirie so wichtig ist für Scrum. Unter anderem haben wir auch folgende Fragen geklärt:
Was benötigen wir dafür, dass Empirie in Scrum funktioniert? Was hat das mit den Scrum Events und Scrum Artefakten zu tun? Was hat Empirie mit Transparenz, regelmäßiger Überprüfung und Anpassung (Inspect and Adapt) zu tun? Was hat das alles mit Komplexität zu tun?
Schau also unbedingt hier vorbei falls du darüber mehr lernen willst.
Im neuen Scrum Guide 2020 steht die wichtigste Aufgabe des Product Owners direkt an erster Stelle.
Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. – Scrum Guide 2020
Das heißt er ist dafür verantwortlich, dass möglichst viel Wert für den Nutzer/Kunden entsteht wie nur möglich. Hierbei ist es ganz wichtig zu beachten, dass man sowohl interne als auch externe Nutzer/Kunden haben kann. Der Grund warum ich das hier so explizit wiederhole ist simpel. Es wird einfach zu oft vergessen und das ist ein fataler Fehler (und das meine ich auch so 😉 ). Wenn wir nicht in engem und regelmäßigen Austausch mit unseren externen Kunden sind, wird das Scrum Team (oder die Scrum Teams) ein Produkt bauen, das für den Kunden nicht attraktiv ist und er wird sich an die Konkurrenz wenden und damit geht unserem Unternehmen Wert verloren. Das sollte jedem im Unternehmen wichtig sein, egal ob Entwickler, Product Owner, Linemanager oder Führungskraft.
Aber auch bei internen Nutzern/Kunden ist der enge Austausch entscheidend und sollte ja vermeintlich einfacher sein. Und trotzdem wird es oft nicht gemacht. Doch wie kommt die Wertminderung der Arbeit des Scrum Teams hier zu tragen? Ganz einfach: Die internen Nutzer/Kunden bauen sich das passende Produkt selbst. Das bedeutet doppelte Verschwendung (In Lean als „Muda“ (engl. Waste) bezeichnet). Nicht nur wird das Ergebnis des Scrum Teams nicht genutzt, sondern zusätzlich muss der eigentliche Nutzer auch noch Zeit aufwänden, um sich das passende Produkt zu bauen (zusätzlich entstehen hier noch Insellösungen was das ganze noch schlimmer macht). Und das bringt uns zum richtigen Mindset des Product Owners.
Hierfür müssen wir uns das Projektmanagement-Dreieck nochmal in Erinnerung rufen.
Hat der Product Owner nun ein Projekt-Mindset wird der Erfolg und damit auch der Wert dadurch gemessen, dass vorab interne Metriken wie Zeit, Umfang und Budget festgelegt werden und je näher man diesen Vorab-Plan befolgt hat, desto erfolgreicher war das Projekt. Dies führt unweigerlich zu vermehrten Handoffs (Übergaben) zwischen Teams oder Teammitgliedern und eher zu Aufgaben- bzw. Personen-Management. Dazu kommt, dass gerne alle drei Eckpunkte des Dreiecks fix sind, was nur eine Möglichkeit übrig lässt, das Planziel zu erreichen, welche aber oft nicht berücksichtigt wird.
Nämlich die Qualität des Ergebnisses. Diese muss unweigerlich verringert werden, um die anderen 3 Kriterien einhalten zu können. Und die Entscheidung um ein Produkt mit geringerer Qualität mehr oder weniger Wert für den Kunden liefert (und damit Zufriedenheit) überlassen wir an dieser Stelle jedem selbst.
Eine kleine Randnotiz: Was geringere Qualität noch alles für Folgen hat erklären wir in einem späteren Artikel zum Thema Technical Debt (technische Schulden), da das sonst den Rahmen sprengen würde 😉 .
Was ist aber nun das richtige Mindset?
Das richtige Mindset ist ein Produkt-Mindset, wie es der Rollenname (Product Owner) schon verrät. Aber warum ist dieses Produkt-Mindset nun besser? Stell dir dazu einfach folgende Frage:
Was schätzt mein Kunde mehr wert? Projekte oder Produkte?
Selbst in einem Umfeld, in dem man z.B. als Projekt die Software XY einführen soll, ist der Kundenmehrwert die nachher vorhandene Software (Produkt) und nicht so sehr, dass das Projekt (Einführung der Software XY) jetzt beendet ist.
Das Ziel ist es nicht Projekte abzuschließen, sondern Wert zu schaffen, in dem man [hochwertige] Produkte an den Kunden ausliefert.
Dieses Produkt-Mindset hat nun mehrere Vorteile:
Indem er seinen Product-Backlog klar priorisiert, aktuell und immer transparent hält. Fehlt eines dieser Elemente so führt das wiederum zu Verschwendung. Zum Beispiel:
Und genau für diesen Product Backlog ist er verantwortlich. Das heißt, seinen Inhalt, die Ordnung der Items und Epics darin, seine Sichtbarkeit und die Klarheit der Sprint- und Product-Goals.
Auch muss der Product Owner sein Sprint Goal und Product Goal (eine der Neuerungen im Scrum Guide 2020, die wir sehr willkommen heißen 🙂 . Aber auch dazu später mehr.) klar und verständlich formulieren. Da nur dann erfüllen diese ihre wichtige Aufgabe den Entwicklern eine klare Richtung und damit Fokus zu geben. Zu oft sehen wir, dass ohne (klares und verständliches) Sprint Goal im Daily Scrum einfach über irgendetwas geredet wird oder gar während des Sprints Nebenarbeiten gemacht werden, die weder direkt Mehrwert liefern noch technische Schuld abarbeiten.
An erster Stelle steht hier ganz klar, dass die Entscheidungen des Product Owners über Priorisierungen von allen im Unternehmen respektiert werden müssen (schon sind wir wieder bei den Scrum Werten 😀 ), da nur er die richtige Menge an Kontext und die richtige Flughöhe für solche Entscheidungen hat und sonst niemand. Natürlich braucht er dafür den Input der Teams und der Stakeholder und Kunden, aber die finale Entscheidung liegt ganz allein bei ihm.
Und das ist auch das perfekt Stichwort für den nächsten Punkt (Zufall? 😀 ). Es gibt pro Produkt nur einen Produkt Owner. Warum? Naja ich glaube jeder von uns kennt das Problem, dass Diskussionen in Gruppen/Committees gerne mal ausufern oder ohne Entscheidung bleiben. Und genau das verhindern wir dadurch, dass es eben nur einen Product Owner gibt. Und das ist auch in der immer schnelllebigeren Zeit in der wir aktuell leben extrem wichtig.
Wir können nicht mehr darauf warten, dass ein Committee in X Wochen tagt und dann vielleicht eine Entscheidung trifft.
Und zu guter Letzt bekommt er natürlich auch Unterstützung vom Scrum Master, der ihm zeigt, wie der Product Backlog zu pflegen ist, was das erwartete Ergebnis (Outcome) eines jeden Events ist und warum seine Rolle, ein Produkt-Mindset, ein gutes Sprint- bzw Product-Goal so wichtig sind.
Der Product Owner muss also das richtige Produkt-Mindset haben, um keine Verschwendungen (Waste) zu erzeugen und nutzt dafür den Product Backlog und eine enge Zusammenarbeit mit den Stakeholdern und Kunden/Nutzern. Er ist vom Unternehmen autorisiert die nötigen Entscheidungen zu treffen und diese werden von allen respektiert. Er tut dies alleine, um Mehraufwand (Overhead) oder Verzögerungen (Delays) zu vermeiden.
Der Product Owner ist also eine ganz entscheidende Rolle in Scrum und hat die Aufgabe den maximalen Wert für den Kunden zu schaffen.
Der Product Owner sollte sich also immer Fragen:
Was können wir als erstes/nächstes liefern, was den größten, positiven Einfluss/Mehrwert für unseren Kunden bringt?
Schreib uns gerne in die Kommentare, ob dir das in deiner Rolle als Product Owner geholfen hat deine Aufgaben besser zu verstehen oder auch gerne weitere Tipps, die du wichtig für/als Product Owner hältst. Gerne auch aus der Sicht einer anderen Rolle 😉 .
Schreib uns das auch unbedingt in die Kommentare und wir werden dir gerne und ausführlich antworten!
Da das jetzt alles wieder sehr viel Input auf einmal war, haben wir eine einfache Übersicht über alles was zum Scrum Rahmenwerk gehört, für dich in einem kostenlosen Poster dargestellt. Du findest es hier:
Damit du all die gelernten Begriffe auch schnell nachschauen kannst, haben wir dir zusätzlich einen kostenlosen Glossar auf Deutsch mit +230 Begriffen zu DevOps, Agile und Lean mit den entsprechenden englischen Fachbegriffen (macht das Googeln meist einfacher, da es noch sehr wenige vollständige deutsche Blogs zu diesen Themen gibt) erstellt.
Und auch der ist komplett kostenlos. Du findest den Glossar hier:
In der nächsten Folge stellen wir dir den Scrum Master genauer vor. Also was genau sind die Aufgaben des Scrum Masters? Welche Verantwortung trägt er ? Was für Anti-Patterns gibt es und warum braucht ein Unternehmen überhaupt einen Scrum Master?
Falls du das nicht verpassen willst und ein noch besserer Scrum Master/Agile Coach/Product Owner/Entwickler oder Leader werden willst, melde dich jetzt für unseren kostenlosen Newsletter an:
Und falls du unsere Experteninterviews und alle anderen Podcast-Folgen als erster hören willst, abonnier einfach unseren Podcast mit folgendem RSS-Feed:
Du stehst auf bewegtes Bild? Dann ab auf unseren YouTube-Channel „Agile Coach Academy“.
Abonniere den Channel und verpasse kein Video oder Experteninterview mehr.
Wie immer freuen wir uns auch wenn du diesen Artikel mit deinen Freunden, Kollegen und Bekannten teilst und uns dein ehrliches Feedback in den Kommentaren schickst.
Wir freuen uns auf dich.
Deine Agile Coach Academy Gründer Ben und Alex