Rubin Essential Scrum
1. Auflage 2014
ISBN: 978-3-8266-8473-9
Verlag: mitp Verlags GmbH & Co.KG
Format: PDF
Kopierschutz: 0 - No protection
Umfassendes Scrum-Wissen aus der Praxis
E-Book, Deutsch, 480 Seiten
Reihe: mitp Professional
ISBN: 978-3-8266-8473-9
Verlag: mitp Verlags GmbH & Co.KG
Format: PDF
Kopierschutz: 0 - No protection
- Umfassendes Scrum-Wissen auf Team-, Produkt- und Portfolio-Ebene
- Kernkonzepte, Rollen, Planung und Sprints ausführlich erläutert
- Auch geeignet zur Vorbereitung auf die Scrum-Zertifizierung
Dieses Buch beschreibt das Wesen von Scrum – die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen zu entwickeln.Es ist entstanden, weil der Autor Kenneth S. Rubin als Agile- und Scrum-Berater oft nach einem Referenzbuch für Scrum gefragt worden ist – einem Buch, das einen umfassenden Überblick über das Scrum-Framework bietet und darüber hinaus die beliebtesten Ansätze für die Anwendung von Scrum präsentiert.
Dieses Buch ist der Versuch, die eine entscheidende Quelle für alles Wesentliche über Scrum bereitzustellen.Rubin beleuchtet die Werte, Prinzipien und Praktiken von Scrum und beschreibt bewährte, flexible Ansätze, die Ihnen helfen werden, sie viel effektiver umzusetzen. Dabei liefert er mehr als nur die Grundlagen und weist zudem auf wichtige Probleme hin, die Ihnen auf Ihrem Weg begegnen können.Ob Sie sich nun zum ersten Mal an Scrum versuchen oder es schon seit Jahren benutzen: Dieses Buch weiht Sie in die Geheimnisse des Scrum-Entwicklungsverfahrens ein und vermittelt Ihnen ein umfangreiches Scrum-Wissen auf Team-, Produkt- und Portfolio-Ebene. Für diejenigen, die bereits mit Scrum vertraut sind, eignet es sich als Scrum-Referenz.Rubin hat das Buch nicht für eine bestimmte Scrum-Rolle geschrieben. Stattdessen soll es allen, die direkt oder indirekt mit Scrum zu tun haben, ein gemeinsames Verständnis von Scrum und den Prinzipien, auf denen es beruht, vermitteln.
1. Teil: Kernkonzepte
- Scrum-Framework
- Agile Prinzipien
- Sprints
- Anforderungen und User Stories
- Das Product Backlog
- Schätzungen und Velocity
- Technische Schulden
2. Teil: Rollen
- Product Owner
- Scrum
- Master
- Entwicklungsteam
- Strukturen des Scrum-Teams
- Manager
3. Teil: Planung
- Scrum-Planungsprinzipien
- Mehrstufige Planung
- Portfolio-Planung
- Visionsfindung/Produktplanung
- Release-Planung
4. Teil: Sprints
- Sprint-Planung
- Sprint-Ausführung
- Sprint Review
- Sprint-Retrospektive
Zielgruppe
Softwareentwickler, ScrumMaster, Projektmanager und alle, die Scrum einsetzen oder sich auf die Scrum-Zetifizierung vorbereiten
Autoren/Hrsg.
Weitere Infos & Material
1;Cover;1
2;Titel;5
3;Impressum;6
4;Inhaltsverzeichnis;7
5;Vorwort von Mike Cohn;21
6;Vorwort von Ron Jeffries;23
7;Einleitung;25
8;Danksagungen;29
9;Über den Autor;33
10;Kapitel 1: Einführung;35
10.1;1.1 Was ist Scrum?;35
10.2;1.2 Die Ursprünge von Scrum;37
10.3;1.3 Wieso Scrum?;38
10.4;1.4 Ergebnisse bei Genomica;39
10.5;1.5 Kann Scrum Ihnen helfen?;39
10.5.1;1.5.1 Die Complex-Domäne;42
10.5.2;1.5.2 Die Complicated-Domäne;42
10.5.3;1.5.3 Die Simple-Domäne;43
10.5.4;1.5.4 Die Chaotic-Domäne;43
10.5.5;1.5.5 Disorder (Nicht-Wissen, Regellosigkeit);43
10.5.6;1.5.6 Unterbrechungsgesteuerte Arbeit;44
10.6;1.6 Abschließende Bemerkungen;45
11;Teil I: Kernkonzepte;47
11.1;Kapitel 2: Das Scrum-Framework;49
11.1.1;2.1 Überblick;49
11.1.2;2.2 Scrum-Rollen;50
11.1.2.1;2.2.1 Product Owner;51
11.1.2.2;2.2.2 ScrumMaster;51
11.1.2.3;2.2.3 Das Entwicklungsteam;52
11.1.3;2.3 Scrum-Aktivitäten und Artefakte;52
11.1.3.1;2.3.1 Product Backlog;54
11.1.3.2;2.3.2 Sprints;56
11.1.3.3;2.3.3 Sprint-Planung;57
11.1.3.4;2.3.4 Sprint-Ausführung;58
11.1.3.5;2.3.5 Daily Scrum;59
11.1.3.6;2.3.6 Fertig (Done);60
11.1.3.7;2.3.7 Sprint Review;62
11.1.3.8;2.3.8 Sprint-Retrospektive;63
11.1.4;2.4 Abschließende Bemerkungen;63
11.2;Kapitel 3: Agile Prinzipien;65
11.2.1;3.1 Überblick;65
11.2.2;3.2 Veränderlichkeit und Unsicherheit;68
11.2.2.1;3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen;68
11.2.2.2;3.2.2 Iterative und inkrementelle Entwicklung nutzen;69
11.2.2.3;3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion, Anpassung und Transparenz;71
11.2.2.4;3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit;72
11.2.3;3.3 Vorhersage und Anpassung;73
11.2.3.1;3.3.1 Optionen offen halten;73
11.2.3.2;3.3.2 Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann;74
11.2.3.3;3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen;76
11.2.3.4;3.3.4 Änderung auf eine ökonomisch sinnvolle Weise annehmen;77
11.2.3.5;3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit adaptiver, bedarfsgerechter Arbeit abwägen;80
11.2.4;3.4 Validiertes Wissen;81
11.2.4.1;3.4.1 Schnelles Validieren wichtiger Annahmen;81
11.2.4.2;3.4.2 Abwägen mehrerer gleichzeitiger Lernschleifen;81
11.2.4.3;3.4.3 Organisieren des Workflows für schnelle Feedbacks;82
11.2.5;3.5 Work in Process (WIP);84
11.2.5.1;3.5.1 Wirtschaftlich sinnvolle Batch-Größen benutzen;84
11.2.5.2;3.5.2 Lagerbestände erkennen und sinnvoll verwalten;86
11.2.5.3;3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter;87
11.2.5.4;3.5.4 Verzögerungskosten betrachten;89
11.2.6;3.6 Fortschritt;90
11.2.6.1;3.6.1 An Echtzeitinformationen anpassen und umplanen;90
11.2.6.2;3.6.2 Fortschritt messen, indem man funktionierende Güter validiert;91
11.2.6.3;3.6.3 Auf eine wertzentrierte Auslieferung konzentrieren;91
11.2.7;3.7 Leistung;92
11.2.7.1;3.7.1 Gehe schnell, aber hetze nicht;92
11.2.7.2;3.7.2 Baue Qualität ein;93
11.2.7.3;3.7.3 Mache alles ohne großes Zeremoniell;93
11.2.8;3.8 Abschließende Bemerkungen;94
11.3;Kapitel 4: Sprints;97
11.3.1;4.1 Überblick;97
11.3.2;4.2 Timeboxing;98
11.3.2.1;4.2.1 Legt ein WIP-Limit fest;98
11.3.2.2;4.2.2 Erzwingt eine Priorisierung;98
11.3.2.3;4.2.3 Demonstriert Fortschritt;99
11.3.2.4;4.2.4 Verhindert unnötigen Perfektionismus;99
11.3.2.5;4.2.5 Motiviert die Fertigstellung;99
11.3.2.6;4.2.6 Verbessert die Vorhersagbarkeit;100
11.3.3;4.3 Kurze Zeitdauer;100
11.3.3.1;4.3.1 Erleichterte Planung;100
11.3.3.2;4.3.2 Schnelles Feedback;101
11.3.3.3;4.3.3 Verbesserter Return on Investment;101
11.3.3.4;4.3.4 Begrenzte Fehler;101
11.3.3.5;4.3.5 Wiedererweckte Begeisterung;101
11.3.3.6;4.3.6 Häufige Checkpoints;102
11.3.4;4.4 Konsistente Dauer;103
11.3.4.1;4.4.1 Vorteile der Kadenz;104
11.3.4.2;4.4.2 Vereinfacht die Planung;104
11.3.5;4.5 Keine das Ziel beeinflussenden Änderungen;105
11.3.5.1;4.5.1 Was ist ein Sprint-Ziel?;105
11.3.5.2;4.5.2 Gegenseitige Verpflichtung;105
11.3.5.3;4.5.3 Änderungen versus Klärung;106
11.3.5.4;4.5.4 Konsequenzen einer Änderung;106
11.3.5.5;4.5.5 Pragmatisch sein;108
11.3.5.6;4.5.6 Abnormaler Abbruch;109
11.3.6;4.6 Definition von Fertig (Done);110
11.3.6.1;4.6.1 Wie lautet die Definition von Fertig?;110
11.3.6.2;4.6.2 Die Definition von Fertig kann sich im Laufe der Zeit weiterentwickeln;112
11.3.6.3;4.6.3 Definition von Fertig versus Akzeptanzkriterien;114
11.3.6.4;4.6.4 Fertig versus Fertig-Fertig;114
11.3.7;4.7 Abschließende Bemerkungen;115
11.4;Kapitel 5: Anforderungen und User Stories;117
11.4.1;5.1 Überblick;117
11.4.2;5.2 Gespräche;119
11.4.3;5.3 Progressive Verfeinerung;120
11.4.4;5.4 Was sind User Stories?;121
11.4.4.1;5.4.1 Card (Karte);121
11.4.4.2;5.4.2 Conversation (Gespräch);122
11.4.4.3;5.4.3 Confirmation (Bestätigung);123
11.4.5;5.5 Der Detaillierungsgrad;124
11.4.6;5.6 In gute Stories INVESTieren;127
11.4.6.1;5.6.1 Independent (unabhängig);127
11.4.6.2;5.6.2 Negotiable (verhandelbar);128
11.4.6.3;5.6.3 Valuable (werthaltig);128
11.4.6.4;5.6.4 Estimatable (schätzbar);130
11.4.6.5;5.6.5 Passende Größe (klein);130
11.4.6.6;5.6.6 Testable (prüfbar);131
11.4.7;5.7 Nichtfunktionale Anforderungen;131
11.4.8;5.8 Stories zum Wissenserwerb;132
11.4.9;5.9 Stories sammeln;134
11.4.9.1;5.9.1 Workshop zum Schreiben von User Stories;134
11.4.9.2;5.9.2 Story Mapping;135
11.4.10;5.10 Abschließende Bemerkungen;136
11.5;Kapitel 6: Das Product Backlog;139
11.5.1;6.1 Überblick;139
11.5.2;6.2 Product-Backlog-Elemente;140
11.5.3;6.3 Merkmale guter Product Backlogs;141
11.5.3.1;6.3.1 Detailed appropriately (ausreichend detailliert);141
11.5.3.2;6.3.2 Emergent;142
11.5.3.3;6.3.3 Estimated (geschätzt);142
11.5.3.4;6.3.4 Prioritized (priorisiert);143
11.5.4;6.4 Pflege;144
11.5.4.1;6.4.1 Was bedeutet Pflege?;144
11.5.4.2;6.4.2 Wer führt die Pflege durch?;145
11.5.4.3;6.4.3 Wann findet die Pflege statt?;146
11.5.5;6.5 Die Definition von Bereit;148
11.5.6;6.6 Flow Management;150
11.5.6.1;6.6.1 Release Flow Management;150
11.5.6.2;6.6.2 Sprint Flow Management;151
11.5.7;6.7 Welche und wie viele Product Backlogs?;152
11.5.7.1;6.7.1 Was ist ein Produkt?;152
11.5.7.2;6.7.2 Große Produkte – hierarchische Backlogs;154
11.5.7.3;6.7.3 Mehrere Teams – ein Product Backlog;155
11.5.7.4;6.7.4 Ein Team – mehrere Produkte;156
11.5.8;6.8 Abschließende Bemerkungen;157
11.6;Kapitel 7: Schätzung und Velocity;159
11.6.1;7.1 Überblick;159
11.6.2;7.2 Was und wann wir schätzen;160
11.6.2.1;7.2.1 Schätzungen für Portfolio-Backlog-Elemente;161
11.6.2.2;7.2.2 Product-Backlog-Schätzungen;161
11.6.2.3;7.2.3 Aufgabenschätzungen;162
11.6.3;7.3 Schätzkonzepte für Product-Backlog-Elemente;163
11.6.3.1;7.3.1 Als Team schätzen;163
11.6.3.2;7.3.2 Schätzungen sind keine Verpflichtungen;164
11.6.3.3;7.3.3 Exaktheit versus Präzision;165
11.6.3.4;7.3.4 Relative Größenschätzung;165
11.6.4;7.4 Schätzeinheiten für Product-Backlog-Elemente;168
11.6.4.1;7.4.1 Story-Punkte;168
11.6.4.2;7.4.2 Idealtage;168
11.6.5;7.5 Planungspoker;169
11.6.5.1;7.5.1 Schätzskala;170
11.6.5.2;7.5.2 Wie man spielt;171
11.6.5.3;7.5.3 Vorteile;173
11.6.6;7.6 Was ist Velocity?;173
11.6.7;7.7 Einen Velocity-Bereich berechnen;174
11.6.8;7.8 Die Velocity vorhersagen;175
11.6.9;7.9 Die Velocity beeinflussen;176
11.6.10;7.10 Missbrauch der Velocity;177
11.6.11;7.11 Abschließende Bemerkungen;178
11.7;Kapitel 8: Technische Schulden;179
11.7.1;8.1 Überblick;179
11.7.2;8.2 Die Folgen technischer Schulden;181
11.7.2.1;8.2.1 Unvorhersehbarer Wendepunkt;182
11.7.2.2;8.2.2 Zunehmend verzögerte Auslieferung;182
11.7.2.3;8.2.3 Beträchtliche Anzahl an Defekten;182
11.7.2.4;8.2.4 Steigende Entwicklungs- und Support-Kosten;182
11.7.2.5;8.2.5 Das Produkt verkümmert;183
11.7.2.6;8.2.6 Schwindende Vorhersehbarkeit;183
11.7.2.7;8.2.7 Leistungseinbruch;183
11.7.2.8;8.2.8 Allgemeiner Frust;184
11.7.2.9;8.2.9 Sinkende Kundenzufriedenheit;184
11.7.3;8.3 Ursachen der technischen Schulden;184
11.7.3.1;8.3.1 Druck hinsichtlich des Erreichens einer Deadline;184
11.7.3.2;8.3.2 Erfolglose Versuche der Velocity-Beschleunigung;185
11.7.3.3;8.3.3 Gerücht: Weniger Testen kann die Velocity beschleunigen;186
11.7.3.4;8.3.4 Schulden bauen auf Schulden auf;187
11.7.4;8.4 Technische Schulden müssen organisiert werden;188
11.7.5;8.5 Die Zunahme technischer Schulden überwachen;189
11.7.5.1;8.5.1 Bewährte technische Praktiken anwenden;189
11.7.5.2;8.5.2 Eine starke Definition von Fertig benutzen;190
11.7.5.3;8.5.3 Die wirtschaftlichen Aspekte technischer Schulden richtig verstehen;190
11.7.6;8.6 Technische Schulden sichtbar machen;193
11.7.6.1;8.6.1 Technische Schulden auf geschäftlicher Ebene sichtbar machen;193
11.7.6.2;8.6.2 Technische Schulden auf der technischen Ebene sichtbar machen;194
11.7.7;8.7 Technische Schulden abbauen;196
11.7.7.1;8.7.1 Nicht alle technischen Schulden sollten abgebaut werden;197
11.7.7.2;8.7.2 Wenden Sie die Pfadfinderregel an (Bauen Sie die Schulden ab, sobald sie Ihnen begegnen);199
11.7.7.3;8.7.3 Bauen Sie technische Schulden schrittweise ab;199
11.7.7.4;8.7.4 Bauen Sie die technischen Schulden mit den höchsten Zinsen zuerst ab;200
11.7.7.5;8.7.5 Technische Schulden abbauen, während man für den Kunden werthaltige Arbeit erledigt;201
11.7.8;8.8 Abschließende Bemerkungen;202
12;Teil II: Rollen;203
12.1;Kapitel 9: Der Product Owner;205
12.1.1;9.1 Überblick;205
12.1.2;9.2 Hauptaufgaben;206
12.1.2.1;9.2.1 Organisation der wirtschaftlichen Belange;207
12.1.2.2;9.2.2 Mitwirkung an der Planung;209
12.1.2.3;9.2.3 Pflege des Product Backlogs;209
12.1.2.4;9.2.4 Definition und Verifikation der Akzeptanzkriterien;209
12.1.2.5;9.2.5 Zusammenarbeit mit dem Entwicklungsteam;210
12.1.2.6;9.2.6 Zusammenarbeit mit den Stakeholdern;211
12.1.3;9.3 Eigenschaften/Fähigkeiten;212
12.1.3.1;9.3.1 Fachwissen;212
12.1.3.2;9.3.2 Soziale Kompetenz;213
12.1.3.3;9.3.3 Entscheidungsfindung;213
12.1.3.4;9.3.4 Verantwortung;213
12.1.4;9.4 Der Alltag eines Product Owners;214
12.1.5;9.5 Wer sollte Product Owner sein?;216
12.1.5.1;9.5.1 Interne Entwicklung;217
12.1.5.2;9.5.2 Gewerbliche Entwicklung;218
12.1.5.3;9.5.3 Ausgelagerte Entwicklung;220
12.1.5.4;9.5.4 Komponentenentwicklung;221
12.1.6;9.6 Product Owner kombiniert mit anderen Rollen;222
12.1.7;9.7 Das Product-Owner-Team;222
12.1.7.1;9.7.1 Product-Owner-Stellvertreter;223
12.1.7.2;9.7.2 Chief Product Owner;224
12.1.8;9.8 Abschließende Bemerkungen;225
12.2;Kapitel 10: ScrumMaster;227
12.2.1;10.1 Überblick;227
12.2.2;10.2 Wichtigste Aufgaben;227
12.2.2.1;10.2.1 Coach;227
12.2.2.2;10.2.2 »Dienende Führungskraft«;228
12.2.2.3;10.2.3 Prozessautorität;229
12.2.2.4;10.2.4 Schutz vor störenden Einflüssen;229
12.2.2.5;10.2.5 Beseitigung von Hindernissen;229
12.2.2.6;10.2.6 Berater in der Organisationsentwicklung;229
12.2.3;10.3 Eigenschaften/Fähigkeiten;230
12.2.3.1;10.3.1 Sachkundig;230
12.2.3.2;10.3.2 Neugierig;230
12.2.3.3;10.3.3 Geduldig;231
12.2.3.4;10.3.4 Teamfähig;231
12.2.3.5;10.3.5 Schützend;231
12.2.3.6;10.3.6 Transparent;232
12.2.4;10.4 Alltag;232
12.2.5;10.5 Die Rolle ausfüllen;233
12.2.5.1;10.5.1 Wer sollte ScrumMaster sein?;233
12.2.5.2;10.5.2 Ist die Rolle des ScrumMasters eine Vollzeitbeschäftigung?;234
12.2.5.3;10.5.3 ScrumMaster in Kombination mit anderen Rollen;234
12.2.6;10.6 Abschließende Bemerkungen;235
12.3;Kapitel 11: Das Entwicklungsteam;237
12.3.1;11.1 Überblick;237
12.3.2;11.2 Rollenspezifische Teams;237
12.3.3;11.3 Wichtigste Aufgaben;238
12.3.3.1;11.3.1 Durchführung des Sprints;238
12.3.3.2;11.3.2 Tägliches Untersuchen und Anpassen (»Inspect and Adapt«);239
12.3.3.3;11.3.3 Pflege des Product Backlogs;239
12.3.3.4;11.3.4 Den Sprint planen;239
12.3.3.5;11.3.5 Produkt und Prozess untersuchen und anpassen;239
12.3.4;11.4 Eigenschaften/Fertigkeiten;240
12.3.4.1;11.4.1 Selbstorganisierend;240
12.3.4.2;11.4.2 Funktionsübergreifend vielseitig;242
12.3.4.3;11.4.3 T-förmige Fertigkeiten;243
12.3.4.4;11.4.4 Die Musketier-Einstellung;245
12.3.4.5;11.4.5 Kommunikation mit hoher Bandbreite;247
12.3.4.6;11.4.6 Transparente Kommunikation;248
12.3.4.7;11.4.7 Die richtige Größe;248
12.3.4.8;11.4.8 Fokussiert und verpflichtet;249
12.3.4.9;11.4.9 In einer nachhaltigen Geschwindigkeit arbeiten;251
12.3.4.10;11.4.10 Langlebig;252
12.3.5;11.5 Abschließende Bemerkungen;254
12.4;Kapitel 12: Die Strukturen des Scrum-Teams;255
12.4.1;12.1 Überblick;255
12.4.2;12.2 Funktionsteams versus Komponententeams;255
12.4.3;12.3 Koordination mehrerer Teams;260
12.4.3.1;12.3.1 Scrum of Scrums;260
12.4.3.2;12.3.2 Der Release-Train;262
12.4.4;12.4 Abschließende Bemerkungen;265
12.5;Kapitel 13: Manager;267
12.5.1;13.1 Überblick;267
12.5.2;13.2 Teams koordinieren;268
12.5.2.1;13.2.1 Grenzen definieren;269
12.5.2.2;13.2.2 Ein klares Ziel vorgeben;269
12.5.2.3;13.2.3 Teams bilden;270
12.5.2.4;13.2.4 Die Teamzusammensetzung ändern;271
12.5.2.5;13.2.5 Teams bevollmächtigen;271
12.5.3;13.3 Teams fördern;273
12.5.3.1;13.3.1 Die Mitarbeiter anspornen;273
12.5.3.2;13.3.2 Kompetenz entwickeln;273
12.5.3.3;13.3.3 Fachliche Anleitung bieten;274
12.5.3.4;13.3.4 Die Integrität des Teams bewahren;275
12.5.4;13.4 Die Umgebung ausrichten und anpassen;275
12.5.4.1;13.4.1 Agile Werte fördern;275
12.5.4.2;13.4.2 Organisatorische Hindernisse entfernen;276
12.5.4.3;13.4.3 Die internen Abteilungen ausrichten;276
12.5.4.4;13.4.4 Die Partner ausrichten;277
12.5.5;13.5 Den Wertschöpfungsfluss organisieren;277
12.5.5.1;13.5.1 Die Sichtweise des Systems annehmen;277
12.5.5.2;13.5.2 Die wirtschaftlichen Aspekte organisieren;278
12.5.5.3;13.5.3 Messungen und Berichte überwachen;278
12.5.6;13.6 Projektmanager;279
12.5.6.1;13.6.1 Projektmanagementaufgaben in einem Scrum-Team;279
12.5.6.2;13.6.2 Eine getrennte Projektmanager-Rolle bewahren;281
12.5.7;13.7 Abschließende Bemerkungen;285
13;Teil III: Planen;287
13.1;Kapitel 14: Scrum-Planungsprinzipien;289
13.1.1;14.1 Überblick;289
13.1.2;14.2 Gehen Sie nicht davon aus, dass im Voraus erstellte Pläne korrekt sind;290
13.1.3;14.3 Die Vorabplanung sollte hilfreich, aber nicht exzessiv sein;290
13.1.4;14.4 Halten Sie sich die Planungsoptionen bis zum letzten verantwortbaren Augenblick offen;291
13.1.5;14.5 Konzentrieren Sie sich stärker auf das Anpassen und Neuplanen als darauf, einem Plan zu genügen;291
13.1.6;14.6 Den Planungsbestand richtig organisieren;294
13.1.7;14.7 Bevorzugen Sie kleinere und häufigere Releases;295
13.1.8;14.8 Lernen Sie schnell dazu und weichen Sie vom Plan ab, wenn es nötig sein sollte;297
13.1.9;14.9 Abschließende Bemerkungen;297
13.2;Kapitel 15: Planung auf mehreren Ebenen;299
13.2.1;15.1 Überblick;299
13.2.2;15.2 Portfolio-Planung;301
13.2.3;15.3 Produktplanung (Visionsbildung);301
13.2.3.1;15.3.1 Die Vision;301
13.2.3.2;15.3.2 Allgemeines Product Backlog;302
13.2.3.3;15.3.3 Produkt-Roadmap;302
13.2.4;15.4 Release-Planung;304
13.2.5;15.5 Sprint-Planung;306
13.2.6;15.6 Tägliche Planung;306
13.2.7;15.7 Abschließende Bemerkungen;307
13.3;Kapitel 16: Portfolio-Planung;309
13.3.1;16.1 Überblick;309
13.3.1.1;16.1.1 Das Timing;309
13.3.1.2;16.1.2 Teilnehmer;310
13.3.1.3;16.1.3 Der Prozess;310
13.3.2;16.2 Zeitplanungsstrategien;312
13.3.2.1;16.2.1 Optimierung der Rendite über die Lebensdauer;313
13.3.2.2;16.2.2 Kalkulation der Verzögerungskosten;314
13.3.2.3;16.2.3 Schätzungen mit Genauigkeit statt Präzision;317
13.3.3;16.3 Zuflussstrategien;318
13.3.3.1;16.3.1 Den wirtschaftlichen Filter anwenden;318
13.3.3.2;16.3.2 Zufluss- und Abflussrate ausbalancieren;319
13.3.3.3;16.3.3 Sich bietende Gelegenheiten schnell ergreifen;321
13.3.3.4;16.3.4 Planen Sie kleinere, häufigere Releases;322
13.3.4;16.4 Abflussstrategien;324
13.3.4.1;16.4.1 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Mitarbeiter;324
13.3.4.2;16.4.2 Einrichten eines WIP-Limits;324
13.3.4.3;16.4.3 Auf ein komplettes Team warten;325
13.3.5;16.5 Strategien zur Überprüfung der in Bearbeitung befindlichen Produkte;326
13.3.5.1;16.5.1 Die Grenznutzenrechnung verwenden;327
13.3.6;16.6 Abschließende Bemerkungen;328
13.4;Kapitel 17: Visionsfindung (Produktplanung);331
13.4.1;17.1 Überblick;331
13.4.1.1;17.1.1 Das Timing;332
13.4.1.2;17.1.2 Teilnehmer;332
13.4.1.3;17.1.3 Der Prozess;334
13.4.2;17.2 SR4U-Beispiel;334
13.4.3;17.3 Die Entwicklung der Vision;336
13.4.4;17.4 Erstellen eines allgemeinen Product Backlogs;338
13.4.5;17.5 Die Definition der Produkt-Roadmap;339
13.4.6;17.6 Andere Aktivitäten;342
13.4.7;17.7 Wirtschaftlich vernünftige Visionsfindung;344
13.4.7.1;17.7.1 Eine realistische Vertrauensschwelle anstreben;345
13.4.7.2;17.7.2 Konzentrieren Sie sich auf einen kurzfristigen Planungshorizont;346
13.4.7.3;17.7.3 Handeln Sie schnell;347
13.4.7.4;17.7.4 Erwerben Sie validiertes Wissen;347
13.4.7.5;17.7.5 Nutzen Sie eine inkrementelle Finanzierung;348
13.4.7.6;17.7.6 Lernen Sie schnell dazu und weichen Sie ggf. vom Plan ab (aka Schnelles Scheitern);350
13.4.8;17.8 Abschließende Bemerkungen;350
13.5;Kapitel 18: Release-Planung (längerfristige Planung);351
13.5.1;18.1 Überblick;351
13.5.1.1;18.1.1 Das Timing;352
13.5.1.2;18.1.2 Teilnehmer;352
13.5.1.3;18.1.3 Der Prozess;353
13.5.2;18.2 Release-Einschränkungen;355
13.5.2.1;18.2.1 Alles fest;355
13.5.2.2;18.2.2 Umfang und Termin fest;356
13.5.2.3;18.2.3 Fester Umfang;357
13.5.2.4;18.2.4 Fester Termin;358
13.5.2.5;18.2.5 Variable Qualität;358
13.5.2.6;18.2.6 Einschränkungen aktualisieren;358
13.5.3;18.3 Das Product Backlog pflegen;359
13.5.4;18.4 Die minimal freigebbaren Funktionen (Minimum Releasable Features, MRFs) verfeinern;360
13.5.5;18.5 Sprint Mapping (Einordnung der Product-Backlog-Elemente);361
13.5.6;18.6 Release-Planung mit festem Termin;363
13.5.7;18.7 Release-Planung mit festem Umfang;368
13.5.8;18.8 Die Kosten berechnen;370
13.5.9;18.9 Kommunizieren;371
13.5.9.1;18.9.1 Den Fortschritt in einem Release mit festem Umfang kommunizieren;371
13.5.9.2;18.9.2 Den Fortschritt in einem Release mit festem Termin kommunizieren;374
13.5.10;18.10 Abschließende Bemerkungen;375
14;Teil IV: Sprints;377
14.1;Kapitel 19: Die Sprint-Planung;379
14.1.1;19.1 Überblick;379
14.1.1.1;19.1.1 Das Timing;379
14.1.1.2;19.1.2 Teilnehmer;379
14.1.1.3;19.1.3 Der Prozess;380
14.1.2;19.2 Ansätze für die Sprint-Planung;382
14.1.2.1;19.2.1 Zweiteilige Sprint-Planung;382
14.1.2.2;19.2.2 Einteilige Sprint-Planung;383
14.1.3;19.3 Die Kapazität ermitteln;384
14.1.3.1;19.3.1 Was ist die Kapazität?;384
14.1.3.2;19.3.2 Kapazität in Story-Punkten;386
14.1.3.3;19.3.3 Die Kapazität in Aufwandsstunden;386
14.1.4;19.4 Product-Backlog-Elemente auswählen;387
14.1.5;19.5 Zuversicht erwerben;388
14.1.6;19.6 Das Sprint-Ziel verfeinern;390
14.1.7;19.7 Die Verpflichtung finalisieren;390
14.1.8;19.8 Abschließende Bemerkungen;390
14.2;Kapitel 20: Die Sprint-Ausführung;391
14.2.1;20.1 Überblick;391
14.2.1.1;20.1.1 Das Timing;391
14.2.1.2;20.1.2 Teilnehmer;392
14.2.1.3;20.1.3 Der Prozess;392
14.2.2;20.2 Die Planung der Sprint-Ausführung;393
14.2.3;20.3 Flow-Management;393
14.2.3.1;20.3.1 Parallele Arbeit und Ausschwärmen;394
14.2.3.2;20.3.2 Welche Arbeit begonnen werden soll;396
14.2.3.3;20.3.3 Wie man die Arbeit an den Aufgaben organisiert;397
14.2.3.4;20.3.4 Welche Arbeit muss erledigt werden?;397
14.2.3.5;20.3.5 Wer erledigt die Arbeit?;398
14.2.4;20.4 Daily Scrum;398
14.2.5;20.5 Die Durchführung der Aufgaben – Technische Praktiken;399
14.2.6;20.6 Kommunizieren;400
14.2.6.1;20.6.1 Task Board;400
14.2.6.2;20.6.2 Das Sprint-Burndown-Chart;401
14.2.6.3;20.6.3 Das Sprint-Burnup-Chart;404
14.2.7;20.7 Abschließende Bemerkungen;405
14.3;Kapitel 21: Sprint Review;407
14.3.1;21.1 Überblick;407
14.3.2;21.2 Teilnehmer;408
14.3.3;21.3 Vorarbeiten;409
14.3.3.1;21.3.1 Entscheiden, wen man einlädt;410
14.3.3.2;21.3.2 Die Aktivität zeitlich planen;410
14.3.3.3;21.3.3 Bestätigen, dass die Sprint-Arbeit erledigt ist;411
14.3.3.4;21.3.4 Auf die Demonstration vorbereiten;412
14.3.3.5;21.3.5 Festlegen, wer was macht;412
14.3.4;21.4 Das Vorgehen;412
14.3.4.1;21.4.1 Zusammenfassen;413
14.3.4.2;21.4.2 Demonstrieren;414
14.3.4.3;21.4.3 Diskutieren;415
14.3.4.4;21.4.4 Ändern;415
14.3.5;21.5 Sprint-Review-Probleme;416
14.3.5.1;21.5.1 Abnahmen der PBIs;416
14.3.5.2;21.5.2 Sporadische Teilnahme;416
14.3.5.3;21.5.3 Umfangreiche Entwicklungsprojekte;417
14.3.6;21.6 Abschließende Bemerkungen;417
14.4;Kapitel 22: Die Sprint-Retrospektive;419
14.4.1;22.1 Überblick;419
14.4.2;22.2 Teilnehmer;421
14.4.3;22.3 Die Vorarbeit;422
14.4.3.1;22.3.1 Den Fokus der Retrospektive definieren;422
14.4.3.2;22.3.2 Die Übungen auswählen;423
14.4.3.3;22.3.3 Objektive Daten sammeln;423
14.4.3.4;22.3.4 Die Retrospektive strukturieren;424
14.4.4;22.4 Das Vorgehen;425
14.4.4.1;22.4.1 Die Atmosphäre gestalten;426
14.4.4.2;22.4.2 Gemeinsamer Kontext;427
14.4.4.3;22.4.3 Einsichten identifizieren;429
14.4.4.4;22.4.4 Aktionen festlegen;432
14.4.4.5;22.4.5 Die Retrospektive schließen;435
14.4.5;22.5 Dranbleiben;435
14.4.6;22.6 Probleme der Sprint-Retrospektive;436
14.4.7;22.7 Abschließende Bemerkungen;438
14.5;Kapitel 23: Der Weg nach vorn;439
14.5.1;23.1 Es gibt keinen Endzustand;439
14.5.2;23.2 Finden Sie Ihren eigenen Weg;440
14.5.3;23.3 Best Practices mit anderen teilen;440
14.5.4;23.4 Mit Scrum den Weg nach vorn finden;441
14.5.5;23.5 Immer weiter!;443
15;Anhang A: Referenzen;445
16;Anhang B: Glossar;449
17;Stichwortverzeichnis;471
Einleitung
Dieses Buch beschreibt das Wesen von Scrum – die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen von Scrum?
Scrum beruht auf einer kleinen Menge an Kernwerten, -prinzipien und -praktiken (zusammenfassend als Scrum-Framework bezeichnet). Organisationen, die Scrum einsetzen, müssen das Scrum-Framework in seiner Gänze annehmen. Das muss sicher nicht in der ganzen Organisation auf einmal geschehen, aber zumindest in den ersten Teams, die Scrum benutzen werden. Scrum komplett anzunehmen, bedeutet jedoch nicht, dass die Organisationen dieses Entwicklungsverfahren entsprechend einer vorgefertigten Einheitsformel umsetzen müssen. Es bedeutet vielmehr, dass sie sich immer an das Scrum-Framework halten müssen, während sie ihre eigene passende Mischung aus den Vorgehensweisen für ihre individuelle Scrum-Umsetzung entwickeln. Essential Scrum kombiniert die Werte, Prinzipien und Praktiken von Scrum mit einer Reihe bewährter Ansätze, die mit dem Scrum-Framework konsistent sind, aber nicht von ihm vorgegeben werden. Einige dieser Ansätze werden sich für Ihre Situation eignen, andere wiederum nicht. Jeder Ansatz muss untersucht und an Ihre jeweiligen Umstände angepasst werden. Die Ursprünge dieses Buches
Als Agile/Scrum-Berater und -Trainer werde ich oft nach einem Referenzbuch für Scrum gefragt – einem, das einen umfassenden Überblick über das Scrum-Framework bietet und darüber hinaus die beliebtesten Ansätze für die Anwendung von Scrum präsentiert. Da es mir nicht gelungen ist, ein einziges Buch zu finden, das diese Themen auf einem Niveau behandelt, das für heutige Anwender sinnvoll wäre, habe ich immer gleich eine ganze Sammlung an Büchern empfohlen: einige, die das Scrum-Framework diskutieren, aber nicht mehr aktuell oder in gewisser Weise unvollständig sind, einige hoch angesehene Agile-Bücher, die sich nicht ausschließlich auf Scrum beschränken, und eine Handvoll Bücher, die sich auf einen speziellen Aspekt von Scrum oder einen bestimmten Ansatz konzentrieren, aber nicht das komplette Scrum-Framework in aller Tiefe behandeln. Das sind viele Bücher für jemanden, der nur eine einzige Ressource sucht, die das Wesen von Scrum abdeckt! Die Begründer von Scrum (Jeff Sutherland und Ken Schwaber) bieten eine Scrum-spezifische Publikation namens The Scrum Guide. Dieses kurze Dokument (ca. 15 Seiten) wird von seinen Autoren als das »definitive Regelbuch zu Scrum und die Dokumentation von Scrum selbst« beschrieben (Schwaber und Sutherland 2011). Sie vergleichen ihr Werk mit den Regeln des Schachspiels, die »beschreiben, wie die Figuren gesetzt werden, wie gewechselt wird, was ein Gewinn ist usw.«. Obwohl The Scrum Guide als Überblick oder Regelwerk zu Scrum ganz nützlich ist, ist es von seiner Anlage her nicht als umfassende Quelle für alle wesentlichen Scrum-Kenntnisse gedacht. Stellen Sie sich zur Verdeutlichung einfach vor, Sie würden einem Schachanfänger eine 15-seitige Beschreibung der Regeln des Schachspiels geben und dann von ihm erwarten, dass er anschließend ein anständiger Spieler ist. Das funktioniert nicht. Genauso wenig können Sie erwarten, dass jemand The Scrum Guide liest und sofort gute Ergebnisse abliefert. Dieses Buch, Essential Scrum, ist der Versuch, die eine entscheidende, bisher fehlende Quelle für alles wesentliche Wissen über Scrum bereitzustellen. Es enthält eine tiefgreifende Diskussion der Scrum-Prinzipien, -werte und -praktiken – eine, die in den meisten Fällen mit führenden Köpfen aus der Agile-Szene sowie dem The Scrum Guide konform geht. (Ich weise darauf hin und erkläre, wo von den allgemein bekanntesten Ansichten abgewichen wird.) Dieses Buch beschreibt außerdem Ansätze, die mit dem Scrum-Framework konsistent sind und erfolgreich von mir und den von mir trainierten Teams eingesetzt wurden. Es soll keine anderen Bücher ersetzen, die eine tiefgreifende vertikale Behandlung einer vorhandenen Scrum-Praxis oder -Vorgehensweise liefern. Solche Bücher ergänzen vielmehr dieses Buch und gehen teilweise sogar darüber hinaus. Stellen Sie sich Essential Scrum lieber als einen Ausgangspunkt Ihrer Reise vor, auf der Sie Scrum einsetzen, um Ihre Kunden zu erfreuen. Zielgruppe
Für die vielen Tausend Leute, die meine Kurse »Working on a Scrum Team«, »Certified ScrumMaster« und »Certified Scrum Product Owner« besucht haben, und die vielen Teams, die ich trainiert habe, wird dieses Buch Themen, die wir bereits diskutiert haben, wieder auffrischen und vielleicht auch näher erläutern. Und für die noch viel größere Anzahl an Leuten, mit denen ich noch nicht das Vergnügen hatte zusammenzuarbeiten, wird es entweder eine erste Einführung in Scrum und agile Praktiken sein oder eine Chance, Scrum in einem anderen Licht zu sehen und die eigene Anwendung von Scrum zu verbessern. Ich habe dieses Buch nicht für eine bestimmte Rolle geschrieben – es ist nicht speziell für Product Owner oder ScrumMaster oder Mitglieder des Entwicklungsteams gedacht. Stattdessen soll es allen, die direkt oder indirekt mit Scrum zu tun haben, ein gemeinsames Verständnis von Scrum und den Prinzipien, auf denen es beruht, vermitteln. Ich hoffe, dass Ihre Organisation mit dieser gemeinsamen Grundlage in eine bessere Lage versetzt wird, Scrum erfolgreich einzusetzen. Ich stelle mir vor, dass jedes Mitglied des Scrum-Teams dieses Buch auf seinem Schreibtisch hat, aufgeschlagen in einem Kapitel, das für die gerade ausgeführte Arbeit relevant ist. Ich stelle mir außerdem Manager auf allen Ebenen der Organisation vor, die das Buch lesen, weil sie verstehen wollen, wie sich Scrum effektiv zum Organisieren der Arbeit einsetzen lässt und welche organisatorischen Änderungen erforderlich sind, um Scrum erfolgreich umzusetzen. Organisationen, die einen anderen agilen Ansatz als Scrum benutzen oder benutzen wollen, werden die hier enthaltenen Informationen nichtsdestotrotz für ihre spezielle Version des agilen Denkens hilfreich finden. Der Aufbau dieses Buches
Dieses Buch beginnt mit einer kurzen Einführung in Scrum (Kapitel 2) und schließt mit einer Diskussion des vorwärtsweisenden Weges (Kapitel 23). Die restlichen Kapitel sind in vier Teile gegliedert: Teil I – Kernkonzepte (Kapitel 2–8): Scrum-Framework, agile Prinzipien, Sprints, Anforderungen und User Stories, Product Backlog, Schätzungen und Velocity sowie technische Schulden Teil II – Rollen (Kapitel 9–13): Product Owner, ScrumMaster, Entwicklungsteam, Scrum-Team-Strukturen und -Manager Teil III – Planung (Kapitel 14–18): Scrum-Planungsprinzipien, mehrstufige Planung, Portfolio-Planung, Visionsbildung/Produktplanung und Release-Planung Teil IV – Sprints (Kapitel 19–22): Sprint-Planung, Sprint-Ausführung, Sprint Review und Sprint-Retrospektive Wie Sie dieses Buch benutzen
Wie man es erwarten würde, schrieb ich dieses Buch in der Annahme, dass die meisten Leute es strikt von vorn nach hinten lesen würden. Wenn Sie mit Scrum noch nicht so vertraut sind, dann sollten Sie auch tatsächlich so vorgehen, weil die Kapitel normalerweise aufeinander aufbauen. Sollten Sie sich zunächst einmal einen Komplettüberblick über das Scrum-Framework verschaffen wollen, dann lesen Sie Kapitel 2. Für diejenigen, die bereits mit Scrum vertraut sind, eignet sich dieses Buch als Scrum-Referenz. Falls Sie sich für Sprint-Retrospektiven interessieren, dann gehen Sie direkt zu Kapitel 22. Wollen Sie die Feinheiten des Product Backlogs untersuchen, lesen Sie Kapitel 6. Ich empfehle jedoch allen – auch denen, die Scrum schon kennen – dringend, Kapitel 3 komplett zu lesen. Die Prinzipien, die dort dargestellt werden, bilden die Grundlage für das Scrum-Framework und den Rest des Buches – und dabei handelt es sich nicht einfach um eine Wiederholung der Werte und Prinzipien des Agile Manifesto (Beck et al. 2001), die Sie in vielen anderen Beschreibungen von Scrum finden. Visual AGILExicon
Ich bin stolz, in diesem Buch eine neue visuelle Sprache zur Beschreibung von Scrum präsentieren zu dürfen – Visual AGILExicon. Mithilfe dieser Sprache wurden die mehr als 200 Grafiken in diesem Buch erstellt. Visual AGILExicon besteht aus einem Vokabular aus Icons, die speziell zur Darstellung der wesentlichen Scrum-Rollen, -Artefakte und -Aktivitäten entworfen wurde, und stellt somit eine effektive Methode dar, um Konzepte zu vermitteln und das allgemeine Verständnis von Scrum zu verbessern. Wenn Sie Visual AGILExicon in ihrer ganzen Farbenpracht genießen wollen, finden Sie unter www.innolution.com weiterführende Informationen. Diese Website enthält auch eine Vielzahl an Ressourcen und Diskussionen im Zusammenhang mit diesem...
