In der agilen Software-Entwicklung nach Scrum steht und fällt der Erfolg eines Projektes mit der Besetzung der Schlüsselstellen. Zwei der wichtigsten Positionen im Projektteam sind dabei der Product Owner und der Product Manager. Da sich beide Funktionen in ihren Verantwortungsbereichen oft überschneiden, wollen wir in diesem Artikel das Zusammenspiel beider Rollen näher beleuchten und erklären, mit welchem Setup wir bei creativestyle in über 10 Jahren die besten Erfahrungen gemacht haben.
Der Product Manager
Kein erfolgreiches Projekt ohne einen guten Product Manager: denn er ist dafür verantwortlich, ein Produkt zu entwerfen, das die Wünsche der Zielgruppe trifft. Deshalb steht er im engen Kontakt mit den Stakeholdern, also den künftigen Anwendern des Produktes. Die höchste Anforderung an den Product Manager ist deshalb, die Funktionen mit dem höchsten wirtschaftlichen Nutzen zu ermitteln. Dazu muss er zunächst die Zielgruppe des Produktes identifizieren, um dann über den gesamten Projektverlauf im Dialog mit den internen (Mitarbeiter) und externen Anwendern (Kunden) zu erarbeiten, welche Anwendungsfälle („User Stories“) das Produkt erfüllen soll.
Ein Product Manager muss dabei herausfinden, welche Interaktionen ein User mit einem (digitalen) Produkt heute hat (“Kundenaufgaben”), bei welchen Interaktionen der Nutzer kein zufriedenstellendes Erlebnis hat (“Kundenprobleme”) und mit welchen zukünftigen Features die Interaktion mit dem Produkt verbessert und so die Kundenzufriedenheit gesteigert werden kann (“Kundengewinne”). Diese Informationen soll er möglichst wenig durch seine eigene Subjektive Wahrnehmung erarbeiten und möglichst intensiv durch den direkten Austausch mit den unterschiedlichen Kundensegmenten. Letzliches Ziel des Produktmanagers muss sein, die Features mit der größten Value Proposition zu identifizieren - zunächst einmal unabhängig vom damit verbundenen Entwicklungsaufwand.
Der Product Owner
Der Product Owner ist in der Welt des agilen Projektmanagements derjenige, der die womöglich wichtigste Rolle für den Erfolg eines (Software-)Produktes innehat. Denn obgleich er nicht jedes Detail genau kennen oder verstehen muss, trägt er die Verantwortung für die Vision des Produktes - also das Verständnis über den angestrebten Nutzen und die dafür notwendigen Ressourcen.
Aufgabe des Product Owners ist dabei, für den optimalen Input und Output der Entwickler zu sorgen. Nur wenn der PO den Output (die Produktivität) seiner Entwickler realistisch abschätzt, kann er für eine effiziente Auslastung innerhalb des Projekts sorgen. Die wohl wichtigste Verantwortung liegt dabei in der Priorisierung der Arbeitspakete, die er an das Development Team übergibt. Dazu hat der PO zwei elementare Größen zu kennen: den zu erwartenden Business Value sowie den Aufwand für die Entwicklung des Arbeitspaketes. Höher priorisiert werden natürlicherweise Pakete, die entweder bei gleichem Aufwand einen höheren geschäftlichen Wert versprechen, oder bei ähnlichem Wert mit geringeren Ressourcen umgesetzt werden können.
Risiken
Alle Aufgaben, die nicht unmittelbar an das Entwicklerteam weitergegeben werden, landen zunächst im sogenannten Product Backlog, also dem „Abstellgleis“ für Arbeitspakete, denen noch keine Ressource oder Termin zugeordnet ist. Wenn allerdings in höherer Frequenz Wünsche nach weiteren Features ("User Stories") an den PO herangetragen werden, als das Entwicklerteam seine Arbeitspakete erledigen kann, wird der Backlog unweigerlich anwachsen.
Eine der entscheidenden Qualitäten eines guten Product Owners ist daher die Fähigkeit, Arbeitspakete auch abzulehnen - sei es, weil der Umsetzungsaufwand ("Story Size") in keinem Verhältnis zum wirtschaftlichen Nutzen ("Story Value") steht, oder weil die Umsetzung Ressourcen binden würde, die für den zeit- und budgetgerechten Abschluss des Projektes erforderlich sind. Unsere Erfahrung lehrt: in fast allen Projekten werden im laufenden Betrieb mehr User Stories erzeugt, als das Development Team in seinen Sprints erledigen kann.
Ohne einem Product Owner, der den Business Value der einzelnen Features bewerten kann, aber vor allem die Auswirkungen auf die Ressourcenplanung im Gesamtkontext des Projektes zuverlässig einschätzen kann, gerät ein komplexes IT-Projekt schnell in Schieflage. Das Backlog droht dann ins unermessliche zu wachsen, die Wartezeit für neue Features wird länger, das Vertrauen auf Auftraggeberseite in das Projekt schwindet.
Unser Setup
Bei creativestyle setzen wir deshalb in unseren Projekten einen erfahrenen Projektmanager aus unseren Reihen als Product Owner ein. In der heißen Phase ist dieser in Vollzeit für den Erfolg des Projektes abgestellt und stimmt sich täglich sowohl mit dem Auftraggeber als auch mit dem Entwicklerteam ab. In enger Abstimmung mit dem Product Manager beim Kunden kann er so sicherstellen, dass die Features mit dem höchsten Kosten/Nutzen-Verhältnis mit Priorität behandelt werden und behält stets darauf, dass der Kunde zum angestrebten Go-Live-Termin in jedem Fall eine funktionale Version seiner gewünschten Lösung erhalten wird.
Ebenso wichtig für den Erfolg ist damit im Umkehrschluss die Rolle des Product Managers auf Kundenseite: durch den engen Kontakt mit internen und externen Stakeholdern beim Kunden ist der PM in der Lage, die verschiedenen User Stories und deren individuellen Mehrwert richtig zu bewerten und dem Product Owner so eine verlässliche Grundlage für die Abschätzung von Aufwand und Nutzen zu liefern.
Agiles Projektmanagement lebt von der Kommunikation
Selbstverständlich liegen dem Product Owner die Informationen zu wirtschaftlichem Nutzen („Story Value“) und Entwicklungsaufwand („Story Size“) in den wenigsten Fällen schwarz auf weiß vor, sondern müssen durch kontinuierliche Kommunikation mit dem Product Manager, den Stakeholdern und dem Entwicklerteam so präzise wie möglich ermittelt werden. Je weiter ein Projekt fortgeschritten ist, desto präziser werden solche Abschätzungen im Regelfall. Allein aus diesem Grund ist ein starres Projektmanagement für ein hochkomplexes Software-Projekt mit sich dynamisch ändernden Anforderungen als sehr kritisch zu betrachten
