Sent from Hauptstadt!

ein Blog für den geneigten Leser

Scrum + Produktmanagement = ❤ ?

Tags: ,

Kategorie Software Engineering | 1 Kommentar »

Nachdem ich die Hauptaufgaben eines Software Produktmanagers vorgestellt habe, kam die Frage auf, wie das Zusammenspiel von Produktmanagement und Scrum funktioniert? Um es schon mal vorweg zu nehmen, bei Scrum + Produktmanagement handelt es sich in der Praxis häufig eher um eine Zweckgemeinschaft als die große Liebe…

Zusammenspiel Product Owner und Scrum Team

Auf dem Papier ist die Scrum Welt ganz  einfach. Die Anforderungssicht an das Produkt wird in Scrum durch den Product Owner (zu Deutsch vielleicht Produktmanager) repräsentiert. Der Product Owner pflegt den Product Backlog, also die priorisierte Liste der als nächstes zu realisierenden Anforderungen. Das Scrum Team unterstützt den Product Owner bei der Pflege des Product Backlogs, etwa bei der Schätzung von User Stories oder beim Aufzeigen von technischen Abhängigkeiten zwischen User Stories. Das Scrum Team zieht sich dann im Sprint Planning die obersten User Stories aus dem Product Backlog und erklärt damit, dass es als Team glaubt, diese Anforderungen bis Sprintende umsetzen zu können. Am Ende des Sprints präsentiert das Scrum Team dann dem Product Owner die realisierten User Stories und der Product Owner nimmt diese ab. Der Product Owner darf den Product Backlog jederzeit ändern und zum Beispiel aktuell wichtig werdende Anforderungen an die Spitze der Liste setzen. Dadurch kann agil auf Marktveränderungen oder Benutzerrückmeldungen reagiert werden.

Trennung zwischen Product Owner und Scrum Team

Wer den letzten Abschnitt aufmerksam liest, wird feststellen, dass ich auf der einen Seite vom Scrum Team und auf der anderen Seite vom Product Owner spreche. In der offiziellen Scrum Theorie ist der Product Owner nicht Teil des Scrum Teams. Ich vermute (Achtung, Spekulation!), dies wurde ursprünglich deshalb so definiert, da Scrum im Rahmen von Agenturprojekten (Englisch: bespoke project) entwickelt wurde und der Product Owner dann der externe Kunde war. Damit ergab sich allein schon aus der Firmengrenze diese Trennung.

Ich halte diese Trennung für gefährlich! Scrum erzeugt hier eine harte Trennung, die in der Praxis leicht zu Abteilungsdenken führt. In meiner Idealvorstellung ist der Product Owner Teil des Scrum Teams und an allen Meetings beteiligt. So sollte der Product Owner sowohl am täglichen Standup teilnehmen, als auch bei den Retrospektiven präsent sein.

Leider sehen sich die wenigsten Product Owner als Teil des Teams noch wollen sie es sein und auch viele Teams sind froh, wenn der Product Owner nicht genau weiß, was im Team wirklich gemacht wird. Häufig gehört der Product Owner einer anderen Abteilung an oder in Konzernen sogar zu einem anderen Vorstandsbereich. Bei der Diskussion mit Scrum Teams habe ich es auch schon erlebt, dass die Rolle des Scrum Masters als Beschützer vor dem Product Owner definiert wurde.

Meine ganz persönliche Vision hingegen ist eine maximal offene Kommunikation zwischen Scrum Team und Product Owner. Ich bevorzuge, wenn der Product Owner lieber weniger Produkte betreut, dafür aber von Planung bis Umsetzung involviert ist. Der Product Owner soll sehen, welche Probleme im Team existieren, denn dann kann er die Komplexität von Anforderungen besser selbst abschätzen. Auch kann er dann früher mögliche Terminverschiebungen oder nicht realisierbare Anforderungen zum Beispiel an Vertrieb und Marketing kommunizieren und sich in Schadensbegrenzung üben.

Die Mär vom Product Backlog

Scrum selbst sagt wenig darüber aus, wie die User Stories in den Product Backlog kommen. Auch wird in der Literatur angenommen, dass jedes Teammitglied prinzipiell jede Anforderung aus dem Product Backlog übernehmen kann. Gerade bei der Entwicklung größerer Geschäftssoftware ist dies meiner Erfahrung nach aber nie der Fall. In der Realität gibt es nun mal Spezialisten für die unterschiedlichen Bereiche wie Datenbankanbindung, Geschäftslogik und Client. Häufig wird ein wilder Mix an Technologien von C++ über Java bis JavaScript eingesetzt und kaum ein Entwickler schafft noch will es in allen Gebieten gleichermaßen firm zu sein. Deshalb ergibt sich die Reihenfolge von User Stories im Product Backlog nicht nur anhand der Priorität, sondern auch anhand der verfügbaren Resourcen und deren Fähigkeiten.

