Wer sich entschieden hat, von der hierarchischen in eine nichthierarchische Unternehmensstruktur zu wechseln und ein dafür geeignetes Projekt identifiziert hat, steht bald darauf vor der nächsten Herausforderung: Es gilt, ein Scrum Team aufzubauen. Eine Schlüsselrolle darin hat der Product Owner. Welches Mindset er dafür braucht und was seine wichtigsten Aufgaben sind, erklärt dieser Blog-Beitrag.

Product Owner: Voller Fokus auf die Produktvision

Ein Scrum Team besteht aus drei Rollen: Product Owner (PO), Scrum Master und Entwicklungsteam. Der Product Owner verantwortet die Eigenschaften sowie den wirtschaftlichen Erfolg des Produkts. Er ist zuständig dafür, dass das Entwicklungsteam immer genau das entwickelt, was den Wert des Produktes am Ehesten erhöht. Wenn er dabei nun so agiert wie ein traditioneller Projektleiter (indem er beispielsweise langfristige Ressourcen- und Budgetpläne erstellt, detaillierte Meilensteine für die gesamte Projektlaufzeit festlegt etc.), ist die Transformation direkt zum Scheitern verurteilt: Die traditionellen Projektleitungsprinzipien stehen denen des agilen Arbeitens diametral entgegen.

Ein PO braucht also das passende Mindset, um seine Rolle gut ausfüllen zu können. Dieses Mindset besteht im Wesentlichen darin, dass er seinen vollen Fokus auf die Produktvision setzt, wie er sie idealerweise in diesem Modell definiert hat. Daraus leitet sich entsprechend ab, wie die Mission und die Strategie für das Produkt sowie die Roadmap für die nächsten Monate aussehen. Diese Vision stellt der PO jederzeit in den Vordergrund. Jegliche internen politischen oder hierarchischen Interessen aus dem Betriebssystem 1 bzw. der hierarchischen Organisation ignoriert er. Dass er interne Interessen nicht berücksichtigt, gefällt vielen Menschen aus der hierarchischen Organisation nicht.

Product Backlog Management: Prioritäten setzen, bitte!

Kern der Aufgaben eines PO bildet das Product Backlog Management. Im Product Backlog sind die Anforderungen an das Produkt aufgelistet, priorisiert nach Aspekten wie wirtschaftlicher Nutzen, Risiko und Notwendigkeit. Mit Risiko ist hier der Grad der Abhängigkeit zu anderen Anforderungen gemeint. Der PO pflegt und entwickelt das Product Backlog ständig weiter. Alles, was das Entwicklungsteam erledigt, hat seinen Ursprung dort. Die Granularität der einzelnen Items bzw. Anforderungen nimmt von oben nach unten zu. So steht beispielsweise ganz unten im Product Backlog „E-Mail-Marketing-System auswählen und installieren“; dies hat hier eher eine Reminder-Funktion. Welche einzelnen Schritte die Anforderung umfasst, wird später definiert, wenn sie weiter nach oben gerückt ist.

Für das Product Backlog Management ist eine „diktatorische“ Herangehensweise am effizientesten – und der PO übernimmt die Rolle des „Diktators“. Er ist der einzige, der das Product Backlog editiert und sortiert. Er plant die Produktentwicklung und gibt vor, was entwickelt wird. Das Entwicklungsteam legt lediglich fest, wie etwas entwickelt wird. Gleichwohl ist volle Transparenz wichtig. Jeder im Team darf sich das Backlog anschauen. Ziel ist nicht, dass der PO isoliert arbeitet und quasi sein eigenes Schloss baut – sondern seine Aufgabe ist es, das Backlog zu priorisieren, indem er vollen Fokus auf die Vision des Produkts richtet und nicht auf die Interessen des Betriebssystems 1. Der große Vorteil dieser Form der „Diktatur“: Der PO hat viele Sparringspartner, die ihn im Dienst an der Sache herausfordern und mit ihm diskutieren. Er muss also immer eine Argumentation für das entwickeln, was er tut.

Fehler gehören nicht ins Backlog

Das intensive Feedback des Teams zu den Anforderungen des Product Backlogs und die daraus resultierende Reflektion ist essenziell für die Entwicklung eines Produkts. Wie sieht dies im Detail aus? Zunächst beschreibt der Product Owner die jeweilige Anforderung aus fachlicher und aus Business-Sicht. Er berichtet, was für den Kunden daran am wichtigsten ist und wie aufwendig die Umsetzung seiner Ansicht nach ist. Dazu gibt ihm das Entwicklungsteam dann eine Rückmeldung, indem es Fragen stellt und dann definiert, wie komplex es seiner Einschätzung nach ist, diese Anforderung umzusetzen. Alle gemeinsam diskutieren dann darüber, wie die Umsetzung erfolgen kann. Schließlich bestimmen sie den Business-Wert einer Anforderung. Dieser Wert ist aber keinesfalls als ein Zahlenwert definiert, sondern dient dem PO als Grundlage für die Priorisierung seines Product Backlogs: Nach der Rückmeldung durch das Entwicklungsteam kann er schlüssig begründen, warum eine bestimmte Anforderung wichtiger ist als eine andere.

