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.

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