Essential Scrum (eBook)

Umfassendes Scrum-Wissen aus der Praxis

Kenneth S. Rubin (Autor)

eBook Download: PDF | EPUB

2014 | 1. Auflage
480 Seiten
MITP Verlags GmbH & Co. KG
978-3-8266-8473-9 (ISBN)

Infos

• 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.

Aus dem Inhalt:
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

Kenneth S. Rubin bietet Scrum- und Agile-Training und Beratung an und hilft Unternehmen, Produkte effektiver und wirtschaftlicher zu entwickeln. Als zertifizierter Scrum-Trainer hat er mehr als 18.000 Menschen zu den Themen Agile und Scrum, Smalltalk-Entwicklung, Organisieren objektorientierter Projekte und Übergangsmanagement unterrichtet. Er hat Hunderte von Unternehmen beraten, von Startups bis Fortune-10-Firmen. Rubin war der erste Managing Director der weltweit agierenden Scrum Alliance, einer nichtkommerziellen Organisation, die sich auf die erfolgreiche Scrum-Übernahme konzentriert. Er war bereits erfolgreich als Scrum-Product-Owner, ScrumMaster und Entwickler unterwegs und hat auch als CEO, COO, VP of Engineering, VP of Product Management und VP of Professional Services gearbeitet.

Inhalt

