Die Rolle des Product Owner in Scrum
Bei der schlanken Softwareentwicklungsmethode Scrum gibt es drei Rollen: das Team, den Scrum Master und den Product Owner. Meiner Erfahrung nach ist die Rolle des Product Owner bei weitem die verwirrendste und am schwierigsten zu erfüllende Rolle und löst die meisten Diskussionen aus. Selbst die bloße Definition dessen, was diese Person tun sollte, wird von den meisten Scrum-Praktikern, mit denen ich gesprochen habe, diskutiert. Ich möchte die Ursprünge der Rolle des Product Owner erörtern und meine Erfahrungen damit, wie man diese Rolle (nicht) ausfüllt, insbesondere in Unternehmen, die keine Produktentwicklung betreiben.
Der mythische Product Owner
Ich habe schon viele Arten von Product Ownern gesehen und keiner von ihnen hat wirklich so funktioniert, wie er sollte. Es gibt sogar das Gerücht, dass es keine guten Product Owner gibt. Das ist etwas, worüber wir offen reden sollten, wenn das stimmt. Wenn der Product Owner eine Kombination von Verantwortlichkeiten ist, die in der Praxis nicht funktioniert, sollten wir eine Alternative finden. Zunächst werde ich meine bisherigen Erfahrungen erläutern.
Definition der Rolle
Scrum basiert auf bewährten Praktiken. Niemand hat Scrum 'erfunden', indem er lediglich Theorien darüber aufgestellt hat, wie die Welt funktionieren sollte. Leute wie Jeff Sutherland und Ken Schwaber haben in der Vergangenheit Projekte durchgeführt, die erfolgreich waren. Einer der Hauptgründe für ihren Erfolg war die Anwesenheit einer Person, die alle Kundeninteressen gegenüber dem Team vertrat (später Product Owner genannt). Ken Schwaber beschreibt den Product Owner als 'eine Person [die] für die Pflege und Aufrechterhaltung des Inhalts und der Priorität eines einzelnen Product Backlogs verantwortlich ist' Jeff Sutherland ist ausführlicher und listet in seinem Online-Buch 'The Scrum Papers' alle Verantwortlichkeiten des Product Owners auf. Unter anderem fügt er die Verantwortung "[...] für die Rentabilität des Produkts (ROI)" hinzu. Die direkte Verbindung zwischen dem ROI und den Funktionen des Produkts ist das, worum es bei Product Ownership geht.
Verschiedene Geschmacksrichtungen
Wenn ich mir vor Augen halte, was der Product Owner nach Scrum sein sollte, möchte ich die verschiedenen Varianten von Product Ownern, die mir begegnet sind, erläutern. Ihr Geschmack wurde meist durch die Person, die die Produktverantwortung übernimmt, und ihren 'normalen' Job definiert. PO der Produktmanager In Unternehmen, die sich mit der Produktentwicklung befassen, wie z.B. berühmte Scrum-Unternehmen wie PatientKeeper und Planon, gibt es in der Regel eine Rolle, die Produktmanager genannt wird. Ein Produktmanager kann ohne weiteres der Product Owner sein, da beide Rollen fast synonym sind. Scrum gibt dem Produktmanager mit dem Product Backlog eine spezifische Möglichkeit, sein Produkt zu kontrollieren. Das einzige wirkliche Problem, das ich gesehen habe, ist, dass Produktmanager dazu neigen, die Teams zur Lieferung zu drängen, was als schlechte Praxis angesehen wird und letztendlich die Produktivität verringert. Produktmanager müssen 'nur' empirisches Management lernen, um gute Product Owner zu sein. PO der Projektmanager In den meisten Projekten, in denen ich gearbeitet habe, ist der Projektmanager für die Planung der Aktivitäten zuständig. Wenn er die Rolle des Product Owners übernimmt, geht er das Backlog normalerweise aus der Planungsperspektive an. Das bedeutet, dass er auf der Grundlage von externen Abhängigkeiten und der Verfügbarkeit von Mitarbeitern usw. entscheidet, was in welchen Sprint kommt. Die meisten Projektmanager sind eigentlich nicht für die Rentabilität des Projekts oder das Budget verantwortlich. Der PM erstellt den Plan, aber der Projektvorstand genehmigt den Plan und das Budget. Wenn das Projekt den Termin oder das Budget überschreitet, ist der Projektvorstand dafür verantwortlich (wenn der PM ausreichend gewarnt hat). Das Hauptproblem ist, dass die Arbeit nicht von den Managern, sondern direkt von den Stakeholdern an die Entwickler weitergegeben werden sollte, denn ein Manager ist nicht der Kunde und verfügt in der Regel nicht über das nötige Fachwissen, um die richtigen Entscheidungen zu treffen. Ein Projektmanager müsste eigentlich für das Budget und die Rentabilität verantwortlich gemacht werden, um ein guter Product Owner zu sein. PO der Funktions-/Informationsanalytiker Für die meisten Teams klingt dies wie der ideale Product Owner. Ein Informationsanalyst verfügt in der Regel über ein umfassendes Wissen darüber, was der Kunde braucht. Die Informationsanalysten, mit denen ich gearbeitet habe, waren gut darin, Informationen zu strukturieren und sie an die Entwickler weiterzugeben. Obwohl ein Informationsanalyst sehr gut für die Produktivität ist, ist er nicht dasselbe wie ein Product Owner. Der Analyst hat in der Regel eine 'Feature-Perspektive': was soll das Produkt leisten. Seine Hauptkompetenz besteht darin, die Anforderungen und Wünsche der (potenziellen) Benutzer des Systems zu ermitteln. Wenn er sich nicht darum kümmert, wird er versuchen, den Kunden zufrieden zu stellen, indem er alles implementiert, was der Kunde wünscht. Alle Anforderungen zu implementieren klingt gut, aber nur wenige Projekte verfügen über genügend Ressourcen, um das zu tun, deshalb müssen Sie die Funktionen priorisieren. Ich habe noch nicht erlebt, dass Informationsanalysten das sehr gut gemacht haben, weil das Budget nicht in ihrer Verantwortung lag. Der Analyst arbeitet vielleicht sehr eng mit dem Product Owner zusammen, um die kommenden Sprints vorzubereiten, aber dafür braucht er den Product Owner eigentlich nicht, wenn das Product Backlog in guter Form ist. In jedem Fall ist ein Informationsanalyst ein sehr wertvolles Teammitglied, kein Product Owner. PO der Release Manager Der Begriff 'Release Manager' ist nicht ganz eindeutig, aber er lässt sich am besten als koordinierender Planungs- und Ressourcenmanager erklären, der die zu erledigenden Arbeiten plant und die Teammitglieder auswählt, die sie erledigen sollen. Außerdem berichtet er den Beteiligten über den Stand der Arbeit. In gewisser Weise ähnelt die Rolle des Release Managers der Rolle des Product Owners, da beide dem Team die Arbeit vorgeben. Allerdings gab es bei diesem speziellen Release Manager als Product Owner ein paar Probleme. Zunächst einmal plante der Release Manager die Arbeit nur für einen 'Typ' von Entwicklern (J2EE, C++ oder .Net usw.), was bedeutet, dass die Funktionen bereits in Arbeitspakete für jede Kompetenz aufgeteilt waren. Das macht die Priorisierung zu einer unmöglichen Aufgabe, da die Verbindung zwischen den Arbeitspaketen und den tatsächlichen Funktionen fehlte. Der Abstand zwischen dem Business Case und den Stakeholdern und den Release Managern war einfach zu groß, um wirkliche Entscheidungen zu treffen, und es war nicht erlaubt, Features fallen zu lassen, um den Zeitplan einzuhalten. Diese Release Manager waren also aus einem Grund Product Owner: Wir führten Scrum ein und brauchten jemanden (irgendjemanden?), der diese Rolle ausfüllte, weil es im Scrum-Buch stand. PO the Unit Manager In einem meiner Projekte übernahm ein Unit Manager (Leiter eines Geschäftsbereichs innerhalb einer IT-Organisation) die Rolle des Product Owners eines internen Projekts. Das Hauptaugenmerk eines Geschäftsbereichsleiters liegt auf seinen Mitarbeitern, und da er sich mit Scrum auskannte, hatte er kein Problem damit, das Team zu leiten und ihm Vertrauen und Verantwortung zu übertragen. Aber das ist nicht die Hauptverantwortung des Product Owners, sondern die Verantwortung für das Projektergebnis. Es ist vielleicht noch schwieriger, die Verantwortung in einem internen Projekt richtig zu verteilen, als wenn es eine klare Beziehung zwischen Kunde und Anbieter gibt. In diesem Fall waren die Teammitglieder auch Stakeholder und der Abteilungsleiter und die Stakeholder wollten auch bei der Entwicklung helfen (sind Sie noch bei mir?). Das Hauptproblem bestand darin, dass die Verantwortlichkeit nicht explizit auf den Product Owner übertragen worden war. Die Führungskraft, die das Budget kontrollierte, hatte wenig Kontrolle über das Projekt und so tappten wir in die uralte Projektfalle, bei der die Leute mit dem Geld fragen: "Wohin geht mein Geld?" Der Unit Manager konnte das Geld nicht nach eigenem Gutdünken ausgeben und übernahm auch nicht die Verantwortung für den Erfolg des Projekts, so dass die Führungskraft der "versteckte" Product Owner war.
Der 'richtige' Product Owner
Ich habe zwar noch nicht gesehen, dass die Rolle korrekt ausgefüllt wurde, aber ich sehe die Notwendigkeit, die die Rolle des Product Owner in agilen Projekten erfüllen soll. Das große Wort hier ist Business Case. Der Business Case beschreibt den Nutzen der Ergebnisse des Projekts, zum Beispiel: "Wenn wir Softwareprodukt x einführen, werden wir pro Jahr x Geld einsparen". Führungskräfte lieben Business Case-gesteuerte Entwicklung und deshalb sollte der Product Owner das Projekt anhand des Business Case steuern (vielleicht sollten wir ihn 'Business Case Owner' nennen?). Umgekehrt gilt das Gleiche: Wenn Ihr Product Owner nicht für die Umsetzung des Business Case verantwortlich ist, ist er nicht Ihr wirklicher Product Owner. Aber wenn Sie die Verantwortung auf den Product Owner übertragen können, welche Art von Kompetenzen muss der Product Owner dann haben, um die Business Case-gesteuerte Steuerung durchzuführen? Business Case Value Er muss wissen, welche Funktionen den größten Mehrwert für den Business Case darstellen. Wenn Zeitersparnis das Hauptziel des Produkts ist, werden messbare zeitsparende Funktionen höher bewertet als (zum Beispiel) Funktionen zur Benutzerfreundlichkeit oder zur Produktpflege. Finanziell Er muss wissen, wie viel Geld eine Funktion kosten wird und wie viel sie einbringt. Eine Funktion X wird unseren Marktanteil um Y erhöhen. Er muss wissen, wie viel er für jede Funktion ausgeben muss und in der Lage sein, Funktionen wegzulassen oder zu vereinfachen, um das Budget einzuhalten. Ein gewisses Fachwissen Der Product Owner benötigt ein gewisses Fachwissen, damit er entscheiden kann, wovon die Stakeholder sprechen. Der Hauptvorteil dieser Rolle besteht darin, dass er sich auf hohem Niveau mit den Funktionen auskennt und gleichzeitig für den Business Case verantwortlich ist. Zeit Ein oft diskutiertes Thema ist die Verfügbarkeit des Product Owners. Wenn Sie sich die Aufgaben ansehen, muss er nicht Vollzeit zur Verfügung stehen. Wenn das Backlog in gutem Zustand ist und sich die Prioritäten nicht oft ändern, kann das Team die Backlog-Elemente auch ohne den Product Owner verfeinern und umsetzen.
Der unmögliche Job?
Und nun das große Problem: die Realität. Jeder kann beschreiben, was ein guter Product Owner sein und tun sollte (das habe ich gerade getan), aber das macht es nicht zur Realität. Es gibt ein grundlegendes Problem mit der Rolle des Scrum Product Owner außerhalb von Produktentwicklungsunternehmen: Gute Product Owner sind zu selten. Die meisten Scrum-Experten geben sogar zu, dass ein guter Product Owner ein seltenes Phänomen ist. Eines der großen Verkaufsargumente von Scrum ist, dass es ein leichtgewichtiger Prozess ist, manche würden es sogar als Prozessrahmen bezeichnen. Das ist gut, denn das bedeutet, dass Sie schnell mit der Anwendung von Scrum beginnen und dann den eigentlichen Prozess innerhalb des Scrum-Rahmens fein abstimmen können. Allerdings behindert die Rolle des Product Owner diese einfache Implementierung des Frameworks. Ich kann nicht sofort mit dem Kunden-Projekt-Feedback-Zyklus beginnen, weil die Anforderungen an die Rolle des Product Owners meiner Erfahrung nach zu hoch sind.
Fazit
Ich habe erklärt, wann die Rolle des Product Owner nicht so funktioniert hat, wie sie hätte funktionieren sollen, und worauf ein guter Product Owner achten sollte, um die Effektivität des Projekts zu maximieren, indem er sich auf den geschäftlichen Wert der Funktionen des Projekts konzentriert. Ich komme zu dem Schluss, dass es schwer ist, die Rolle
Verfasst von
Machiel Groeneveld
Senior Agile Developer
Unsere Ideen
Weitere Blogs
Contact