Ein guter Product Owner steuert über den Product Backlog die Entwicklung und sorgt zum Beispiel dafür, dass bestimmte Themen vollständig umgesetzt sind, bevor mit dem nächsten Thema begonnen wird. Andererseits passt er auf, dass sich das Team nicht mit besonders hübschen Schleifen am eigentlich schon fertigen Feature verzettelt und am Ende nicht genügend Zeit für die restlichen Top Prio Anforderungen bleibt.

Gerade die vorrausschauende Bestückung des Product Backlogs erfordert Fingerspitzengefühl und Erfahrung, denn als Product Owner muss man im Kopf einen groben Plan haben und diesen in erreichbare Sprints runterbrechen können. Scrum bietet hier keinerlei Hilfsmittel!

Produktmanagement und Scrum richtig verbinden

Bleibt also die Frage, wie man Produktmanagement und Scrum richtig verbinden kann? Ich verfüge selbst noch nicht über die finale Antwort, aber folgende Ansätze scheinen hilfreich zu sein:

  1. Der Produktmanager sollte ein Produkt von Planung bis Umsetzung und vielleicht sogar bis zum Rollout und Vermarktung betreuen. Da dies sehr viele Aufgaben sind, kann der Produktmanager nur wenige Produkte betreuen. Man muss deshalb innerhalb des Produktmanagements Wege finden, wie sich die Produktmanager untereinander abstimmen. In Bezug auf Scrum bedeutet dies für mich, dass der Produktmanager an allen Scrum Meetings teilnimmt und jederzeit für Rückfragen zur Verfügung steht.
  2. Der Produktmanager geht aktiv auf die Entwickler zu und beteiligt sie an der Erstellung von User Stories, damit frühzeitig die technische Machbarkeit geklärt ist und die Entwickler Miteigentümer der User Stories werden.
  3. Der Produktmanager verfügt über ein technisches Grundverständnis, hat also zum Beispiel schon mal selbst programmiert oder als Tester gearbeitet. Dadurch denkt der Produktmanager bei initialer Formulierung von User Stories von sich schon an mögliche Auswirkungen eines Features (etwa Architekturänderung, Rechteverwaltung, Fehlerbehandlung, etc.).
  4. Eine fundierte Releaseplanung ist entscheidend. Der Produktmanager sollte für jedes Release eine klare Zielsetzung formulieren und nicht wild zusammengewürfelte Anforderungen vorsehen. Zum Beispiel könnte die Entwicklung eines Blogsystems für ein Release das Ziel verbesserte Verwaltung von eingebetteten Medien vorsehen. Ich nenne es immer den geheimen Masterplan. Man muss wissen, wohin die Fahrt gehen soll und in welchen Etappen man das Ziel erreichen will.
  5. Es ist die Verantwortung des Entwicklerteams technische Umbaumaßnahmen als User Stories zu formulieren, aber dadurch, dass der Produktmanager täglich involviert ist, wird er entsprechende Diskussionen hoffentlich frühzeitig mitbekommen.
  6. Der Produktmanager muss aufpassen, dass das Team seine Verantwortung wahrnimmt und nicht wegen jeder Entscheidung zu ihm kommt, da er sonst schnell zum Engpass wird. Es darf nicht die Situation entstehen, dass das Scrum Team das Gefühl hat, sich vor dem Product Manager rechtfertigen zu müssen. Am Ende stehen alle gemeinsam auf dem Schafott :-)

Zugegeben, ich entferne mich mit dieser sehr engen Verzahnung von Scrum Team und Produktmanager teils stark von der offiziellen Scrum Literatur. Ich bin mir auch bewusst, dass dies in der Praxis nicht leicht umsetzbar ist, da hier plötzlich sehr verschiedenartige Menschen (BWL Fuzzies vs. Hyper Nerds) miteinander arbeiten müssen. Im Geschäftsprozessmanagement (BPM) Umfeld wird das dann gerne als „Bridging the Business-IT Divide“ bezeichnet. Genau dieses Brückenbauen und Kommunikationsebenen finden ist für eine erfolgreiche Beziehung aber entscheidend: so auch für Scrum + Produktmanagement ;-)

Ein Kommentar to “Scrum + Produktmanagement = ❤ ?”

  1. […] meine Erfahrung zur Verknüpfung von Scrum und Produktmanagement […]

Schreiben sie ein Kommentar