Agiles Produktmanagement mit Scrum E-Book

Roman Pichler

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2014

Seitenzahl: 207

Beschreibung

Agiles Produktmanagement mit Scrum hilft Ihnen, innovative Produkte mit Scrum zu entwickeln. Anhand zahlreicher Praxisbeispiele erklärt das Buch anschaulich und leicht verständlich den Einsatz agiler Produktmanagementkonzepte und -techniken. Hierzu zählen: •Die richtige Anwendung der Product-Owner-Rolle •Der effektive Einsatz einer agilen Produktvision und einer agilen Produkt-Roadmap •Der richtige Umgang mit dem Product Backlog inklusive Priorisierung, User Stories und nichtfunktionaler Anforderungen •Das Erstellen eines realistischen Releaseplans •Das richtige Verhalten des Product Owner in den Sprint-Besprechungen •Die Etablierung der Product-Owner-Rolle im Unternehmen Dieses Buch ist für alle Leser, die als Product Owner arbeiten oder dies vorhaben, sowie für Führungskräfte und Scrum Master, die sich für die Anwendung der Rolle und den Einsatz der Praktiken interessieren.

Leseprobe

Roman Pichler ist international renommierter Experte für Scrum und agiles Produktmanagement. Er arbeitet als Berater und Trainer, ist Autor mehrerer Bücher und schreibt auf allthingsproductowner.com einen Blog für Produktmanager und Product Owner.

Agiles Produktmanagement mit Scrum

Erfolgreich als Product Owner arbeiten

2., korrigierte Auflage

Roman Pichler

Roman Pichler