Viele Product Owner schreiben übrigens Fehlermeldungen von Nutzern des Produkts ins Backlog. Fehler am Produkt gehören jedoch in den aktuellen Sprint, damit sie so zeitnah wie möglich behoben werden. Landen sie im Product Backlog, besteht die Gefahr, dass sie sehr lange dortbleiben und immer „älter“ werden. Wenn ein Fehler nicht sofort behoben werden muss – und der PO deshalb denkt, das Backlog sei ein guter Platz dafür –, dann handelt es sich nicht um einen Fehler, sondern eine Weiterentwicklung, die zu einem späteren Zeitpunkt erfolgen kann.

Stakeholder Management: Enge Verbindung zu den Produktnutzern

Ein Produkt wird immer für jemanden entwickelt. Und in der Entwicklung gibt es immer Schnittstellen zu anderen. Das Stakeholder Management ist deshalb ein weiterer sehr wichtiger Aufgabenbereich eines Product Owners.

Zentrales Dokument des Stakeholder Managements ist die Stakeholder Map. Dort hält der PO fest, wer die Stakeholder des Produkts sind: Gruppen, Rollen, Personen, Firmen. Leitend ist dabei die Frage: Wen interessiert die Entwicklung seines Produkts? Hierbei gilt es die Gruppe der Stakeholder, die tatsächlich das Produkt nutzen und bezahlen (also den Business Value realisieren), von den restlichen Stakeholdern abzugrenzen. Nur wenn der Product Owner einen sehr engen Draht zu den Nutzern hat, kann er die Anforderungen korrekt bestimmen, die dann entsprechend ins Product Backlog einfließen. Angenommen, das Produkt ist ein Online-Portal für Stromkunden und der PO erfährt aufgrund des engen Drahts zu den Endkunden, dass diese gerne die Rechnung per Mail oder online bekommen möchten anstatt auf Papier, dann weiß er: Weil diese Anforderung noch nicht im Product Backlog steht, ist der fachliche Wert dieser Innovation hoch. Er muss dann nur noch gemeinsam mit dem Entwicklungsteam die Komplexität dieser Anforderung einschätzen und kann loslegen.

Das Stakeholder Management im Sinne der Kontaktpflege zu den Stakeholdern kann lose erfolgen (beispielsweise, wenn der PO die Stakeholder anruft oder sich mit ihnen zu einem Austausch bzw. Sparring verabredet), aber auch ganz strukturiert, indem er die Stakeholder zu den Reviews am Ende der Sprints einlädt. In diesen Reviews werden die entwickelten Features vorgestellt und alle Stakeholder können sich ein Bild davon machen, welche Fortschritte erreicht wurden und wie der Status quo gerade aussieht.

Ein häufiger Fehler, der dabei gemacht wird: Der Product Owner spricht die Review-Einladungen einmal pauschal für alle aus. Bei den ersten drei, vier Reviews folgen dann auch noch sehr viele Stakeholder dieser Einladung. Weil jedoch nicht in jedem Sprint etwas entwickelt wurde, das alle Stakeholder gleichermaßen interessiert, werden diese Reviews für manche Stakeholder reizlos. Deshalb sollte der PO zu jedem einzelnen Review gezielt die Stakeholder einladen, die davon betroffen sind. Auch dies ist eine Frage des Mindsets des PO: Da er massiv auf dem Produkt fokussiert ist, hat er ein hohes Interesse daran, die Stakeholder gezielt einzuladen, denn die Reviews sind in der Regel die besten Gelegenheiten, um sie in die Belange des Produkts einzubeziehen.

Zum strukturierten Stakeholder Management gehören aber nicht nur persönliche Begegnungen, sondern auch Betrachtungen des Produktnutzerverhaltens, beispielsweise die Analyse der Besucherzahl oder Funktionalität einer Website. Nichts Schlimmeres, als wenn ein Kunde anruft und sagt: „Auf Ihrer Website funktioniert gerade das Kontaktformular nicht!“

Scrum Master: Der provokante Freund des PO

Genauso wichtig wie der Product Owner und das Entwicklungsteam ist der Scrum Master – auch wenn viele Menschen aus dem hierarchischen Organigramm immer wieder behaupten, er sei verzichtbar; vor allem dann, wenn alles gut und reibungslos läuft.

Der Scrum Master ist der „provokante Freund“ des PO. Dort, wo der PO will, dass möglichst viel weiterentwickelt und damit schnell viel Product Value realisiert wird, unterstützt der Scrum Master das Entwicklungsteam dahingehend, dass es sich nicht zu viel vornimmt im Sprint, dass es immer gleichbleibend entwickelt und auch seine persönliche Weiterentwicklung nicht vernachlässigt. Wer immer nur arbeitet, arbeitet, arbeitet, verliert irgendwann die Energie. Es ist hilfreich, sich das, was vor einem halben Jahr entwickelt wurde, anzuschauen und sich bewusst zu machen, was man mittlerweile gelernt hat. Der Scrum Master achtet also darauf, dass das Team nicht ausbrennt und auch darauf, was es braucht (z. B. andere Hardware, andere Applikationen, andere Auswertungen).

Eine weitere Aufgabe des Scrum Masters ist es, den Product Owner zu coachen, beispielsweise wenn dieser jeweiligen Anforderungen so beschrieben hat, dass das Entwicklungsteam diese nur nach vielen Rückfragen versteht.

Auch wenn das Mindset eines PO einer der wesentlichen Erfolgsfaktoren für eine nichthierarchische Unternehmensstruktur ist: Schlussendlich tragen alle drei Rollen in ihrem fein austarierten Zusammenspiel dazu bei. Product Owner, Entwicklungsteam und Scrum Master – keiner ist verzichtbar.