Cover 1
Titel 5
Impressum 6
Inhaltsverzeichnis 7
Vorwort von Mike Cohn 21
Vorwort von Ron Jeffries 23
Einleitung 25
Danksagungen 29
Über den Autor 33
Kapitel 1: Einführung 35
1.1 Was ist Scrum? 35
1.2 Die Ursprünge von Scrum 37
1.3 Wieso Scrum? 38
1.4 Ergebnisse bei Genomica 39
1.5 Kann Scrum Ihnen helfen? 39
1.5.1 Die Complex-Domäne 42
1.5.2 Die Complicated-Domäne 42
1.5.3 Die Simple-Domäne 43
1.5.4 Die Chaotic-Domäne 43
1.5.5 Disorder (Nicht-Wissen, Regellosigkeit) 43
1.5.6 Unterbrechungsgesteuerte Arbeit 44
1.6 Abschließende Bemerkungen 45
Teil I: Kernkonzepte 47
Kapitel 2: Das Scrum-Framework 49
2.1 Überblick 49
2.2 Scrum-Rollen 50
2.2.1 Product Owner 51
2.2.2 ScrumMaster 51
2.2.3 Das Entwicklungsteam 52
2.3 Scrum-Aktivitäten und Artefakte 52
2.3.1 Product Backlog 54
2.3.2 Sprints 56
2.3.3 Sprint-Planung 57
2.3.4 Sprint-Ausführung 58
2.3.5 Daily Scrum 59
2.3.6 Fertig (Done) 60
2.3.7 Sprint Review 62
2.3.8 Sprint-Retrospektive 63
2.4 Abschließende Bemerkungen 63
Kapitel 3: Agile Prinzipien 65
3.1 Überblick 65
3.2 Veränderlichkeit und Unsicherheit 68
3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen 68
3.2.2 Iterative und inkrementelle Entwicklung nutzen 69
3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion, Anpassung und Transparenz 71
3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit 72
3.3 Vorhersage und Anpassung 73
3.3.1 Optionen offen halten 73
3.3.2 Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann 74
3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen 76
3.3.4 Änderung auf eine ökonomisch sinnvolle Weise annehmen 77
3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit adaptiver, bedarfsgerechter Arbeit abwägen 80
3.4 Validiertes Wissen 81
3.4.1 Schnelles Validieren wichtiger Annahmen 81
3.4.2 Abwägen mehrerer gleichzeitiger Lernschleifen 81
3.4.3 Organisieren des Workflows für schnelle Feedbacks 82
3.5 Work in Process (WIP) 84
3.5.1 Wirtschaftlich sinnvolle Batch-Größen benutzen 84
3.5.2 Lagerbestände erkennen und sinnvoll verwalten 86
3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter 87
3.5.4 Verzögerungskosten betrachten 89
3.6 Fortschritt 90
3.6.1 An Echtzeitinformationen anpassen und umplanen 90
3.6.2 Fortschritt messen, indem man funktionierende Güter validiert 91
3.6.3 Auf eine wertzentrierte Auslieferung konzentrieren 91
3.7 Leistung 92
3.7.1 Gehe schnell, aber hetze nicht 92
3.7.2 Baue Qualität ein 93
3.7.3 Mache alles ohne großes Zeremoniell 93
3.8 Abschließende Bemerkungen 94
Kapitel 4: Sprints 97
4.1 Überblick 97
4.2 Timeboxing 98
4.2.1 Legt ein WIP-Limit fest 98
4.2.2 Erzwingt eine Priorisierung 98
4.2.3 Demonstriert Fortschritt 99
4.2.4 Verhindert unnötigen Perfektionismus 99
4.2.5 Motiviert die Fertigstellung 99
4.2.6 Verbessert die Vorhersagbarkeit 100
4.3 Kurze Zeitdauer 100
4.3.1 Erleichterte Planung 100
4.3.2 Schnelles Feedback 101
4.3.3 Verbesserter Return on Investment 101
4.3.4 Begrenzte Fehler 101
4.3.5 Wiedererweckte Begeisterung 101
4.3.6 Häufige Checkpoints 102
4.4 Konsistente Dauer 103
4.4.1 Vorteile der Kadenz 104
4.4.2 Vereinfacht die Planung 104
4.5 Keine das Ziel beeinflussenden Änderungen 105
4.5.1 Was ist ein Sprint-Ziel? 105
4.5.2 Gegenseitige Verpflichtung 105
4.5.3 Änderungen versus Klärung 106
4.5.4 Konsequenzen einer Änderung 106
4.5.5 Pragmatisch sein 108
4.5.6 Abnormaler Abbruch 109
4.6 Definition von Fertig (Done) 110
4.6.1 Wie lautet die Definition von Fertig? 110
4.6.2 Die Definition von Fertig kann sich im Laufe der Zeit weiterentwickeln 112
4.6.3 Definition von Fertig versus Akzeptanzkriterien 114
4.6.4 Fertig versus Fertig-Fertig 114
4.7 Abschließende Bemerkungen 115
Kapitel 5: Anforderungen und User Stories 117
5.1 Überblick 117
5.2 Gespräche 119
5.3 Progressive Verfeinerung 120
5.4 Was sind User Stories? 121
5.4.1 Card (Karte) 121
5.4.2 Conversation (Gespräch) 122
5.4.3 Confirmation (Bestätigung) 123
5.5 Der Detaillierungsgrad 124
5.6 In gute Stories INVESTieren 127
5.6.1 Independent (unabhängig) 127
5.6.2 Negotiable (verhandelbar) 128
5.6.3 Valuable (werthaltig) 128
5.6.4 Estimatable (schätzbar) 130
5.6.5 Passende Größe (klein) 130
5.6.6 Testable (prüfbar) 131
5.7 Nichtfunktionale Anforderungen 131
5.8 Stories zum Wissenserwerb 132
5.9 Stories sammeln 134
5.9.1 Workshop zum Schreiben von User Stories 134
5.9.2 Story Mapping 135
5.10 Abschließende Bemerkungen 136
Kapitel 6: Das Product Backlog 139
6.1 Überblick 139
6.2 Product-Backlog-Elemente 140
6.3 Merkmale guter Product Backlogs 141
6.3.1 Detailed appropriately (ausreichend detailliert) 141
6.3.2 Emergent 142
6.3.3 Estimated (geschätzt) 142
6.3.4 Prioritized (priorisiert) 143
6.4 Pflege 144
6.4.1 Was bedeutet Pflege? 144
6.4.2 Wer führt die Pflege durch? 145
6.4.3 Wann findet die Pflege statt? 146
6.5 Die Definition von Bereit 148
6.6 Flow Management 150
6.6.1 Release Flow Management 150
6.6.2 Sprint Flow Management 151
6.7 Welche und wie viele Product Backlogs? 152
6.7.1 Was ist ein Produkt? 152
6.7.2 Große Produkte – hierarchische Backlogs 154
6.7.3 Mehrere Teams – ein Product Backlog 155
6.7.4 Ein Team – mehrere Produkte 156
6.8 Abschließende Bemerkungen 157
Kapitel 7: Schätzung und Velocity 159
7.1 Überblick 159
7.2 Was und wann wir schätzen 160
7.2.1 Schätzungen für Portfolio-Backlog-Elemente 161
7.2.2 Product-Backlog-Schätzungen 161
7.2.3 Aufgabenschätzungen 162
7.3 Schätzkonzepte für Product-Backlog-Elemente 163
7.3.1 Als Team schätzen 163
7.3.2 Schätzungen sind keine Verpflichtungen 164
7.3.3 Exaktheit versus Präzision 165
7.3.4 Relative Größenschätzung 165
7.4 Schätzeinheiten für Product-Backlog-Elemente 168
7.4.1 Story-Punkte 168
7.4.2 Idealtage 168
7.5 Planungspoker 169
7.5.1 Schätzskala 170
7.5.2 Wie man spielt 171
7.5.3 Vorteile 173
7.6 Was ist Velocity? 173
7.7 Einen Velocity-Bereich berechnen 174
7.8 Die Velocity vorhersagen 175
7.9 Die Velocity beeinflussen 176
7.10 Missbrauch der Velocity 177
7.11 Abschließende Bemerkungen 178
Kapitel 8: Technische Schulden 179
8.1 Überblick 179
8.2 Die Folgen technischer Schulden 181
8.2.1 Unvorhersehbarer Wendepunkt 182
8.2.2 Zunehmend verzögerte Auslieferung 182
8.2.3 Beträchtliche Anzahl an Defekten 182
8.2.4 Steigende Entwicklungs- und Support-Kosten 182
8.2.5 Das Produkt verkümmert 183
8.2.6 Schwindende Vorhersehbarkeit 183
8.2.7 Leistungseinbruch 183
8.2.8 Allgemeiner Frust 184
8.2.9 Sinkende Kundenzufriedenheit 184
8.3 Ursachen der technischen Schulden 184
8.3.1 Druck hinsichtlich des Erreichens einer Deadline 184
8.3.2 Erfolglose Versuche der Velocity-Beschleunigung 185
8.3.3 Gerücht: Weniger Testen kann die Velocity beschleunigen 186
8.3.4 Schulden bauen auf Schulden auf 187
8.4 Technische Schulden müssen organisiert werden 188
8.5 Die Zunahme technischer Schulden überwachen 189
8.5.1 Bewährte technische Praktiken anwenden 189
8.5.2 Eine starke Definition von Fertig benutzen 190
8.5.3 Die wirtschaftlichen Aspekte technischer Schulden richtig verstehen 190
8.6 Technische Schulden sichtbar machen 193
8.6.1 Technische Schulden auf geschäftlicher Ebene sichtbar machen 193
8.6.2 Technische Schulden auf der technischen Ebene sichtbar machen 194
8.7 Technische Schulden abbauen 196
8.7.1 Nicht alle technischen Schulden sollten abgebaut werden 197
8.7.2 Wenden Sie die Pfadfinderregel an (Bauen Sie die Schulden ab, sobald sie Ihnen begegnen) 199
8.7.3 Bauen Sie technische Schulden schrittweise ab 199
8.7.4 Bauen Sie die technischen Schulden mit den höchsten Zinsen zuerst ab 200
8.7.5 Technische Schulden abbauen, während man für den Kunden werthaltige Arbeit erledigt 201
8.8 Abschließende Bemerkungen 202
Teil II: Rollen 203
Kapitel 9: Der Product Owner 205
9.1 Überblick 205
9.2 Hauptaufgaben 206
9.2.1 Organisation der wirtschaftlichen Belange 207
9.2.2 Mitwirkung an der Planung 209
9.2.3 Pflege des Product Backlogs 209
9.2.4 Definition und Verifikation der Akzeptanzkriterien 209
9.2.5 Zusammenarbeit mit dem Entwicklungsteam 210
9.2.6 Zusammenarbeit mit den Stakeholdern 211
9.3 Eigenschaften/Fähigkeiten 212
9.3.1 Fachwissen 212
9.3.2 Soziale Kompetenz 213
9.3.3 Entscheidungsfindung 213
9.3.4 Verantwortung 213
9.4 Der Alltag eines Product Owners 214
9.5 Wer sollte Product Owner sein? 216
9.5.1 Interne Entwicklung 217
9.5.2 Gewerbliche Entwicklung 218
9.5.3 Ausgelagerte Entwicklung 220
9.5.4 Komponentenentwicklung 221
9.6 Product Owner kombiniert mit anderen Rollen 222
9.7 Das Product-Owner-Team 222
9.7.1 Product-Owner-Stellvertreter 223
9.7.2 Chief Product Owner 224
9.8 Abschließende Bemerkungen 225
Kapitel 10: ScrumMaster 227
10.1 Überblick 227
10.2 Wichtigste Aufgaben 227
10.2.1 Coach 227
10.2.2 »Dienende Führungskraft« 228
10.2.3 Prozessautorität 229
10.2.4 Schutz vor störenden Einflüssen 229
10.2.5 Beseitigung von Hindernissen 229
10.2.6 Berater in der Organisationsentwicklung 229
10.3 Eigenschaften/Fähigkeiten 230
10.3.1 Sachkundig 230
10.3.2 Neugierig 230
10.3.3 Geduldig 231
10.3.4 Teamfähig 231
10.3.5 Schützend 231
10.3.6 Transparent 232
10.4 Alltag 232
10.5 Die Rolle ausfüllen 233
10.5.1 Wer sollte ScrumMaster sein? 233
10.5.2 Ist die Rolle des ScrumMasters eine Vollzeitbeschäftigung? 234
10.5.3 ScrumMaster in Kombination mit anderen Rollen 234
10.6 Abschließende Bemerkungen 235
Kapitel 11: Das Entwicklungsteam 237
11.1 Überblick 237
11.2 Rollenspezifische Teams 237
11.3 Wichtigste Aufgaben 238
11.3.1 Durchführung des Sprints 238
11.3.2 Tägliches Untersuchen und Anpassen (»Inspect and Adapt«) 239
11.3.3 Pflege des Product Backlogs 239
11.3.4 Den Sprint planen 239
11.3.5 Produkt und Prozess untersuchen und anpassen 239
11.4 Eigenschaften/Fertigkeiten 240
11.4.1 Selbstorganisierend 240
11.4.2 Funktionsübergreifend vielseitig 242
11.4.3 T-förmige Fertigkeiten 243
11.4.4 Die Musketier-Einstellung 245
11.4.5 Kommunikation mit hoher Bandbreite 247
11.4.6 Transparente Kommunikation 248
11.4.7 Die richtige Größe 248
11.4.8 Fokussiert und verpflichtet 249
11.4.9 In einer nachhaltigen Geschwindigkeit arbeiten 251
11.4.10 Langlebig 252
11.5 Abschließende Bemerkungen 254
Kapitel 12: Die Strukturen des Scrum-Teams 255
12.1 Überblick 255
12.2 Funktionsteams versus Komponententeams 255
12.3 Koordination mehrerer Teams 260
12.3.1 Scrum of Scrums 260
12.3.2 Der Release-Train 262
12.4 Abschließende Bemerkungen 265
Kapitel 13: Manager 267
13.1 Überblick 267
13.2 Teams koordinieren 268
13.2.1 Grenzen definieren 269
13.2.2 Ein klares Ziel vorgeben 269
13.2.3 Teams bilden 270
13.2.4 Die Teamzusammensetzung ändern 271
13.2.5 Teams bevollmächtigen 271
13.3 Teams fördern 273
13.3.1 Die Mitarbeiter anspornen 273
13.3.2 Kompetenz entwickeln 273
13.3.3 Fachliche Anleitung bieten 274
13.3.4 Die Integrität des Teams bewahren 275
13.4 Die Umgebung ausrichten und anpassen 275
13.4.1 Agile Werte fördern 275
13.4.2 Organisatorische Hindernisse entfernen 276
13.4.3 Die internen Abteilungen ausrichten 276
13.4.4 Die Partner ausrichten 277
13.5 Den Wertschöpfungsfluss organisieren 277
13.5.1 Die Sichtweise des Systems annehmen 277
13.5.2 Die wirtschaftlichen Aspekte organisieren 278
13.5.3 Messungen und Berichte überwachen 278
13.6 Projektmanager 279
13.6.1 Projektmanagementaufgaben in einem Scrum-Team 279
13.6.2 Eine getrennte Projektmanager-Rolle bewahren 281
13.7 Abschließende Bemerkungen 285
Teil III: Planen 287
Kapitel 14: Scrum-Planungsprinzipien 289
14.1 Überblick 289
14.2 Gehen Sie nicht davon aus, dass im Voraus erstellte Pläne korrekt sind 290
14.3 Die Vorabplanung sollte hilfreich, aber nicht exzessiv sein 290
14.4 Halten Sie sich die Planungsoptionen bis zum letzten verantwortbaren Augenblick offen 291
14.5 Konzentrieren Sie sich stärker auf das Anpassen und Neuplanen als darauf, einem Plan zu genügen 291
14.6 Den Planungsbestand richtig organisieren 294
14.7 Bevorzugen Sie kleinere und häufigere Releases 295
14.8 Lernen Sie schnell dazu und weichen Sie vom Plan ab, wenn es nötig sein sollte 297
14.9 Abschließende Bemerkungen 297
Kapitel 15: Planung auf mehreren Ebenen 299
15.1 Überblick 299
15.2 Portfolio-Planung 301
15.3 Produktplanung (Visionsbildung) 301
15.3.1 Die Vision 301
15.3.2 Allgemeines Product Backlog 302
15.3.3 Produkt-Roadmap 302
15.4 Release-Planung 304
15.5 Sprint-Planung 306
15.6 Tägliche Planung 306
15.7 Abschließende Bemerkungen 307
Kapitel 16: Portfolio-Planung 309
16.1 Überblick 309
16.1.1 Das Timing 309
16.1.2 Teilnehmer 310
16.1.3 Der Prozess 310
16.2 Zeitplanungsstrategien 312
16.2.1 Optimierung der Rendite über die Lebensdauer 313
16.2.2 Kalkulation der Verzögerungskosten 314
16.2.3 Schätzungen mit Genauigkeit statt Präzision 317
16.3 Zuflussstrategien 318
16.3.1 Den wirtschaftlichen Filter anwenden 318
16.3.2 Zufluss- und Abflussrate ausbalancieren 319
16.3.3 Sich bietende Gelegenheiten schnell ergreifen 321
16.3.4 Planen Sie kleinere, häufigere Releases 322
16.4 Abflussstrategien 324
16.4.1 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Mitarbeiter 324
16.4.2 Einrichten eines WIP-Limits 324
16.4.3 Auf ein komplettes Team warten 325
16.5 Strategien zur Überprüfung der in Bearbeitung befindlichen Produkte 326
16.5.1 Die Grenznutzenrechnung verwenden 327
16.6 Abschließende Bemerkungen 328
Kapitel 17: Visionsfindung (Produktplanung) 331
17.1 Überblick 331
17.1.1 Das Timing 332
17.1.2 Teilnehmer 332
17.1.3 Der Prozess 334
17.2 SR4U-Beispiel 334
17.3 Die Entwicklung der Vision 336
17.4 Erstellen eines allgemeinen Product Backlogs 338
17.5 Die Definition der Produkt-Roadmap 339
17.6 Andere Aktivitäten 342
17.7 Wirtschaftlich vernünftige Visionsfindung 344
17.7.1 Eine realistische Vertrauensschwelle anstreben 345
17.7.2 Konzentrieren Sie sich auf einen kurzfristigen Planungshorizont 346
17.7.3 Handeln Sie schnell 347
17.7.4 Erwerben Sie validiertes Wissen 347
17.7.5 Nutzen Sie eine inkrementelle Finanzierung 348
17.7.6 Lernen Sie schnell dazu und weichen Sie ggf. vom Plan ab (aka Schnelles Scheitern) 350
17.8 Abschließende Bemerkungen 350
Kapitel 18: Release-Planung (längerfristige Planung) 351
18.1 Überblick 351
18.1.1 Das Timing 352
18.1.2 Teilnehmer 352
18.1.3 Der Prozess 353
18.2 Release-Einschränkungen 355
18.2.1 Alles fest 355
18.2.2 Umfang und Termin fest 356
18.2.3 Fester Umfang 357
18.2.4 Fester Termin 358
18.2.5 Variable Qualität 358
18.2.6 Einschränkungen aktualisieren 358
18.3 Das Product Backlog pflegen 359
18.4 Die minimal freigebbaren Funktionen (Minimum Releasable Features, MRFs) verfeinern 360
18.5 Sprint Mapping (Einordnung der Product-Backlog-Elemente) 361
18.6 Release-Planung mit festem Termin 363
18.7 Release-Planung mit festem Umfang 368
18.8 Die Kosten berechnen 370
18.9 Kommunizieren 371
18.9.1 Den Fortschritt in einem Release mit festem Umfang kommunizieren 371
18.9.2 Den Fortschritt in einem Release mit festem Termin kommunizieren 374
18.10 Abschließende Bemerkungen 375
Teil IV: Sprints 377
Kapitel 19: Die Sprint-Planung 379
19.1 Überblick 379
19.1.1 Das Timing 379
19.1.2 Teilnehmer 379
19.1.3 Der Prozess 380
19.2 Ansätze für die Sprint-Planung 382
19.2.1 Zweiteilige Sprint-Planung 382
19.2.2 Einteilige Sprint-Planung 383
19.3 Die Kapazität ermitteln 384
19.3.1 Was ist die Kapazität? 384
19.3.2 Kapazität in Story-Punkten 386
19.3.3 Die Kapazität in Aufwandsstunden 386
19.4 Product-Backlog-Elemente auswählen 387
19.5 Zuversicht erwerben 388
19.6 Das Sprint-Ziel verfeinern 390
19.7 Die Verpflichtung finalisieren 390
19.8 Abschließende Bemerkungen 390
Kapitel 20: Die Sprint-Ausführung 391
20.1 Überblick 391
20.1.1 Das Timing 391
20.1.2 Teilnehmer 392
20.1.3 Der Prozess 392
20.2 Die Planung der Sprint-Ausführung 393
20.3 Flow-Management 393
20.3.1 Parallele Arbeit und Ausschwärmen 394
20.3.2 Welche Arbeit begonnen werden soll 396
20.3.3 Wie man die Arbeit an den Aufgaben organisiert 397
20.3.4 Welche Arbeit muss erledigt werden? 397
20.3.5 Wer erledigt die Arbeit? 398
20.4 Daily Scrum 398
20.5 Die Durchführung der Aufgaben – Technische Praktiken 399
20.6 Kommunizieren 400
20.6.1 Task Board 400
20.6.2 Das Sprint-Burndown-Chart 401
20.6.3 Das Sprint-Burnup-Chart 404
20.7 Abschließende Bemerkungen 405
Kapitel 21: Sprint Review 407
21.1 Überblick 407
21.2 Teilnehmer 408
21.3 Vorarbeiten 409
21.3.1 Entscheiden, wen man einlädt 410
21.3.2 Die Aktivität zeitlich planen 410
21.3.3 Bestätigen, dass die Sprint-Arbeit erledigt ist 411
21.3.4 Auf die Demonstration vorbereiten 412
21.3.5 Festlegen, wer was macht 412
21.4 Das Vorgehen 412
21.4.1 Zusammenfassen 413
21.4.2 Demonstrieren 414
21.4.3 Diskutieren 415
21.4.4 Ändern 415
21.5 Sprint-Review-Probleme 416
21.5.1 Abnahmen der PBIs 416
21.5.2 Sporadische Teilnahme 416
21.5.3 Umfangreiche Entwicklungsprojekte 417
21.6 Abschließende Bemerkungen 417
Kapitel 22: Die Sprint-Retrospektive 419
22.1 Überblick 419
22.2 Teilnehmer 421
22.3 Die Vorarbeit 422
22.3.1 Den Fokus der Retrospektive definieren 422
22.3.2 Die Übungen auswählen 423
22.3.3 Objektive Daten sammeln 423
22.3.4 Die Retrospektive strukturieren 424
22.4 Das Vorgehen 425
22.4.1 Die Atmosphäre gestalten 426
22.4.2 Gemeinsamer Kontext 427
22.4.3 Einsichten identifizieren 429
22.4.4 Aktionen festlegen 432
22.4.5 Die Retrospektive schließen 435
22.5 Dranbleiben 435
22.6 Probleme der Sprint-Retrospektive 436
22.7 Abschließende Bemerkungen 438
Kapitel 23: Der Weg nach vorn 439
23.1 Es gibt keinen Endzustand 439
23.2 Finden Sie Ihren eigenen Weg 440
23.3 Best Practices mit anderen teilen 440
23.4 Mit Scrum den Weg nach vorn finden 441
23.5 Immer weiter! 443
Anhang A: Referenzen 445
Anhang B: Glossar 449
Stichwortverzeichnis 471

Textauszug

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...

Produkt-Details

• Erscheint lt. Verlag: 15.5.2014
• Reihe/Serie: mitp Professional
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge
• Schlagworte: Agil • Agile-Software-Entwicklung • Release-Planung • Retrospektive • Review • Scrum • Scrum-Framework • ScrumMaster • ScrumMater • Scrum-Zertifizierung • Sicherheit • Sprint • Übergangsmanagement • Velocity • Visionsfindung • Zertifizierung
• ISBN-10: 3-8266-8473-7 / 3826684737
• ISBN-13: 978-3-8266-8473-9 / 9783826684739