[email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Herstellung: Birgit Bäuerlein

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;

detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN

Buch 978-3-86490-142-3

PDF 978-3-86491-436-2

ePub 978-3-86491-437-9

2., korrigierte Auflage 2014

Copyright © 2014 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Dieses Buch erschien bis Juli 2013 unter gleichem Titel als 1. Auflage im Addison-Wesley Verlag, München, ISBN 978-3-8273-2915-8

Autorisierte Übersetzung der amerikanischen Originalausgabe »Agile Product Management with Scrum«. Authorized translation from the English language edition, entitled Agile Product Management with Scrum, by Roman Pichler, published by Pearson publishing as Addison Wesley, (ISBN 978-0-321-60578-8)

Copyright © 2010.

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Für meine ElternGeorg und Christine Pichler

Geleitwort von Jeff Sutherland

Die Product-Owner-Rolle ist für die meisten Unternehmen neu und bedarf der verständlichen und überzeugenden Darstellung wie in diesem Buch. Als der allererste Product Owner ausgewählt wurde, war ich Vizepräsident bei Object Technology und dafür verantwortlich, das erste mit Scrum entwickelte Produkt abzuliefern. Das neue Produkt war kritisch für den Erfolg der Firma. Mir aber blieben nur sechs Monate, um ein Entwicklungstool auszuliefern, das den Markt verändern sollte. Neben der Erstellung des Produkts mit einem kleinen, sorgfältig ausgewählten Team musste ich die gesamte Firma um dessen Auslieferung herum organisieren. Da nur wenige Monate bis zur Auslieferung übrig blieben, war glasklar, dass die richtige Zusammenstellung eines minimalen Feature-Sets über Erfolg oder Misserfolg entscheiden würde. Mir fehlte schlichtweg die Zeit, Kunden zu interviewen und Wettbewerber genau zu analysieren, um vorab das exakt richtige Feature-Set zu bestimmen und diese Features für das Team in kleine Product-Backlog-Einträge herunterzubrechen.

Ich hatte meine Verantwortung als Engineer bereits an den ersten ScrumMaster John Scumniotales delegiert und brauchte nun einen Product Owner. Ich konnte auf alle Mitarbeiter der Firma zugreifen, also wählte ich für die Rolle die beste Person aus dem Produktmanagementteam: Don Roedner. Als erster Product Owner sollte Don die Vision für das Produkt, den Businessplan und die Einnahmen, die Roadmap sowie den Releaseplan verantworten. Und ganz wichtig: Er sollte sich um ein sorgfältig gepflegtes und präzise priorisiertes Product Backlog für das Team kümmern.

Don verbrachte die Hälfte seiner Zeit beim Team. Die andere Hälfte war er bei den Kunden. Sein Job bestand darin, das richtige Produkt abzuliefern, während ich mit der restlichen Firma an der Namensgebung für das Produkt und dessen Branding, an der Marketing- und Kommunikationsstrategie sowie an der Verkaufsplanung und an Schulungen arbeitete, während ich parallel täglich in Scrum-Besprechungen saß und damit beschäftigt war, Hindernisse für das Team zu beseitigen. Die Rolle, die Don ausfüllen musste, war größer als die eines Produktmarketingmanagers. Plötzlich war er für einen neuen Geschäftszweig verantwortlich. Zugleich war er nun auf einmal im Engineering-Team gelandet und half täglich dabei, das Team zu motivieren und Zusammenhänge zu erläutern. Gleichzeitig in den Markt und ins Team eingebettet zu sein, war für ihn eine unglaubliche Erfahrung.

Dieses Buch stellt hervorragend dar, wie sich ein guter Product Owner auf den Produkterfolg fokussiert und für diesen Verantwortung übernimmt. Leider finden sich solche Product Owner nur selten. Wir benötigen ein klares Bild eines ausgezeichneten Product Owner und müssen verstehen, wie die Rolle gelebt werden soll. Hierfür liefert Roman Pichler eine hervorragende Anleitung.

Jeff Sutherland

Miterfinder von Scrum

Geleitwort von Brett Queener

Die gesamte Softwarebranche ist in Bewegung und wird agil. In den vergangenen beiden Jahrzehnten waren viele Kunden, Partner und Mitarbeiter von der Art und Weise desillusioniert, wie technologische Lösungen für Unternehmen entwickelt wurden. Diese Lösungen waren oft von geringer Qualität, brauchten Jahre, bis sie auf den Markt gebracht wurden, und ihnen fehlte die nötige Innovationskraft, um Geschäftsprobleme wirklich zu lösen.

Salesforce.com hat sich auf die Fahne geschrieben, ein anderes Softwareunternehmen zu sein, indem wir uns auf den Erfolg von Kunden und Mitarbeitern konzentrieren. Wir wussten, dass traditionelle Methoden der Softwareherstellung für unsere Vision einer anderen Unternehmensart einfach nicht funktionieren würden. Wir mussten unser Modell überdenken, alte Annahmen über Bord werfen und einen besseren Weg finden. Wir fragten uns: Können wir Software in höchster Qualität pünktlich abliefern, und zwar jedes Mal? Gibt es eine Möglichkeit, unseren Kunden bereits früh und häufig etwas Wertvolles in die Hand zu geben? Können wir immer mehr Innovationen umsetzen? Das alles ist tatsächlich möglich.

Als Chief Product Owner bei Salesforce.com musste ich meine Produktmanager in die Lage versetzen, die Wünsche und Bedürfnisse unserer Kunden und des Unternehmens den Entwicklungsteams über einen Dialog verständlich zu machen. Der Einsatz von Scrum ermöglicht es, dass die Produktmanager für das Schaffen von Kundenmehrwert verantwortlich sind. Sie können nun die wichtigsten Features zuerst entwickeln und diese schnellstmöglich an die Kunden ausliefern. Sie können flexibel und schnell auf verändernde Marktbedingungen reagieren oder rasch tolle Innovationen umsetzen, die in unseren Entwicklungsteams entstehen. In Agiles Produktmanagement mit Scrum erfahren Sie, wie sich ein Product Owner von einem traditionellen Produktmanager unterscheidet, wie er eine größere Verantwortung für den Erfolg des Produkts trägt. Das Buch stellt die unterschiedlichen Aufgaben und Verhaltensweisen der traditionellen und der agilen Rolle klar heraus und vergleicht sie miteinander.

Viele haben versucht, die Rolle des Product Owner zu erklären, doch niemand kann die Essenz dieser Rolle so gut beschreiben wie Roman Pichler. Dieses Buch bietet überzeugende agile Produktmanagementkonzepte und -praktiken, die Product Owner, Teams und Führungskräften helfen, Innovationen umzusetzen. Roman Pichler liefert zahlreiche Praxisbeispiele von höchst innovativen Unternehmen, zu denen auch Salesforce.com zählt, wie die Erstellung eines minimalen Produkts, um Innovationen schnell auf den Markt zu bringen. Darüber hinaus stellt er die üblichen Fallstricke und Fehler vor, mit denen viele Product Owner zu kämpfen haben.

In den dynamischen und wettbewerbsorientierten Märkten, die wir heutzutage erleben, sind die Erwartungen und Ansprüche unserer Kunden größer als je zuvor. Für Salesforce.com hat agiles Arbeiten fantastische Ergebnisse erbracht: Unsere Product Owner können mehr Innovationen umsetzen und mehr Mehrwert schaffen. Wenn Sie an ähnlichen Erfolgen interessiert sind, halten Sie das genau richtige Buch in der Hand. Seine Tools, Techniken und Anleitungen sind der perfekte Leitfaden, um für Ihre Kunden außergewöhnliche Erfolge zu erzielen.

Brett Queener

Senior Vice President, Products, bei Salesforce.com

Inhaltsverzeichnis

1     Einleitung

1.1     Agiles Produktmanagement im Überblick

1.2     Agiles Produktmanagement als Teil eines Ganzen

1.3     Über dieses Buch und seine Zielgruppe

1.4     Danksagung

2     Die Product-Owner-Rolle

2.1     Die Aufgaben des Product Owner

2.2     Hilfreiche Eigenschaften des Product Owner

2.2.1     Unternehmer im Unternehmen

2.2.2     Mannschaftsdienlicher Leader

2.2.3     Verhandlungs- und kommunikationsgeschickt

2.2.4     Bevollmächtigt und engagiert

2.2.5     Verfügbar und qualifiziert

2.3     Die Zusammenarbeit mit dem Team

2.4     Die Zusammenarbeit mit dem ScrumMaster

2.5     Die Zusammenarbeit mit Kunden, Anwendern und anderen Interessenvertretern

2.6     Die Product-Owner-Rolle in großen Scrum-Projekten

2.6.1     Der Chief Product Owner

2.6.2     Product-Owner-Hierarchien

2.6.3     Die Wahl der richtigen Product Owner

2.7     Häufige Fehler

2.7.1     Der machtlose Product Owner

2.7.2     Der überarbeitete Product Owner

2.7.3     Der partielle Product Owner

2.7.4     Der distanzierte Product Owner

2.7.5     Der Proxy Product Owner

2.7.6     Das Product-Owner-Komitee

2.8     Zusammenfassung

3     Produktvision und Produkt-Roadmap

3.1     Die Produktvision und ihre Eigenschaften

3.1.1     Gemeinsames Ziel und Hypothese

3.1.2     Von allen mitgetragen

3.1.3     Grob und motivierend

3.1.4     Kurz und bündig

3.2     Das Erstellen der Produktvision

3.2.1     Zusammenarbeit und Kontinuität

3.2.2     Das Product Vision Board

3.2.3     Die Zielgruppe mit Personas beschreiben

3.2.4     Die Bedürfnisse mithilfe von Szenarien untersuchen

3.2.5     Das Produkt skizzieren

3.2.6     Eine Wirtschaftlichkeitsbetrachtung vornehmen

3.2.7     Die Informationen visualisieren

3.2.8     Der Einsatz von konventionellen Marktforschungstechniken

3.3     Das minimale Produkt als agile Produktplanungstechnik

3.4     Einfachheit als Leitprinzip

3.4.1     Ockhams Rasiermesser

3.4.2     Weniger ist mehr

3.4.3     Einfache Benutzerschnittstellen

3.5     Voraussetzungen für Innovationen schaffen

3.6     Die Produkt-Roadmap

3.6.1     Überblick

3.6.2     Vorteile

3.6.3     Erfolgsfaktoren

3.6.4     Zeitpunkt der Roadmap-Erstellung

3.6.5     Planungshorizont

3.7     Produktvarianten

3.8     Häufige Fehler

3.8.1     Wolpertinger

3.8.2     Analyse-Paralyse

3.8.3     Elfenbeinturm

3.8.4     Groß und mächtig

3.9     Zusammenfassung

4     Das Product Backlog

4.1     Die Eigenschaften des Product Backlog

4.1.1     Adäquat detailliert

4.1.2     Abgeschätzt

4.1.3     Veränderlich

4.1.4     Priorisiert

4.1.5     Sichtbar

4.2     Die Pflege des Product Backlog

4.2.1     Die Pflegeaktivitäten im Überblick

4.2.2     Backlog-Pflege ist Teamarbeit

4.2.3     Pflegeworkshops

4.3     Das Entdecken und Beschreiben von Einträgen

4.3.1     Einträge entdecken

4.3.2     Einträge beschreiben

4.3.3     Themen bilden

4.4     Die Priorisierung des Product Backlog

4.4.1     Wert

4.4.2     Risiko

4.4.3     Auslieferbarkeit

4.4.4     Abhängigkeiten

4.5     Vorbereitung auf die Sprint-Planungssitzung

4.5.1     Auswahl des Sprint-Ziels

4.5.2     Gerade genug Einträge zeitoptimal vorbereiten

4.5.3     Einträge herunterbrechen

4.5.4     Klarheit, Testbarkeit und Machbarkeit sicherstellen

4.6     Einträge abschätzen

4.6.1     Story Points

4.6.2     Planungspoker

4.7     Nicht funktionale Anforderungen richtig erfassen und managen

4.7.1     Nicht funktionale Anforderungen beschreiben

4.7.2     Nicht funktionale Anforderungen richtig behandlen

4.8     Das Product Backlog Board

4.8.1     Der Story-Bereich

4.8.2     Der Constraint-Bereich

4.8.3     Der Modellbereich

4.8.4     Das Product Backlog Board anlegen

4.8.5     Das Board sichtbar machen

4.9     Das Product Backlog skalieren

4.9.1     Ein projektweites Product Backlog verwenden

4.9.2     Den Pflegehorizont erweitern

4.9.3     Teamspezifische Product-Backlog-Ausschnitte verwenden

4.10   Häufige Fehler

4.10.1   Anforderungsspezifikation

4.10.2   Santas Wunschliste

4.10.3   Wüste

4.10.4   Feature-Suppe

4.10.5   Requirements Push

4.10.6   Ungepflegtes Backlog

4.10.7   Mehrere Backlogs pro Sprint

4.11   Zusammenfassung

5     Die Releaseplanung

5.1     Zeit, Kosten und Funktionalität

5.2     Keine faulen Qualitätskompromisse

5.3     Zieltermin

5.4     Kosten

5.5     Frühzeitiges Ausliefern

5.6     Quartalszyklen

5.7     Regelmäßiges Ausliefern

5.8     Velocity

5.9     Release-Burndown

5.9.1     Erstellung des Diagramms

5.9.2     Effektiver Einsatz des Diagramms

5.10   Releaseplan

5.10.1   Die Velocity vorhersagen

5.10.2   Den Releaseplan erstellen

5.11   Die Releaseplanung bei großen Projekten

5.11.1   Gemeinsame Grundlagen für die Schätzwerte

5.11.2   Vorausschauende Planung

5.11.3   Pipelining

5.12   Häufige Fehler

5.12.1   Kein Plan

5.12.2   Product Owner als Beifahrer

5.12.3   »Big Bang«-Release

5.12.4   Qualitätskompromisse

5.13   Zusammenfassung

6     Die Rolle des Product Owner in den Sprint-Besprechungen

6.1     Die Sprint-Planungssitzung

6.2     Daily Scrum

6.3     Das Sprint-Review

6.3.1     Zielsetzung

6.3.2     Teilnehmer und benötigte Artefakte

6.3.3     Ablauf

6.3.4     Ergebnisse

6.4     Die Sprint-Retrospektive

6.5     Sprint-Besprechungen bei großen Projekten

6.5.1     Gemeinsame Sprint-Planungssitzung

6.5.2     Scrum of Scrums

6.5.3     Projektweites Sprint-Review

6.5.4     Projektweite Sprint-Retrospektive

6.6     Häufige Fehler

6.6.1     Bungee Product Owner und Babysitter

6.6.2     Der passive Product Owner

6.6.3     Unhaltbares Tempo

6.6.4     Blendwerk

6.6.5     Sprint-Burndown-Diagramm als Projektstatusbericht

6.7     Zusammenfassung

7     Die Etablierung der Product-Owner-Rolle

7.1     So werden Sie ein guter Product Owner

7.1.1     Selbsterkenntnis

7.1.2     Wachstum

7.1.3     Coaching

7.1.4     Sponsor

7.1.5     Netzwerk

7.2     So unterstützen Sie die Product Owner

7.2.1     Produktbewusstsein und Unternehmertum

7.2.2     Der richtige Mitarbeiter

7.2.3     Unterstützung

7.2.4     Nachhaltigkeit

7.3     Zusammenfassung

Referenzen

Index

1 Einleitung

Zu den Themen agile Softwareentwicklung und Produktmanagement finden sich viele ausgezeichnete Bücher. Eine umfassende Beschreibung agilen Produktmanagements existiert bislang jedoch nicht. Es scheint, als ob die Kenner agiler Methoden einen weiten Bogen um das Thema gemacht haben und die Produktmanagementexperten immer noch versuchen, die schöne neue agile Welt zu verstehen. Mit einer wachsenden Anzahl von Unternehmen, die Scrum einsetzen, wird aber die Frage immer dringender, wie Produktmanagement im Kontext von Scrum gelebt wird. Das vorliegende Buch möchte hierauf eine Antwort geben.

Als ich 1999 zum ersten Mal mit agilen Praktiken in Berührung kam, war ich besonders von der engen Zusammenarbeit zwischen Geschäftsleuten und Entwicklern beeindruckt. Bis dahin hatte ich geglaubt, dass sich nur Programmierer für Software interessieren. Als ich mein erstes agiles Projekt 2001 betreute, war meine größte Herausforderung, den beteiligten Produktmanagern beim Übergang in die agile Arbeitswelt zu helfen. Auch bei allen anderen Unternehmen, die ich seitdem bei der Einführung von Scrum begleitet habe, hat sich agiles Produktmanagement als die größte Hürde und der wichtigste Erfolgsfaktor herausgestellt – nicht nur um erfolgreiche Produkte mit Scrum zu entwickeln, sondern auch um Scrum langfristig erfolgreich einzusetzen. Um es mit den Worten von Chris Fry und Steve Greene [Fry & Greene 2007, S. 139] zu sagen, die die Einführung von Scrum bei Salesforce.com betreut haben:

Als wir mit dem Rollout [von Scrum] begannen, hörten wir von vielen Experten, dass die Rolle des Product Owner ein kritischer Erfolgsfaktor sei. Obwohl wir dies intuitiv verstanden, war uns das wahre Ausmaß der Veränderungen, die die Product Owner in ihrer Rolle erfahren würden, nicht klar.

1.1 Agiles Produktmanagement im Überblick

Scrum-basiertes, agiles Produktmanagement unterscheidet sich von herkömmlichen Ansätzen, wie Tabelle 1–1 zeigt.1

Konventionell

Agil

Mehrere Rollen, wie Produktmanager, Produktmarketer und Projektmanager, sind dafür verantwortlich, dass ein erfolgreiches Produkt entsteht.

Eine Person, der Product Owner, ist für den Produkterfolg verantwortlich und leitet das Entwicklungsprojekt. Der Product Owner ist Unternehmer im Unternehmen. Kapitel 2 und 6 beschreiben die Rolle des Product Owner ausführlich.

Produktmanager arbeiten weitestgehend unabhängig von den Entwicklungsteams, oft getrennt durch Prozess- und Abteilungsgrenzen sowie separate Arbeitszimmer.

Der Product Owner ist ein Mitglied des Scrum-Teams und arbeitet eng mit ScrumMaster und Team zusammen. Kapitel 2, 4 und 6 diskutieren die Zusammenarbeit im Scrum-Team genauer.

Umfangreiche Marktforschungsarbeiten, Produktplanung und Geschäftsanalyse werden zu Beginn des Innovationsprozesses ausgeführt.

Nur minimale, zum Erstellen der Produktvision notwendige Aufwände werden vorab erbracht. Kapitel 3 beschreibt die Produktvision in Scrum ausführlich.

Die Produktfunktionalität wird vorab festgelegt: Anforderungen werden frühzeitig detailliert und eingefroren.

Produktdefinition ist ein kontinuierlicher Prozess: Durch Kunden- und Anwenderfeedback werden neue Anforderungen im laufenden Projekt entdeckt und existierende verändern sich. Mehr Informationen finden Sie in den Kapiteln 5 und 6.

Kundenfeedback stellt sich meist spät ein, typischerweise im Markttest und bei der Markteinführung.

Das Vorführen und Ausliefern von Produktinkrementen erlaubt, die Marktreaktion frühzeitig zu erkennen und das Produkt im Dialog mit den Kunden zu entwickeln. Kapitel 5 und 6 erklären diese Techniken näher.

Tab. 1–1 Agiles und konventionelles Produktmanagement im Vergleich

Scrum folgt wie andere agile Methoden einer uralten Weisheit: Es sieht Wandel als die einzige Konstante an. »Wenn ein Unternehmen seine Produkte nicht durch seine eigene Forschung überflüssig macht, dann tut dies ein anderes«, schrieb Theodore Levitt in seinem bekannten Artikel »Marketing Myopia« im Jahre 1960 [Levitt 1960]. Und [Christensen 1997] zeigt, dass disruptive Innovationen in jedem Markt auftreten. Lediglich ihre Häufigkeit ist ungewiss. Unternehmen, die sich nicht schnell auf die entsprechende Veränderung einstellen können, sind nicht länger wettbewerbsfähig.

Zum Glück eignet sich Scrum bestens für das Umsetzen von Innovationen. Aufgrund seiner empirischen Natur ist Scrum prädestiniert für Einsatzgebiete, die von Veränderungen, Unsicherheit und Risiko gekennzeichnet sind. Die in diesem Buch aufgeführten Konzepte und Techniken wie das Etablieren eines Product Owner mit klarer Produktverantwortung, das frühe und regelmäßige Einbeziehen von Anwendern und Kunden in die Produktentwicklung, das Reduzieren der Time-to-Market durch die Entwicklung eines schlanken, minimalen Produkts oder das regelmäßige Ausliefern von Produktaktualisierungen verbessern Ihre Innovationskraft und helfen Ihnen, nachhaltig erfolgreich zu wirtschaften.

Dabei sollte Ihnen bewusst sein, dass Scrum im Grunde ein trial-and-error-basierter Prozess ist: Gestartet wird mit einer Vision und einem skizzenhaften Product Backlog. Letzteres bildet den Input für die Erstellung des ersten Produktinkrements. Dieses wird Kunden und Anwendern vorgeführt, um zu verstehen, ob das richtige Produkt mit den richtigen Features entwickelt wird. Das Feedback der Kunden und Anwender fließt in das Backlog ein und beeinflusst so die Entwicklung der nächsten Inkremente. Dieses Vorgehen wird auch als inspect and adapt – als untersuchen und anpassen – bezeichnet.

1.2 Agiles Produktmanagement als Teil eines Ganzen

Damit agiles Produktmanagement langfristig erfolgreich angewandt werden kann, muss es mit zwei weiteren Bereichen harmonieren: mit agilen Managementpraktiken und agilen Entwicklungspraktiken. Dies veranschaulicht Abbildung 1–1:

Abb. 1–1 Der agile Dreiklang

Agile Managementpraktiken helfen Teams, effektiv zusammenzuarbeiten, und werden von einem Framework wie Scrum bereitgestellt [Pichler 2008]. Agile Entwicklungspraktiken stellen sicher, dass Kunden- und Anwenderfeedback rasch in die Software integriert werden kann. Beispiele sind testgetriebene Entwicklung, kontinuierliche Integration oder Pair Programming [Pichler & Roock 2011].

1.3 Über dieses Buch und seine Zielgruppe

Dieses Buch wendet sich an alle, die sich für das Thema agiles Produktmanagement interessieren, insbesondere an diejenigen Leser, die als Product Owner arbeiten oder vorhaben, dies zu tun. Das Buch bespricht die Rolle des Product Owner zusammen mit wichtigen agilen Produktmanagementpraktiken wie die Erstellung der Produktvision, das Anlegen und Pflegen des Product Backlog, das Planen und Verfolgen des Projekts, die Rolle des Product Owner in den Sprint-Besprechungen sowie notwendige Veränderungen zur Etablierung agilen Produktmanagements. Als praktischer Leitfaden hilft Ihnen das Buch, agile Produktmanagementtechniken in Scrum erfolgreich einzusetzen. Im Fokus stehen softwarebasierte Produkte, die von Webapplikationen bis zu Mobiltelefonen reichen.

Bitte beachten Sie, dass das Buch weder eine Einführung in das Thema Produktmanagement noch in das Thema Scrum bietet. Die Lektüre des Buchs setzt ein solides Grundwissen in beiden Themen voraus. Eine umfangreiche Darstellung von Scrum finden Sie in [Schwaber 2004] und [Pichler 2008]. Das vorliegende Buch fokussiert die für Scrum spezifischen Konzepte und Praktiken und klammert andere Produktmanagementbereiche bewusst aus.

Ich hoffe, dass dieses Buch Ihnen dabei hilft, auf eine gesunde und nachhaltige Art und Weise Produkte zu entwickeln, die Kunden begeistern.

1.4 Danksagung

Dieses Buch wäre ohne die Unterstützung vieler Menschen nicht möglich gewesen. Für die vorliegende aktualisierte und erweiterte deutsche Ausgabe möchte ich insbesondere Markus Andrezak, Arne Roock und Stefan Roock für ihre Reviews danken. Außerdem gilt mein Dank Jürgen Dubau, der mich beim Übersetzen unterstützt hat. Ganz besonders möchte ich meiner Frau Melissa Pichler danken, die mir mit Rat und Tat zur Seite stand und mich beim Erstellen der Grafiken unterstützt hat.

Für die englische Ausgabe, auf der dieses Buch aufbaut, bedanke ich mich herzlich bei den folgenden Reviewern (in alphabetischer Reihenfolge): Lyssa Adkins, Geir Amsjø, Markus Andrezak, Gabrielle Benefield, Robert Bogetti, Thomke Buhl, Marty Cagan, Sabine Canditt, John Clifford, Alistair Cockburn, Mike Cohn, Jens Coldeway, Kaustabh Debbarman, Pete Deemer, Chris Fry, Steve Greene, Roland Hanbury, Kevlin Henney, Ben Hogan, Clinton Keith, Andreas Klinger, Hans-Peter Korn, Jochen Krebs, Craig Larman, Bill Li, Lowell Lindstrom, Catherine Louis, Rodrigo Luna, Artem Marchenko, Jason Martinez, Ralph Miarka, Philip Missler, Bent Myllerup, Jeff Patton, Tobias Pichler, Brett Queener, Cesário Ramos, Dan Rawsthorne, Simon Roberts, Stefan Roock, Rene Rosendahl, Johanna Rothman, Kenneth Rubin, Martin Rusnak, Hans-Peter Samios, Bob Schatz, Andreas Schliep, Ken Schwaber, Christa Schwanninger, Karl Scotland, Martin Shaw, Lisa Shoop, James Siddle, Michele Sliger, Preston Smith, Dieter Stefanowitz, Jeff Sutherland, Mads Troels Hansen, Bas Vodde, Geoff Watts, Harvey Wheaton, Rüdiger Wolf, Elizabeth Woodward und Lv Yi.

Außerdem bin ich besonders Mike Cohn zu Dank verpflichtet. Mikes frühes und regelmäßiges Feedback hat mir beim Schreiben der englischen Ausgabe enorm geholfen. Vielen Dank auch an Jeff Sutherland und Brett Queener für ihre Geleitworte und an Ken Schwaber, der mir Scrum beigebracht hat.

Ein Buchprojekt ist für mich nur mit der Unterstützung meiner Familie realisierbar. Meine Frau Melissa Pichler hat nicht nur meine Gemütsschwankungen beim Schreiben der englischen und deutschen Version geduldig ertragen. Sie war auch stets ein wichtiger Gesprächs- und Reviewpartner. Mein Dank gilt auch meinen Kindern Leo und Yasmin für ihre Rücksichtnahme auf Papas Konzentrationsbedarf und den Versuch, nicht ganz so laut zu spielen.

1 Bitte beachten Sie, dass ich den Begriff Scrum-Team verwende, um das Team, bestehend aus Product Owner, ScrumMaster und (Entwicklungs-)Team, zu bezeichnen.

2 Die Product-Owner-Rolle

Vor etlichen Jahren war ich an der Entwicklung eines ambitionierten medizintechnischen Produkts beteiligt. Dieses sollte nicht nur die Vorgängerversion ersetzen, sondern zugleich neue Funktionalität anbieten und die Konkurrenz überflügeln. Nach mehr als zwei Jahren Entwicklungszeit wurde das neue Produkt mit hohen Erwartungen in den Markt eingeführt – und floppte. Ein wichtiger Grund für den Fehlschlag waren die vielen Übergaben und komplizierten Entscheidungsprozesse: Das Produktmarketing hatte die Marktforschungsaktivitäten ausgeführt, das Produktkonzept erstellt und es an das Produktmanagement weitergeleitet. Dieses verfasste die Anforderungsspezifikation und übergab diese an den zuständigen Projektmanager. Und der reichte die Dokumente an die Entwicklungsteams weiter. Einen Mitarbeiter, der eine Vision des neuen Produkts kreierte und deren Umsetzung in ein auslieferbares Produkt betreute, gab es nicht.

In Scrum ist eine Person für die Entstehung des Produkts und seinen Erfolg verantwortlich – der Product Owner. Übergaben, Missverständnisse und unklare Verantwortlichkeiten werden so vermieden. Dieses Kapitel beschreibt die Product-Owner-Rolle im Detail. Es erklärt die Rechte und Pflichten der Rolle zusammen mit ihrer Anwendung.

2.1 Die Aufgaben des Product Owner

Der Product Owner ist für den Erfolg des Produkts verantwortlich oder, anders gesagt, dafür, dass das Team möglichst viel Wert schafft (vgl. [Schwaber 2011, S. 3]). Dies kann bedeuten, ein Renditeziel zu erreichen, einen bestimmten Marktanteil zu erobern, den Markennamen weiterzuentwickeln oder Kosteneinsparungen zu erzielen. Um diese Verantwortung wahrnehmen zu können, muss der Product Owner nach meiner Erfahrung meist folgende Aufgaben übernehmen: die Produktvision erstellen und die Produkt-Roadmap managen; das Product Backlog anlegen und pflegen; das Projekt steuern und das Budget managen; Kunden, Anwender und andere Interessenvertreter einbinden und mit dem Team vertrauensvoll zusammenarbeiten; die Markteinführung bzw. Inbetriebnahme des Produkts vorbereiten. Abbildung 2–1 stellt die Rolle mit ihren wichtigsten Aufgaben, Artefakten und Einschränkungen kurz und knapp dar.

Abb. 2–1 Die Product-Owner-Rolle im Überblick

Der Product Owner ist nicht nur für die Entstehung eines neuen Produkts verantwortlich, sondern betreut auch seine Weiterentwicklung und managt so den Produktlebenszyklus. Dies schafft Kontinuität und unterstützt eine langfristige Erfolgsorientierung. Eine Mitarbeiterbefragung der SAP AG förderte weitere Vorteile zutage: Als Product Owner fühlten sich die Mitarbeiter souveräner, konnten mehr Einfluss geltend machen, hatten mehr Sichtbarkeit, konnten ihre Arbeit besser organisieren und waren motivierter [Schmidkonz 2008].

Auch wenn der Product Owner an herkömmliche Rollen wie Produktmanager oder Projektleiter erinnern mag, ist sie doch neu und eigenständig. Denn die Rolle vereint wesentliche Rechte und Pflichten, die sich traditionell auf verschiedene Schultern verteilen, wie Abbildung 2–2 zeigt. Durch das Zusammenziehen der Verantwortung werden Übergaben und Informationsverluste, unklare Zuständigkeiten, lange Entscheidungswege und schlechte Kompromisse vermieden.

Abb. 2–2 Die Product-Owner-Rolle vereint wesentliche Aspekte traditioneller Rollen.

Trotz seiner herausgehobenen Stellung ist der Product Owner kein Einzelkämpfer, sondern Mitglied des Scrum-Teams. ScrumMaster und Team unterstützen den Product Owner bei der Bewältigung seiner Aufgaben, beispielsweise beim Identifizieren und Beschreiben von Anforderungen oder bei dem Verfeinern von User Stories.

Die spezifische Ausprägung der Product-Owner-Rolle hängt unter anderem von der Art des Produkts, der Produktlebenszyklusphase und der Projektgröße ab. Die Arbeit eines Product Owner für ein neues Produkt aus Software, Hardware und Mechanik unterscheidet sich beispielsweise von der Weiterentwicklung einer iPhone-Applikation. Für kommerzielle Produkte wird die Product-Owner-Rolle typischerweise durch einen Kundenvertreter wie einen Produktmarketingmanager oder Produktmanager besetzt. Der Product Owner agiert demnach als Kundenproxy, wie Abbildung 2–3 darstellt. Das bedeutet übrigens nicht, dass Teammitglieder nicht direkt mit Kunden und Anwendern kommunizieren. Im Gegenteil: Team und Stakeholder interagieren beispielsweise im Sprint-Review-Meeting (kurz: Sprint-Review), wie ich in Kapitel 6 näher erläutere.

Abb. 2–3 Der Product Owner als Kundenrepräsentant

Kunden, Anwender und andere Interessenvertreter wie das Marketing und der Vertrieb sind zwar wichtige Quellen für Anforderungen und Ideen, in letzter Konsequenz entscheidet aber der Product Owner darüber, wann welche Funktionalität realisiert wird. Dazu gehört es auch, Anforderungen zurückzuweisen, wenn diese nicht hilfreich für das Erreichen des Projektziels sind.

Endkunden übernehmen meist dann die Product-Owner-Rolle, wenn es sich um eine Auftragsentwicklung handelt, beispielsweise wenn ein Kunde eine maßgeschneiderte Data-Warehouse-Lösung benötigt oder die Marketingabteilung die Erweiterung einer Webapplikation, wie Abbildung 2–4 zeigt.

Abb. 2–4 Kunde als Product Owner

Ich habe Kunden, Anwender, Führungskräfte, Produktmanager, Projektleiter, Business Analysts und Architekten als Product Owner erlebt, die unter den gegebenen Umständen die Rolle gut ausgefüllt haben. Sogar Firmenchefs können als Product Owner agieren, wie im Fall von Ript, einem visuellen Planungstool, das Benutzern erlaubt, den Inhalt von beliebigen Webseiten zusammenzufügen. Die Software war die Idee von Gerry Laybourne, CEO von Oxygen Media, und folglich übte die Firmenchefin die Product-Owner-Rolle für die erste Produktversion aus [Judy 2007].

Produkt, Projekt und Release

Scrum stellt das Produkt in den Mittelpunkt und spricht von Product Owner, Produktvision und Product Backlog. Der Projektbegriff spielt eine untergeordnete Rolle. Und das hat einen guten Grund: Scrum unterstützt langfristiges und nachhaltiges Wirtschaften. Schließlich ist ein Projekt nur Mittel zum Zweck – es dient der Entwicklung der nächsten Produktversion. Dies veranschaulicht Abbildung 2–5.

Abb. 2–5 Produkt vs. Projekt

Ein Produkt besitzt eine Version, die ausgewählte Kunden- und Anwenderbedürfnisse adressiert. Diese wird durch ein Projekt entwickelt, das Software ein- oder mehrmals freigibt.

Überlegungen zur Besetzung der Product-Owner-Rolle lösen bei meinen Kunden immer wieder eine Diskussion über den Produktbegriff aus. Denn um die Rolle richtig zu besetzen, müssen wir uns zunächst im Klaren sein, welche Produkte die Organisation bereitstellt und wie diese für ihre Entwicklung geschnitten werden. Ich bevorzuge es dabei, mit schlanken fokussierten Produkten zu arbeiten, die jeweils von einem oder wenigen Teams entwickelt werden können – anstatt ein großes, komplexes Produkt mit einem großen Projekt zu erstellen.

2.2 Hilfreiche Eigenschaften des Product Owner

Die richtige Besetzung der Product Owner ist ein Erfolgsfaktor für jedes Produkt, das mit Scrum entwickelt wird. Die nachfolgend aufgeführten Eigenschaften beschreiben nützliche Qualifikationen und hilfreiches Verhalten. Da die Arbeit als Product Owner oft eine neue Erfahrung darstellt, benötigen die Mitarbeiter meist Zeit und Unterstützung, um in die Rolle hineinzuwachsen, wie ich ausführlicher in Kapitel 7 bespreche.

2.2.1 Unternehmer im Unternehmen

Der Product Owner agiert als Unternehmer (im Unternehmen), der eine Vision für sein Produkt entwickelt und tatkräftig an deren Umsetzung mitwirkt. Letzteres beinhaltet das Beschreiben der Produktfunktionalität, eine enge Zusammenarbeit mit dem Team, das Akzeptieren oder Ablehnen von Arbeitsergebnissen und das Planen des Projekts. Als Unternehmer im Unternehmen fördert der Product Owner Kreativität und Innovation und kann mit Wandel, Ambiguität, Konflikten und Unsicherheit konstruktiv umgehen und ist bereit, Risiken bewusst einzugehen.

Ich finde es dabei hilfreich, ein Scrum-Projekt als internes Start-up bzw. Inkubator zu betrachten und das Projekt entsprechend aufzusetzen – ähnlich wie Google dies für die Entwicklung einiger seiner Produkte praktiziert (siehe Kasten »Unternehmerische Innovation bei Google«). Der Product Owner agiert dann als Intrapreneur.

In-house Innovation bei Google

»[Google] Wave begann als Idee, ein neues Paradigma für virtuelle Zusammenarbeit zu schaffen, und hatte das ehrgeizige Ziel, E-Mail zu verbessern und möglicherweise zu ersetzen«, schreiben Alberto Savoia und Patrick Copeland in »Entrepreneurial Innovation at Google« [