»Dieses Buch liefert die besten und weitreichendsten Erläuterungen zum Thema Scrum-
Framework, die man sich nur wünschen kann! Essential Scrum richtet sich an alle, die an den
wesentlichen Aspekten des Entwicklungsprozesses interessiert sind – unabhängig davon, ob
bereits Scrum-Vorkenntnisse vorhanden sind oder nicht. Unter Zuhilfenahme gemeinver-
ständlicher visueller Elemente veranschaulicht Kenny die Kernprinzipien des Scrum-Frame-
works in bestechend nachvollziehbarer Weise. Bei meiner Arbeit als Scrum-Coach greife ich
fortlaufend auf Referenzmaterial zurück, das neue Wege einschlägt, um den Teams beim
Erlernen und der Nutzung des Frameworks zu helfen. Dennoch musste ich in den vergange-
nen mehr als zehn Jahren immer wieder erleben, dass Scrum sowohl vonseiten der großen
Unternehmen als auch der Toolanbieter regelmäßig falsch interpretiert und schlecht umge-
setzt wird. Dieses Buch richtet den Fokus jedoch wieder auf den Kern der Sache und konzen-
triert sich auf das, was in diesem Zusammenhang wirklich wichtig ist.«
– Joe Balistrieri, Process Development Manager, Rockwell Automation
»Kennys weitreichender Erfahrungsschatz aus seiner Tätigkeit als Berater, Trainer und ehema-
liger Managing Director der Scrum Alliance kommt in diesem Werk voll und ganz zur Gel-
tung. Neben der ausführlichen Auseinandersetzung mit den elementaren Aspekten des
Scrum-Prinzips beschäftigt sich dieses Buch auch mit der Frage aller Fragen: Was geschieht
mit den Projektmanagern? Essential Scrum zeichnet ein verständliches Bild des großen Gan-
zen und demonstriert sehr anschaulich, wie sich die Unternehmensleitung einbringen und
ihre Scrum-Teams bei der erfolgreichen Umstellung auf agile Methoden unterstützen kann.«
– Sameer S. Bendre, Certified ScrumMaster (CSM) & Project Management Professional (PMP),
Senior Consultant, 3i Infotech Inc.
»Wenn agile Vorgehensmodelle oder das Scrum-Verfahren Neuland für Sie sind, wird Ihnen
dieses Buch zu einem »fliegenden Start« verhelfen. Die Beispiele und Beschreibungen sind
klar verständlich und lebendig formuliert, und Sie werden feststellen, dass ein Thema oder
eine Frage, die sich Ihnen aufdrängt, oftmals schon unmittelbar im nächsten Moment ange-
sprochen wird.«
– Johannes Brodwall, Principal Solution Architect, Steria Norway
»Kennys sorgfältig strukturierte Ausführungen spiegeln die Sensibilität der Programmierspra-
che Smalltalk wider – der Entwicklungsumgebung, in der er jahrelang gearbeitet hat und aus
der sowohl Scrum als auch das Extreme Programming hervorgingen. Essential Scrum greift die
maßgeblichen Agile-Management-Prinzipien auf und geleitet seine Leserschaft zielsicher auf
den Weg zu einem effizienteren agilen Entwicklungsansatz.«
– Rowan Bunning, Gründer, Scrum WithStyle
»Es gibt heutzutage eine ganze Reihe von Referenzmaterial zum Thema Scrum – Essential
Scrum betrachtet die Dinge allerdings aus einer ganz neuen Perspektive: in Form eines »Rea-
lity-Checks« für praktizierende Softwareentwickler. Kenny zeigt anhand von unmissverständ-
lich illustrierten Beispielen aus der realen Arbeitswelt auf, wie sich ein solides Fundament für
die erfolgreiche agile Entwicklung legen lässt. Er vermittelt dem Leser unter anderem ein kla-
res Verständnis vom Wert der Qualitätsimplementierung und liefert schlüssige Antworten auf
die Frage, warum wir als Entwickler nicht schon im Voraus alles richtig machen können – son-
dern vielmehr inkrementell arbeiten und im Laufe des Prozesses hinzulernen müssen. Trotz
der ausdrücklichen Nennung des Begriffs »Scrum« im Titel werden in diesem Buch darüber
hinaus aber auch andere effiziente Praktiken aus dem agilen Universum thematisiert, um
Managern und ihren Teams zum Erfolg zu verhelfen.«
– Lisa Crispin, Co-Autorin von Agile Testing
»Kenny Rubin hat es fertiggebracht, ein Buch zu schreiben, das meiner Meinung nach wirk-
lich jeder, der mit dem Vorgehensmodell Scrum zu tun hat, lesen sollte! Seine Ausführungen
repräsentieren eine lückenlose Darstellung dessen, was man über Scrum wissen muss, und
noch vieles mehr!«
– Martine Devos, europäische Scrum-Pionierin und Certified ScrumMaster
»Nachdem ich in den vergangenen Jahren eine ganze Reihe von Büchern über agile Methoden
rezensiert habe, drängt sich mir natürlich die Frage auf: »Brauchen wir denn wirklich noch
eins?« Nun, im Fall von Essential Scrum kann ich dies nur mit einem überzeugten »Ja« beant-
worten. Anders als die gewohnten Nachschlagewerke dieser Art bringt Kenny dem Leser
außergewöhnliche, von Erfahrung geprägte Perspektiven näher, die wertvolle neue Einblicke
gewähren. Zweifellos einzigartig an diesem Buch ist die innovative »Ikonografie« – die Bild-
sprache, die Kenny selbst speziell für Scrum und andere agile Methoden entwickelt hat. Für
mich steht fest: Dieses Buch bietet eine unverzichtbare Hilfestellung für den Ausbau eigener
Ideen im Hinblick auf den erfolgreichen Einsatz des Scrum-Modells.«
– Scott Duncan, Agile/Scrum-Coach und -Trainer
»Wer ein Scrum-Training absolviert hat oder schon einmal in einem Scrum-Team tätig war,
wird in Essential Scrum eine großartige Aufbaulektüre finden. Dieses Buch demonstriert in
eindrucksvoller Weise, wie Sie durch die Adaption von Scrum-Prozessen agiler werden und
wie sich komplexe Projekte in handhabbare Segmente (bzw. »Sprints«) gliedern lassen. Kenny
Rubin beschreibt eine Vielzahl von praxisorientierten Fallstudien, die offenbaren, was in diver-
sen Organisationen funktioniert hat und was nicht. Das geordnete Layout und die professio-
nellen Grafiken in diesem Buch gewährleisten eine gute Übersichtlichkeit und erleichtern das
schnelle Auffinden bestimmter Themenbereiche. Organisationen, die sich vom traditionellen
Wasserfall-Modell weg und hin zu einem agileren Entwicklungsverfahren orientieren möch-
ten, finden in Essential Scrum einen verlässlichen Wegweiser und Ratgeber.«
– Julia Frazier, Produktmanagerin
Kenneth S. Rubin
Essential Scrum
Umfassendes Scrum-Wissen
aus der Praxis
ISBN 978-3-8266-8473-9
1. Auflage 2014
www.mitp.de
E-Mail: kundenservice@hjr-verlag.de
Telefon: +49 6221 / 489 -555
Telefax: +49 6221 / 489 -410
© 2014 mitp, eine Marke der Verlagsgruppe Hüthig Jehle Rehm GmbH Heidelberg,
München, Landsberg, Frechen, Hamburg
Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwer-
tung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des
Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Überset-
zungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen
Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in die-
sem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass sol-
che Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu
betrachten wären und daher von jedermann benutzt werden dürften.
Authorized translation from the English language edition, entitled ESSENTIAL SCRUM:
A PRACTICAL GUIDE TO THE MOST POPULAR AGILE PROCESS, 1st Edition,
0137043295 by RUBIN, KENNETH S., published by Pearson Education, Inc, publishing as
Addison-Wesley Professional, Copyright © 2013 by Pearson Education, Inc.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by
any means, electronic or mechanical, including photocopying, recording or by any informa-
tion storage retrieval system, without permission from Pearson Education, Inc. GERMAN
language edition published by mitp, an imprint of Verlagsgruppe Hüthig Jehle Rehm
GmbH, Copyright © 2014.
Zitate – Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.1 Was ist Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.2 Die Ursprünge von Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.3 Wieso Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.4 Ergebnisse bei Genomica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.5 Kann Scrum Ihnen helfen?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.5.1 Die Complex-Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.5.2 Die Complicated-Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.5.3 Die Simple-Domäne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.5.4 Die Chaotic-Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.5.5 Disorder (Nicht-Wissen, Regellosigkeit). . . . . . . . . . . . . . . . . 41
1.5.6 Unterbrechungsgesteuerte Arbeit . . . . . . . . . . . . . . . . . . . . . . 42
1.6 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Teil I Kernkonzepte 45
2 Das Scrum-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2 Scrum-Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.2.1 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.2 ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5
Inhaltsverzeichnis
3 Agile Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2 Veränderlichkeit und Unsicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen . . . . . . . 66
3.2.2 Iterative und inkrementelle Entwicklung nutzen. . . . . . . . . . 67
3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion,
Anpassung und Transparenz. . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit . . 70
3.3 Vorhersage und Anpassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3.1 Optionen offen halten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3.2 Akzeptieren, dass man es nicht gleich von Anfang
an richtig machen kann . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen . . . . . 74
3.3.4 Änderung auf eine ökonomisch sinnvolle Weise
annehmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit
adaptiver, bedarfsgerechter Arbeit abwägen . . . . . . . . . . . . . . 78
3.4 Validiertes Wissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.4.1 Schnelles Validieren wichtiger Annahmen . . . . . . . . . . . . . . 79
3.4.2 Abwägen mehrerer gleichzeitiger Lernschleifen . . . . . . . . . . 79
3.4.3 Organisieren des Workflows für schnelle Feedbacks . . . . . . 80
3.5 Work in Process (WIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.5.1 Wirtschaftlich sinnvolle Batch-Größen benutzen . . . . . . . . . 82
3.5.2 Lagerbestände erkennen und sinnvoll verwalten . . . . . . . . . . 84
3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf
untätige Arbeiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.5.4 Verzögerungskosten betrachten . . . . . . . . . . . . . . . . . . . . . . . 87
6
Inhaltsverzeichnis
3.6 Fortschritt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.6.1 An Echtzeitinformationen anpassen und umplanen. . . . . . . 88
3.6.2 Fortschritt messen, indem man funktionierende
Güter validiert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.6.3 Auf eine wertzentrierte Auslieferung konzentrieren. . . . . . . 89
3.7 Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.7.1 Gehe schnell, aber hetze nicht . . . . . . . . . . . . . . . . . . . . . . . . 90
3.7.2 Baue Qualität ein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.7.3 Mache alles ohne großes Zeremoniell . . . . . . . . . . . . . . . . . . 91
3.8 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.2 Timeboxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.1 Legt ein WIP-Limit fest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.2 Erzwingt eine Priorisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.3 Demonstriert Fortschritt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.2.4 Verhindert unnötigen Perfektionismus . . . . . . . . . . . . . . . . . 97
4.2.5 Motiviert die Fertigstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.2.6 Verbessert die Vorhersagbarkeit . . . . . . . . . . . . . . . . . . . . . . . 98
4.3 Kurze Zeitdauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3.1 Erleichterte Planung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3.2 Schnelles Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.3.3 Verbesserter Return on Investment . . . . . . . . . . . . . . . . . . . . 99
4.3.4 Begrenzte Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.3.5 Wiedererweckte Begeisterung . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.3.6 Häufige Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4 Konsistente Dauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.4.1 Vorteile der Kadenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4.2 Vereinfacht die Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.5 Keine das Ziel beeinflussenden Änderungen . . . . . . . . . . . . . . . . . . . 103
4.5.1 Was ist ein Sprint-Ziel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.5.2 Gegenseitige Verpflichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.5.3 Änderungen versus Klärung . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.5.4 Konsequenzen einer Änderung. . . . . . . . . . . . . . . . . . . . . . . . 104
4.5.5 Pragmatisch sein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.5.6 Abnormaler Abbruch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.6 Definition von Fertig (Done) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.6.1 Wie lautet die Definition von Fertig? . . . . . . . . . . . . . . . . . . . 108
7
Inhaltsverzeichnis
4.6.2 Die Definition von Fertig kann sich im Laufe der Zeit
weiterentwickeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.6.3 Definition von Fertig versus Akzeptanzkriterien . . . . . . . . . . 112
4.6.4 Fertig versus Fertig-Fertig . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8
Inhaltsverzeichnis
9
Inhaltsverzeichnis
10
Inhaltsverzeichnis
10 ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
10.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
10.2 Wichtigste Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
10.2.1 Coach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
10.2.2 »Dienende Führungskraft« . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
11
Inhaltsverzeichnis
12
Inhaltsverzeichnis
13 Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
13.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
13.2 Teams koordinieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
13.2.1 Grenzen definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
13.2.2 Ein klares Ziel vorgeben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
13.2.3 Teams bilden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
13.2.4 Die Teamzusammensetzung ändern . . . . . . . . . . . . . . . . . . . 269
13.2.5 Teams bevollmächtigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
13.3 Teams fördern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
13.3.1 Die Mitarbeiter anspornen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
13.3.2 Kompetenz entwickeln. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
13.3.3 Fachliche Anleitung bieten . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
13.3.4 Die Integrität des Teams bewahren . . . . . . . . . . . . . . . . . . . . 273
13.4 Die Umgebung ausrichten und anpassen . . . . . . . . . . . . . . . . . . . . . . 273
13.4.1 Agile Werte fördern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
13.4.2 Organisatorische Hindernisse entfernen . . . . . . . . . . . . . . . . 274
13.4.3 Die internen Abteilungen ausrichten . . . . . . . . . . . . . . . . . . . 274
13.4.4 Die Partner ausrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
13.5 Den Wertschöpfungsfluss organisieren . . . . . . . . . . . . . . . . . . . . . . . 275
13.5.1 Die Sichtweise des Systems annehmen . . . . . . . . . . . . . . . . . 275
13.5.2 Die wirtschaftlichen Aspekte organisieren. . . . . . . . . . . . . . . 276
13.5.3 Messungen und Berichte überwachen . . . . . . . . . . . . . . . . . . 276
13.6 Projektmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
13.6.1 Projektmanagementaufgaben in einem Scrum-Team . . . . . 277
13.6.2 Eine getrennte Projektmanager-Rolle bewahren . . . . . . . . . . 279
13.7 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
13
Inhaltsverzeichnis
14 Scrum-Planungsprinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
14.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
14.2 Gehen Sie nicht davon aus, dass im Voraus erstellte Pläne
korrekt sind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
14.3 Die Vorabplanung sollte hilfreich, aber nicht exzessiv sein . . . . . . . 288
14.4 Halten Sie sich die Planungsoptionen bis zum letzten
verantwortbaren Augenblick offen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
14.5 Konzentrieren Sie sich stärker auf das Anpassen und
Neuplanen als darauf, einem Plan zu genügen. . . . . . . . . . . . . . . . . . 289
14.6 Den Planungsbestand richtig organisieren . . . . . . . . . . . . . . . . . . . . . 292
14.7 Bevorzugen Sie kleinere und häufigere Releases . . . . . . . . . . . . . . . . 293
14.8 Lernen Sie schnell dazu und weichen Sie vom Plan ab,
wenn es nötig sein sollte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
14.9 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
16 Portfolio-Planung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
16.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
16.1.1 Das Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
16.1.2 Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
16.1.3 Der Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
16.2 Zeitplanungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
16.2.1 Optimierung der Rendite über die Lebensdauer . . . . . . . . . . 311
16.2.2 Kalkulation der Verzögerungskosten . . . . . . . . . . . . . . . . . . . 312
16.2.3 Schätzungen mit Genauigkeit statt Präzision . . . . . . . . . . . . 315
16.3 Zuflussstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
16.3.1 Den wirtschaftlichen Filter anwenden . . . . . . . . . . . . . . . . . . 316
14
Inhaltsverzeichnis
15
Inhaltsverzeichnis
16
Inhaltsverzeichnis
17
Inhaltsverzeichnis
A Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
B Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
18
Vorwort von Mike Cohn
Ich habe heute Mittag bei Burger King gegessen. Auf einem Schild an der Wand war zu
lesen, das Restaurant sei »Home of the Whopper« und es gäbe mehr als eine Million Mög-
lichkeiten, einen Whopper zu bestellen. Wenn verschiedene Kombinationen aus zusätzli-
chen oder keinen Gurken, Tomaten, Salatblättern, Käsescheiben usw. zu mehr als einer
Million Möglichkeiten führen können, einen Hamburger herzustellen, dann muss es Milli-
arden mögliche Wege geben, Scrum umzusetzen. Und auch wenn es den einen richtigen
Weg nicht gibt, so gibt es doch bessere und schlechtere Methoden, um Scrum zu imple-
mentieren.
Mit Essential Scrum hilft Kenny Rubin den Lesern, bessere Wege zu finden. Er will mit sei-
nem Buch nichts vorschreiben – er sagt nicht »Sie müssen dies oder jenes tun«. Stattdes-
sen lehrt er die wichtigsten Prinzipien, die dem Erfolg mit Scrum zugrunde liegen, und
zeigt uns Wahlmöglichkeiten auf, die wir haben, um diesen Prinzipien zu genügen. So gibt
es z.B. keine Methode zur Planung von Sprints, die für alle Teams gilt. Was in einem
Unternehmen oder Projekt funktioniert, könnte in einem anderen zum Scheitern führen.
Und so lässt Kenny uns die Wahl. Er beschreibt eine Gesamtstruktur, die den Ausgangs-
punkt dafür bildet, warum Scrum-Teams ihre Sprints planen und welche Ergebnisse die
Sprint-Planung nach sich ziehen sollte, und zeigt alternative Ansätze, die ebenfalls funktio-
nieren. Am Ende aber liegt die Entscheidung bei den einzelnen Teams – und glücklicher-
weise steht diesen Teams nun dieses Buch zur Seite.
Ein unerwarteter Bonus von Essential Scrum ist die visuelle Sprache, die Kenny für die Kom-
munikation über Scrum einführt. Mir haben diese Bilder sehr dabei geholfen, dem Text zu
folgen, und ich vermute, dass sie in künftigen Diskussionen über Scrum zum Allgemein-
gut werden.
Die Welt hat schon lange auf dieses Buch gewartet. Scrum begann als kleines Konzept. Das
erste Buch, in dem es Erwähnung fand – Wicked Problems, Righteous Solutions von DeGrace
und Stahl aus dem Jahr 1990 –, erledigte das auf sechs Seiten. Doch in den mehr als 20
Jahren seit Erscheinen dieses Buches hat sich Scrum ausgeweitet. Es wurden neue Rollen,
Meetings und Artefakte eingeführt und verfeinert. Mit jeder neuen Ergänzung bestand
allerdings auch die Gefahr, dass wir das »Herz« von Scrum verlieren – also den Teil, bei
dem es darum geht, dass das Team plant, wie es etwas machen möchte, einen kleinen Teil
davon erledigt und dann reflektiert, was die Teammitglieder bewerkstelligt und wie gut sie
zusammengearbeitet haben.
Mit Essential Scrum holt Kenny uns zurück in das Herz von Scrum. Und von dort aus kön-
nen die Teams beginnen, die Entscheidungen zu treffen, die notwendig sind, wenn sie
Scrum anwenden und sich zu eigen machen wollen. Dieses Buch erweist sich als unent-
19
Vorwort von Mike Cohn
behrlicher Führer, der den Teams hilft, aus den Milliarden möglichen Wegen zur Umset-
zung von Scrum denjenigen auszuwählen, der zum Erfolg führt.
– Mike Cohn
Autor von Succeeding with Agile, Agile Estimating and Planning und User Stories Applied
www.mountaingoatsoftware.com
20
Vorwort von Ron Jeffries
Als Kenny mich bat, ein Vorwort für Essential Scrum zu schreiben, dachte ich: »Das geht
schnell und leicht, schließlich wird es nur ein kurzes Buch sein, eine direkte und einfache
Beschreibung von Scrum.« Ich kannte Kennys Arbeit und wusste daher, dass es sich gut
lesen lassen und nicht zu lang sein würde. Es gibt nichts Besseres!
Stellen Sie sich meine Überraschung und mein Entzücken vor, als ich feststellte, dass das
Buch praktisch alles behandelt, was man über Scrum wissen muss – sowohl als Anfänger
als auch als alter Hase. Doch damit nicht genug: Kenny beginnt mit den zentralen Konzep-
ten, darunter die agilen Prinzipien, die allen agilen Methoden zugrunde liegen, und einem
schnellen Überblick über das Scrum-Framework. Und dann dringt er tiefer und tiefer und
tiefer vor. Das Buch liest sich trotzdem immer noch gut und ist außerdem unglaublich
umfangreich.
Kenny behandelt zunächst ausführlich die Planung, betrachtet Anforderungen, Stories, das
Backlog, Schätzungen sowie die Velocity. Dann führt er uns tiefer in die Scrum-Prinzipien
ein und hilft uns beim Umgang mit allen Ebenen des Planens und all den Zeithorizonten.
Er beschreibt, wie Sprints geplant, ausgeführt, nachgeprüft und verbessert werden. Und
dabei liefert er mehr als nur die Grundlagen und weist zudem auf wichtige Probleme hin,
die Ihnen auf Ihrem Weg begegnen können.
Mein eigener Fokus in Scrum und den agilen Arbeitsweisen liegt auf den notwendigen Ent-
wicklerfähigkeiten, die sicherstellen sollen, dass Teams in jedem Sprint echte, funktionie-
rende, unternehmensfokussierte Software abliefern. Kenny hilft uns dabei zu verstehen,
wie man Konzepte wie die Velocity und technische Schulden sicher und gut einsetzen
kann. Beides sind wichtige Themen, mit denen Sie sich unbedingt vertraut machen sollten.
Die Velocity verrät uns, wie viel das Team im Laufe der Zeit abliefert. Wir können sie nut-
zen, um ein Gefühl dafür zu entwickeln, wie viel wir schaffen und ob wir uns verbessern.
Kenny warnt uns jedoch, dass wir unsere Geschäftsergebnisse schädigen, wenn wir die
Velocity als Maß für die Leistung verwenden – und er verrät uns auch, woran das liegt.
Technische Schulden sind zu einem sehr weit gefassten Begriff geworden, der sich auf fast
alles bezieht, was im Code schiefgehen kann. Deshalb klärt Kenny für uns die verschiede-
nen Bedeutungen auf und hilft uns dabei zu verstehen, warum wir uns um diese scheinbar
technischen Details kümmern sollten. Mir gefällt vor allem seine Erklärung, dass Druck,
der auf das Team ausgeübt wird, ganz unweigerlich dazu führt, dass die Qualität und die
Pünktlichkeit leiden.
Scrum nutzt wie alle agilen Methoden einen untersuchenden Ansatz mit schnellem Feed-
back. Kenny erzählt uns in diesem Zusammenhang auch davon, wie er einmal Lochkarten
benutzt hat – und das erinnerte mich an meine früheste Erfahrung mit Rechentechnik,
viele Jahre, bevor Kenny seine erste Lochkarte gesehen hat.
21
Vorwort von Ron Jeffries
Als College-Student hatte ich das Glück, eine Art Praktikum im Hauptquartier der Strategic
Air Command in Omaha machen zu dürfen. Damals wurden noch Lochkarten benutzt.
Meine Karten wurden im SAC-Hauptquartier mehrere Etagen unter die Erde geschickt und
auf dem Computer ausgeführt, der auch in einem Krieg eingesetzt werden würde. Ich hatte
das Glück, ein oder zwei Durchläufe pro Tag zu bekommen.
Sobald meine Sicherheitsfreigabe kam, ging ich mitten in der Nacht hinunter in den Com-
puterraum. Ich beschwatzte Sergeant Whittaker, mich meine eigenen Programme ausfüh-
ren zu lassen. Dazu setzte ich mich an die Konsole der Maschine – ja genau, an die
Maschine, deren Hauptaufgabe es sein würde, einen Atomwaffenangriff durchzuführen.
Aber nur keine Panik, der rote Knopf war nicht in diesem Raum.
Durch das direkte Arbeiten an der Maschine schaffte ich zehnmal mehr Arbeit, als wenn
ich darauf hätte warten müssen, dass meine Karten nach unten und die gedruckten Ergeb-
nislisten wieder nach oben gebracht worden wären. Die Feedbacks kamen schneller, ich
lernte schneller und meine Programme funktionierten eher.
Und genau darum geht es auch bei Scrum. Anstatt Monate oder gar Jahre darauf zu warten,
zu erfahren, was die Programmierer eigentlich machen, finden wir das mit Scrum alle paar
Wochen heraus. Ein Scrum-Product-Owner mit einem wirklich guten Team sieht schon
nach wenigen Tagen, wie die Funktionen Form annehmen!
Das ist es auch, worum es in Kennys Buch geht. Wenn Scrum für Sie neu ist, dann lesen
Sie es von vorn bis hinten durch und legen Sie es anschließend nicht allzu weit weg. Wenn
Sie Scrum schon eine Weile benutzen, dann überfliegen Sie es und halten Sie es anschlie-
ßend weiterhin in griffbereiter Nähe.
Wenn Sie über irgendetwas nachgrübeln, was gerade in Ihrem Team passiert oder sich fra-
gen, welche Dinge Sie einmal ausprobieren könnten, dann nehmen Sie das Buch zur Hand
und schauen Sie sich um. Sie werden aller Wahrscheinlichkeit nach fündig werden.
– Ron Jeffries
22
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.
23
Einleitung
Die Begründer von Scrum (Jeff Sutherland und Ken Schwaber) bieten eine Scrum-spezifi-
sche 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 Schach-
spiels 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 tiefgrei-
fende 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-Frame-
work 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. Statt-
dessen soll es allen, die direkt oder indirekt mit Scrum zu tun haben, ein gemeinsames Ver-
stä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 Schreib-
tisch 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 ein-
24
Der Aufbau dieses Buches
setzen lässt und welche organisatorischen Änderungen erforderlich sind, um Scrum erfolg-
reich 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.
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 Voka-
bular aus Icons, die speziell zur Darstellung der wesentlichen Scrum-Rollen, -Artefakte
und -Aktivitäten entworfen wurde, und stellt somit eine effektive Methode dar, um Kon-
25
Einleitung
zepte 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 Buch.
26
Danksagungen
Dieses Buch wäre ohne die Hilfe vieler Leute, einschließlich der Tausenden von Teilneh-
mern an meinen Agile-Kursen und Trainingssessions, nicht möglich gewesen. All diese
Menschen namentlich aufzuführen, wäre schier unmöglich, daher werde ich mich hier auf
einzelne Personen beschränken. Aber auch diejenigen, die ich an dieser Stelle nicht
namentlich erwähne, sollen wissen, dass all unsere Diskussionen und E-Mail-Korrespon-
denzen von unschätzbarem Wert für mich gewesen sind und dieses Buch definitiv beein-
flusst haben!
Mein besonderer Dank gilt Mike Cohn, Rebecca Traeger und Jeff Schaich. Ohne die unver-
zichtbaren Beiträge dieser drei Menschen wäre dieses Buch nur ein Schatten seiner selbst.
Mike Cohn ist mein Freund und Kollege, seit wir im Jahr 2000 bei Genomica das erste Mal
zusammengearbeitet haben. Er war so großzügig, mein Buch in die Mike Cohn Signature
Series aufzunehmen. Durch die Verbindung zu Mike und den anderen angesehenen Auto-
ren dieser Buchreihe fällt ein Teil des Glanzes auch auf mich, wie meine Eltern sagen wür-
den. Mike war mein Ansprechpartner, wann immer ich Ideen wälzen oder Buchstrategien
diskutieren wollte. Er hat trotz seines irren Terminkalenders immer Zeit gefunden, die ein-
zelnen Kapitel zu lesen und mir seine Meinung dazu zu sagen. Die Zusammenarbeit mit
Mike im Laufe der letzten Jahre war ausgesprochen lohnend – und ich hoffe, wir können
sie auch in der Zukunft fortsetzen.
Rebecca Traeger war bei diesem Buch meine persönliche Lektorin. Wir arbeiten bereits seit
meiner Zeit als Managing Director der Scrum Alliance im Jahr 2007 zusammen. Damals
war Rebecca Redakteurin der Website von Scrum Alliance. Durch diese Arbeit wurde sie
zur führenden Fachredakteurin zum Thema Agile. Gleich als ich anfing, dieses Buch zu
schreiben, habe ich Rebecca gefragt, ob sie wieder mit mir zusammenarbeiten würde. Und
zu meinem großen Glück hat sie zugesagt. Sie war stets die Erste, die die fertiggestellten
Kapitel zu sehen bekam. Manchmal brachte mich ihr Feedback sogar etwas in Verlegenheit,
weil sie meine Ausführungen häufig so umformulierte, dass sie verständlicher und auch
nachvollziehbarer waren. Sollten Sie also irgendeinen Abschnitt dieses Buches als ganz
besonders gut beschrieben empfinden, dann können Sie sicher sein, dass das an Rebecca
liegt – im anderen Fall habe ich vermutlich idiotischerweise ihre Vorschläge ignoriert.
Jeff Schaich ist ein außergewöhnlicher Künstler und Designer. Wir haben an so vielen ver-
schiedenen Kunstprojekten zusammengearbeitet, dass ich mich gar nicht mehr an alle
erinnern kann. Bereits in der Frühphase dieses Buches hatte ich den Wunsch, ein Agile/
Scrum-Vokabular aus Icons zu schaffen, das als Grundlage für meine Trainingspräsentati-
onen und viele der mehr als 200 Abbildungen in diesem Buch dienen könnte. Ich wusste,
dass ich dafür einen großartigen Designer brauchen würde. Und Jeff nahm die Herausfor-
derung an. Manchmal erschien mir die Arbeit an diesem Buch wie zwei separate Projekte –
27
Danksagungen
einerseits das Schreiben und andererseits die Ausarbeitung der künstlerischen Konzepte.
Ich weiß wirklich nicht, was länger gedauert hat – allerdings steht zweifelsfrei außer Frage,
dass dieses Buch ohne Jeffs künstlerischen Beitrag beträchtlich schlechter geworden wäre.
Ich fühle mich äußerst geehrt, dass sowohl Mike Cohn als auch Ron Jeffries, zwei Kory-
phäen der agilen Gemeinde, Vorwörter zu diesem Buch geschrieben haben! Sie haben es
auf ihre jeweils ganz eigene Weise geschafft, es in einen Kontext zu setzen und die Tür für
eine Diskussion zu öffnen. Außerdem: Mike, hör auf, bei Burger King zu essen, und danke,
Ron, dass du den roten Knopf nicht gedrückt hast!
Außerdem möchte ich den vielen Menschen danken, die sich die Zeit genommen haben,
die Kapitel fachlich zu begutachten und mir ihre Meinungen mitzuteilen. Für ihr umfang-
reiches Feedback möchte ich mich vor allem bedanken bei: Joe Balistrieri, Johannes Brod-
wall, Leyna Cotran, Martine Devos, Scott Duncan, Ilan Goldstein, John Hebley, Geir
Hedemark, James Kovacs, Lauri Mackinnon, Robert Maksimchuk und Kevin Tureski.
Für ihr ausgezeichnetes Feedback zu ausgewählten Kapiteln danke ich außerdem: Lyssa
Adkins, John Bauer, Sameer Bendre, Susan Briscoe, Pawel Brodzinski, Rowan Bunning,
Josh Chappell, Lisa Crispin, Ward Cunningham, Cornelius Engelbrecht, Julia Frazier, Brin-
dusa Gabur, Caroline Gordon, Drew Jemilo, Mike Klimkosky, Tom Langerhorst, Bjarne Lar-
sen, Dean Leffingwell, Maurice le Rutte, David Luzquiños, Lv Yi, Shay McAulay, Armond
Mehrabian, Sheriff Mohamed, Cuan Mulligan, Greg Pease, Roman Pichler, Jacopo Romei,
Jens Schauder, Bill Schroeder, Yves Stalgies, Branko Stojaković, Howard Sublett, Julie Syl-
vain, Kevin Tambascio, Stephen Wolfram und Michael Wollin.
Darüber hinaus gilt mein Dank auch den Mitarbeitern bei Pearson, die sich bei diesem Pro-
jekt als großartige Partner erwiesen haben. Sie tolerierten meine Verspätungen mit viel
Geduld und haben mich stets ermutigt. Besonderer Dank geht an Chris Guzikowski, der
dieses Buchprojekt von Anfang an begleitet hat. Er war von meinem ersten Pearson-Treffen
in einer Kneipe in Lexington, MA, bis zum Ende der Produktion mit dabei. Auch möchte
ich Olivia Basegio danken, die sich gekonnt um die Logistik gekümmert hat, sowie Julie
Nahil, die das Projekt ganz fantastisch überwacht hat. Danke auch an Barbara Wood für
ihre großartige Hilfe beim Aufpolieren des Manuskripts und an Gail Cocker für das
Zusammensetzen der Grafiken zu einem wunderbaren Ganzen.
Meiner Assistentin Lindsey Kalicki bin unglaublich dankbar dafür, dass ich viele wichtige
Aufgaben auf sie abladen und mich dadurch weiter auf die Entwicklung des Buches kon-
zentrieren konnte. Ich habe Glück, mit einem solchen Profi zusammenarbeiten zu dürfen.
Die größte Anerkennung gebührt jedoch meiner Familie – Jenine, Jonah und Asher – und
der entscheidenden Rolle, die sie gespielt hat. Ich habe ihnen während der langen Entste-
hungsphase dieses Buches sehr viel abverlangt. Keine noch so große Dankbarkeit kann den
Druck auf meine Familie und unsere verlorene gemeinsame Zeit wiedergutmachen.
Jenine ist meine wahre Seelenverwandte und hat mir durch die Höhen und Tiefen beim
Schreiben dieses Buches stets zur Seite gestanden. Wenn ich auch nur versuchen wollte, all
die Opfer aufzuzählen, die sie gebracht hat, damit ich schreiben konnte, würde dieses Buch
auf den doppelten Umfang anwachsen. Ohne sie hätte ich es nicht geschafft!
Das Witzige ist: In dem Jahr nach unserer Heirat 1993 brachte ich mein erstes Buch,
Succeeding with Objects, heraus. Damals musste ich Jenine versprechen, dass ich nie wieder
ein Buch schreiben würde. Zu meinem Glück verblassen die Erinnerungen nach 15 Jahren
28
Danksagungen
und die Belastung schien rückblickend nicht so schlimm gewesen zu sein. Deswegen war
ich mehr als überrascht, als sie mich drängte, dieses Buch zu schreiben! Sie hat mir bisher
noch nicht gesagt, dass ich Buch Nummer Drei nicht schreiben dürfe, aber ich vermute,
dass es weitere 15 Jahre dauern dürfte, bis die Erinnerung an dieses Buch so weit in Verges-
senheit geraten ist, dass wir beide ein weiteres schreiben wollen!
Natürlich weiß ich auch die liebende Unterstützung meiner beiden Söhne Jonah und Asher
außerordentlich zu schätzen. Sie haben auf Zeit mit ihrem Dad verzichtet, damit ich schrei-
ben konnte. Sie waren immer da, um Ideen zu wälzen und etwas zu diesem Buch beizutra-
gen. Nicht wenige ihrer inhaltlichen und künstlerischen Vorschläge haben es in das Buch
geschafft – dank ihnen ist es besser geworden! Ich hoffe, sie haben den Wert der Beharr-
lichkeit erkannt und gelernt, dass selbst die abschreckendste Arbeit zu schaffen ist, wenn
man immer einen Schritt nach dem anderen macht und nicht aufgibt.
Schließlich möchte ich meinen Eltern, Joyce und Manny Rubin, für all ihre Liebe und
Unterstützung danken. Ohne ihren Einfluss wäre dieses Buch niemals möglich gewesen.
Leider hat keiner von beiden mehr seine Veröffentlichung erlebt. Mom verstarb im Januar
2012 und Dad im Juli 2012. Sie hinterließen in meinem Leben und dem meiner Familie
eine Leere, die niemals wieder gefüllt werden kann. Sie waren für viele, die sie gekannt
haben, ganz besondere Menschen. Mom und Dad, ich vermisse euch mehr, als sich mit
Worten ausdrücken lässt.
29
Über den Autor
Kenny Rubin bietet Scrum- und Agile-Training und -Beratung an, um Unternehmen zu
helfen, Produkte auf effektive und wirtschaftlich vernünftige Weise zu entwickeln. Als Cer-
tified Scrum Trainer hat Kenny mehr als 19.000 Menschen in agilen Techniken und
Scrum, Smalltalk-Entwicklung, der Organisation objektorientierter Projeke und im Über-
gangsmanagement unterwiesen. Dabei hat er mehr als 200 Unternehmen beraten, von
Start-ups bis zu Fortune-10-Unternehmen.
Kenny war der erste Managing Director der weltweit agierenden Scrum Alliance, einer
nicht-kommerziellen Organisation, die sich auf die erfolgreiche Übernahme von Scrum
konzentriert. Er ist außerdem Co-Autor des 1995 erschienenen Buches Succeeding with
Objects: Decision Frameworks for Project Management. Seinen Bachelor of Science in Informa-
tion and Computer Science hat Kenny am Georgia Institute of Technology erworben, sei-
nen Master of Science in Computer Science hat er an der Stanford University gemacht.
Ursprünglich war Kenny hauptsächlich mit der Objektorientierung befasst. Er begann 1985
als Smalltalk-Entwickler an einem NASA-finanzierten Projekt und entwickelte das erste
Blackboard-Expertensystem außerhalb von LISP. 1988 wechselte er zu ParcPlace Systems,
einem Start-up-Unternehmen, das aus Xerox PARC hervorgegangen war und dessen Ziel
darin bestand, die objektorientierte Technik aus den Forschungslaboren zu befreien und
auf die Welt loszulassen. Als Berater für Smalltalk-Entwicklung bei vielen unterschiedli-
chen Organisationen in den späten 1980ern und den 1990ern gehörte Kenny zu den frü-
hen Verfechtern agiler Praktiken. Das erste Mal setzte er Scrum im Jahr 2000 bei der
Entwicklung von Bioinformatik-Software ein.
Im Laufe seiner Karriere hat Kenny viele Positionen eingenommen. So war er unter ande-
rem als Scrum-Product-Owner, ScrumMaster und Mitglied von Entwicklungsteams, aber
auch im Management erfolgreich tätig, als CEO, COO, VP of Engineering, VP of Product
Management und VP of Professional Services. Er überwachte die Entwicklung von fünf
kommerziellen Software-Suites und generierte damit Einnahmen von insgesamt mehr als
200 Millionen Dollar. Darüber hinaus war er unmittelbar an der Beschaffung von mehr als
150 Millionen Dollar an Venture Capital beteiligt und hat dabei geholfen, zwei Unterneh-
men an die NASDAQ zu bringen.
Dank seiner vielfältigen Erfahrungen besitzt Kenny die außergewöhnliche Fähigkeit,
Scrum und seine Implikationen aus verschiedenen Perspektiven gleichermaßen gut zu ver-
stehen (und zu erklären): vom Entwicklungsteam bis hin zum Vorstand.
31
Kapitel 1
Einführung
Am 21. Juni 2000 war ich als stellvertretender Vorstandsvorsitzender bei Genomica tätig,
einer Bioinformatik-Firma in Boulder, Colorado. Dieses Datum ist mir deshalb in besonde-
rer Erinnerung, weil mein Sohn Asher an diesem Tag um 1 Uhr nachts geboren wurde.
Und seine Geburt war zweifellos ein guter Auftakt für diesen Tag. Asher wurde tatsächlich
am berechneten Geburtstermin geboren (das passiert in den USA nur bei etwa 5% der
Geburten) – wir (oder besser gesagt meine Frau Jenine) hatten unser Neun-Monats-»Pro-
jekt« also absolut pünktlich abgeschlossen. Und zur Krönung des Ganzen war ihm auch
noch ein sehr hoher Apgar-Wert attestiert worden, was eindeutig belegte, dass wir ein
gesundes, hochwertiges »Erzeugnis« produziert hatten! Unser wichtigster »Anteilseigner«
(Stakeholder), unser älterer Sohn Jonah, war begeistert, einen jüngeren Bruder zu haben.
Ein pünktlich geliefertes, hochwertiges Produkt und noch dazu hocherfreute Anteilseigner
– es war wirklich ein guter Tag!
Nach einem kurzen Nickerchen rief ich meine E-Mails ab und sah, dass der Vorstandschef
von Genomica eine dringende Nachricht geschickt hatte, in der er mich bat, um 8 Uhr zu
einem Treffen des Vorstands zu erscheinen. Widerstrebend verließ ich das Krankenhaus
und ging zu der Sitzung.
Als ich ankam, erfuhr ich, dass der Leiter der technischen Entwicklungsabteilung am
Abend zuvor gefeuert worden war und ich das 90 Leute starke Technikteam geerbt hatte.
Das überraschte mich allerdings nicht: Bereits seit mehreren Monaten hatten die Füh-
rungsmannschaft und der Vorstand Genomicas Unfähigkeit diskutiert, wertige Produkte
von guter Qualität pünktlich auszuliefern – und der Leiter der technischen Entwicklung
hatte im Mittelpunkt dieser Diskussion gestanden.
Jetzt war ich verantwortlich dafür, die Ergebnisse unserer Produktentwicklung deutlich zu
verbessern. Ich erinnere mich noch, wie paradox es mir vorkam, dass zwei so bedeutsame
Ereignisse wie die glückliche Geburt meines Sohnes und die Übernahme meines neuen
Verantwortungsbereichs auf ein und denselben Tag fielen.
Da ich mit dem Verkauf und dem Marketing ohnehin schon ziemlich ausgelastet war,
gestand man mir zu, dass ich nach meinem Ermessen einen Technikchef einstellen
konnte, der mir direkt unterstellt war. Also besetzte ich diesen Posten mit Mike Cohn
(Cohn 2004; Cohn 2006; Cohn 2010) und wir beschlossen, es mit Scrum zu versuchen.
33
Kapitel 1
Einführung
Bei einem agilen Ansatz beginnen Sie zunächst mit einem Product Backlog – einer priori-
sierten Liste der Funktionen und Fähigkeiten, die erforderlich sind, um ein erfolgreiches
Produkt zu entwickeln. Wenn Sie sich an das Product Backlog halten, arbeiten Sie immer
zuallererst die wichtigsten Aufgaben ab, also diejenigen mit der höchsten Priorität. Sollten
Ihnen dann irgendwann die Ressourcen ausgehen (wie z.B. die Zeit), haben somit alle
noch verbleibenden Aufgaben eine niedrigere Priorität als die bereits abgeschlossenen
Arbeiten.
Product Backlog
Funktion A
Iterations-Review
Funktion B
Iterationsplanung
Funktion C
Funktion A
Funktion B
Funktion C
Die Arbeiten selbst werden in kurzen, zeitlich fest begrenzten (time-boxed) Iterationen
durchgeführt, wobei sich der hierfür vorgesehene Zeitrahmen normalerweise zwischen
einer Woche und einem Kalendermonat bewegt. Während der einzelnen Iterationen erle-
digt ein Team die Arbeiten, die nötig sind, um abgeschlossene, funktionierende Elemente
herzustellen, die dann in die Produktion überführt werden können. Das Team organisiert
sich selbst und kann sich mehrerer Funktionen annehmen – wie etwa dem Entwerfen,
Bauen und Testen.
Üblicherweise ist in der Planung eines Product Backlogs deutlich mehr Arbeit vorgesehen,
als ein Team innerhalb einer kurzen Iteration bewältigen kann. Deshalb legt das Team zu
Beginn jeder Iteration zunächst einmal fest, welche hoch priorisierte Teilmenge des Pro-
duct Backlogs in der kommenden Iteration erledigt werden soll. In dem Beispiel aus Abbil-
dung 1.1 ist es z.B. übereingekommen, sich den Funktionen A, B und C zu widmen.
Am Ende der Iteration prüft das Team die abgeschlossenen Funktionen noch einmal
gemeinsam mit den Stakeholdern, um deren Feedback zu erhalten. Und je nachdem, wel-
che Kritikpunkte dabei zutage treten, können der Product Owner und das Team ihre Pläne
für die nächsten Arbeitsschritte ändern. Falls die Stakeholder bei genauerer Betrachtung
einer bereits abgeschlossenen Funktion also etwa feststellen, dass noch eine andere Funk-
34
1.2
Die Ursprünge von Scrum
tion in das Produkt eingebracht werden muss, die zuvor unberücksichtigt geblieben war,
kann der Product Owner hierfür einfach ein entsprechendes neues Element anlegen, das
dann an der passenden Stelle im Product Backlog eingefügt und in einer künftigen Itera-
tion bearbeitet wird.
Am Ende der einzelnen Iterationen sollte das Team ein potenziell auslieferungsfähiges Pro-
dukt haben (oder ein Inkrement des Produkts, also eine Produktfunktionalität), das prinzi-
piell freigegeben werden könnte. Sollten individuelle Freigaben nach jeder Iteration
hingegen nicht sinnvoll sein, könnten alternativ auch Funktionssätze aus mehreren Itera-
tionen zusammen freigegeben werden.
Nach Beendigung einer Iteration fängt der ganze Prozess mit der Planung der nächsten Ite-
ration wieder von vorn an.
35
Kapitel 1
Einführung
Project Management with Scrum« (Schwaber 2004) und »The Scrum Guide« (Schwaber
und Sutherland 2011).
Obwohl Scrum vorwiegend für die Entwicklung von Software-Produkten eingesetzt wird,
lassen sich seine Grundwerte und Prinzipien auch für die Entwicklung anderer Produkte
oder zum Organisieren der Arbeitsabläufe (Workflow) unterschiedlicher Betätigungsfelder
nutzen. So habe ich beispielsweise mit Organisationen zusammengearbeitet, in denen
Scrum ebenso erfolgreich für die Abwicklung und Verwaltung von Hardware-Entwicklun-
gen, Marketingprogrammen und Verkaufsinitiativen eingesetzt wurde.
36
1.4
Ergebnisse bei Genomica
sierten – vorzugsweise täglich. Denn in der Vergangenheit hatte die mangelhafte Kommu-
nikation hinsichtlich gravierender Probleme, die bereits während der Entwicklungsphase
aufgetreten waren, zu einer Verschärfung der zugrunde liegenden Fehler geführt. Die
Leute in den unterschiedlichen Bereichen redeten einfach nicht oft genug miteinander.
Aus diesen und anderen Gründen entschieden wir, dass Scrum sich gut für Genomica eig-
nen würde.
37
Kapitel 1
Einführung
wicklungsbemühungen zufrieden?« oder »Glaubt ihr, dass wir unseren Kunden zu einem
spürbaren zeitlichen, wirtschaftlichen und qualitativen Nutzen verhelfen?«
In sehr vielen Fällen haben die Leute, die ich im Rahmen meiner weltweiten Trainings- und
Beratungstätigkeit dazu befragt habe, mit einem klaren »Nein« geantwortet. Vielmehr
tönte es von allen Seiten: »Die Projektausfallrate ist inakzeptabel hoch«, »Die Auslieferung
erfolgt immer verspätet«, »Die Rentabilität liegt unter den Erwartungen«, »Die Software-
Qualität ist mies«, »Die Produktivität ist beschämend«, »Niemand übernimmt die Verant-
wortung für die Ergebnisse«, »Die Arbeitsmoral ist schlecht«, »Wir haben eine hohe Mitar-
beiterfluktuation«. Und dann wird mit einem desillusionierten Lächeln und ironischem
Unterton noch angefügt: »Es müsste doch auch besser gehen.«
Bei aller Verdrossenheit scheinen sich die meisten Leute damit abgefunden zu haben, dass
Unzufriedenheit zur Software-Entwicklung einfach dazugehört. Dabei muss das nicht so
sein.
Organisationen, die Scrum gewissenhaft einsetzen, haben da ganz andere Erfahrungen
gemacht (siehe Abbildung 1.2).
Erfreute Kunden
Verbesserte Rendite
Reduzierte Kosten
Scrum-Vorteile
Schnelle Ergebnisse
Mehr Freude
Diese Organisationen begeistern ihre Kunden in schöner Regelmäßigkeit, indem sie ihnen
wirklich das liefern, was sie sich wünschen, und nicht bloß die Funktionen, die am ersten
Tag festgelegt wurden, als noch niemand den wahren Bedarf kannte. Außerdem erwirt-
schaften sie eine bessere Rendite, weil sie häufiger kleinere Releases herausbringen. Und
durch das schonungslose Aufdecken mangelhafter organisatorischer Abläufe und Ver-
schwendungen sind diese Organisationen zudem in der Lage, die Kosten zu senken.
38
1.5
Kann Scrum Ihnen helfen?
Komplex Kompliziert
Prüfen, Erspüren, Reagieren Erspüren, Analysieren, Reagieren
• Problem durch Erkundung kennenlernen, • Situation einschätzen, mehrere Optionen
dann untersuchen und anpassen untersuchen, Reaktion basiert auf guter Praxis
• Erfordert kreative/innovative Ansätze • Experten gewähren Einblick
• Gesicherte Umgebung zum Experimentieren • Metriken helfen, Kontrolle zu gewinnen
und Erkennen von Mustern schaffen • Domäne der guten Praktiken
• Maß an Interaktion/Kommunikation erhöhen • Mehrere richtige Antworten
• Domäne der Emergenz • Ursache und Wirkung lassen sich entdecken, sind
• Hinterher weiß man alles besser aber nicht unmittelbar offensichtlich
• Eher unvorhersehbar als vorhersehbar • Eher vorhersehbar als unvorhersehbar
Disorder
Chaotisch Einfach
Handeln, Erspüren, Reagieren Erspüren, Kategorisieren, Reagieren
• Sofort handeln, dann untersuchen, ob die • Fakten erfassen und kategorisieren,
Situation stabil ist, dann versuchen, Kontext Antwort basiert auf etabliertem Vorgehen
in komplexe Domäne zu migrieren • Domäne der besten Praktiken
• Viele Entscheidungen, wenig Zeit • Stabile Domäne (Änderung unwahrscheinlich)
• Sofortige Aktion, um Ordnung • Klare Ursache-Wirkungs-Beziehungen
wiederherzustellen sind offensichtlich für jeden
• Schauen, was geht, anstatt richtige • Es existiert eine korrekte Antwort
Antworten zu suchen • Faktenbasiertes Management
• Domäne des Ungewöhnlichen
• Niemand weiß etwas
• Keine klare Ursache und Wirkung
Verstehen Sie mich nicht falsch: Scrum ist zwar in vielen Situationen eine ausgezeichnete
Lösung, aber trotzdem nicht in allen Fällen das geeignete Mittel zum Zweck. Das Cynefin-
Framework (Snowden und Boone 2007) ist ein sinnvolles Hilfsmittel, um die vorliegende
39
Kapitel 1
Einführung
40
1.5
Kann Scrum Ihnen helfen?
auf einer bewährten Praxis aufbauen. Ein Großteil der alltäglichen Software-Wartung (das
Durchführen von Produkt-Support oder das Beheben von Defekten) fällt in diese Kategorie.
Hier sind viele der taktischen, quantitativen Ansätze wie Six Sigma besonders gut geeignet,
wenngleich diese auch bei einfachen Domänen eingesetzt werden können.
41
Kapitel 1
Einführung
zelne Teile zerlegen und diese jeweils einer der vier anderen Domänen zuordnen. In der
Disorder-Domäne probieren Sie gar nicht erst Scrum anzuwenden, sondern versuchen
vielmehr, diese Domäne zu verlassen.
42
1.6
Abschließende Bemerkungen
43
Teil I
Kernkonzepte
In diesem Teil:
쐽 Kapitel 2
Das Scrum-Framework . . . . . . . . . . . . . . . . . . . . . . 47
쐽 Kapitel 3
Agile Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
쐽 Kapitel 4
Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
쐽 Kapitel 5
Anforderungen und User Stories . . . . . . . . . . . . . . 115
쐽 Kapitel 6
Das Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . 137
쐽 Kapitel 7
Schätzung und Velocity . . . . . . . . . . . . . . . . . . . . . . 157
쐽 Kapitel 8
Technische Schulden . . . . . . . . . . . . . . . . . . . . . . . . 177
45
Kapitel 2
Das Scrum-Framework
In diesem Kapitel präsentiere ich Ihnen einen Überblick über das Scrum-Framework.
Dabei konzentriere ich mich besonders auf seine Praktiken, einschließlich seiner Rollen,
Aktivitäten und Artefakte. In den nachfolgenden Kapiteln werde ich dann noch ausführli-
cher auf diese einzelnen Praktiken eingehen und einen genaueren Blick auf die Prinzipien
werfen, die diesen Praktiken zugrunde liegen.
2.1 Überblick
Scrum ist kein standardisierter Prozess, bei dem Sie sich methodisch an eine Schrittabfolge
halten, die garantiert, pünktlich und preiswert ein hochwertiges Produkt ergibt, das Ihre
Kunden in Entzückung versetzt. Stattdessen bietet Scrum einen Rahmen zum Organisie-
ren und Verwalten von Arbeit. Das Scrum-Framework basiert auf einer Reihe von Werten,
Prinzipien und Praktiken, die die Grundlage bieten, auf der Ihre Organisation ihre eigene
Umsetzung relevanter technischer Praktiken sowie Ihre speziellen Ansätze zum Umsetzen
der Scrum-Praktiken aufsetzt. Das Ergebnis ist eine Version von Scrum, die einzigartig für
Ihre Organisation ist.
Um das Konzept des Scrum-Frameworks besser zu verstehen, stellen Sie sich vor, dass es
das Fundament und die Wände eines Gebäudes bildet. Die Werte, Prinzipien und Praktiken
von Scrum würden den wichtigen strukturellen Komponenten entsprechen. Sie können
einen Wert, ein Prinzip oder eine Praxis nicht ignorieren oder grundlegend ändern, ohne
zu riskieren, dass das Ganze zusammenbricht. Was Sie jedoch können, ist, die innere
Struktur von Scrum anzupassen sowie Inventar und Elemente hinzuzufügen, bis Sie einen
Prozess haben, der zu Ihnen passt.
Scrum ist ein angenehm einfaches, auf die Menschen ausgerichtetes Framework, das auf
den Werten Ehrlichkeit, Offenheit, Mut, Respekt, Fokus, Vertrauen, Stärkung und Zusam-
menarbeit beruht. In Kapitel 3 werden die Scrum-Prinzipien genauer beschrieben und in
den darauffolgenden Kapiteln wird aufgezeigt, inwiefern bestimmte Praktiken und
Ansätze aus diesen Prinzipien und Werten erwachsen. Die Scrum-Praktiken selbst sind in
bestimmten Rollen, Aktivitäten, Artefakten und den ihnen zugewiesenen Regeln verkör-
pert (siehe Abbildung 2.1).
Der Rest dieses Kapitels konzentriert sich auf die Scrum-Praktiken.
47
Kapitel 2
Das Scrum-Framework
Product Owner
Rollen ScrumMaster
Entwicklungsteam
Sprint
Sprint-Planung
Daily Scrum
Aktivitäten Sprint-Ausführung
Sprint-Retrospektive
Product-Backlog-Pflege
Product Backlog
2.2 Scrum-Rollen
Scrum-Entwicklungsmaßnahmen bestehen aus einem oder mehreren Scrum-Teams, die
jeweils aus drei Scrum-Rollen gebildet werden: Product Owner, ScrumMaster und
Entwicklungsteam (siehe Abbildung 2.2). Es kann bei der Anwendung von Scrum noch
weitere Rollen geben, das Scrum-Framework benötigt jedoch nur die drei hier aufgeführten
Rollen.
Der Product Owner ist verantwortlich dafür, was entwickelt wird und in welcher Reihen-
folge dies geschieht. Der ScrumMaster ist dafür verantwortlich, das Team beim Erschaffen
und Befolgen seines eigenen Prozesses – basierend auf dem allgemeineren Scrum-Frame-
work – anzuleiten. Und das Entwicklungsteam ist dafür verantwortlich, festzulegen, wie es
das liefern kann, was der Product Owner haben möchte.
48
2.2
Scrum-Rollen
Scrum-Team
Product Owner ScrumMaster
Entwicklungsteam
Machen Sie sich als Manager keine Sorgen, dass »Manager« nicht als Rolle in Abbildung
2.2 auftaucht. Manager spielen in Organisationen, die Scrum nutzen, natürlich weiterhin
eine wichtige Rolle (siehe Kapitel 13). Das Scrum-Framework definiert nur die Scrum-spezi-
fischen Rollen, nicht alle Rollen, die in einer Organisation, die Scrum einsetzt, existieren
können und sollten.
2.2.2 ScrumMaster
Der ScrumMaster hilft allen Beteiligten, die Scrum-Werte, -Prinzipien und -Praktiken zu
verstehen und zu übernehmen. Er agiert als Trainer, bietet Führerschaft für den Prozess
und hilft dem Scrum-Team und dem Rest der Organisation, ihren eigenen leistungsstarken
und organisationsspezifischen Scrum-Ansatz zu entwickeln. Gleichzeitig unterstützt der
49
Kapitel 2
Das Scrum-Framework
50
2.3
Scrum-Aktivitäten und Artefakte
Mitte der Abbildung dominiert. Die Anzahl der Elemente im Product Backlog übersteigt
wahrscheinlich das Pensum, was das Entwicklungsteam in einem kurzen Sprint bewälti-
gen kann. Aus diesem Grund muss das Entwicklungsteam zu Beginn jedes Sprints eine
Teilmenge der Elemente aus dem Product Backlog festlegen, die es glaubt, schaffen zu kön-
nen – eine Aktivität, die als Sprint-Planung bezeichnet wird und rechts neben dem großen
Product-Backlog-Würfel zu sehen ist.
Daily Scrum
Sprint-Planung
Sprint Backlog
Product Backlog
Sprint-Ausführung
Pflege
Potenziell
auslieferungsfähiges
Produktinkrement
Sprint Review
Sprint-Retrospektive
Übrigens rief eine 2011 vorgenommene Änderung in »The Scrum Guide« (Schwaber und
Sutherland 2011) eine Debatte hervor, ob sich das Ergebnis einer Sprint-Planung als
Vorhersage oder doch eher als Verpflichtung beschreiben lässt. Befürworter des Wortes
Vorhersage mögen es, weil sie glauben, dass das Entwicklungsteam zwar die bestmögliche
Schätzung vornimmt, diese Schätzung sich aber ändern kann, wenn im Laufe des Sprints
mehr Informationen bekannt werden. Manche glauben auch, dass eine Verpflichtung aufsei-
ten des Teams das Team dazu bewegen könnte, Qualitätseinbußen hinzunehmen oder sich
einfach zu weniger zu verpflichten, um die Verpflichtung garantiert zu erfüllen.
Ich stimme zu, dass alle Entwicklungsteams eine Vorhersage (Schätzung) darüber abgeben
sollten, was sie bei jedem Sprint liefern können. Viele Entwicklungsteams würden jedoch
davon profitieren, wenn sie die Vorhersage benutzen würden, um eine Verpflichtung abzu-
leiten. Verpflichtungen fördern das gegenseitige Vertrauen zwischen dem Product Owner
und dem Entwicklungsteam sowie innerhalb des Entwicklungsteams. Darüber hinaus
unterstützen Verpflichtungen die vernünftige Kurzzeitplanung und Entscheidungsfindung
innerhalb einer Organisation. Und wenn die Produktentwicklung in mehreren Teams statt-
findet, fördern Verpflichtungen eine synchronisierte Planung – ein Team kann auf der
Grundlage dessen, wozu sich ein anderes Team verpflichtet hat, seine Entscheidungen tref-
fen. Ich bevorzuge in diesem Buch den Begriff Verpflichtung, benutze aber gelegentlich das
Wort Vorhersage, wenn der Kontext es zulässt.
Um die Zuversicht zu gewinnen, dass das Entwicklungsteam eine vernünftige Verpflich-
tung gefasst hat, legen die Teammitglieder während der Sprint-Planung ein zweites Back-
51
Kapitel 2
Das Scrum-Framework
log an, das als Sprint Backlog bezeichnet wird. Das Sprint Backlog beschreibt anhand einer
Reihe detaillierter Aufgaben, wie das Team in diesem speziellen Sprint Entwurf, Aufbau,
Integration und Test der ausgewählten Funktionen aus dem Product Backlog durchführen
will.
Nun kommt die Sprint-Ausführung, während der das Entwicklungsteam die Aufgaben erle-
digt, die nötig sind, um die ausgewählten Funktionen umzusetzen. Während der Sprint-
Ausführung helfen die Teammitglieder täglich bei der Verwaltung des Workflows, indem
sie eine Aktivität durchführen, die als Daily Scrum bezeichnet wird und der Synchronisie-
rung, Inspektion und Vorausplanung dient. Am Ende der Sprint-Ausführung hat das Team
ein potenziell auslieferungsfähiges Produktinkrement hergestellt, das einen Teil, jedoch
nicht die gesamte Vision des Product Owners repräsentiert.
Das Scrum-Team schließt den Sprint mit zwei Aktivitäten zur Untersuchung und Anpas-
sung ab. In der ersten, dem Sprint Review, untersuchen die Stakeholder und das Scrum-
Team das hergestellte Produkt. In der zweiten, der Sprint-Retrospektive, untersucht das
Scrum-Team den Scrum-Prozess, der eingesetzt wurde, um das Produkt zu erschaffen. Das
Ergebnis dieser Aktivitäten könnten Änderungen sein, die ihren Weg in das Product Back-
log finden oder als Teil des Entwicklungsprozesses des Teams betrachtet werden.
Nun wiederholt sich der Scrum-Sprint-Kreislauf. Er beginnt erneut damit, dass das Ent-
wicklungsteam die nächstwichtige Menge der Elemente aus dem Product Backlog
bestimmt, die es abschließen kann. Nachdem eine entsprechende Anzahl von Sprints erle-
digt wurde, ist die Vision des Product Owners verwirklicht und die Lösung kann freigege-
ben werden.
Im Rest dieses Kapitels gehe ich näher auf diese Aktivitäten und Artefakte ein.
52
2.3
Scrum-Aktivitäten und Artefakte
Insgesamt ist die Aktivität des Anlegens und Verfeinerns der Elemente des Product Back-
logs, ihr Abschätzen und Priorisieren als Pflege oder Grooming bekannt (siehe Abbil-
dung 2.5).
Funktion A
Funktion B
Hochpriorisierte Elemente
Funktion C
Defekt 23
Restrukt. X
Funktion D
Funktion E
Funktion F
Niedrigpriorisierte Elemente
Product Backlog
Funktion A
Funktion B
Funktion C
Priorisieren
Anlegen Schätzen
und Verfeinern
Noch eine zweite kurze Anmerkung: 2011 gab es eine weitere Debatte darüber, ob der kor-
rekte Begriff für das Beschreiben der Abfolge der Elemente im Product Backlog priorisiert
(der Originalbegriff) oder geordnet lauten soll, wie es in »The Scrum Guide« (Schwaber und
Sutherland 2011) heißt. Es wurde argumentiert, dass Priorisieren einfach nur eine Form
des Ordnens sei (und, wie manche behaupteten, nicht einmal die geeignetste). Die Frage,
wie man die Elemente im Product Backlog aufreiht, wird jedoch von vielen Faktoren beein-
flusst. Ein einziges Wort kann vermutlich niemals die volle Breite und Tiefe des Konzepts
erfassen. Theoretisch mag der Streit über die Begriffe »geordnet« und »priorisiert« irgend-
53
Kapitel 2
Das Scrum-Framework
einen Nutzen haben, die meisten Leute (auch ich) verwenden sie bei der Diskussion um die
Elemente im Product Backlog jedoch je nach Kontext.
Bevor wir das Priorisieren, Ordnen oder anderweitige Arrangieren des Product Backlogs
abschließen, müssen wir wissen, wie groß die einzelnen Elemente sein werden (siehe
Abbildung 2.6).
Funktion A | 5
Funktion B | 3 Relative Größenschätzungen
Funktion C | 2 (typischerweise Story-Punkte oder Idealtage)
Funktion D | 5
Funktion E | 8
Die Größe entspricht den Kosten. Product Owner müssen die Kosten eines Elements ken-
nen, um dessen Priorität bestimmen zu können. Scrum gibt nicht vor, welches Größenmaß
man gegebenenfalls für Elemente des Product Backlogs benutzen sollte. In der Praxis ver-
wenden viele Teams ein relatives Größenmaß wie Story-Punkte oder Idealtage. Ein relatives
Größenmaß drückt die Gesamtgröße eines Elements auf eine Weise aus, dass nicht der
absolute Wert in Betracht gezogen wird, sondern die relative Größe eines Elements im Ver-
gleich zu anderen Elementen. So hat z.B. Funktion C in Abbildung 2.6 die Größe 2, wäh-
rend Funktion E die Größe 8 besitzt. Wir können daraus schließen, dass Funktion E
ungefähr achtmal größer ist als Funktion C. Ich gehe in Kapitel 7 näher auf diese Maße ein.
2.3.2 Sprints
In Scrum wird die Arbeit in Iterationen oder Zyklen durchgeführt, die bis zu einem Kalen-
dermonat dauern können und Sprints genannt werden (siehe Abbildung 2.7). Die Arbeit,
die in einem Sprint abgeschlossen wird, sollte etwas schaffen, das für den Kunden oder
User einen irgendwie greifbaren Wert aufweist.
Starttermin Endtermin
Feste Länge
54
2.3
Scrum-Aktivitäten und Artefakte
Sprints sind in Time-Boxen eingeteilt, sie haben also immer ein festes Anfangs- und End-
datum und sollten im Allgemeinen alle gleich lang sein. Ein neuer Sprint folgt unmittelbar
auf den Abschluss des vorhergehenden Sprints. Normalerweise gilt die Regel, dass wäh-
rend eines Sprints keine Änderungen in Umfang oder Personal zulässig sind, die das Ziel
gefährden. Manchmal machen es jedoch die geschäftlichen Umstände unmöglich, diese
Regel zu befolgen. Ich werde Sprints in Kapitel 4 näher beschreiben.
2.3.3 Sprint-Planung
Ein Product Backlog könnte viele Wochen oder Monate an Arbeit repräsentieren, was natür-
lich mehr ist, als sich in einem einzigen kurzen Sprint bewältigen lässt. Um die wichtigste
Teilmenge der Elemente eines Product Backlogs zu ermitteln, die in den nächsten Sprint
aufgenommen werden sollen, führen der Product Owner, das Entwicklungsteam und der
ScrumMaster ein Planungstreffen durch, die Sprint-Planung (siehe Abbildung 2.8).
Sprint-Planung
Sprint Backlog
Product Backlog
Funktion A
Funktion B Aufgaben = wie es zu tun ist
Funktion C
Was zu tun ist
Pflege
Die Sprint-Planung
ist der erste Teil
jedes Sprints
Während der Sprint-Planung einigen sich der Product Owner und das Entwicklungsteam
auf ein Sprint-Ziel, das definiert, was im kommenden Sprint erreicht werden soll. Anhand
dieses Ziels prüft das Entwicklungsteam das Product Backlog und ermittelt die Elemente
mit hoher Priorität, die das Team realistischerweise im kommenden Sprint erledigen kann,
wenn es in einer nachhaltigen Geschwindigkeit arbeitet, d.h. einer Geschwindigkeit, die
das Team über einen längeren Zeitraum durchhalten kann.
Um Vertrauen in das zu gewinnen, was es schaffen kann, teilen viele Entwicklungsteams
die jeweils angestrebten Funktionen in eine Reihe von Aufgaben auf. Diese Aufgaben-
sammlung bildet dann zusammen mit ihren jeweiligen Product-Backlog-Elementen ein
zweites Backlog, das Sprint Backlog (siehe Abbildung 2.9).
Das Entwicklungsteam gibt außerdem eine Schätzung über den Aufwand ab (typischer-
weise in Stunden), der zum Abschließen der einzelnen Aufgaben nötig sein wird. Das Auf-
teilen der Elemente des Product Backlogs in Aufgaben ist eine Form des Designs und der
Just-in-time-Planung für die Fertigstellung dieser Funktionen.
Die meisten Scrum-Teams, die Sprints von zwei Wochen bis einem Monat durchführen,
versuchen, die Sprint-Planung in vier bis acht Stunden zu schaffen. Die Planung eines
55
Kapitel 2
Das Scrum-Framework
Sprints von einer Woche Dauer sollte nicht mehr als einige Stunden erfordern (eher sogar
weniger). In dieser Zeit kann man mehreren Ansätzen folgen. Ich nutze meist einen einfa-
chen Zyklus: Auswahl eines Elements aus dem Product Backlog (wenn möglich, das
nächstwichtige Element, wie es vom Product Owner definiert wurde), Zerlegen des Ele-
ments in Aufgaben und Feststellen, ob das ausgewählte Element bequem in den Sprint
passt (zusammen mit anderen Elementen, die ebenfalls für diesen Sprint vorgesehen sind).
Falls das Element passt und noch Kapazitäten für weitere Arbeiten frei sind, wird der Zyk-
lus wiederholt, bis die Kapazitäten des Teams erschöpft sind.
Alternativ könnten der Product Owner und das Team alle Zielelemente des Product Back-
logs auf einmal auswählen. Das Entwicklungsteam nimmt dann allein die Aufteilung in
Aufgaben vor, um zu bestätigen, dass es tatsächlich alle ausgewählten Elemente ausliefern
kann. Die einzelnen Vorgehensweisen werden in Kapitel 19 genauer betrachtet.
2.3.4 Sprint-Ausführung
Sobald das Scrum-Team die Sprint-Planung abgeschlossen und sich auf den Inhalt des
nächsten Sprints geeinigt hat, führt das Entwicklungsteam unter Anleitung des ScrumMas-
ters alle aufgabenbezogenen Arbeiten durch, die erforderlich sind, um die Funktionen fer-
tigzustellen (siehe Abbildung 2.10). Done (Fertig) bedeutet, dass im Team eine große
Zuversicht darüber herrscht, dass alle Arbeiten zur Bereitstellung hochwertiger Funktionen
abgeschlossen sind.
Welche Aufgaben das Team nun genau durchführt, hängt natürlich von der Art der Arbeit
ab (produzieren wir z.B. Software, stellen wir Hardware her oder geht es um Marketingar-
beit?).
Niemand sagt dem Entwicklungsteam, in welcher Reihenfolge oder wie es die aufgabenbe-
zogenen Arbeiten im Sprint Backlog erledigen soll. Stattdessen definieren die Teammitglie-
56
2.3
Scrum-Aktivitäten und Artefakte
der ihre Arbeit und organisieren sich dann selbst so, wie es ihnen am besten erscheint, um
das Sprint-Ziel zu erreichen. In Kapitel 20 erfahren Sie mehr über die Sprint-Ausführung.
Sprint Backlog
Sprint-Ausführung
Alle 24 Stunden
Daily Scrum
Sprint-Ausführung
57
Kapitel 2
Das Scrum-Framework
Ein verbreitetes Vorgehen beim Daily Scrum sieht so aus, dass der ScrumMaster moderiert
und die einzelnen Teammitglieder nacheinander drei Fragen für die anderen Teammitglie-
der beantworten:
쐽 Was habe ich seit dem letzten Daily Scrum erreicht?
쐽 Woran möchte ich bis zum nächsten Daily Scrum arbeiten?
쐽 Welche Hürden oder Hindernisse haben dafür gesorgt, dass ich keine Fortschritte ge-
macht habe?
Durch die Beantwortung dieser Fragen bekommt jeder mit, was im Großen und Ganzen
passiert, wie der Stand der Dinge in Bezug auf das Sprint-Ziel ist, ob und wie die Pläne für
die Arbeit des nächsten Tages geändert wurden und welche Probleme angesprochen wer-
den müssen. Das Daily Scrum ist ein ganz wesentlicher Faktor, damit das Entwicklungs-
team den schnellen, flexiblen Workflow in einem Sprint bewältigen kann.
Es dient allerdings nicht der Lösung von Problemen. Stattdessen bevorzugen es viele
Teams, vorliegende Problemstellungen erst nach dem Daily Scrum zu besprechen, und
zwar nicht in der ganzen Gruppe, sondern lediglich im kleineren Kreis Interessierter. Auch
ist das Daily Scrum kein traditionelles Statustreffen, wie es früher von Projektmanagern
einberufen wurde, um sich über den Status des Projekts zu informieren. Ein Daily Scrum
kann jedoch sinnvoll sein, um die Mitglieder des Entwicklungsteams über den Status der
Elemente des Sprint Backlogs zu informieren. Es ist in der Hauptsache eine Aktivität zur
Überprüfung, Synchronisierung und Anpassung der täglichen Planung, die dem selbstor-
ganisierten Team hilft, besser zu werden.
Auch wenn sie heute nicht mehr zum Scrum-Sprachgebrauch gehören, wurden früher die
Begriffe »Pigs« (Schweine) und »Chicken« (Hühner) benutzt, um zwischen denjenigen zu
unterscheiden, die an den Daily Scrums aktiv teilnehmen, und jenen, die einfach nur beob-
achten sollten. Damit bezog man sich auf einen alten Haustier-Witz: »Bei einem Frühstück
aus Schinken und Eiern sind die Hühner interessiert, die Schweine jedoch beteiligt«. Diese
Bezeichnungen sollten also lediglich zur Unterscheidung von am Erreichen des Sprint-
Ziels Interessierten (Chicken) auf der einen Seite und und unmittelbar daran Beteiligten
(Pigs) auf der anderen Seite dienen. In Bezug auf das Daily Scrum sollten also nur die Pigs
reden, während die Chicken höchstens als Beobachter anwesend sein sollten.
Ich habe festgestellt, dass es am besten ist, wenn man die Mitglieder des Scrum-Teams als
Pigs betrachtet, und alle, die nicht zum Team gehören, als Chicken. Das sehen aber nicht
alle so. So ist es z.B. für den Product Owner nicht erforderlich, am Daily Scrum teilzuneh-
men, so dass manche ihn als Chicken ansehen. (Die Logik dahinter lautet: Wie kann man
»beteiligt« sein, wenn man nicht teilnehmen muss?) Das scheint mir falsch zu sein, weil
ich mir nicht vorstellen kann, wie der Product Owner als Mitglied des Scrum-Teams weni-
ger am Ergebnis beteiligt sein kann als das Entwicklungsteam. Die Metapher der Pigs und
Chicken hält nicht stand, wenn Sie versuchen, sie innerhalb eines Scrum-Teams anzuwen-
den.
58
2.3
Scrum-Aktivitäten und Artefakte
legt den Grad der Überzeugung des Teams fest, dass die abgeschlossene Arbeit von guter
Qualität und potenziell für die Auslieferung bereit ist. Beim Entwickeln von Software z.B.
sollte eine minimale Definition von »Fertig« ein komplettes Stück Produktfunktionalität
umfassen, das entworfen, entwickelt, integriert, getestet und dokumentiert wurde.
Sprint-Ausführung
Potenziell
auslieferungsfähiges
Produktinkrement
Sprint Review
Eine aggressive Definition von Fertig erlaubt es der Organisation, bei jedem Sprint zu ent-
scheiden, ob das, was hergestellt wurde, an interne oder externe Kunden ausgeliefert (oder
ausgebracht oder freigegeben) werden kann.
Noch einmal: »Potenziell auslieferungsfähig« bedeutet nicht, dass auch tatsächlich etwas
ausgeliefert werden muss. Die Auslieferung ist eine geschäftliche Entscheidung, die oft von
Dingen beeinflusst wird wie »Haben wir genügend Funktionen oder genügend Kunden-
Workflow, um eine Übergabe an den Kunden zu rechtfertigen?« oder »Können unsere Kun-
den eine weitere Änderung verkraften, zumal wir ihnen erst vor zwei Wochen eine Version
übergeben haben?«
Stellen Sie sich unter der Formulierung »potenziell auslieferungsfähig« lieber als einen
Zuversichtsstatus vor: Das, was in dem Sprint hergestellt wurde, ist tatsächlich fertig. Mit
anderen Worten: Es sind keine grundlegend wichtigen Arbeiten unerledigt geblieben (wie
etwa wichtige Tests oder die Integration), die abgeschlossen werden müssten, bevor wir die
Ergebnisse des Sprints ausliefern können, falls wir das wollten.
Aus praktischen Erwägungen ändern Teams manchmal im Laufe der Zeit die Definition
von Fertig. So ist es möglicherweise in den frühen Stadien der Spieleentwicklung wirt-
schaftlich nicht praktikabel oder wünschenswert, Funktionen zu implementieren, die
potenziell auslieferungsfähig sind (wenn man die erforschende Natur der frühen Spieleent-
59
Kapitel 2
Das Scrum-Framework
wicklung bedenkt). In diesen Situationen könnte eine angemessene Definition von Fertig
sein, dass man ein Stück der Produktfunktionalität hat, das ausreichend funktioniert und
so einsetzbar ist, dass das Team Feedback erhalten kann, um zu entscheiden, welche Arbei-
ten als Nächstes durchgeführt werden könnten. In Kapitel 4 erfahren Sie mehr über die
Definition von Fertig.
Potenziell
auslieferungsfähiges
Produktinkrement
Sprint Review
Sprint-Retrospektive
Das Ziel dieser Aktivität besteht darin, das Produkt, das gebaut wird, zu überprüfen und
anzupassen. Wichtig ist hierbei der Austausch, der zwischen den Teilnehmern stattfindet.
Dazu gehören das Scrum-Team, die Stakeholder, die Sponsoren, die Kunden sowie interes-
sierte Mitglieder anderer Teams. Die Gespräche konzentrieren sich auf das erneute
Überprüfen der gerade fertiggestellten Funktionen im Kontext der gesamten Entwicklungs-
arbeit. Alle Anwesenden erhalten einen klaren Überblick über das, was passiert, und haben
die Möglichkeit, die weitere Entwicklung zu beeinflussen, um dafür zu sorgen, dass die
beste Lösung gefunden werden kann.
Ein erfolgreicher Review ergibt einen Informationsfluss, der in zwei Richtungen verläuft.
Die Leute, die nicht im Scrum-Team sind, werden über die Entwicklungsarbeit auf den
neuesten Stand gebracht und helfen dabei, deren Richtung zu bestimmen. Gleichzeitig
erlangen die Mitglieder des Scrum-Teams durch die häufigen Feedbacks hinsichtlich der
»Annäherung« des Produkts an Kunden oder Benutzer ein tieferes Verständnis für die
Geschäfts- und Marketingseite ihres Produkts. Der Sprint Review stellt daher eine planmä-
ßige Gelegenheit dar, das Produkt zu überprüfen und anzupassen. Leute, die nicht im
Scrum-Team sind, können Kritik an den Funktionen in dem Sprint üben und ihre Meinung
äußern, um dem Scrum-Team zu helfen, sein Sprint-Ziel besser zu erreichen. Mehr zum
Sprint Review erfahren Sie in Kapitel 21.
60
2.4
Abschließende Bemerkungen
2.3.8 Sprint-Retrospektive
Die zweite Aktivität am Ende des Sprints zum Überprüfen und Anpassen ist die Sprint-
Retrospektive (siehe Abbildung 2.14). Sie erfolgt häufig erst nach dem Sprint Review und
vor der nächsten Sprint-Planung.
Sprint Review
Sprint-Retrospektive
Abb. 2.14: Sprint-Retrospektive
Während der Sprint Review Gelegenheit zum Überprüfen und Anpassen des Produkts bie-
tet, ist die Sprint-Retrospektive eine Gelegenheit, um den Prozess zu untersuchen und zu
adaptieren. Das Entwicklungsteam, der ScrumMaster und der Product Owner setzen sich
zusammen und diskutieren, was mit Scrum und den damit verbundenen technischen
Praktiken funktioniert hat und was nicht. Der Fokus liegt dabei auf der stetigen Verbesse-
rung des Prozesses, die notwendig ist, damit aus einem guten ein wirklich großartiges
Scrum-Team wird. Am Ende einer Sprint-Retrospektive sollte das Scrum-Team eine kon-
krete Anzahl von Aktionen zur Prozessverbesserung identifiziert haben, die vom Scrum-
Team im nächsten Sprint durchgeführt werden. Mehr dazu erfahren Sie in Kapitel 22.
Nachdem die Sprint-Retrospektive abgeschlossen ist, fängt der gesamte Zyklus wieder von
vorn an – beginnend mit der nächsten Sitzung zur Sprint-Planung, in der die aktuell als am
wertvollsten eingeschätzten Arbeiten ermittelt werden, auf die sich das Team jetzt konzen-
trieren wird.
61
Kapitel 3
Agile Prinzipien
Bevor wir tiefer in die Mechanismen von Scrum eintauchen, sollten wir uns zunächst ein-
mal mit den zugrundeliegenden Prinzipien vertraut machen, die diese Mechanismen
antreiben und auszeichnen.
Auf den nachfolgenden Seiten werden daher die agilen Prinzipien erläutert, auf denen
Scrum basiert, und einem Vergleich mit den Grundlagen der traditionellen, plangesteuer-
ten, sequenziellen Produktentwicklung unterzogen. Dieses Kapitel zeigt auf, wie sich
Scrum von den traditionelleren Formen der Produktentwicklung unterscheidet und bietet
Ihnen somit eine solide Wissensbasis für die in den nachfolgenden Kapiteln beschriebene
ausführlichere Analyse der Scrum-Praktiken.
3.1 Überblick
Ich halte es für sehr aufschlussreich, die Scrum zugrundeliegenden Prinzipien anhand
eines Vergleichs mit den Grundsätzen der traditionellen, plangesteuerten, sequenziellen
Entwicklung vorzustellen – denn dadurch sollte Ihnen das Verständnis dessen, inwiefern
Scrum der Ihnen bereits bekannten Vorgehensweise ähnelt bzw. sich davon unterscheidet,
leichter fallen.
Diese Gegenüberstellung der agilen und der traditionellen Entwicklungsprinzipien soll
jedoch nicht etwa demonstrieren, dass die plangesteuerte, sequenzielle Entwicklung
schlecht und Scrum gut ist. Im Gegenteil: Beides sind wertvolle Werkzeuge im Repertoire
eines jeden professionellen Entwicklers. Es gibt keine schlechten Werkzeuge, sondern nur
unpassende Gelegenheiten, diese Werkzeuge einzusetzen. Und wie ich im Zusammen-
hang mit dem Cynefin-Framework in Kapitel 2 schon kurz erklärt habe, sind sowohl Scrum
als auch die traditionelle, plangesteuerte, sequenzielle Entwicklung jeweils für unterschied-
liche Klassen von Problemen hervorragend geeignet.
Zum Vergleichen dieser beiden Ansätze greife ich auf die reine, quasi lehrbuchmäßige
Beschreibung der plangesteuerten, sequenziellen Entwicklung zurück. Aus dieser Perspek-
tive betrachtet, lassen sich die Prinzipien, die der Scrum-basierten Entwicklung zugrunde
liegen sowie deren Unterschiede zu der traditionellen Entwicklung einfach besser und
deutlicher darstellen. Eine reine Form der traditionellen, plangesteuerten Entwicklung wird
häufig als Wasserfall-Modell bezeichnet (siehe Abbildung 3.1). Diese Entwicklungsvariante
stellt jedoch nur eins von vielen Beispielen einer breiteren Klasse von plangesteuerten Pro-
zessen dar (die auch als traditionelle, sequenzielle, vorausschauende, prädiktive oder vor-
schreibende Entwicklungsprozesse bekannt sind).
Plangesteuerte Prozesse verdanken ihre Bezeichnung der Tatsache, dass hier versucht
wird, alle Funktionen, die sich der Benutzer für das Endprodukt möglicherweise wünschen
63
Kapitel 3
Agile Prinzipien
könnte, vorauszuplanen und festzustellen, wie man diese Funktionen am besten realisiert.
Die Idee dahinter ist, dass eine bessere Planung das Verständnis und damit auch die
Durchführung der Entwicklung des betreffenden Produkts begünstigt. Derartige Prozesse
werden oft auch als sequenzielle Prozesse bezeichnet, weil die Anwender nacheinander
eine komplette Anforderungsanalyse durchführen, dann einen kompletten Designentwurf
erstellen, dem wiederum die Programmierung und schließlich die Tests folgen.
• Auslieferung/Meilenstein
• Review/Genehmigung
Analyse
Design
Programmierung
Tests
Betrieb
Die plangesteuerte Entwicklung funktioniert prima, wenn Sie sie auf wohldefinierte und
vorhersehbare Probleme anwenden, die sich mit hoher Wahrscheinlichkeit nicht mehr gra-
vierend ändern. Leider sind die meisten in der Produktentwicklung anfallenden Arbeiten
jedoch alles andere als vorhersehbar, speziell am Anfang. Während Ihnen ein plangesteuer-
ter Prozess also den Eindruck eines geregelten, erklärbaren und messbaren Vorgehens ver-
mittelt, kann dieser Eindruck durchaus zu einem falschen Gefühl der Sicherheit führen –
denn letzten Endes verläuft das Entwickeln eines Produkts nur selten wie geplant.
Grundsätzlich erscheint ein plangesteuerter, sequenzieller Prozess sinnvoll – Verstehen,
Entwerfen, Programmieren, Testen, Ausliefern, und das alles nach einem schön definier-
ten, vorher festgelegten Plan. Viele sind daher der Auffassung, dass das in jedem Fall funk-
tionieren müsste. Und wenn ein plangesteuertes Vorgehen dann doch nicht funktioniert,
wird häufig davon ausgegangen, dass irgendetwas schiefgelaufen sein muss: Selbst wenn
ein Prozess wiederholt enttäuschende Ergebnisse liefert, halten viele Organisationen den-
noch daran fest, weil sie sicher sind, dass die Ergebnisse sich schon irgendwann verbessern
werden. Das Problem liegt jedoch nicht in der Ausführung, sondern darin, dass plangesteu-
erte Ansätze auf Überzeugungen beruhen, die nicht mit der Unsicherheit konform gehen,
die den meisten Produktentwicklungsarbeiten innewohnen.
Scrum basiert dagegen auf anderen Überzeugungen – die sich gut auf Probleme abbilden
lassen, die so unsicher sind, dass sich nicht viel vorhersagen lässt. Die Prinzipien, die ich in
64
3.1
Überblick
diesem Kapitel beschreiben werde, entstammen einer ganzen Reihe von Quellen, darunter
dem »Agilen Manifest« (Beck et al. 2001), der »Schlanken Produktentwicklung« (Reinertsten
2009b; Poppendieck und Poppendieck 2003) sowie »The Scrum Guide« (Schwaber und
Sutherland 2011).
Diese Prinzipien sind in mehrere Kategorien aufgeteilt, die in Abbildung 3.2 dargestellt
sind.
Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann
Vorhersage und
Einen adaptiven, untersuchenden Ansatz bevorzugen
Anpassung
Prinzipien
Organisieren des Arbeitsablaufs für schnelle Rückmeldungen
Verzögerungskosten betrachten
65
Kapitel 3
Agile Prinzipien
Ich beginne an dieser Stelle mit den Prinzipien, die sich die Veränderlichkeit und Unsi-
cherheit zunutze machen, die der Produktentwicklung zu eigen sind. Anschließend folgt
eine Diskussion der Prinzipien, bei denen es um die Balance zwischen einer im Vorfeld
getroffenen Vorhersage und einer situationsbezogenen Anpassung geht. Danach erläutere
ich dann die Prinzipien, die sich auf das Lernen konzentrieren, gefolgt von den Prinzipien
für die Organisation laufender Arbeitsprozesse. Und zum Schluss gehe ich schließlich
auch auf die Prinzipien ein, die sich auf Fortschritt und Leistung beziehen.
Bei der Entwicklung besteht das Ziel hingegen darin, eine einzige, einmalige Instanz des
Produkts herzustellen, und nicht, das Produkt an sich zu fertigen. Diese eine Instanz kann
man analog zu einer einzigartigen Rezeptur sehen: Es liegt uns fern, ein und dieselbe
Rezeptur ein weiteres Mal zusammenzustellen – denn das wäre reine Geldverschwendung.
Vielmehr wollen wir eine einzigartige Rezeptur für ein neues Produkt entwerfen. Und um
jedes Mal ein anderes Produkt zu erhalten, ist natürlich eine gewisse Veränderlichkeit
erforderlich. Um genau zu sein, unterscheidet sich jede Funktion, die wir in das Produkt
einbauen, von jeder anderen Funktion innerhalb dieses Produkts, so dass wir die Veränder-
lichkeit auf dieser Ebene sogar brauchen. Und erst wenn wir die Rezeptur haben, fertigen
wir das Produkt an – im Fall von Software-Produkten bedeutet das einfach, dass wir die Bits
kopieren.
66
3.2
Veränderlichkeit und Unsicherheit
Andererseits lassen sich einige Konzepte der Fertigung auch auf die Produktentwicklung
anwenden und sollten dementsprechend ausgenutzt werden. Wie ich z.B. in Kürze noch
ausführen werde, ist das Erfassen und Organisieren der Bestände (bzw. der laufenden
Arbeiten) – ein wichtiger Faktor für die Fertigung – auch in der Produktentwicklung uner-
lässlich. Rein vom Wesen der anfallenden Arbeiten her sind die Produktentwicklung und
die Produktherstellung jedoch ganz und gar nicht gleich und erfordern deshalb ganz unter-
schiedliche Prozesse.
67
Kapitel 3
Agile Prinzipien
Die inkrementelle Entwicklung liefert uns wichtige Informationen, die es uns erlauben,
unsere Entwicklungsarbeit im weiteren Fortgang der Arbeit anzupassen und zu ändern.
Andererseits besteht ihr größter Nachteil darin, dass wir möglicherweise das Komplettbild
aus den Augen verlieren, während wir die kleineren Einzelteile bauen. (»Wir sehen den
Wald vor lauter Bäumen nicht mehr.«)
Scrum nutzt die Vorteile sowohl der iterativen als auch der inkrementellen Entwicklung
aus und negiert dabei die Nachteile, die sich ergäben, würde man diese Verfahren einzeln
benutzen. Dies wird dadurch erreicht, dass beide Ansätze in einer adaptiven Reihe zeit-
lich begrenzter Iterationen eingesetzt werden, die man als Sprints bezeichnet (siehe
Abbildung 3.4).
Während jedes Sprints führen wir alle Aktivitäten durch, die notwendig sind, um ein funk-
tionierendes Produktinkrement herzustellen (also einen Teil des Produkts, nicht das
gesamte Produkt). Dies ist in Abbildung 3.4 dargestellt: In jedem Sprint wird ein Teil der
Analyse-, Design-, Aufbau-, Integrations- und Testarbeit abgeschlossen. Dieser Ansatz des
»alles-auf-einmal« hat den Vorteil, dass die Annahmen, die beim Entwickeln der Funktio-
nen des Produkts getroffen wurden, schnell validiert werden können. So treffen wir z.B.
einige Designentscheidungen, stellen ein wenig Code her, der auf diesen Entscheidungen
beruht, und testen dann das Design und den Code – alles im selben Sprint. Indem wir die
gesamte zusammenhängende Arbeit in einem Sprint erledigen, können wir Funktionen
schnell überarbeiten und ziehen so einen Vorteil aus der iterativen Entwicklung, ohne dass
wir extra weitere Iterationen einplanen müssen.
Ein Missbrauch des Sprint-Konzepts wäre es, wenn man jeden Sprint nur auf eine Art von
Arbeit konzentriert – z.B. Sprint 1 (Analyse), Sprint 2 (Design), Sprint 3 (Kodierung) und
Sprint 4 (Test). Ein solches Vorgehen versucht, Scrum eine wasserfallartige Teilstruktur
überzustülpen. Ich bezeichne diesen fehlgeleiteten Versuch als WaterScrum, habe aber
auch schon den Begriff Scrummerfall gehört.
In Scrum arbeiten wir nicht eine Phase nach der anderen ab, sondern eine Funktion nach
der anderen. Am Ende eines Sprints haben wir also ein wertvolles Produktinkrement her-
gestellt (sprich einige, aber nicht alle Funktionen des Produkts). Dieses Inkrement enthält
zuvor entwickelte Funktionen oder ist in diese integriert und wurde mit ihnen getestet. Ist
dies nicht geschehen, kann das betreffende Produktinkrement nicht als Fertig (Done)
betrachtet werden. So enthält z.B. Inkrement 2 in Abbildung 3.4 die Funktionen von Inkre-
68
3.2
Veränderlichkeit und Unsicherheit
ment 1. Am Ende des Sprints können wir ein Feedback zu den neu fertiggestellten Funk-
tionen im Kontext der bereits abgeschlossenen Funktionen erhalten. Das hilft uns dabei,
das Produkt aus einer umfassenderen Perspektive zu betrachten, als es ansonsten möglich
wäre.
Wir erhalten also Feedbacks zu den Sprint-Ergebnissen, was es uns erlaubt, uns anzupas-
sen. So können wir für die Arbeit im nächsten Sprint eine andere Gruppe von Funktionen
wählen oder den bislang eingesetzten Prozessablauf ändern, um die nächsten Funktionen
zu erstellen. Manchmal stellt sich auch heraus, dass das Inkrement nicht so gut ist, wie es
sein könnte, obwohl es technisch gesehen alle Anforderungen erfüllt. In diesem Fall kön-
nen wir für einen künftigen Sprint eine Überarbeitung einplanen – schließlich haben wir
uns einer iterativen Entwicklung und kontinuierlichen Verbesserung der Funktionen ver-
schrieben. Auf diese Weise lösen wir das Problem, dass wir nicht im Voraus wussten, wie
viele Verbesserungsläufe wir benötigen würden. Scrum verlangt nicht von uns, vorher eine
bestimmte Anzahl von Iterationen festzulegen, vielmehr führen uns die kontinuierlichen
Feedbacks zu einer angemessenen und ökonomisch sinnvollen Anzahl von Iterationen,
während wir das Produkt inkrementell entwickeln.
69
Kapitel 3
Agile Prinzipien
Prozess-
Anpassung überprüfung Feedback
Anpassung
Erste Fertiges
Eingabe Scrum Ergebnis
Eingabe Ergebnis
Anpassung
Anpassung Feedback
Produkt-
überprüfung
70
3.3
Vorhersage und Anpassung
Dieser vereinfachende, lineare Ansatz zum Abbau der Unsicherheit eignet sich nur bedingt
für die komplexe Domäne der Produktentwicklung, bei der sich unsere Aktionen und die
Umgebung, in der wir arbeiten, gegenseitig hemmen. Zum Beispiel:
쐽 Wir beschließen, eine Funktion zu bauen (unsere Aktion).
쐽 Wir zeigen diese Funktion anschließend einem Kunden, der daraufhin seine Meinung
hinsichtlich dessen, was er eigentlich haben möchte, ändert oder merkt, dass er die Ein-
zelheiten der Funktion nicht richtig vermittelt hat (unsere Aktion löst eine Reaktion sei-
tens der Umgebung aus).
쐽 Wir nehmen aufgrund der Feedbacks Designänderungen vor (die Reaktion seitens der
Umgebung veranlasst uns, eine weitere unvorhergesehene Aktion vorzunehmen).
In Scrum behindern wir uns nicht selbst, indem wir uns erst einmal ausgiebig um eine ein-
zige Unsicherheitskategorie kümmern, bevor es dann an die nächste geht. Stattdessen
verfolgen wir einen eher holistischen Ansatz und konzentrieren uns darauf, alle Unsicher-
heiten gleichzeitig zu verringern (Ende, Methoden, Kunden usw.). Natürlich können wir
uns dennoch jederzeit stärker auf eine Kategorie konzentrieren als auf eine andere. Das
gleichzeitige Behandeln mehrerer Unsicherheitskategorien wird durch die iterative und
inkrementelle Entwicklung unterstützt und durch die ständige Inspektion, Anpassung und
Transparenz angeleitet. Solch ein Vorgehen erlaubt es uns, unsere Umgebung ganz nach
unseren Wünschen und Vorstellungen zu testen und zu erkunden sowie mehr über die
unbekannten Unbekannten (Dinge, von denen wir noch gar nicht wissen, dass wir sie nicht
kennen) zu lernen, die dabei in Erscheinung treten.
71
Kapitel 3
Agile Prinzipien
Prinzip wird oft als Last Responsible Moment (LRM; letzter verantwortbarer Augenblick)
bezeichnet (Poppendieck und Poppendieck 2003). Das bedeutet, dass wir die Festlegung
oder Verpflichtung verzögern und wichtige sowie irreversible Entscheidungen erst im letz-
ten Augenblick treffen, den wir verantworten können. Und wann ist das? Wenn die Kosten,
die Entscheidung nicht zu treffen, höher werden als die Kosten für die Entscheidung (siehe
Abbildung 3.6). In diesem Augenblick entscheiden wir uns.
ögerung
Verz
Letzter (wirtschaftlich)
verantwortbarer Augenblick
Kosten
der
n
ste
Ko
K o st
en für
Entscheidung
Zeit
Um sich dieses Prinzips bewusst zu werden, denken Sie einmal über Folgendes nach: Am
ersten Tag einer Produktentwicklung verfügen wir über die wenigsten Informationen hin-
sichtlich dessen, was wir tun. An jedem nachfolgenden Entwicklungstag lernen wir ein
bisschen mehr. Warum sollten wir uns also jemals dazu entschließen, die wichtigsten und
möglicherweise nicht wieder rückgängig zu machenden Entscheidungen schon am ersten
Tag oder zumindest sehr frühzeitig zu treffen? Die meisten von uns würden es vorziehen
zu warten, bis wir mehr Informationen haben, damit wir eine qualifiziertere Entscheidung
treffen können. Wenn wir uns bei wichtigen und unwiderruflichen Entscheidungen zu
früh festlegen und uns irren, landen wir schnell auf dem exponentiell ansteigenden Teil der
Kostenkurve aus Abbildung 3.6. Gewinnen wir hingegen ein besseres Verständnis hinsicht-
lich der Entscheidung, sinken die Kosten (und die Wahrscheinlichkeit, eine schlechte Ent-
scheidung zu treffen, sinkt dabei ebenfalls, weil unsere Sicherheit in Bezug auf den Markt
oder die Technik zunimmt). Deshalb sollten wir warten, bis wir bessere Informationen
haben, bevor wir uns zu einer Entscheidung durchringen.
72
3.3
Vorhersage und Anpassung
müssen wir die Grundforderungen und Pläne so korrigieren, dass sie der aktuellen Realität
entsprechen (mehr dazu in Kapitel 5).
In Scrum erkennen wir an, dass wir nicht alle Anforderungen oder Pläne gleich von
Anfang an fehlerfrei berücksichtigen können. Wir sind sogar der Meinung, dass es gefähr-
lich sein könnte, dies zu versuchen, da uns mit Sicherheit wichtige Erkenntnisse fehlt, was
wiederum dazu führt, dass wir viele qualitativ schlechte Anforderungen stellen (siehe
Abbildung 3.7).
Die nachstehende Grafik zeigt, dass bei einem plangesteuerten, sequenziellen Prozess
bereits sehr früh eine große Anzahl von Anforderungen gestellt wird – also zu einem Zeit-
punkt, zu dem wir am wenigsten über das Produkt wissen. Solch ein Vorgehen ist riskant,
weil wir uns der Illusion hingeben, dass wir die End-Unsicherheit eliminiert haben. Und
das führt potenziell zu einer Verschwendung von Zeit und Geld, sobald wir weitere
Erkenntnisse gewinnen oder sich Dinge ändern (wie ich in Kürze beschreiben werde).
Gefahrenzone! Da sind
viele Anforderungen
schlechter Qualität,
obwohl wir noch
nicht genug wissen Menge der Anforderungen,
die zu jedem
Zeitpunkt produziert
werden
Gesammeltes
Wissen
Unser gesammeltes
Produktwissen
wächst mit der Zeit
Phase
Dennoch stellen wir auch beim Einsatz von Scrum im Voraus Anforderungen und entwi-
ckeln Pläne – allerdings nur so viele wie nötig und unter der Voraussetzung, dass wir die
Details dieser Anforderungen und Pläne später ergänzen, wenn wir mehr über das Produkt
gelernt haben, das wir bauen wollen. Denn selbst wenn wir glauben, dass wir zu 100% wis-
sen, was wir erreichen wollen und wie wir das organisieren können, werden wir feststellen,
dass wir uns irren, sobald wir unsere frühen inkrementellen Lieferungen der Umgebung
aussetzen, in der sie später funktionieren sollen. Zu diesem Zeitpunkt werden alle unbe-
quemen Realitäten dessen, was wirklich gebraucht wird, uns dazu bringen, Änderungen
vorzunehmen.
73
Kapitel 3
Agile Prinzipien
untersuchenden Ansatz
Bevorzugt einen
prädiktiven Ansatz, bei
dem man versucht,
alles von Vornherein
richtig zu machen
So habe ich z.B. in meinem ersten Studienjahr an der Georgia Tech (Anfang der 1980er
Jahre) kurzzeitig Lochkarten benutzt – ein Werkzeug, bei dem es, genau wie bei einer
Schreibmaschine, absolut schrecklich war, wenn man Fehler machte oder etwas ändern
musste. Es war schwierig, sich mit dem Konzept des »Lasst uns das schnell mal ausprobie-
ren und schauen, was passiert« anzufreunden, wenn man für jede potenzielle Lösung
gewissenhaft Lochkarten stanzen, sich in die Schlange am Großrechner einreihen und bis
zu 24 Stunden warten musste, bis die Lösung verarbeitet wurde. Selbst ein einfacher Tipp-
fehler kostete einen wenigstens einen ganzen Tag. Ein wasserfallartiger Prozess, der eine
sorgfältige Abwägung des aktuellen Wissens und angesichts der Unsicherheit eine Vorher-
sage zuließ, damit man eine gute Lösung entwickelte, war in diesem Fall ökonomisch sinn-
voll.
Zum Glück sind die Werkzeuge und Technologien inzwischen besser geworden und die
Kosten für Erkundungen sind stark gesunken. Es ist nicht länger eine wirtschaftliche Kata-
74
3.3
Vorhersage und Anpassung
strophe, wenn man Erkundungen anstellt. Heute ist es oft sogar billiger, wenn man die
benutzerseitigen Feedbacks zu etwas, das man schnell gebaut hat, berücksichtigt, als
bereits im Voraus alles richtig zu machen. Schließlich wird auch der Kontext (die umgeben-
den Technologien), in dem unsere Lösungen überleben müssen, immer komplexer.
Falls wir in Scrum genügend Wissen angehäuft haben, um mit unserer Lösung einen qua-
lifizierten, vernünftigen Schritt nach vorn wagen zu können, kommen wir voran. Sehen wir
uns jedoch einer Unsicherheit gegenüber, dann versuchen wir nicht, sie mittels Vorhersa-
gen verschwinden zu lassen, sondern beschaffen uns die relevanten Informationen durch
Erkundungen, deren Ergebnisse uns dann auf dem Weg zu unserer Lösung voranbringen.
Die Feedbacks zu unserer Aktion helfen uns dabei festzulegen, ob und wann wir weiter
erkunden müssen.
Abb. 3.9: Bei der sequenziellen Entwicklung sind die Kosten für späte Änderungen ganz
beträchtlich.
So könnte z.B. eine Änderung während der Analyse 1 Dollar kosten – und die gleiche Ände-
rung während der (späten) Testphase könnte 1.000 Dollar kosten. Aber warum ist das so?
Wenn wir während der Analyse einen Fehler machen und ihn auch während der Analyse
finden, dann ist es nicht teuer, ihn zu beheben. Wird dieser Fehler dagegen erst beim
Design gefunden, dann müssen wir nicht nur die fehlerhafte Anforderung korrigieren,
sondern möglicherweise auch Teile unseres Designs, die auf dieser fehlerhaften Anforde-
rung beruhen. Denn dieser Fehler setzt sich durch jede nachfolgende Phase fort und so
wird aus einem vielleicht kleinen Mangel während der korrekten Analyse zu einem riesigen
Problem, das dann beim Test oder im Betrieb korrigiert werden muss.
Um späte Änderungen zu vermeiden, versuchen sequenzielle Prozesse, sich ändernde
Anforderungen oder Designs entweder sorgfältig zu kontrollieren oder auf ein Minimum
75
Kapitel 3
Agile Prinzipien
zu reduzieren, indem sie die Genauigkeit der Vorhersagen über das System oder den Pro-
zess verbessern.
Leider hat es oft den entgegengesetzten Effekt, wenn man in den Phasen der frühen Aktivi-
tät übermäßig prophetisch ist: Zum einen schafft man es nicht, Änderungen zu eliminie-
ren, zum anderen kann es passieren, dass zu spät ausgeliefert wird oder die Kosten
explodieren. Doch wie kommt es zu dieser paradoxen Wahrheit? Erstens zwingt uns der
Wunsch, teure Änderungen zu eliminieren, dazu, es in jeder Phase zu übertreiben – wir
verrichten mehr Arbeit, als notwendig und praktisch wäre. Und zweitens sind wir gezwun-
gen, frühzeitig im Prozess Entscheidungen zu treffen, die auf wichtigen Annahmen beru-
hen – bevor wir diese Annahmen durch Feedbacks von unseren Stakeholdern bestätigt
haben. In der Folge fertigen wir eine große Menge von Produkten an, die auf diesen
Annahmen beruhen. Und später müssen wir diese Ansammlung an Produkten dann mit
hoher Wahrscheinlichkeit korrigieren oder verwerfen, wenn wir unsere Annahmen bestäti-
gen (oder sie sich als ungültig herausstellen) oder eine Änderung auftritt (weil z.B. Anfor-
derungen auftauchen oder sich weiterentwickeln). Dies entspricht dem klassischen Muster
einer sich selbst erfüllenden Prophezeiung (siehe Abbildung 3.10).
1
Wir glauben, späte
Änderungen sind
sehr teuer
Änderungskosten bei
sequenzieller Entwicklung
Kosten der Änderung
4 2
Bei Änderungen müssen
Wir fürchten Kosten für
viele Produkte ent-
späte Änderungen, weshalb
sprechend angepasst oder
wir vorher länger und
verworfen werden, was
schwerer arbeiten, um
hohe Kosten verursacht
Änderungen zu vermeiden
3
Was dafür sorgt, dass
wir vorzeitig viele
Produkte herstellen,
wie Spezifikationen
und Designs
In Scrum setzen wir einfach voraus, dass Änderungen normal sind. Wir glauben, dass wir
die der Produktentwicklung innewohnende Unsicherheit nicht einfach durch Vorhersagen
ausräumen können, indem wir im Vorfeld länger und schwerer arbeiten. Deshalb müssen
76
3.3
Vorhersage und Anpassung
wir uns darauf einstellen, dass Änderungen eintreten. Und wenn diese Änderung auftritt,
wollen wir, dass dies wirtschaftlich gesehen günstiger ist als bei der traditionellen Entwick-
lung, selbst wenn die Änderung später erfolgt.
Unser Ziel besteht deshalb darin, die Kostenkurve so lange wie möglich flach zu halten
– damit es ökonomisch sinnvoll ist, auch spät noch Änderungen vorzunehmen. Abbil-
dung 3.11 verdeutlicht diese Idee.
Wir können dieses Ziel erreichen, indem wir die Menge der Arbeit in diesem Prozess
und den Fluss dieser Arbeit so organisieren, dass die Kosten für eine Änderung beim
Einsatz von Scrum weniger durch den Zeitfaktor beeinflusst werden als bei sequenziel-
len Projekten.
Kosten der Änderung
Scrum
Traditionell
Zeit
Unabhängig davon, welchen Ansatz zur Produktentwicklung wir verfolgen, soll folgende
Beziehung gelten: Eine kleine Änderung der Anforderungen soll eine ebenso kleine Ände-
rung bei der Implementierung und damit bei den Kosten ergeben (eine größere Änderung
würde natürlich entsprechend mehr kosten). Eine weitere wünschenswerte Eigenschaft
dieser Beziehung ist, dass sie unabhängig vom Zeitpunkt des Änderungswunsches gelten
soll.
Mit Scrum fertigen wir viele Arbeitsprodukte (wie etwa ausführliche Anforderungen,
Designs und Testfälle) zum Zeitpunkt des Bedarfs (just in time) an, womit wir die Herstel-
lung potenziell unnötiger Artefakte vermeiden. Wenn dann eine Änderung auftritt, müs-
sen üblicherweise weniger Artefakte oder Entscheidungen verworfen oder überarbeitet
werden, was die Kosten proportional zur angeforderten Änderung hält.
Bei einer sequenziellen Entwicklung führt die frühe Herstellung von Artefakten und der
Zwang, vorzeitig zu endgültigen Entscheidungen zu kommen, dazu, dass die Kosten für
Änderungen mit zunehmender Produktmenge rapide ansteigen. Der Wendepunkt auf der
traditionellen Kurve in Abbildung 3.11, also die Stelle, an der die Linie stark nach oben
ansteigt, tritt hier sehr früh auf. Bei der Entwicklung mit Scrum kommt ebenfalls unwei-
gerlich der Moment, ab dem die Kosten für eine Änderung nicht mehr proportional zur
77
Kapitel 3
Agile Prinzipien
Größe der Änderungsanfrage sind, allerdings tritt dieser Zeitpunkt (wie der Wendepunkt
auf der Scrum-Kurve in Abbildung 3.11 verdeutlicht) später ein.
Prädik
tiv
(vorab
)
Ad
(bedar aptiv
fsgere
cht)
Raten Chaos
Mit Scrum erkennen wir an, dass es nicht möglich ist, bereits im Voraus exakt alle Anforde-
rungen und Pläne zu kennen. Aber bedeutet das, dass wir im Vorhinein überhaupt keine
Anforderungen aufstellen oder Pläne schmieden sollten? Natürlich nicht! Bei Scrum geht
es darum, eine Balance zu finden – wägen Sie die prädiktive, im Voraus erfolgende Arbeit
gegen die adaptive, bedarfsgerechte Arbeit ab (siehe Abbildung 3.13, nach einem Bild von
Cohn 2009).
Wenn ein Produkt entwickelt wird, sollte der Ausgleichspunkt auf wirtschaftlich sinnvolle
Weise gesetzt werden, um die Anzahl der laufenden Anpassungen, die auf den schnellen
Feedbacks beruht, zu maximieren und die Anzahl der im Vorfeld stattfindenden Vorhersa-
gen zu minimieren, während vereinbarte, regulatorische und/oder unternehmerische
Randbedingungen erfüllt werden.
Wie genau dieser Ausgleich geschaffen wird, hängt teils vom Produkt ab, teils vom Grad
der Unsicherheit sowohl in dem, was wir bauen wollen (End-Unsicherheit), als auch in
dem, wie wir es bauen wollen (Methoden-Unsicherheit), und teils von den Beschränkun-
gen, denen die Entwicklung unterliegt. Wären wir übermäßig prophetisch veranlagt, müss-
ten wir angesichts einer großen Unsicherheit viele Annahmen treffen. Wären wir dagegen
78
3.4
Validiertes Wissen
übermäßig adaptiv, würden wir in einem Zustand ständiger Änderungen leben, wodurch
sich unsere Arbeit ineffektiv und chaotisch anfühlen würde. Um schnell innovative Pro-
dukte zu entwickeln, müssen wir in einem Raum agieren, in dem Anpassungsfähigkeit
durch gerade genügend Vorhersage ausgeglichen wird, um das Abgleiten ins Chaos zu ver-
hindern. Das Scrum-Framework arbeitet an diesem Ausgleichspunkt zwischen Ordnung
und Chaos ausgesprochen gut.
79
Kapitel 3
Agile Prinzipien
In Scrum verstehen wir, dass ständiges Lernen der Schlüssel zum Erfolg ist. Wenn wir
Scrum einsetzen, erkennen und nutzen wir Feedback-Schleifen, um das Gelernte zu ver-
stärken. Ein wiederkehrendes Muster bei dieser Art von Produktentwicklung ist, eine
Annahme zu treffen (oder ein Ziel zu setzen), etwas zu bauen (einige Aktivitäten auszufüh-
ren), ein Feedback zu dem zu erhalten, was wir gebaut haben, und dieses dann zu nutzen,
um das, was wir gebaut haben, und unsere Annahme zu überprüfen. Anschließend neh-
men wir anhand dessen, was wir bei dieser Überprüfung gelernt haben, Anpassungen am
Produkt, Prozess und/oder unseren Vorstellungen vor (siehe Abbildung 3.13).
Scrum nutzt mehrere vordefinierte Lernschleifen aus. So ist z.B. der Daily Scrum eine täg-
liche Schleife und der Sprint-Review eine Schleife auf Iterationsebene. Diese und andere
Schleifen werde ich in späteren Kapiteln genauer beschreiben.
Annehmen
Anpassen Bauen
Überprüfen Feedback
Das Scrum-Framework ist flexibel genug für viele weitere Lernschleifen. So werden bei der
Scrum-Entwicklung, obwohl dies nicht spezifisch vorgegeben ist, oft z.B. auch Feedback-
Schleifen für technische Praktiken verwendet, wie etwa die Paarprogrammierung (sekun-
denschnelles Feedback) und die testgesteuerte Entwicklung (minutenschnelles Feedback).
80
3.4
Validiertes Wissen
Nehmen wir als Beispiel einmal die Integration und das Testen von Komponenten. Stellen
Sie sich vor, wir würden drei Komponenten parallel entwickeln. Irgendwann müssen diese
Komponenten integriert und getestet werden, bevor wir ein Produkt haben, das ausgeliefert
werden kann. Solange wir die Integration nicht versucht haben, können wir wirklich nicht
mit Sicherheit sagen, ob wir die Komponenten korrekt entwickelt haben. Erst ein Versuch
der Integration liefert uns diesbezüglich wichtiges Feedback.
Bei einer sequenziellen Entwicklung würden Integration und Tests erst in der vorherbe-
stimmten Phase zum Ende der Entwicklung erfolgen. Dabei würden dann die meisten oder
alle Komponenten auf einmal integriert werden. Leider funktioniert es normalerweise
nicht, gleich einen ganzen Haufen Komponenten parallel zu entwickeln und sie dann spä-
ter in der Integrationsphase zu einem Ganzen zusammenzufügen – selbst wenn wir vor
der Entwicklung der Komponenten alle Schnittstellen sorgfältig definiert hätten, wäre es
sehr wahrscheinlich, dass bei der Integration etwas schiefgeht (siehe Abbildung 3.14).
Feedback-generierende Aktivitäten, die erst weit nach der Entwicklung auftreten, haben
bedauerliche Nebenwirkungen, beispielsweise verwandeln sie die Integration in eine große
Test-und-Reparaturphase, weil sich die Komponenten, die unabhängig voneinander entwi-
ckelt wurden, nicht reibungslos integrieren lassen. Wie lange es dauern und wie viel es kos-
ten wird, dieses Problem zu beheben, kann man zu diesem Zeitpunkt nur erahnen.
In Scrum organisieren wir den Workflow so, dass wir die Lernschleife in Abbildung 3.13
durchlaufen und so schnell wie möglich Feedback erhalten. Damit stellen wir eine zeitnahe
Durchführung Feedback-generierender Aktivitäten unmittelbar nach Beendigung der
ursprünglichen Entwicklungsarbeit sicher. Schnelles Feedback ist wirtschaftlich gesehen
enorm sinnvoll, da Fehler sich aufsummieren, wenn wir das Feedback verzögern, was das
Scheitern exponentiell vergrößern kann.
Schauen wir uns noch einmal das Beispiel der Komponentenintegration an. Beim Entwurf
der Komponenten haben wir wichtige Annahmen darüber getroffen, wie sie sich integrie-
ren lassen werden. Basierend auf diesen Annahmen haben wir den Designvorgang fortge-
81
Kapitel 3
Agile Prinzipien
setzt. Wir wissen an dieser Stelle noch nicht, ob der gewählte Designpfad richtig oder falsch
ist. Es ist einfach unsere beste Vermutung.
Sobald wir uns für einen Weg entschieden haben, treffen wir auf der Grundlage dieser
Wahl viele weitere Entscheidungen. Je länger wir warten, um die Gültigkeit der ursprüngli-
chen Designannahme zu überprüfen, umso größer ist die Anzahl der von ihr abhängigen
Entscheidungen. Stellen wir später (durch das Feedback während der Integrationsphase)
fest, dass die ursprüngliche Annahme falsch war, haben wir ein riesiges Schlamassel vor
uns: Wir müssen nicht nur viele schlechte Entscheidungen noch einmal überarbeiten, es
ist inzwischen auch eine Menge Zeit vergangen. Vermutlich können sich viele der Beteilig-
ten nicht mehr genau an alles erinnern, was sie gemacht haben, so dass sie Zeit brauchen,
um sich erneut einzuarbeiten.
Wenn wir die Gesamtkosten der Überarbeitung potenziell schlechter abhängiger Entschei-
dungen und die Kosten für die verzögerte Produktauslieferung bedenken, dann sind die
wirtschaftlichen Vorteile eines schnellen Feedbacks sehr verlockend. Durch schnelle Feed-
backs wird die Lernschleife sehr schnell wieder geschlossen, wodurch wir schlechte Ent-
wicklungswege kappen können, bevor sie ernsthaften wirtschaftlichen Schaden anrichten.
82
3.5
Work in Process (WIP)
In Scrum akzeptieren wir, dass dieses Denken zwar eins der grundlegenden Prinzipien bei
der Fertigung darstellt, seine dogmatische Befolgung bei der Produktentwicklung jedoch
zu beträchtlichen wirtschaftlichen Schäden führen kann.
Auch wenn das aller Logik zu widersprechen scheint, kann es sich doch als vorteilhaft
erweisen, während der Produktentwicklung in kleineren Batches zu arbeiten. Reinertsen
diskutiert das Problem der Batch-Größe ausführlich, und Tabelle 3.2 zeigt einige der von
ihm beschriebenen Vorteile kleiner Batch-Größen (Reinertsen 2009b).
Wenn kleine Batches besser sind als große, sollten wir dann nicht möglicherweise zu einer
Batch-Größe von 1 übergehen, das heißt, immer nur an jeweils einer einzigen Anforderung
arbeiten und sie durch alle Aktivitäten führen, bis sie fertig ist und an den Kunden ausge-
liefert werden kann? Dies wird als Single-Piece-Flow (zu Deutsch auch als MAF, »Mitarbei-
tergebundener Arbeitsfluss«) bezeichnet. Wie ich später noch zeigen werde, kann eine
Batch-Größe von 1 zwar in manchen Fällen sinnvoll sein, doch anzunehmen, dass »1« das
Ziel ist, verhindert möglicherweise eine Optimierung des Flusses und unserer gesamten
wirtschaftlichen Entwicklung.
Vorteil Beschreibung
Reduzierte Zykluszeit Kleinere Batches ergeben weniger Arbeit, die erledigt werden
muss, was wiederum bedeutet, dass man weniger Zeit aufwendet,
um darauf zu warten, dass die Arbeit fertig wird. Wir erledigen
Dinge also schneller
Reduzierte Denken Sie an ein Restaurant, in dem kleine Gruppen von Leuten
Flussvariabilität kommen und gehen (sie »fließen« schön durch das Restaurant).
Stellen Sie sich nun einen Reisebus vor (großer Batch), aus dem
Leute aussteigen, und die Wirkung, die dies auf das Restaurant
hat.
Beschleunigte Kleine Batches beschleunigen die Feedbacks, wodurch sich Fehler
Feedbacks geringfügiger auswirken.
Reduziertes Risiko Kleine Batches bedeuten einen geringeren Bestand, der sich
ändern könnte. Kleinere Batches gehen auch seltener schief (es
besteht ein größeres Risiko, dass bei zehn Teilen etwas passiert als
bei fünf).
Reduzierter Overhead Die Verwaltung großer Batches bringt einen Overhead mit sich –
so ist das Pflegen einer Liste mit 30.000 Arbeitsobjekten aufwen-
diger als einer Liste mit 30 Objekten.
Erhöhte Motivation Kleine Batches erlauben einen Fokus und ein Gefühl für Verant-
und Dringlichkeit wortung. Es ist viel einfacher, die Auswirkungen von Verzögerun-
gen und Fehlern zu verstehen, wenn man es nur mit kleinen
Batches zu tun hat.
Reduzierte Zunahme Wenn wir uns bei großen Batches irren, dann erleben wir auch
von Kosten und Zeit einen großen Schaden in Bezug auf Kosten und Zeitplan. Arbei-
ten wir in einem kleineren Maßstab, bleiben die Schäden im Rah-
men.
Tabelle 3.2: Vorteile kleiner Batch-Größen nach Reinertsen
83
Kapitel 3
Agile Prinzipien
84
3.5
Work in Process (WIP)
Leider ist das Lager (WIP) eine kritische Variable, auf die man während der Produktent-
wicklung achten muss. Traditionelle Ansätze für die Produktentwicklung konzentrieren
sich nicht auf die Organisation dieses speziellen Bestands. Wie ich in der Diskussion der
Batch-Größen bereits erwähnte, bevorzugt die traditionelle Entwicklung die Schaffung sehr
großer Lager, indem es eine relativ große Batch-Größe wählt (oft 100%). Eine wichtige Kon-
sequenz aus diesem Vorgehen ist, dass die Änderungskosten stark davon beeinflusst wer-
den (siehe die Kurve in Abbildung 3.9).
Wir benötigen zwar einige Anforderungen, wenn wir mit der Entwicklung beginnen, es ist
aber nicht erforderlich, alle Anforderungen zu haben. Haben wir zu viele Anforderungen,
wird sicher eine gewisse Verschwendung der Bestände eintreten, wenn es zu Änderungen
kommt. Haben wir andererseits nicht genügend Anforderungen, unterbrechen wir den
schnellen Workflow, was ebenfalls eine Art von Verschwendung ist. In Scrum besteht unser
Ziel darin, die richtige Balance zwischen gerade genügend Lagerbestand und zu viel Lager-
bestand zu finden.
Es ist wichtig zu erkennen, dass Anforderungen nur eine Form des Lagerbestands sind, der
in der Produktentwicklung existiert. Während der Produktentwicklung können in Arbeit
befindliche Waren an unterschiedlichen Stellen und zu unterschiedlichen Zeiten auftreten.
Und diese müssen wir ebenfalls aktiv identifizieren und organisieren.
85
Kapitel 3
Agile Prinzipien
20
18
16
14
Warteschlangengröße
12
10
8
6
4
2
0
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Auslastung
Abb. 3.15: Einfluss der Auslastung auf die Größe der Warteschlange (Verzögerung)
Jeder, der einen Computer besitzt, versteht dieses Diagramm. Was passiert, wenn Sie Ihren
Computer mit 100%-iger Auslastung betreiben (volle Prozessor- und Speicherlast)? Er
86
3.5
Work in Process (WIP)
beginnt zu überlasten und die auszuführenden Tasks werden immer langsamer. Mit ande-
ren Worten, der Computer arbeitet an immer mehr Dingen, schließt aber immer weniger
Arbeiten ab. Es ist nicht einfach, diesen Zustand wieder zu ändern (vermutlich müssen Sie
Tasks beenden oder den Rechner neu starten). Bei einer Auslastung von etwa 80% wäre Ihr
Computer viel effizienter. In Abbildung 3.15 entspricht die Länge der Warteschlange der
Verzögerung und die Verzögerung ist quasi der Staffelstab auf dem Boden.
Die unerledigte Arbeit (verzögerte Arbeit) nimmt bei sehr hoher Auslastung exponentiell
zu. Und das kann sehr teuer sein, viel teurer als die Kosten für die untätigen Arbeiter (im
nächsten Abschnitt finden Sie ein Beispiel dafür). In Scrum sind wir uns also sehr deutlich
bewusst, dass es ökonomisch gesehen erheblich sinnvoller ist, die Flaschenhälse in unse-
ren Arbeitsabläufen zu finden und zu eliminieren, als alle Mitarbeiter zu 100% zu beschäf-
tigen.
Parameter Wert
Dauer mit Vollzeit-Dokumentar 12 Monate
Dauer mit einem Dokumentar, der am Ende zugewiesen wird (wenn 14 Monate
wir den Zustand »alles, bis auf die Dokumentation« erreicht haben)
Tabelle 3.3: Beispielrechnung: Kosten der Verzögerung
87
Kapitel 3
Agile Prinzipien
Parameter Wert
Zykluszeitkosten, wenn die Dokumentation am Ende gemacht wird 2 Monate
Kosten der Verzögerung pro Monat 250.000 Dollar
Gesamtkosten der Verzögerung 500.000 Dollar
Weisen wir den Dokumentar erst am Ende zu, um die gesamte Dokumentation zu erstel-
len, brauchen wir ihn nur für zwei Monate Vollzeit, verzögern aber gleichzeitig die Auslie-
ferung des Produkts um diese zwei Monate. Und wenn wir die Auslieferung des Produkts
um zwei Monate verzögern, liegen die berechneten Kosten in Bezug auf den Lifecycle Profit
bei 500.000 Dollar. (Der Lifecycle Profit bezeichnet das gesamte Profitpotenzial eines Pro-
dukts über seine Lebensdauer gerechnet – in diesem Fall sinkt dieses Potenzial um
500.000 Dollar).
In diesem Beispiel betragen die Kosten für den untätigen Arbeiter 75.000 Dollar und die
Kosten für die unerledigte Arbeit 500.000 Dollar. Sollten wir uns darauf konzentrieren, die
Auslastung für den Dokumentar zu optimieren, verschlechtern wir damit die wirtschaftli-
chen Aussichten für das Gesamtprodukt. Während der Produktentwicklung sehen wir uns
ständig solchen Konflikten ausgesetzt – und die Verzögerungskosten gehören dabei zu den
wichtigsten Variablen, die es zu beachten gilt, wenn man wirtschaftlich sinnvolle Entschei-
dungen trifft.
3.6 Fortschritt
Wenn wir Scrum benutzen, dann messen wir den Fortschritt an dem, was wir ausgeliefert
und validiert haben, und nicht daran, wie wir entsprechend eines vordefinierten Plans vor-
angekommen sind oder wo wir in einer bestimmten Phase der Entwicklung stehen. Ich
beschreibe in diesem Zusammenhang nachfolgend drei agile Prinzipien:
쐽 An Echtzeitinformationen anpassen und umplanen.
쐽 Fortschritt messen, indem man funktionierende Güter validiert.
쐽 Auf eine wertzentrierte Auslieferung konzentrieren.
88
3.6
Fortschritt
befolgt wird. Im Gegensatz dazu glauben wir in Scrum, dass uns bedingungsloses Ver-
trauen in den Plan oftmals übersehen lässt, dass er falsch sein könnte.
Bei einer Scrum-Entwicklung besteht unser Ziel nicht darin, blind irgendeinem Plan, d.h.
einer im Vorhinein umrissenen Einschätzung des zu erwartenden Entwicklungsablaufs zu
folgen. Vielmehr lautet die Zielsetzung, zügig neu planen und eine jederzeitige Anpassung
an die kontinuierlich eingehenden wirtschaftlich wichtigen Informationen vornehmen zu
können.
89
Kapitel 3
Agile Prinzipien
Scrum
Gelieferter Wert
Traditionell
Zeit
3.7 Leistung
Es gibt spezielle leistungsbezogene Eigenschaften, die wir erwarten, wenn wir Scrum ein-
setzen. Im Folgenden beschreibe ich in diesem Zusammenhang drei agile Prinzipien:
쐽 Gehe schnell, aber hetze nicht.
쐽 Baue Qualität ein.
쐽 Mache alles ohne großes Zeremoniell.
90
3.7
Leistung
91
Kapitel 3
Agile Prinzipien
Der Scrum-Fokus auf ein Minimum an Zeremoniell wird oft fehlinterpretiert: »Scrum ist
gegen Dokumentation«. Doch das ist nicht wahr! Wenn wir Scrum einsetzen, nehmen wir
vielmehr eine ökonomische Sichtweise ein und überlegen sorgfältig, welche Dokumente
wir erstellen können. Falls wir ein Dokument abfassen, das nur für die Schublade gedacht
ist und keinen Wert besitzt, haben wir unsere Zeit und unser Geld auf ein paar tote Fetzen
Papier verschwendet. Aber nicht alle Dokumente sind bloß Makulatur. So verfassen wir
z.B. definitiv ein Dokument, wenn
쐽 es als Teil des Produkts ausgeliefert wird (als Installationsanweisung, Benutzerhand-
buch usw.),
Wenig Viel
Zeremoniell Zeremoniell
쐽 es unser Ziel ist, eine wichtige Diskussion, Entscheidung oder Vereinbarung festzuhal-
ten, damit wir uns in Zukunft genau daran erinnern können, was diskutiert, entschie-
den oder vereinbart wurde,
쐽 es eine sinnvolle Methode darstellt, um neue Teammitglieder schnellstmöglich einzuar-
beiten,
쐽 es eine regulatorische Anforderung ist, ein bestimmtes Dokument zu schreiben (was
nötig sein könnte, wenn man in einer entsprechend überwachten Branche arbeitet).
Wir versuchen lediglich, Arbeit zu vermeiden, die keinen kurzfristigen oder langfristigen
ökonomischen Wert erbringt. In Scrum glauben wir, dass Zeit und Geld besser investiert
werden, um einen Wert für den Kunden zu erbringen.
92
3.8
Abschließende Bemerkungen
Die Zielsetzung dieses Vergleichs bestand nicht darin, Sie davon zu überzeugen, dass das
Wasserfall-Modell schlecht und Scrum gut ist. Vielmehr wollte ich verdeutlichen, dass das
Wasserfall-Modell aufgrund der ihm zugrundeliegenden Überzeugungen für eine andere
Klasse von Problemen geeignet ist als Scrum. Generell bleibt es damit Ihnen selbst überlas-
sen einzuschätzen, welcher Art von Problemen sich Ihre Organisation gegenübersieht und
welches Werkzeug für Sie das passendere ist. Die nachfolgenden Kapitel dieses Buches
beschreiben ausführlich, wie diese Prinzipien einander unterstützen und stärken und
damit einen leistungsstarken Ansatz für die Produktentwicklung liefern.
93
Kapitel 3
Agile Prinzipien
94
Kapitel 4
Sprints
Scrum organisiert die Arbeit in Iterationen oder Zyklen von bis zu einem Kalendermonat
Länge, den sogenannten Sprints. In diesem Kapitel schauen wir uns genauer an, was
Sprints eigentlich sind. Wir diskutieren die unterschiedlichen Schlüsseleigenschaften von
Sprints: sie bestehen aus festen Zeiteinheiten – den Timeboxen –, haben eine kurze und
konsistente Zeitdauer, verfolgen ein Ziel, das nicht geändert werden sollte, sobald sie ein-
mal gestartet wurden, und müssen den Endzustand erreichen, der durch die Definition des
Teams von Fertig (»Done«) festgelegt ist.
4.1 Überblick
Sprints bilden das Grundgerüst des Scrum-Frameworks (siehe Abbildung 4.1).
Kurze Dauer
1 Woche bis
Konsistente Länge 1 Kalendermonat
Timeboxed
95
Kapitel 4
Sprints
Der große graue Hauptpfeil in der Abbildung, der sich vom Product Backlog durch die
gesamte Sprint-Durchführung erstreckt und die Mitglieder des Scrum-Teams einbezieht,
repräsentiert den Sprint. Die anderen Scrum-Artefakte und -Aktivitäten werden entspre-
chend dem relativen Zeitpunkt ihres Auftretens im Sprint angezeigt. Die Sprint-Ausfüh-
rung wird zwar oft mit »dem Sprint« verwechselt, ist aber eigentlich nur eine Aktivität, die
während des Sprints auftritt – neben der Sprint-Planung, dem Sprint Review und der
Sprint-Retrospektive.
Alle Sprints nutzen das sogenannte Timeboxing. Das bedeutet, dass sie feste Anfangs- und
Endzeitpunkte haben. Außerdem müssen Sprints kurz sein, irgendwo zwischen einer
Woche und einem Kalendermonat. Die Länge der Sprints sollte konsistent sein, wobei
unter bestimmten Bedingungen Ausnahmen erlaubt sind. Es gilt die Regel, dass während
eines Sprints keine das Ziel beeinflussenden Änderungen an Umfang oder Personal vorge-
nommen werden dürfen. Und schließlich muss während jedes Sprints ein potenziell aus-
lieferungsfähiges Produktinkrement fertiggestellt werden, das der vom Scrum-Team
vereinbarten Definition von Fertig entspricht. Auch wenn jede Organisation ihre eigene
Implementierung von Scrum benutzen wird, sollten diese Sprint-Charakteristika dennoch
für jeden Sprint und jedes Team gelten. Auf Ausnahmen von dieser Regel werden wir
natürlich auch eingehen. Schauen wir uns nun einmal alle Eigenschaften im Detail an, um
sie besser verstehen zu können.
4.2 Timeboxing
Sprints sind im Konzept des Timeboxing verwurzelt, einer Zeitmanagementtechnik, die
dabei hilft, die Durchführung und den Umfang der Arbeit zu organisieren. Jeder Sprint fin-
det in einem Zeitrahmen mit festen Anfangs- und Endzeitpunkten statt, der als Timebox
bezeichnet wird. Vom Team wird erwartet, innerhalb dieser Timebox mit einer nachhalti-
gen Geschwindigkeit zu arbeiten, um eine festgelegte Arbeitsmenge abzuschließen, die zur
Erreichung des Sprint-Ziels beiträgt.
Das Timeboxing ist aus verschiedenen Gründen wichtig (siehe Abbildung 4.2).
96
4.2
Timeboxing
Demonstriert Fortschritt
Timeboxing-Vorteile
97
Kapitel 4
Sprints
bringt, regt die Mitglieder des Teams an, sich unermüdlich zu bemühen, die Arbeit pünkt-
lich abzuschließen. Ohne einen bekannten Endtermin wirkt die Arbeit auf einmal gar nicht
mehr so dringend.
Erleichterte Planung
Schnelles Feedback
Begrenzte Fehler
Wiedererweckte Begeisterung
Häufige Checkpoints
98
4.3
Kurze Zeitdauer
99
Kapitel 4
Sprints
Begeisterung
Den Ozean
aufkochen
Begeisterung Zeit
Inkrementelle
Releases
kurzer Dauer
Zeit
Wasserfall-Checkpoints
Analyse
Design
Programmierung
Tests
Betrieb
Scrum-Checkpoints
100
4.4
Konsistente Dauer
101
Kapitel 4
Sprints
102
4.5
Keine das Ziel beeinflussenden Änderungen
103
Kapitel 4
Sprints
104
4.5
Keine das Ziel beeinflussenden Änderungen
Wir investieren in Elemente des Product Backlogs, um sie für die Bearbeitung in einem
Sprint vorzubereiten. Sobald jedoch ein Sprint beginnt, hat unsere Investition in diese Pro-
duct-Backlog-Elemente zugenommen (weil wir während der Sprint-Planung Zeit damit
zugebracht haben, sie auf Aufgabenebene zu diskutieren und zu planen). Falls wir nach der
Sprint-Planung eine Änderung vornehmen wollen, dann gefährden wir nicht nur die Pla-
nungsinvestition, sondern verursachen auch noch zusätzliche Kosten, weil wir für die
Änderungen während des Sprints neue Pläne schaffen müssen.
Kumulatives Investment
Sobald wir mit der Ausführung eines Sprints beginnen, steigert sich unsere Investition in
die Arbeit sogar noch weiter, da immer mehr Elemente des Product Backlogs durch die
Zustände »Noch zu erledigen« (Arbeit, die noch nicht begonnen wurde), »Wird erledigt«
(Ware in Arbeit) und »Fertig« (Arbeit abgeschlossen) läuft.
Nehmen wir einmal an, wir wollen Funktion X, die momentan Teil der Sprint-Verpflich-
tung ist, durch Funktion Y ersetzen, die zurzeit nicht in der Sprint-Verpflichtung enthalten
ist. Selbst wenn wir noch nicht begonnen haben, an Funktion X zu arbeiten, verursachen
wir eine Verschwendung von Planungsarbeiten. Funktion X könnte darüber hinaus Abhän-
gigkeiten zu anderen Funktionen im Sprint haben, so dass eine Änderung, die Funktion X
beeinflusst, auch Auswirkungen auf andere Funktionen haben könnte. Das verstärkt den
Einfluss auf das Sprint-Ziel.
Falls die Arbeit an Funktion X bereits begonnen hat, kommen neben der schon erwähnten
noch weitere mögliche Verschwendungen hinzu. So muss möglicherweise die gesamte
Arbeit, die schon an Funktion X durchgeführt wurde, weggeworfen werden. Und wir haben
vielleicht die zusätzliche Verschwendung, dass wir die teilweise fertiggestellte Arbeit an
Funktion X entfernen müssen, die wir in Zukunft vermutlich nie benutzen werden (wir
105
Kapitel 4
Sprints
werden am Ende des Sprints keine teilweise beendete Arbeit in ein potenziell ausliefe-
rungsfähiges Produktinkrement einbauen).
Sollte Funktion X zudem bereits abgeschlossen sein, haben wir natürlich die komplette
Investition in Funktion X verschwendet. Der Schaden wächst also immer weiter!
Die Verschwendung betrifft jedoch nicht nur die unmittelbar wirtschaftlich messbaren
Konsequenzen – sie wirkt sich auch auf die Motivation des Teams und die Zuversicht, die
mit einer Änderung einhergeht. Wenn der Product Owner sich verpflichtet, das Ziel nicht
zu ändern, und diese Verpflichtung dann bricht, wird das Team natürlich demotiviert, was
sich mit hoher Wahrscheinlichkeit auf seinen Eifer auswirkt, andere Elemente des Product
Backlogs fertigzustellen. Darüber hinaus könnte auch die Zuversicht innerhalb des Scrum-
Teams leiden, weil das Entwicklungsteam nicht mehr daran glaubt, dass der Product
Owner sich an seine Verpflichtungen hält.
106
4.5
Keine das Ziel beeinflussenden Änderungen
Option 1
Option 2
Option 3
Abb. 4.7: Nach Abschluss eines Sprints über die nächste Sprint-Dauer entscheiden
107
Kapitel 4
Sprints
108
4.6
Definition von Fertig (Done)
Meist wird es so sein, dass eine Minimaldefinition von Fertig ein komplettes Stück Pro-
duktfunktionalität ergibt – eins, das entworfen, gebaut, integriert, getestet und dokumen-
tiert wurde und nachweislich einen Wert für den Kunden erbringt. Für eine sinnvolle
Checkliste müssen diese relativ groben Elemente jedoch weiter verfeinert werden. Was
bedeutet z.B. getestet? Ein Unit Test? Integrationsgetestet? Systemgetestet? Plattformgetes-
tet? Internationalisierung getestet? Sie können sich sicher noch viele andere Formen des
Testens vorstellen, die auf Ihr Produkt zutreffen. Sind all Testvarianten in Ihrer Definition
von Fertig enthalten?
S Code abgeschlossen
Code restrukturiert
Code in Standardformat
Code ist kommentiert
Code ist eingecheckt
Code ist überprüft
S Endanwenderdokumentation aktualisiert
S Getestet
Unit Test durchgeführt
Integration getestet
Regression getestet
Plattform getestet
Sprache getestet
S Keine bekannten Fehlfunktionen
S Akzeptanz getestet
Denken Sie daran: Wenn Sie die wichtigen Tests (z.B. Leistungstests) nicht während jedes
Sprints durchführen, werden Sie sie irgendwann einmal nachholen müssen. Haben Sie
vielleicht vor, die Leistung zu irgendeinem zukünftigen Zeitpunkt in einem eigenen Sprint
testen? Wenn dem so ist, haben Sie definitiv nicht nach jedem Sprint ein potenziell auslie-
ferungsfähiges Produktinkrement zur Verfügung, denn Leistungstests sind für den
Zustand »Fertig« unerlässlich. Was aber noch schlimmer ist: Wenn Sie dann tatsächlich
erst später einen Leistungstest durchführen und dieser nicht wie geplant verläuft, sind Sie
nicht nur in einem sehr fortgeschrittenen Stadium der Entwicklung mit einem ernsten
Problem konfrontiert, sondern müssen auch mehr Zeit und Geld aufwenden, um dieses
Problem zu beheben, als wenn Sie den Leistungstest früher durchgeführt hätten.
109
Kapitel 4
Sprints
Manchmal dauern die Tests länger als ein Sprint. Sollte dies der Fall sein, weil das Entwick-
lungsteam bislang viele manuelle Tests schuldig geblieben ist, dann müssen die Tests auto-
matisiert werden, damit sie innerhalb eines Sprints beendet werden können. Sollte die
längere Ausführungsdauer hingegen in der Art des Tests begründet sein, dann müssen wir
akzeptieren, dass es nötig ist, ihn in einem Sprint zu beginnen und in einem künftigen
Sprint zu beenden. So baute z.B. eine Organisation, in der ich als Trainer tätig war, ein
Gerät, das aus Hardware, Firmware und Software bestand. Einer ihrer Standardtests
bestand in einem 1.500 Stunden andauernden Dauertest, um festzustellen, ob das Gerät
über diese Zeitspanne hinweg durchhalten würde. Ein solcher Test kann natürlich nicht
innerhalb eines zweiwöchigen Sprints abgeschlossen werden, deshalb passte das Scrum-
Team die Definition von Fertig entsprechend an: Ein Sprint konnte auch dann als beendet
betrachtet werden, wenn der 1.500-Stunden-Test noch nicht abgeschlossen worden war.
Oft werde ich gefragt: »Was ist, wenn es einen gravierenden Defekt gibt, der am letzten Tag
des Sprints noch vorhanden ist? Ist das Element aus dem Product Backlog dann fertig?«
Nein, es ist nicht fertig! Und weil wir Sprints gemäß unserer Regel nicht über den geplan-
ten Zeitraum hinaus verlängern, würden wir den Sprint auch nicht um einen oder zwei
Tage ausdehnen, um den Defekt im aktuellen Sprint zu beheben. Stattdessen wird das
unvollständige Backlog-Element am geplanten Ende des Sprints aus dem aktuellen Sprint
herausgenommen und wieder in das Product Backlog eingefügt, und zwar in der richtigen
Reihenfolge unter den anderen Elementen, die sich momentan im Product Backlog befin-
den. Das unvollständige Element kann dann in einem künftigen Sprint beendet werden.
Scrum-Teams brauchen eine solide Definition von Fertig – eine die ein hohes Maß an
Zuversicht vermittelt, dass ihr Produktinkrement von hoher Qualität ist und ausgeliefert
werden kann. Jede schwächere Definition beraubt die Organisation der geschäftlichen
Gelegenheit, nach ihrem Ermessen auszuliefern und kann dazu führen, dass technische
Schulden angehäuft werden (wie ich in Kapitel 8 näher ausführen werde).
110
4.6
Definition von Fertig (Done)
machen. Deshalb wird in solchen Fällen mit einem weniger anspruchsvollen Endzustand
begonnen und die Definition von Fertig mit dem fortschreitenden Abbau der organisatori-
schen Hürden entsprechend angepasst.
Ich besuchte z.B. einmal ein Unternehmen, das ein medizinisches Datenmanagementsys-
tem für Krankenhäuser entwickelt, mit dem sich eine Vielzahl von medizinischen Daten
verwalten lassen (von denen einige sogar direkt von den diagnostischen und therapeuti-
schen Geräten übermittelt werden). Es war von vornherein klar, dass das System vor der
Auslieferung einem praktischen Test unterzogen werden musste, d.h., das Produkt musste
vor Ort in einem Krankenhauslabor installiert werden, um sicherzugehen, dass es mit der
Krankenhaus-Hardware funktionierte. Weil das Team aber keinen regelmäßigen Zugang
zu einem Labor hatte, hatte es zunächst keine klinischen Tests in seine Definition von Fer-
tig aufgenommen. Stattdessen waren am Ende jedes Releases spezielle »Kliniktest-Sprints«
vorgesehen.
In unseren Besprechungen erfuhr ich, dass diese entscheidenden Kliniktests sowohl dem
Marketing als auch dem Team regelrecht verhasst waren. Niemand konnte vorhersagen,
wie viele Sprints es dauern würde, bis alle Mängel behoben wären. Andererseits konnte das
Produkt aber natürlich erst dann ausgeliefert werden, wenn es keine Mängel mehr gab. Als
wir über mögliche Lösungen nachgrübelten, ergriff der technische Leiter das Wort und
fragte sein Team: »Wärt ihr in der Lage, in jedem Sprint klinische Tests durchzuführen,
wenn ihr Zugang zu einem Krankenhauslabor hättet?«
Die Teammitglieder diskutierten ein wenig und antworteten schließlich: »Ja, aber das
würde bedeuten, dass wir in den einzelnen Sprints weniger Funktionen fertigstellen.« Also
wollte der technische Leiter nun versuchen, das Problem zu lösen, indem er dem Team
Zugang zu einem Labor der örtlichen Universität verschaffte. Auch der Product Owner
stimmte zu, dass die Fertigstellung einer geringeren Zahl an Funktionen in jedem Sprint
ein vernünftiger Kompromiss war, wenn dafür andererseits sichergestellt wäre, dass die
ausgelieferten Funktionen den Praxistest bestanden hatten. Das Team konnte seine Defini-
tion von Fertig somit dergestalt weiterentwickeln, dass es tatsächlich den Zustand »poten-
ziell auslieferungsfähig« erreichte. Und letztendlich gewannen auf diese Weise alle
Beteiligten ein höheres Maß an Vertrauen in die Arbeit, die in den einzelnen Sprints abge-
schlossen wurde.
Manchmal kann sich ein Team aber auch einem Problem gegenübersehen, das nicht so
einfach aus der Welt zu schaffen ist – und damit steht bereits im Vorfeld fest, dass die
Definition von Fertig im Laufe der Entwicklungsarbeit zwangsläufig nachgebessert wer-
den muss. Ein verbreitetes Beispiel hierfür ist ein Produkt, das sowohl Hardware als auch
Software beinhaltet. Ich habe Scrum schon bei vielen solcher Produktentwicklungen im
Einsatz gesehen und die Software-Leute häufig sagen hören: »Die Hardware kommt
immer zu spät!« In derartigen Fällen kann das Team am Ende des Sprints nicht guten
Gewissens behaupten, dass die Ergebnisse potenziell auslieferungsfähig sind – weil
schlicht und ergreifend die Hardware fehlt, um die gebaute Software zu testen. Im besten
Fall ist die Software »emulatorfertig«, weil die Tests in frühen Sprints typischerweise auf
einer Software erfolgen, die die eigentliche Hardware emuliert. Erst wenn später die tat-
sächliche Hardware zur Verfügung steht, entwickelt sich die Definition von Fertig ent-
sprechend weiter.
111
Kapitel 4
Sprints
112
4.7
Abschließende Bemerkungen
Arbeiten zur Kundenzufriedenheit erledigt hat, brauchen keine zwei Zustände – wenn sie
fertig sind, dann sind sie auch wirklich fertig!
113
Kapitel 5
5.1 Überblick
Anforderungen werden in Scrum und in der sequenziellen Produktentwicklung ganz
unterschiedlich behandelt. Bei der sequenziellen Produktentwicklung sind sie nicht ver-
handelbar, werden gleich zu Beginn in detaillierter Form festgelegt und sollen für sich
allein stehen. In Scrum werden die Einzelheiten einer Anforderung hingegen in den wäh-
rend des gesamten Entwicklungsprozesses kontinuierlich geführten Gesprächen sowohl in
zeitlicher als auch in inhaltlicher Hinsicht bedarfsorientiert ausgearbeitet, so dass die Teams
mit dem Bau der entsprechenden Funktionalität beginnen können.
Bei der sequenziellen Produktentwicklung werden Anforderungen genauso behandelt wie
in der Fertigung: Sie repräsentieren notwendige, nicht verhandelbare Spezifikationen,
denen das Produkt entsprechen muss. Diese werden im Voraus ausformuliert und dem
Entwicklungsteam in Form einer sehr detaillierten Dokumentation übergeben. Und dessen
Aufgabe besteht dann darin, ein Produkt herzustellen, das diesen ausführlichen Anforde-
rungen gerecht wird.
Wenn eine Abweichung von der ursprünglichen Projektplanung notwendig erscheint,
muss ein formeller Änderungskontrollprozess durchlaufen werden. Da die Zielsetzung
jedoch darin besteht, eine Konformität mit den vorgegebenen Spezifikationen zu erreichen,
sind solche Abweichungen unerwünscht und teuer – immerhin müsste unter Umständen
ein Großteil der laufenden Arbeit (Work in Process; WIP), sprich die stark detaillierten
Anforderungen (und sämtliche darauf basierenden Arbeiten), geändert oder verworfen
werden.
Im Gegensatz dazu werden die Anforderungen in Scrum als wichtiger Handlungsspiel-
raum erachtet, den wir manipulieren können, um unsere geschäftlichen Ziele zu errei-
chen. Falls uns z.B. das Geld oder die Zeit ausgeht, können wir Anforderungen von
geringem Nutzen verwerfen. Sollten neue Erkenntnisse, die wir während des Entwick-
lungsprozesses hinzugewinnen, darauf hinweisen, dass das Kosten-Nutzen-Verhältnis
115
Kapitel 5
Anforderungen und User Stories
einer Anforderung deutlich ungünstiger ausfällt, als ursprünglich erwartet, können wir
beschließen, sie aus dem Produkt zu entfernen. Und sollte sich eine neue hochwertige
Anforderung ergeben, haben wir die Möglichkeit, sie zu dem Produkt zu ergänzen, indem
wir ggf. eine niederwertige Anforderung verwerfen, um entsprechende Kapazitäten zu
schaffen.
Wir haben wahrscheinlich alle schon die Erfahrung gemacht, dass sich – obwohl zu Beginn
der Entwicklung ein »vollständiges« Anforderungsdokument vorlag – später doch heraus-
stellte, dass eine wichtige Anforderung fehlte. Nach dem Entdecken einer solchen fehlen-
den Anforderung könnte dann ein Gespräch wie das folgende stattgefunden haben:
Kunde: »Jetzt, wo ich diese erstellten Funktionen sehe, merke ich gerade, dass ich
außerdem noch diese andere Funktion brauche, die nicht im Anforderungsdokument
steht.«
Entwickler: »Warum haben Sie diese Funktion denn nicht vorher schon spezifiziert,
wenn Sie sie gern haben wollten?«
Kunde: »Na ja, das ist mir erst aufgefallen, als ich das Produkt gesehen habe.«
Entwickler: »Tja, wenn Sie gleich von vornherein intensiver über die Anforderungen
nachgedacht hätten, dann wäre Ihnen diese Funktion sicher schon früher eingefallen.«
Tatsache ist allerdings: Wenn Sie innovative Produkte entwickeln, können Sie nicht im Vo-
raus schon vollständige Anforderungen aufstellen, indem Sie einfach nur länger und härter
arbeiten oder nachdenken. Manche Anforderungen und Designentscheidungen treten erst
zutage, wenn die Produktentwicklung bereits im Gang ist. Das lässt sich auch durch noch
so umfassende Vorarbeit nicht verhindern.
Wenn wir Scrum einsetzen, wenden wir deshalb nicht übermäßig viel Zeit und Geld auf,
um die Anforderungen bereits im Voraus in aller Ausführlichkeit zu ermitteln. Da wir
ohnehin damit rechnen, dass sich die Spezifika im Laufe der Zeit ändern, während wir
mehr über das Produkt lernen, das wir entwickeln, können wir es vermeiden, zu viel Ener-
gie in Anforderungen zu investieren, die wir später möglicherweise wieder verwerfen.
Anstatt also vorab einen ausführlichen Anforderungskatalog zusammenzustellen, legen
wir Platzhalter für die Anforderungen an, die sogenannten Product-Backlog-Elemente
(Product Backlog Items; PBIs), von denen jedes einen erstrebenswerten Geschäftswert
repräsentiert (siehe Abbildung 5.1).
Zu Anfang sind die Product-Backlog-Elemente umfangreich (sie repräsentieren große
Bereiche des Geschäftswertes) und nicht besonders detailliert. Im Laufe der Zeit werden
diese PBIs jedoch in einer Reihe von Gesprächen zwischen den Stakeholdern, dem Product
Owner und dem Entwicklungsteam so weit verfeinert, dass eine Ansammlung kleinerer,
detaillierterer PBIs entsteht. Und schließlich ist ein Product-Backlog-Element dann klein
und detailliert genug, um es in einen Sprint überführen zu können, in dem es entworfen,
gebaut und getestet wird. Aber auch während des Sprints werden sich in Gesprächen zwi-
schen dem Product Owner und dem Entwicklungsteam noch weitere Details ergeben.
Wie ich in Kapitel 6 ausführen werde, ist das Product Backlog lediglich eine Momentauf-
nahme der aktuellen Sammlung der Product-Backlog-Elemente und der mit ihnen ver-
knüpften Details.
Scrum gibt zwar kein Standardformat für diese Product-Backlog-Elemente vor, die meisten
Teams stellen sie jedoch als User Stories dar. Zwingend erforderlich ist das aber wie gesagt
116
5.2
Gespräche
nicht: Manche Teams bevorzugen stattdessen Use Cases und andere wiederum haben auch
eigene Formate für ihre PBIs.
In diesem Buch werde ich die User Stories als maßgebliche Repräsentationsform der Pro-
duct-Backlog-Elementen aufgreifen. Genaueres dazu erfahren Sie später in diesem Kapitel.
Aber selbst wenn Sie sich für eine andere Darstellungsvariante entscheiden, wird Ihnen die
Diskussion der User Stories helfen, besser zu verstehen, welche Eigenschaften Sie auch in
einer anderen anderen Repräsentationsform verwenden können bzw. sollten.
Legende
Platzhaltergröße
Größer
Kleiner
Menge an Details
Wenig Viel
Zeit
Abb. 5.1: In Scrum werden Platzhalter für die Anforderungen benutzt.
5.2 Gespräche
Anforderungen sind ein wertvolles Kommunikationsinstrument, um das gemeinsame Ver-
ständnis hinsichtlich dessen, was gebaut werden muss, zu fördern und zu erleichtern. Sie
ermöglichen es den Leuten, die eine klare Vorstellung davon haben, was geschaffen werden
soll, ihre Wünsche unmissverständlich an die Personen zu übermitteln, die das Produkt
am Ende herstellen sollen.
Die sequenzielle Produktentwicklung verlässt sich sehr stark auf schriftlich niedergelegte
Anforderungen, die eindrucksvoll sein, aber leicht missverstanden werden können. Ich
erinnere mich da an ein Gespräch mit dem Leiter des Produktmanagements in einem von
mir besuchten Unternehmen. Als ich den Herrn, dem sämtliche Geschäftsanalysten des
Unternehmens unterstanden, fragte, wie man dort mit Anforderungen umgehen würde,
antwortete er: »Am 1. Januar übergibt mein Team den Ingenieuren das Anforderungsdoku-
ment und am 31. Dezember schauen wir, was dabei herausgekommen ist.«
117
Kapitel 5
Anforderungen und User Stories
Ich wollte wissen, wer von seinem Team den Entwicklern das Jahr hindurch für Fragen und
ggf. eingehendere Erläuterungen der Anforderungen zur Verfügung stehen würde. Und er
sagte: »Niemand. Das gesamte Zeitkontingent, das meinem Team für dieses Projekt zuge-
dacht ist, wird in die Erstellung des Anforderungsdokuments investiert. Und dann sind
meine Analysten gleich schon wieder mit den Anforderungsdokumenten für andere Pro-
jekte beschäftigt. Aber keine Panik, wir arbeiten die Dokumentationen sorgfältig aus, so
dass alle Fragen, die die Entwickler oder Tester haben könnten, darin beantwortet werden,
sofern sie es gründlich lesen.«
Mir erschien es allerdings unwahrscheinlich, dass es in seinem 150 Seiten langen, ausführ-
lichen Use-Case-Dokument für ein neues elektronisches Aufzeichnungssystem für medizi-
nische Daten keine Unklarheiten geben sollte – denn normalerweise sind die in
Schriftform festgehaltenen Ausführungen sehr viel weniger präzise, als wenn man eine
Problemstellung in einer direkten, mündlichen Kommunikation erörtert.
Ein besserer Weg, um sicherzustellen, dass die gewünschten Funktionen gebaut werden,
besteht darin, dass die Leute, die wissen, was genau sie haben wollen, rechtzeitig mit den
Leuten reden, die diese Funktionen entwerfen, bauen und testen.
In Scrum dient uns das Gespräch an sich als ein wichtiges Instrument, das dafür sorgt,
dass die Anforderungen richtig diskutiert und kommuniziert werden. Die verbale Kommu-
nikation bringt den riesigen Vorteil mit sich, dass sie eine hohe Bandbreite besitzt und ein
schnelles Feedback gewährleistet, wodurch sich leichter und billiger ein gegenseitiges Ver-
ständnis erreichen lässt. Darüber hinaus erlauben Gespräche eine bidirektionale Kommu-
nikation, die Ideen in Bezug auf Probleme und Chancen zünden lassen kann –
Diskussionen, die beim Lesen eines Dokuments sicher nicht entstehen würden.
Das Gespräch ist jedoch nur ein Werkzeug, kein Ersatz für eine ausführliche Dokumenta-
tion. In Scrum ist das Product Backlog ein »lebendiges Dokument«, das während der Pro-
duktentwicklung ständig zur Verfügung steht. Und sollte darüber hinaus auch ein
separates Spezifikationsdokument für die Anforderungen benötigt werden, lässt sich dies
jederzeit bewerkstelligen, indem man einfach die Elemente aus dem Product Backlog und
die dazugehörigen Details in einem Dokument zusammenfügt.
118
5.4
Was sind User Stories?
119
Kapitel 5
Anforderungen und User Stories
sich, ihn in jedem Fall mit aufzunehmen. Die rechte Seite von Abbildung 5.2 zeigt ein Bei-
spiel für eine User Story, die auf dieser Vorlage beruht.
Die Karte ist nicht dazu gedacht, alle Informationen zu erfassen, aus denen eine Anforde-
rung besteht. Wir benutzen sogar absichtlich kleine Karten, um eine gewisse Knappheit zu
fördern. Eine Karte sollte nur wenige Sätze enthalten, die das Wesen oder die Absicht einer
Anforderung ausdrücken, und dient als Platzhalter für ausführlichere Diskussionen, die
zwischen den Stakeholdern, dem Product Owner und dem Entwicklungsteam stattfinden.
120
5.4
Was sind User Stories?
gangspunkt, um einen ersten Eindruck davon zu bekommen, was gewünscht ist, und um
sich daran zu erinnern, dass man zu gegebener Zeit ausführlicher über die Anforderungen
diskutieren muss. Dabei können und sollten User Stories auf jeden Fall durch alle schriftli-
chen Informationen ergänzt werden, die weitere Klarheit darüber verschaffen, was
gewünscht wird.
121
Kapitel 5
Anforderungen und User Stories
können. Und aus rechtlichen Gründen können wir nicht zulassen, dass Dateien mit
DRM-Beschränkungen (Digital Rights Management) in das Wiki geladen werden.
Größe Valid()
0 True
1073741824 True
1073741825 False
Tabelle 5.1: Beispiel für automatisierten Test
Mit einem Werkzeug wie Fit oder FitNesse könnten wir diese Tests zudem ganz bequem in
tabellarischer Form definieren, wie die Beispiele für unterschiedliche Dateigrößen und
deren Gültigkeit in Tabelle 5.1 zeigen.
Indem wir solche speziellen Beispiele genauer ausführen, können wir die Erstellung der
Story und den progressiven Verfeinerungsprozess vorantreiben und (automatisierte)
Akzeptanztests für jede Story bereitstellen.
122
5.5
Der Detaillierungsgrad
Wenn es nur eine (kleine) Größe für die Stories gibt, sind wir außerdem genötigt, alle
Anforderungen mit einem hohen Detaillierungsgrad zu definieren, obwohl das erst viel
später notwendig ist. Haben wir nur kleine Stories, dann sind alle Vorteile der progressiven
Verfeinerung der Anforderungen – die erst dann erfolgt, wenn sie wirklich notwendig ist –
hinfällig.
Glücklicherweise kann man User Stories so schreiben, dass sie die Bedürfnisse der Kunden
und Anwender auf unterschiedlichen Abstraktionsebenen erfassen.
Abbildung 5.5 stellt Stories auf unterschiedlichen Abstraktionsniveaus dar. Am größten
sind Stories, die einen Umfang von einigen bis vielen Monaten haben und sich über eine
ganze Version oder vielleicht sogar mehrere Versionen erstrecken. Manchmal werden sol-
che Stories auch als Epics bezeichnet, weil sie vom Umfang her mit literarischen Werken
epischen Ausmaßes wie Der Herr der Ringe oder Krieg und Frieden vergleichbar sind. Epics
sind insofern hilfreich, weil sie das ganze Bild zeigen und einen allumfassenden Überblick
über das liefern, was gewünscht ist (siehe Abbildung 5.6).
Allerdings würden wir ein Epic niemals zur Entwicklung in einen Sprint überführen, weil
es viel zu groß und nicht besonders detailliert ist. Stattdessen sind Epics ausgezeichnete
Platzhalter für eine große Sammlung detaillierterer Stories, die zu einem passenden späte-
ren Zeitpunkt geschaffen werden. Bei der Diskussion der Produktplanung in Kapitel 17
werde ich noch näher auf die Verwendung von Epics eingehen.
Tage Sprint-bereit
Stunden Aufgaben
Präferenztraining-Epic
Als typischer Benutzer möchte ich dem
System beibringen, welche Arten von
Produkt- und Service-Kritiken ich
bevorzuge, so dass es in meinem Namen
entsprechend filtern kann.
123
Kapitel 5
Anforderungen und User Stories
Die in Abbildung 5.5 dargestellte nächstkleinere Größe sind Stories, die sich im Rahmen
von einigen Wochen bewegen und deshalb zu groß für einen einzelnen Sprint sind. Man-
che Teams bezeichnen diese als Funktionen.
Und die kleinste Form der User Story ist schließlich diejenige, die ich üblicherweise als
Story bezeichne. Um eine Verwechslung mit Epen, Funktionen oder anderen größeren Ele-
menten zu vermeiden, bei denen es sich ebenfalls um »Stories« handelt, nennen manche
Leute diese Stories entweder sprintfähige Stories oder umsetzbare Stories (implementable
stories). Damit wollen sie andeuten, dass sie sich in Größenordnungen von einigen Tagen
bewegen und deshalb klein genug sind, um in einen Sprint zu passen und umgesetzt zu
werden. Abbildung 5.2 enthält ein Beispiel für eine sprintfähige Story.
Manche Teams benutzen auch den Begriff Theme für eine Sammlung zusammenhängen-
der Stories. Themes eignen sich gut, um auszudrücken, dass mehrere Stories etwas
gemeinsam haben, sich z.B. im selben funktionalen Bereich bewegen. In Abbildung 5.7
wird das Theme aus einer Sammlung von Stories gebildet, in denen die Details zur Durch-
führung des Stichworttrainings ausgeführt sind.
Stichworttraining-Theme
Als typischer Benutzer möchte ich das
System lehren, welche Stichwörter es
beim Filtern von Kritiken nutzen soll, so
dass es nach Wörtern filtert, die
für mich wichtig sind.
Ich stelle mir ein Theme oft als eine zusammenfassende Karte für einen Stapel Karteikar-
ten vor, die mit einem Gummi zusammengehalten werden, damit klar erkennbar ist, dass
sie sich alle auf einen inhaltlichen Bereich beziehen, den wir für wichtig halten.
Aufgaben bilden die Ebene unterhalb der Stories. Sie werden typischerweise von einer, viel-
leicht von zwei Personen bearbeitet. Für ihre Ausführung sind meist nur Stunden nötig.
Wenn wir uns auf die Aufgabenebene begeben, dann geben wir an, wie etwas gebaut wer-
den soll – nicht jedoch, was gebaut wird (dies wird durch Epics, Funktionen und Stories vor-
gegeben). Aufgaben sind keine Stories, daher sollten sie auch keine zur Aufgabenebene
gehörigen Details enthalten.
Denken Sie immer daran, dass Begriffe wie Epic, Funktion, Story und Theme nur Bezeich-
nungen sind, die der Einfachheit halber vergeben werden und nicht unbedingt allgemein
üblich sind. Es spielt keine Rolle, welche Bezeichnungen Sie verwenden, solange Sie kons-
tant dabei bleiben. Zu beachten ist auch, dass Stories auf verschiedenen Abstraktionsstufen
existieren können und daher bei unseren Versuchen, auf verschiedenen Abstraktionsebe-
nen zu planen und große Elemente schrittweise zu kleinen Elementen zu verfeinern, sehr
hilfreich sein können.
124
5.6
In gute Stories INVESTieren
Element Element
Story #9
Abhängigkeiten
Story #11
Abhängigkeiten
Bevor wir an Story #10 arbeiten können, müssen wir alle abhängigen Stories entwickeln. In
diesem speziellen Fall mag das nicht so schlimm sein – aber stellen Sie sich doch einmal
vor, Sie hätten viele unterschiedliche Stories mit einem hohen Grad an gegenseitigen
125
Kapitel 5
Anforderungen und User Stories
Abhängigkeiten haben, wie z.B. in Abbildung 5.8 rechts zu sehen. Die Prioritäten all dieser
Stories zu ermitteln und festzustellen, an welchen von ihnen man in einem Sprint zuerst
arbeiten sollte, ist – gelinde gesagt – schwierig.
Wenn man das Unabhängigkeitskriterium anwendet, besteht das Ziel nicht darin, alle
Abhängigkeiten zu eliminieren, sondern die Stories vielmehr so zu schreiben, dass Abhän-
gigkeiten minimiert werden.
126
5.6
In gute Stories INVESTieren
jemand sagt: »Story #10 hat für niemanden einen Wert, lasst sie uns trotzdem umsetzen.«
Das würden wir einfach nicht tun. Stattdessen würden wir die Story entweder umschrei-
ben, damit sie für den Kunden oder Anwender an Wert gewinnt, oder wir würden sie ver-
werfen.
Doch wie steht es mit Stories, die zwar für die Entwickler werthaltig sind, aber keinen
offensichtlichen Wert für die Kunden oder Anwender haben? Ist es in Ordnung, technische
Stories wie jene aus Abbildung 5.9 zu implementieren?
Das grundlegende Problem mit technischen Stories ist, dass der Product Owner möglicher-
weise keinen Wert in ihnen erkennt – was es schwierig, wenn nicht gar unmöglich macht,
ihnen eine Priorität gegenüber den geschäftlich werthaltigen Stories einzuräumen. Damit
eine technische Story existieren kann, muss der Product Owner verstehen, wieso er dafür
bezahlen soll und welchen Wert diese Story für ihn am Ende darstellt.
Im Fall der Story »Auf eine neue Version von Oracle migrieren« versteht der Product
Owner vielleicht am Anfang nicht, wieso es sinnvoll ist, die Datenbank zu wechseln. Sobald
ihm das Team jedoch die Risiken erklärt hat, die damit verbunden sind, wenn man weiter
auf einer nicht unterstützten Version einer Datenbank entwickelt, könnte der Product
Owner entscheiden, dass das Migrieren der Datenbanken werthaltig genug ist, um das
Bauen einiger neuer Funktionen auf den Zeitpunkt nach der Migration zu verschieben.
Wenn der Product Owner den Wert versteht, kann er die technische Story genauso behan-
deln wie jede andere aus geschäftlicher Sicht werthaltige Story und nach sorgfältigen Erwä-
gungen sachkundig entscheiden, ob sie schließlich in das Product Backlog aufgenommen
wird oder nicht.
In der Praxis allerdings sollten die meisten technischen Stories (wie die aus Abbildung
5.10) nicht im Product Backlog auftauchen.
Stattdessen sollten sie als Aufgaben behandelt werden, die mit der Erledigung geschäftlich
werthaltiger Stories verknüpft werden. Sofern das Entwicklungsteam eine solide Definition
von Fertig hat, sollte es eigentlich nicht notwendig sein, diese Art von Stories zu schreiben,
weil die darin ausgewiesene Arbeit durch die Definition von Fertig impliziert wird.
Der Knackpunkt des Kriteriums werthaltig ist, dass aus Sicht des Product Owners alle Sto-
ries im Backlog werthaltig sein müssen (d.h., um Werte, Zeit und Geld in sie zu investie-
ren). Schließlich repräsentiert die Sicht des Product Owners die Sicht der Kunden und
Anwender. Nicht alle Stories sind unabhängig und nicht alle Stories sind voll verhandelbar,
aber alle Stories müssen werthaltig sein.
127
Kapitel 5
Anforderungen und User Stories
Automatische Builds
Als Entwickler möchte ich, dass die
Builds automatisch laufen, wenn ich den
Code einchecke, damit Regressionsfehler
erkannt werden, sobald sie auftreten.
Sollte das Team nicht in der Lage sein, die Größe einer Story zu bestimmen, dann ist sie
entweder zu umfangreich oder zu unklar, oder das Team besitzt nicht genug Informatio-
nen, um eine Größe schätzen zu können. Ist die Story zu groß, muss das Team mit dem
Product Owner zusammenarbeiten, um sie in kleinere, besser zu handhabende Stories auf-
zuteilen. Mangelt es dem Team an Informationen, sind gewisse Erkundungsaktivitäten
erforderlich, um diese zu erlangen (darauf gehe ich gleich ein).
128
5.7
Nichtfunktionale Anforderungen
müssten uns bemühen, es erst einmal auf die passende Größe zurechtzustutzen. Sie müs-
sen also in Betracht ziehen, wann eine Story bearbeitet werden soll, wenn Sie dieses Krite-
rium anwenden.
Internationalisierung Webbrowser-Unterstützung
Als Benutzer möchte ich eine Oberfläche System muss IE8, IE9, Firefox 6,
in Englisch, einer romanischen Sprache Firefox 7, Safari 5 und Chrome 15
und einer komplexen Sprache, damit sie unterstützen.
in allen 70 geforderten Sprachen
funktioniert.
129
Kapitel 5
Anforderungen und User Stories
dung 5.11 rechts) bei jedem Website-Projekt üblich. Wenn das Team die Funktionen der
Website entwickelt, muss es dafür sorgen, dass diese mit allen angegebenen Browsern
funktionieren.
Außerdem muss das Team entscheiden, wann es all diese Browser testet. Alle nichtfunktio-
nalen Anforderungen müssen in die Definition von Fertig aufgenommen werden. Nimmt
das Team also die nichtfunktionale Anforderung »Webbrowser-Unterstützung« in seine
Definition von Fertig auf, muss es alle neuen Funktionen, die in dem Sprint entstanden
sind, mit allen aufgeführten Browsern testen. Funktioniert das nicht mit allen, ist die Story
nicht fertig.
Generell sollten die Teams so viele der nichtfunktionalen Anforderungen in ihre Definitio-
nen von Fertig aufnehmen wie möglich – werden sie nämlich erst in einer späten Phase
des Entwicklungsprozesses getestet, verzögert sich damit natürlich auch das Feedback zu
wichtigen Merkmalen der Systemleistung.
130
5.8
Stories zum Wissenserwerb
muss allerdings in der Lage sein zu sagen, wie viel Aufwand es betreiben möchte, um die
Informationen zu beschaffen, die für diese architektonische Entscheidung nötig sind. Des-
halb bitten wir das Team, die Größe der Prototyping-Story einzuschätzen.
Nehmen wir einmal an, die Größenschätzung weist darauf hin, dass das komplette Team
einen ganzen Sprint lang an der Story arbeiten muss. Wir wissen, wer im Team ist und wie
lange der Sprint dauert, so dass wir auch die Kosten für den Erwerb der Informationen ken-
nen. (Es könnten z.B. 10.000 Dollar sein.) Nun müssen wir den Wert der Informationen
ermitteln.
Hier ist eine Möglichkeit, den Wert zu schätzen. Stellen Sie sich vor, ich würde eine Münze
werfen: Liegt Kopf oben, nehmen wir Architektur A, bei Zahl nehmen wir Architektur B.
Jetzt bitte ich das Team einzuschätzen, was es kostet, wenn es sich irrt. Was würde es z.B.
kosten, die schlechte Entscheidung rückgängig zu machen und alles auf Architektur B auf-
zubauen – immer vorausgesetzt, ich hatte Kopf geworfen und wir habe alles auf Architek-
tur A aufgebaut, was sich aber als die falsche Entscheidung herausgestellt hat? Nehmen wir
weiter an, das Team hätte die Kosten auf 500.000 Dollar geschätzt.
131
Kapitel 5
Anforderungen und User Stories
132
5.9
Stories sammeln
Während des Workshops gibt es keine Standardmethode zum Generieren von User Stories.
Manche Teams bevorzugen es, sich von oben nach unten (Top-down) vorzuarbeiten, andere
gehen lieber von unten nach oben (Bottom-up) vor. Beim Top-down-Ansatz beginnt das
Team mit einer großen Geschichte (wie einem literarischen Epos) und konzentriert sich
dann darauf, aus diesem Epos eine vernünftige Sammlung kleinerer Stories zu erstellen.
Alternativ kann man sich aber auch von unten nach oben durcharbeiten und sofort damit
beginnen, sich Stories auszudenken, die mit der nächsten Version eines existierenden Sys-
tems zusammenhängen. Es gibt kein richtiges oder falsches Vorgehen. Nutzen Sie den
Ansatz, der für Sie gut funktioniert, oder wechseln Sie, um das Beste aus beiden Varianten
herauszuholen.
Epic Epic
Kaufe ein Produkt
Story Story
Suche nach Autor Wageninhalt
zusammenrechnen
Story
Suche nach ISBN
133
Kapitel 5
Anforderungen und User Stories
Patton benutzt Begriffe wie Aktivität, Aufgabe und Teilaufgabe, um die Hierarchie innerhalb
einer Story Map zu beschreiben. Um bei der bisher verwendeten Terminologie zu bleiben,
benutze ich hier auch weiterhin die Begriffe Epic, Theme und sprintfähige Story.
Auf der höchsten Ebene befinden sich die Epics, die die großen Aktivitäten von messbarem
wirtschaftlichem Wert für den Benutzer repräsentieren – z.B. das Epic »Kaufe ein Pro-
dukt«.
Als Nächstes denken wir über die Abfolge oder den normalen Arbeitsablauf der Benutzer-
aufgaben nach, aus denen das Epic besteht (repräsentiert durch Themes – sprich Samm-
lungen zusammenhängender Stories). Wir platzieren die Themes entlang einer Zeitlinie,
in der diejenigen, die frühzeitiger im Arbeitsablauf auftreten, links von denen postiert wer-
den, die erst später auftauchen. So würde z.B. das Theme »Suche nach Produkt« links vom
Theme »Organisiere Einkaufswagen« stehen.
Jedes Theme wird dann in eine Reihe umsetzbare Stories zerlegt, die vertikal in der Reihen-
folge ihrer Priorität angeordnet werden (eigentlich in der Reihenfolge ihrer Erwünschtheit,
da es unwahrscheinlich ist, dass die Stories schon geschätzt wurden und wir die endgültige
Priorität erst bestimmen können, wenn wir die Kosten kennen). Nicht alle Stories inner-
halb eines Themes müssen in dieselbe Version aufgenommen werden. So könnte die Story
»Suche nach Farbe« in der ersten Version fehlen, während »Suche nach Namen« vermut-
lich enthalten wäre.
Das Story Mapping kombiniert die Konzepte des anwenderzentrierten Designs mit der
Story-Zerlegung. Gute Story Maps zeigen einen Aktivitäts-Flow aus Sicht des Benutzers
und liefern einen Kontext zum Verständnis der einzelnen Stories und deren Relation zu
größeren Kundenwerteinheiten.
Selbst wenn Sie kein formales Story Mapping durchführen, finde ich die Idee von Arbeits-
abläufen in meinen Workshops immer ganz hilfreich. Sie fokussieren die Diskussion auf
das Schreiben von Stories, die dem Benutzer einen kompletten Arbeitsablauf liefern sollen,
der für ihn von Nutzen ist. Mit dem Kontext des Arbeitsablaufs ist es einfacher festzustel-
len, ob wir in diesem Zusammenhang irgendwelche wichtigen Stories vergessen haben.
Ein Unterschied zwischen den traditionellen Workshops zum Schreiben von Stories und
dem Story Mapping besteht darin, dass wir uns während des Workshops vorrangig darauf
konzentrieren, Stories zu generieren, und weniger darauf, sie zu priorisieren (das ist die
vertikale Position der umsetzbaren Stories in einer Story Map). Wir könnten das Story Map-
ping deshalb als ergänzende Technik zum Workshop nutzen, die uns hilft, die Prioritäten
der Stories zu visualisieren. Story Maps bieten eine zweidimensionale Darstellung eines
Product Backlogs – im Gegensatz zur traditionell linearen (eindimensionalen) Darstellung.
134
5.10
Abschließende Bemerkungen
derungen genauer herauszuarbeiten. Wir nutzen außerdem eine Strategie der progressiven
Verfeinerung großer, weniger detaillierter Stories in kleinere, detailliertere Stories, und
zwar zum Zeitpunkt des Bedarfs an diesen Stories.
Außerdem habe ich den formalen Aufbau von User Stories im Kontext der Methode »Karte,
Gespräch und Bestätigung« (Card, Conversation und Confirmation) vorgestellt und aufge-
zeigt, wie man mit ihrer Hilfe den Geschäftswert auf unterschiedlichen Abstraktionsebe-
nen darstellt. Anschließend erklärte ich, wie man anhand der INVEST-Kriterien feststellen
kann, ob man gute User Stories hat und erläuterte die Methoden für den Umgang mit
nichtfunktionalen Anforderungen und Aktivitäten zum Wissenserwerb. Zum Schluss
folgte eine Diskussion über das Sammeln von User Stories. Dabei konzentrierte ich mich
auf Workshops zum Schreiben von Stories und auf das Story Mapping. Im nächsten Kapitel
befasse ich mich mit dem Product Backlog.
135
Kapitel 6
In diesem Kapitel beschreibe ich die wichtige Rolle, die das Product Backlog in einem
Scrum-Entwicklungsprojekt einnimmt. Ich beginne mit der Beschreibung der unterschied-
lichen Arten von Elementen, die Sie normalerweise in einem Product Backlog finden.
Danach stelle ich vier Merkmale eines guten Product Backlogs vor und zeige auf, wie Sie
mit einer guten Backlog-Pflege (»Grooming«) sicherstellen, dass diese Merkmale erreicht
werden. Anschließend erläutere ich, weshalb das Product Backlog ein Schlüsselelement
beim Organisieren eines schnellen, flexiblen Workflows sowohl auf Versions- als auch auf
Sprint-Ebene ist. Und zum Schluss erfahren Sie, wie Sie feststellen können, welche und
wie viele Product Backlogs Sie haben sollten.
6.1 Überblick
Das Product Backlog ist eine priorisierte Liste der gewünschten Produktfunktionalität. Es
stellt eine zentralisierte und gemeinsame Vereinbarung dessen dar, was gebaut werden und
in welcher Reihenfolge dies erfolgen soll. Es ist ein deutlich sichtbares Artefakt im Herzen
des Scrum-Frameworks, das für alle Projektteilnehmer erreichbar ist (siehe Abbildung 6.1).
Daily Scrum
Sprint-Planung
Sprint Backlog
Product Backlog
Sprint-Ausführung
Pflege
Potenziell
auslieferungsfähiges
Produktinkrement
Sprint Review
Sprint-Retrospektive
Abb. 6.1: Das Product Backlog ist das Herzstück des Scrum-Frameworks
137
Kapitel 6
Das Product Backlog
Immer wenn ein Produkt oder System gebaut, erweitert oder unterstützt wird, gibt es auch
ein Product Backlog.
6.2 Product-Backlog-Elemente
Das Product Backlog besteht aus Product-Backlog-Elementen (Product Backlog Items), die
ich im Folgenden als PBIs, Backlog-Elemente oder einfach nur Elemente bezeichne (siehe
Abbildung 6.2).
Element Größe
Funktionen
Defekte
Product-Backlog-
Elemente (PBIs)
Technische Arbeit
Wissenserwerb
Die meisten PBIs sind Funktionen – Elemente mit einer Funktionalität, die einen greifba-
ren Wert für den Benutzer oder den Kunden haben. Oft werden sie als User Stories aufge-
schrieben (obwohl Scrum das Format der PBIs nicht vorgibt). Beispiele für Funktionen
sind etwas Brandneues (ein Login-Bildschirm für eine neue Website) oder eine Änderung
an einer vorhandenen Funktion (ein benutzerfreundlicherer Login-Bildschirm für eine vor-
handene Website). Andere PBIs sind unter anderem Defekte, die einer Reparatur bedürfen,
technische Verbesserungen, Arbeiten zum Wissenserwerb und alle anderen Tätigkeiten,
die der Product Owner für werthaltig erachtet. In Tabelle 6.1 finden Sie Beispiele für die
verschiedenen PBI-Typen.
138
6.3
Merkmale guter Product Backlogs
PBI-Typ Beispiel
Funktion Als Vertreter des Kundendienstes möchte ich ein Ticket für ein Kunden-
problem anlegen können, damit ich eine Support-Anfrage eines Kunden
aufzeichnen und organisieren kann.
Änderung Als Vertreter des Kundendienstes möchte ich, dass die Standardsortie-
rung der Suchergebnisse nach dem Nachnamen erfolgt und nicht nach
der Ticketnummer, damit es leichter ist, ein bestimmtes Support-Ticket
zu finden.
Defekt Behebe Defekt #256 im Fallbearbeitungs- bzw. Ticket-System, damit in
Suchbegriffen enthaltene Sonderzeichen die Kundensuchläufe nicht
zum Absturz bringen.
Technische Wechsle zur neuesten Version des Oracle DBMS.
Verbesserung
Wissenserwerb Schaffe einen Prototypen oder ein Konzept zweier Architekturen und
führe drei Tests durch, um festzustellen, welcher Ansatz für unser Pro-
dukt besser wäre.
Tabelle 6.1: Beispiele für Product-Backlog-Elemente
139
Kapitel 6
Das Product Backlog
Product-Backlog-
Elemente
Kleine Größe Werden bald bearbeitet
Viele Details
Große Größe
Wenige Details Werden nicht so bald bearbeitet
6.3.2 Emergent
Solange ein Produkt entwickelt oder gepflegt wird, ist das Product Backlog niemals voll-
ständig oder »auf Eis gelegt«. Vielmehr wird es auf der Grundlage eines kontinuierlichen
Flusses wirtschaftlich wertvoller Informationen ständig aktualisiert. So könnten sich z.B.
die Kundenwünsche ändern, Konkurrenten könnten einen unerwarteten waghalsigen Vor-
stoß unternehmen oder es könnten unvorhergesehene technische Probleme auftreten.
Und das Product Backlog muss sich stets an derartige Geschehnisse anpassen.
Die Struktur des Product Backlogs entwickelt sich somit im Laufe der Zeit immer weiter.
Wenn neue Elemente hinzugefügt oder vorhandene Elemente verfeinert werden, muss der
Product Owner das Product Backlog anhand der hinzugewonnenen Informationen neu
ausrichten und die Prioritäten der Elemente entsprechend anpassen.
140
6.3
Merkmale guter Product Backlogs
Element Größe
2
3 Jedes Element hat eine Größenschätzung
2
5 Die meisten Schätzungen erfolgen in Form von
13 Story-Punkten oder Idealtagen
13
20
20
40
Diese Schätzungen dienen dem Product Owner als Ausgangswerte, um die Priorität (und
damit die Position) des PBI im Product Backlog zu ermitteln. Ein großes PBI mit hoher Pri-
orität (nahe der Spitze des Backlogs) signalisiert dem Product Owner, dass eine zusätzliche
Verfeinerung dieses Elements erforderlich ist, bevor es in einen der nächsten Sprints über-
führt werden kann.
Wie in Kapitel 7 noch genauer ausgeführt wird, werden die meisten PBIs entweder in
Story-Punkten oder in Idealtagen geschätzt. Diese Größenschätzungen müssen einigerma-
ßen akkurat, aber auch nicht übermäßig genau sein. Da Elemente nahe der Spitze des
Backlogs kleiner und detaillierter sind, fallen ihre Schätzungen ebenfalls kleiner und exak-
ter aus. Allerdings ist es in der Regel nicht möglich, numerisch akkurate Schätzungen für
größere Elemente (z.B. Epics) im unteren Teil des Backlogs vorzunehmen. Deshalb ziehen
es manche Teams vor, entweder überhaupt keine Schätzungen für diese Elemente vorzu-
nehmen oder sie in Form von T-Shirt-Maßen anzugeben (L, XL, XXL usw.). Bei der Zerle-
gung der größeren Elemente in kleinere Elementen werden sie dann aber natürlich
ebenfalls wieder mit Zahlenwerten geschätzt.
141
Kapitel 6
Das Product Backlog
ren, wie man glaubt, in Release 1 zu kommen. Grundsätzlich lohnt es sich aber vermutlich
nicht, über diesen Punkt hinaus mehr als eine grobe Priorisierung vorzunehmen.
Wir könnten z.B. erklären, dass ein Element entsprechend unserer Produkt-Roadmap für
Release 2 oder Release 3 gedacht ist. Sollten wir jedoch noch in einer frühen Phase der
Funktionsentwicklung für Release 1 stecken, wäre unsere wertvolle Zeit nicht gut investiert,
wenn wir uns an dieser Stelle Gedanken über die Prioritäten von Funktionen für die Relea-
ses 2 oder 3 machen würden. Möglicherweise kommt es ja gar nicht zu Release 2 oder
Release 3 oder vielleicht ändern wir unser Konzept im Laufe der Entwicklung von Release 1
ganz grundlegend. Dann wäre die Zeit, die wir mit einer Priorisierung so weit entfernter
Elemente verbracht haben, schlicht und ergreifend vergeudet.
Sollten im Laufe einer Entwicklung neue Elemente auftauchen, ist natürlich der Product
Owner dafür verantwortlich, diese an der passenden Stelle in das Backlog einzufügen.
6.4 Pflege
Um ein gutes, den DEEP-Kriterien entsprechendes Product Backlog zu erhalten, müssen
wir es proaktiv organisieren, verwalten, administrieren und pflegen.
142
6.4
Pflege
Abbildung 6.6 veranschaulicht einige spezielle Pflegeaufgaben und zeigt, wie sie die Struk-
tur des Product Backlogs beeinflussen.
Element Größe
3 Schätzen
Element einfügen
Element löschen
Abb. 6.6: Die Pflege (»Grooming«) verändert die Form des Product Backlogs.
Damit ihre Reihenfolge im Backlog bestimmt und entschieden werden kann, ob eine wei-
tere Verfeinerung erforderlich ist, müssen alle PBIs zu gegebener Zeit geschätzt werden.
Ebenso müssen mit dem Bekanntwerden relevanter Informationen neue Elemente erzeugt
und in der richtigen Reihenfolge in das Backlog eingefügt werden. Und wenn sich Prioritä-
ten verschieben, zieht das natürlich eine entsprechende Anpassung der Elementeanord-
nung im Backlog nach sich. Sobald größere Elemente näher heranrücken, müssen wir
diese in eine Ansammlung kleinerer Elemente zerlegen. Wir könnten außerdem entschei-
den, dass ein bestimmtes Element im Product Backlog eigentlich nicht gebraucht wird – in
diesem Fall entfernen wir es.
143
Kapitel 6
Das Product Backlog
Informationen aufgedeckt, die ansonsten verloren gehen. Gute Product Owner wissen
außerdem, dass durch das Einbeziehen verschiedener Teammitglieder in die Pflege sicher-
gestellt wird, dass alle Beteiligten das Product Backlog besser verstehen und weniger Zeit
durch Missverständnisse vergeudet wird. Solche gemeinsamen Anstrengungen sind
zudem gut geeignet, um die seit Langem bestehende Lücke zwischen dem Management
und dem technischen Personal zu schließen.
Interne Stakeholder
(Unternehmenseigentümer, Manager,
Product Owner
Programmmanagement) ScrumMaster
Scrum-Team
Product Backlog
Priorisieren
Anlegen Schätzen
und Verfeinern
Stakeholder sollten sich je nach Art der Organisation und des Projekts ausreichend Zeit für
die Pflege freihalten. Als Faustregel gilt, dass das Entwicklungsteam bis zu 10% seiner Zeit
in einem Sprint reservieren sollte, um dem Product Owner bei der Pflege des Backlogs zur
Hand zu gehen. Das Team nutzt diese Zeit, um beim Anlegen oder der Beurteilung neu
aufgekommener Backlog-Elemente sowie der progressiven Verfeinerung größerer Ele-
mente in kleinere zu helfen. Außerdem schätzt es die Größe der Product-Backlog-Elemente
ein und unterstützt den Product Owner dabei, diese auf der Grundlage der technischen
Abhängigkeiten und Ressourcenbeschränkungen zu priorisieren.
144
6.4
Pflege
Komplette Genehmigte
Anforderungen Grund-
Anforderungen Design Bau Test
genehmigen anforderungen
erfassen
Primärer Workflow
Änderungskontrollprozess
Änderung prüfen Anforderungen
außerhalb des primären Änderungs-
und genehmigen und Pläne
Workflows (ungeplante Arbeit) anfrage
aktualisieren
Zeit
Daher ist die Pflege in einem sequenziellen Entwicklungsverfahren eher die Ausnahme –
eine ungeplante, außerhalb des primären Workflows stattfindende Aktivität, die wir nur
dann durchführen, wenn es unerlässlich ist, weil sie die zügige Auslieferung des Geschäfts-
wertes empfindlich stört.
Wenn wir Scrum einsetzen, gehen wir von einer unsicheren Umgebung aus und müssen
daher darauf vorbereitet sein, ständig zu prüfen und uns anzupassen. Wir erwarten, dass
sich das Product Backlog stetig weiterentwickelt und nicht schon früh feststeht – und auch
nur durch einen sekundären Prozess zum Behandeln von unerwünschten Ausnahmesitua-
tionen geändert werden kann. Aus diesem Grund müssen wir dafür sorgen, dass unsere
Pflegeaktivitäten ein wesentlicher, inhärenter Bestandteil unserer Arbeitsorganisation sind.
Abbildung 6.9 zeigt die unterschiedlichen Zeitpunkte, zu denen die Pflege stattfinden
könnte. Eine erste Pflege ist bereits Teil der Release-Planung (Näheres dazu in Kapitel 18).
Während der Produktentwicklung trifft sich der Product Owner mit den Stakeholdern. Wie
oft dies geschieht, hängt davon ab, wie sinnvoll es für eine vernünftige Pflege ist.
Beim Arbeiten mit dem Entwicklungsteam könnte der Product Owner entweder einen
wöchentlichen oder einen einmal pro Sprint stattfindenden Pflege-Workshop ansetzen.
Dadurch stellt er sicher, dass die Pflege regelmäßig durchgeführt wird. Das Team kann
diese Zeit bei der Sprint-Planung berücksichtigen. Es muss keine Zeit mehr damit ver-
schwendet werden, Ad-hoc-Treffen zu organisieren (um herauszufinden, wann die Leute
Zeit haben, wo ein Raum für das Treffen frei ist usw.).
Manchmal ziehen es Teams auch vor, die Pflege während des gesamten Sprints durchzu-
führen, anstatt einen vorher festgelegten Zeitraum dafür freizuhalten. Sie nehmen sich
nach ihrem Daily Scrum jeweils ein wenig Zeit für kleinere Pflegeaktivitäten, an denen
nicht alle Teammitglieder beteiligt sein müssen. So könnte der Product Owner z.B. nach
145
Kapitel 6
Das Product Backlog
dem Daily Scrum um Hilfe beim Verfeinern einer großen Story bitten und Teammitglieder,
die Bescheid wissen und interessiert sind, bleiben und helfen dem Product Owner. Und
beim nächsten Mal assistieren dann andere Teammitglieder.
Pflege
Potenziell
auslieferungsfähiges
Produktinkrement
Sprint Review
Sprint-Retrospektive
Selbst wenn regelmäßige Workshops stattfinden oder sich das Team jeden Tag ein bisschen
Zeit nimmt, um sich das Backlog anzuschauen, werden die meisten Teams automatisch
auch während des Sprint Reviews ein wenig Pflege betreiben. Denn da alle Beteiligten ein
besseres Verständnis dafür entwickeln, wo das Produkt steht und wohin es sich entwickelt,
werden oft auch neue PBIs erzeugt oder vorhandene PBIs neu priorisiert oder entfernt,
falls sie nicht mehr notwendig sind.
Es ist nicht so wichtig, wann die Pflege stattfindet. Entscheidend ist, dass sie gut in die
Scrum-Entwicklungsabläufe integriert ist, damit eine flexible und schnelle Auslieferung
des Geschäftswertes gewährleistet ist.
146
6.5
Die Definition von Bereit
Bereit Fertig
Pflege
Potenziell
auslieferungsfähiges
Produktinkrement
Sprint Review
Sprint-Retrospektive
Bei beiden Definitionen handelt es sich um Checklisten der Tätigkeiten, die abgeschlossen
werden müssen, bevor man davon sprechen kann, dass ein Product-Backlog-Element den
jeweiligen Zustand angenommen hat. Ein Beispiel für eine Checkliste der Definition von
Bereit sehen Sie in Tabelle 6.2.
S Das Entwicklungsteam hat die Einzelheiten richtig verstanden, so dass es in der Lage
ist, eine fundierte Entscheidung zu treffen, ob es das PBI abschließen kann.
S Abhängigkeiten wurden erkannt und es gibt keine externen Abhängigkeiten, die die
Fertigstellung des PBIs blockieren.
S Das Team hat ausreichend Leute, um das PBI abzuschließen.
S Das PBI ist geschätzt und klein genug, um es in einem Sprint fertigzustellen.
S Das Scrum-Team versteht, wie es das PBI beim Sprint Review demonstrieren soll.
147
Kapitel 6
Das Product Backlog
Eine starke Definition von Bereit verbessert die Chance des Scrum-Teams, das Sprint-Ziel
erfolgreich zu erreichen, ganz beträchtlich.
Element
Must have
Nice to have
Won´t have
148
6.6
Flow Management
Diese zwei Linien unterteilen das Backlog in drei Bereiche: muss man haben, wäre nett und
wird man nicht haben. Die Must-have-Funktionen sind die Elemente, die im kommenden
Release einfach vorhanden sein müssen, weil wir sonst keine brauchbare Kundenversion
bekommen. Die Nice-to-have-Funktionen repräsentieren Elemente, die wir für die nächste
Version anstreben und gern einbinden würden. Falls uns jedoch die Zeit oder andere Res-
sourcen ausgehen, könnten wir die Nice-to-have-Funktionen fallenlassen und hätten trotz-
dem ein brauchbares Produkt. Die Wird-man-nicht-haben-Funktionen sind Elemente, die
wir ausdrücklich nicht in die aktuelle Version aufnehmen werden. Die zweite Linie – also
diejenige, die die Wird-man-nicht-haben-Elemente von den anderen trennt – ist identisch
mit der Release-1-Linie aus Abbildung 6.5.
Ein auf diese Art geführtes Backlog hilft uns auch bei der laufenden Release-Planung, wie
ich in Kapitel 18 erläutern werde.
Flow
Sprint-Planung
Bereit
Abb. 6.12: Das Product Backlog als eine Pipeline aus Anforderungen
149
Kapitel 6
Das Product Backlog
Falls zwischen dem Hinein- und dem Hinausfließen der Elemente jemals eine Unstimmig-
keit auftritt, haben wir ein Problem: Rücken die gepflegten, detaillierten und zur Umset-
zung bereiten Elemente zu langsam nach, trocknet die Pipeline irgendwann aus und das
Team kann den nächsten Sprint nicht mehr planen und ausführen (eine große Unterbre-
chung oder gar Verschwendung des Scrum-Workflows). Bringt man andererseits zu viele
Elemente zur Verfeinerung in die Pipeline, wird ein großer Bestand an detaillierten Anfor-
derungen geschaffen, den wir überarbeiten oder verwerfen müssen, wenn wir irgendwann
über weiterführende Informationen verfügen (ein großer Quell der Verschwendung). Die
ideale Situation besteht deshalb darin, gerade genügend Elemente im Product Backlog zu
haben, um einen gleichmäßigen Flow zu erzeugen, aber nicht so viele, dass etwas ver-
schwendet wird.
Scrum-Teams gehen deshalb unter anderem so vor, dass sie einen angemessenen Bestand
an gepflegten und zur Umsetzung bereiten Elementen im Backlog haben. Eine Heuristik,
die für viele Teams zu funktionieren scheint, ist, dass man Stories für etwa zwei bis drei
Sprints bereithält. Falls das Team z.B. etwa 5 PBIs pro Sprint erledigen kann, dann stellt es
sein Backlog bei der Pflege so ein, dass jederzeit 10 bis 15 PBIs bereit sind. Dieser zusätzli-
che Bestand stellt sicher, dass die Pipeline nicht leerläuft und bietet dem Team außerdem
die nötige Flexibilität, falls es aus Kapazitätsgründen oder anderen sprintspezifischen Ein-
schränkungen außer der Reihe PBIs auswählen muss (mehr dazu in Kapitel 19).
150
6.7
Welche und wie viele Product Backlogs?
übermäßig vereinfacht erscheinen mag, wollen wir sie hier einmal als Ausgangspunkt
benutzen. Ein Produkt ist etwas von Wert, für das ein Kunde etwas bezahlen würde und das
wir einpacken und verkaufen würden.
Word Office
Excel
Outlook
Abb. 6.13: Das Product Backlog ist mit dem Produkt verknüpft.
Die Anwendung dieser Regel wird komplizierter, wenn wir Komponententeams bilden,
deren Zweck es ist, eine Komponente eines größeren Produkts zu schaffen, das ein Kunde
kaufen würde (in Kapitel 12 finden Sie eine ausführlichere Diskussion zu den Komponen-
tenteams). Als ich z.B. mein portables GPS erwarb, kaufte ich nicht den Routenplaner-
Algorithmus, sondern ein portables Gerät, das mir akkurate grafische und auditive Rich-
tungsanweisungen geben würde. Die Routenplaner-»Komponente« war einfach eine von
vielen, die zusammen ein Gerät bildeten, das ein Kunde wie ich kaufen würde.
Gibt es ein Product Backlog für die Routenplaner-Komponente, falls der GPS-Hersteller ein
entsprechendes Team gebildet hat, um diese Komponente zu entwickeln? Oder gibt es nur
ein Product Backlog für das gesamte GPS, in das die Funktionen zur Routenplanung einge-
woben sind?
Noch interessanter ist die Fragestellung: Was wäre, wenn die Routenplaner-Komponente in
mehrere GPS-Produkte (jeweils mit einer eigenen PID) eingebunden werden könnte?
Wären wir eher geneigt, ein eigenes Product Backlog für eine Komponente zu schaffen,
wenn diese in mehreren Geräteprodukten eingesetzt werden könnte?
151
Kapitel 6
Das Product Backlog
Sie sehen: Wenn wir erst einmal anfangen, diese Fragen zu stellen, können wir immer tie-
fer graben. Um uns aus dieser Abwärtsspirale zu befreien, sollten wir daran denken, dass
es unser Ziel ist, die Anzahl der Komponententeams und damit den Bedarf für Komponen-
ten-Product-Backlogs zu minimieren. Konzentrieren Sie sich auf das, was Sie herstellen,
um es zu verpacken, auszuliefern und damit den Kunden zu erfreuen, und passen Sie Ihr
Product Backlog entsprechend an.
Bereichs-Backlogs Bereichsteams
Product Backlog
152
6.7
Welche und wie viele Product Backlogs?
Ganz oben in der Hierarchie haben wir weiterhin das eine Product Backlog, das sehr grob
die Funktionalität (möglicherweise in Form eines Epics) des Produkts beschreibt. Auf die-
ser Ebene gäbe es dann auch den Chief Product Owner, wie ich in Kapitel 9 näher erläutern
werde. Alle zusammengehörenden Funktionsbereiche besitzen jeweils ein eigenes Back-
log. Der Audiovideo-Player-Bereich hat also ein Backlog, das die PBIs für die sieben Teams
enthält, die in diesem Bereich arbeiten. Die PBIs auf Funktionsebene sind wahrscheinlich
im Verhältnis kleiner (Funktions- oder Story-Größe) als die entsprechenden Elemente im
Product Backlog. In Kapitel 12 stelle ich das Release-Train-Konzept vor, das auf einem drei-
stufigen Unternehmens-Backlog-Modell beruht: Portfolio-Backlog (enthält Epics), Pro-
gramm-Backlog (enthält die Funktionen) und die Team-Backlogs (enthalten sprintfähige
User Stories).
153
Kapitel 6
Das Product Backlog
Teamspezifische Sicht
des Product Backlogs Nicht austauschbare Teams
Team A
Product Backlog
Team B
Team C
154
6.8
Abschließende Bemerkungen
Produkt A Produkt A
Ein Team
Produkt B Produkt B
Produkt C Produkt C
Selbst wenn wir uns dafür entscheiden, drei getrennte Product Backlogs vorzuhalten, muss
in jedem Sprint jemand (vorzugsweise der Product Owner für das Team) eine priorisierte
PBI-Auswahl aus den drei Backlogs zusammenstellen (möglicherweise basierend auf der
Zeit, die das Team während des Sprints für die einzelnen Produkte aufwenden möchte)
und diese dem Team vorlegen, damit es darüber befinden kann.
155
Kapitel 7
In diesem Kapitel beschreibe ich die Konzepte der Schätzung und der Velocity (Entwick-
lungsgeschwindigkeit). Ich beginne zunächst mit einem Überblick über den wichtigen
Stellenwert, den sie in der agilen Planung einnehmen, und erkläre dann, welche verschie-
denen Elemente wir schätzen sowie wann und wie wir das tun. Der Großteil dieses Kapitels
konzentriert sich darauf, wie sich Product-Backlog-Elemente schätzen lassen, wie man eine
geeignete Maßeinheit wählt und wie man den Planungspoker »spielt«. Im Anschluss daran
stelle ich das Konzept der Velocity vor und erläutere, welche Bedeutung ein Velocity-
Bereich für die Planung hat und wie neue Teams trotz fehlender historischer Daten die
Velocity vorhersagen können. Zum Schluss gehe ich außerdem auf einige Methoden zur
Beeinflussung der Velocity ein und zeige auf, welche Arten des Missbrauchs der Velocity es
gibt.
7.1 Überblick
Wenn wir die Entwicklung eines Produkts planen und organisieren, müssen wir wichtige
Fragen beantworten, wie etwa: »Wie viele Funktionen werden abgeschlossen?«, »Wann
werden wir fertig sein?« und »Wie viel wird das kosten?«. Um diese Fragen mithilfe von
Scrum zu beantworten, müssen wir die Größe des zu bauenden Produkts schätzen und die
Velocity oder Rate messen, in der wir die Arbeit fertigstellen können. Auf der Grundlage
dieser Informationen können wir dann die wahrscheinliche Dauer der Produktentwicklung
(und die entsprechenden Kosten) ableiten, indem wir die geschätzte Größe eines Funk-
tionssatzes durch die Velocity des Teams teilen.
Wie viel Zeit brauchen wir unter Zugrundelegung des Product Backlogs in Abbildung 7.1,
um die Features aus Release 1 zu erstellen? Um diese Frage zu beantworten, müssen wir
zuerst die Größe von Release 1 schätzen. Dazu addieren wir die einzelnen Größenschätzun-
gen für die jeweiligen PBIs, die für Release 1 vorgesehen sind. (In unserem Beispiel beträgt
die Summe der PBI-Schätzungen 200 Punkte.)
Sobald wir die ungefähre Größe der Version kennen, wenden wir unsere Aufmerksamkeit
der Velocity des Teams zu, also der Frage, wie viel Arbeit das Team typischerweise in einem
Sprint erledigen kann. Die Velocity, sprich die Entwicklungsgeschwindigkeit, lässt sich
leicht messen: Am Ende jedes Sprints addieren wir einfach die Größenschätzungen aller
Elemente, die während des Sprints abgeschlossen wurden. Wurde ein Element nicht been-
det, dann fließt es nicht in die Velocity ein. Die Summe der Größen aller abgeschlossenen
Product-Backlog-Elemente in einem Sprint gibt die Velocity des Teams für diesen Sprint
an. Das Diagramm in Abbildung 7.1 zeigt die Velocity-Daten des Teams für die vergange-
nen sieben Sprints. Die durchschnittliche Velocity liegt bei 20.
157
Kapitel 7
Schätzung und Velocity
Nachdem wir die Größe geschätzt und die Velocity gemessen haben, können wir die Dauer
berechnen bzw. ableiten. Dazu teilen wir die Größe durch die Velocity. Beträgt die Größe
von Release 1 200 Punkte und kann das Team im Durchschnitt pro Sprint 20 Punkte
abschließen, dann sollte es 10 Sprints dauern, bis das Team Release 1 beendet hat (in Kapi-
tel 18 finden Sie eine ausführlichere Beschreibung der Release-Planung). Ich werde später
in diesem Kapitel erklären, wieso ein Velocity-Bereich für diese Berechnungen genauer ist
als ein durchschnittlicher Velocity-Wert. Zur Illustration habe ich hier jedoch den Durch-
schnitt der Velocity verwendet.
Funktion ZX | 5 10
5
Funktion ZY | 2
Release 1 0
1 2 3 4 5 6 7
Funktion ZZ | 1
Funktion … |…
Obwohl sich die grundlegende Beziehung zwischen Größe, Velocity und Dauer nicht
ändert, können einige Details variieren. Das hängt davon ab, an welcher Stelle in der Ent-
wicklung Sie stehen, was Sie zu messen versuchen und wie Sie die Daten einsetzen wollen.
Schauen wir uns die Schätzung und die Velocity einmal genauer an, um herauszufinden,
wie sich diese Faktoren in Abhängigkeit von Ihren Aktionen ändern.
158
7.2
Was und wann wir schätzen
log, im Product Backlog und im Sprint Backlog nieder. Betrachten wir das einmal etwas
genauer.
Produkt D l L
Icons anlegen Puffertest
Stunden = 8 Stunden = 2
7.2.2 Product-Backlog-Schätzungen
Sobald jedoch ein Produkt oder Projekt befürwortet wurde und wir beginnen, weitere
Details zu seinen Product-Backlog-Elementen hinzuzufügen, müssen wir anders schätzen.
Wenn PBIs eine höhere Priorität bekommen haben und mehr Details enthalten, vergeben
die meisten Teams numerische Größenschätzungen in Form von Story-Punkten oder Ideal-
tagen. Ich werde beide Ansätze später in diesem Kapitel erläutern.
159
Kapitel 7
Schätzung und Velocity
Das Schätzen von PBIs ist Teil der Pflege des Product Backlogs. Abbildung 6.9 zeigt, wann
diese Pflege normalerweise stattfindet. Typischerweise wird die Schätzung in »Schätzsit-
zungen« oder »Schätzklausuren« durchgeführt. Die erste dieser Sitzungen fällt vermutlich
mit der ersten Release-Planung zusammen. Darüber hinaus kann der Product Owner auch
während eines Sprints zusätzliche Schätzsitzungen einberufen, falls neue PBIs geschätzt
werden müssen.
Nicht alle Anwender von Scrum sind der Meinung, dass die Größenschätzung von PBIs
notwendig ist. Ihrer Erfahrung nach können Scrum-Teams auch so gut sein, dass sie es
schaffen, PBIs anzulegen, die klein und alle ungefähr gleich groß sind. Sie halten es für
überflüssig, kleine Elemente ähnlicher Größe zu schätzen. Stattdessen zählen sie die PBIs
einfach. Das Konzept der Velocity nutzen sie zwar, allerdings messen sie sie als die Anzahl
der PBIs, die in einem Sprint abgeschlossen werden, und nicht als die Summe der Größen
der PBIs, die in einem Sprint beendet werden.
Ich verstehe das »Wir brauchen keine Schätzungen«-Argument, ziehe es aber dennoch aus
mehreren Gründen vor, PBIs zu schätzen:
쐽 Wie ich in Kapitel 5 bereits erwähnt habe, werden nicht alle PBIs zum selben Zeitpunkt
die gleiche Größe haben, so dass es im Backlog ohnehin einige größere PBIs geben
wird, auch wenn wir an der Spitze des Backlogs eine Sammlung kleinerer Elemente
ähnlicher Größe haben.
쐽 Es kann einige Zeit dauern, bis Teams die Fähigkeit besitzen, PBIs in ungefähr dieselbe
Größe zu zerlegen.
쐽 Möglicherweise müssen Teams Stories an unnatürlichen Stellen teilen, um zu errei-
chen, dass sie dieselbe Größe bekommen.
쐽 Und schließlich – und das ist vermutlich am wichtigsten – findet durch die Schätzsit-
zungen auch ein Lernprozess statt. Nichts fördert eine gesunde Debatte so sehr wie die
Forderung, etwas mit Zahlen zu unterlegen. Dabei werden ganz zwangsläufig Unstim-
migkeiten und Hypothesen zutage gefördert. Würden wir auf die Schätzung verzichten,
müssten wir eine andere Methode finden, um diese gesunden Diskussionen anzure-
gen.
7.2.3 Aufgabenschätzungen
Auf der Ebene mit den meisten Details haben wir die Aufgaben, die sich im Sprint Backlog
befinden. Die meisten Teams nehmen die Einschätzung ihrer Aufgaben während der
Sprint-Planung vor, damit sie das Vertrauen gewinnen, dass die Verpflichtungen, die sie
eingehen wollen, auch vernünftig sind (mehr dazu in Kapitel 19).
Aufgaben werden in Idealstunden (auch als Personenstunden, früher: Mannstunden
bezeichnet) gemessen. In Abbildung 7.2 schätzt das Team, dass die Benutzerschnittstellen-
aufgabe fünf Personenstunden in Anspruch nehmen wird. Das bedeutet aber nicht, dass es
fünf Zeitstunden dauert. Eine Person könnte mehrere Tage brauchen, um die Benutzer-
schnittstelle zu programmieren, mehrere Personen, die zusammenarbeiten, brauchen viel-
leicht weniger als einen Tag. Die Schätzung sagt lediglich aus, wie viel Aufwand das Team
aufbringen muss, um die Aufgabe abzuschließen. Ich werde den Einsatz von Aufgaben-
schätzungen in Kapitel 19 näher beschreiben, wenn es um die Details der Sprint-Planung
geht.
160
7.3
Schätzkonzepte für Product-Backlog-Elemente
PBI-Schätzkonzepte
161
Kapitel 7
Schätzung und Velocity
Product Backlog
Funktion A
Funktion B
Funktion C
Schätzen
Schätzen gemeinsam
Abb. 7.5: Der Effekt der Verpflichtung auf die Einhaltung von Schätzwerten
162
7.3
Schätzkonzepte für Product-Backlog-Elemente
Anschließend sage ich so etwas wie: »Ach übrigens, ich vergaß zu erwähnen, dass Ihr
gesamter Bonus des nächsten Jahres davon abhängt, ob Ihre Schätzung korrekt ist. Also
gebe ich Ihnen jetzt die Gelegenheit, Ihre Schätzung zu revidieren.« An dieser Stelle führe
ich meine Hände immer weiter auseinander, um zunehmend größere Schätzwerte anzu-
deuten (wie in Abbildung 7.5 rechts). Und dann füge ich ergänzend noch etwa Folgendes
hinzu: »Sagen Sie mir, wann ich aufhören soll. Meine Arme sind ja nicht endlos lang, ich
bin schließlich kein Basketballspieler!«
Der springende Punkt dabei ist: Wenn ich die Leute bitte, die Größe einer Story zu schät-
zen, dann erwarte ich ein realistisches Ergebnis. Aber wenn ich darüber hinaus erwähne,
dass ihre Boni von der Korrektheit der Schätzung abhängen, dann wird jeder, auch ich
selbst, eine viel höhere Schätzung abgeben als die, die er anfangs für richtig gehalten hat.
Die Schätzwerte sollen ein realistisches Maß dafür darstellen, wie groß bzw. umfangreich
etwas ist. Wir wollen sie nicht künstlich aufblähen, nur weil wir von außen beeinflusst wer-
den – das würde lediglich zu überdimensionierten Zeitplänen und einem Hin und Her aus
übertriebenen Schätzungen der Teammitglieder auf der einen und Versuchen des Manage-
ments, diese Werte zu reduzieren, auf der anderen Seite führen. Und am Ende hätten wir
dann überhaupt keine realistischen Zahlen, weil sie viel zu oft von unterschiedlichen Leu-
ten manipuliert wurden.
163
Kapitel 7
Schätzung und Velocity
Wie Abbildung 7.7 zeigt, ist die Einschätzung des Größenverhältnisses der verschiedenen
Gläser zueinander noch recht einfach, allerdings könnte ich nicht mit Sicherheit sagen,
welche absolute Flüssigkeitsmenge die einzelnen Gläser tatsächlich enthalten.
50%
0%
Aufwand
1X 4X 9X
Abb. 7.7: Relative Größenschätzung
164
7.3
Schätzkonzepte für Product-Backlog-Elemente
Meinen eigenen Beobachtungen zufolge bin ich überzeugt, dass der Mensch bei relativen
Größenschätzungen generell deutlich besser abschneidet als bei absoluten Größenschät-
zungen. Abbildung 7.8 zeigt ein Beispiel, das ich in meinen Kursen nutze, um diese These
zu untermauern.
Dazu gehe ich zur einen Seite des Raumes und wende mich der gegenüberliegenden Wand
zu. Dann bitte ich die Teilnehmer, in absoluten Größeneinheiten (z.B. Metern) aufzu-
schreiben, wie weit ich ihrer Meinung nach von der entgegengesetzten Wand entfernt bin.
(Die Leute, die nach oben schauen, um die Deckenplatten zu zählen, fordere ich auf, nicht
zu schummeln!)
In vielen Kursräumen ist ungefähr in der Mitte der Decke ein LCD-Projektor montiert. Des-
halb bitte ich sie außerdem aufzuschreiben, in welcher relativen Position sich der Projektor
zur entfernten Wand und zu mir befindet.
Dabei kommen fast immer die gleichen Ergebnisse zustande. Wenn ich in einem typischen
Kurs mit 30 Leuten frage: »In welcher absoluten Entfernung befinde ich mich zu der ande-
ren Wand?«, bekomme ich üblicherweise 27 unterschiedliche Antworten. Wenn ich dage-
gen frage: »In welcher relativen Position befindet sich der Projektor zwischen mir und der
entgegengesetzten Wand?«, dann antworten 29 von 30 Leuten: »Etwa auf der Hälfte«, wäh-
rend die dreißigste Person mich veralbern will und so etwas sagt wie »5/11 der Strecke!«.
Natürlich handelt es sich hierbei nicht um ein lupenreines wissenschaftliches Experiment,
dennoch stimmen mir die meisten Leute zu, dass sie tatsächlich besser darin sind, relative
165
Kapitel 7
Schätzung und Velocity
Größen zu beurteilen als absolute. Auch wenn es vorkommt, dass der Projektor ein Drittel
oder zwei Drittel der Raumlänge von mir entfernt ist, sind die Ergebnisse bei der relativen
Schätzung normalerweise korrekt.
Wenn wir also jemanden auffordern, etwas zu schätzen, sollten wir die dafür zu verwen-
dende Technik auf dem aufbauen, was die Leute gut können (relative Größenschätzung)
und nicht auf dem, was sie nicht gut können (absolute Größenschätzung).
7.4.1 Story-Punkte
Story-Punkte messen die Größe bzw. den Umfang eines Product-Backlog-Elements. Sie
können durch mehrere Faktoren wie Komplexität und physische Größe beeinflusst werden.
Es bedarf nicht unbedingt physischer Größe, damit etwas als groß bezeichnet werden kann.
So könnte die Story beispielsweise die Entwicklung eines komplexen Unternehmensalgo-
rithmus repräsentieren. Das Endergebnis muss dabei nicht unbedingt sehr groß ausfallen,
der Aufwand, der nötig ist, um sie zu entwickeln, könnte es aber durchaus sein. Anderer-
seits könnte eine Story zwar physisch sehr groß, aber nicht sehr komplex sein. Nehmen wir
an, wir müssten alle 60.000 Zellen in einer Kalkulationstabelle aktualisieren. Keine der
einzelnen Aktualisierungen ist schwierig, aber sie können nicht automatisiert werden. Wie
viel dieser Arbeit können wir in einem Sprint schaffen? Die Story ist also nicht komplex,
aber dennoch umfangreich und somit groß.
Story-Punkte kombinieren Faktoren wie Komplexität und physische Größe zu einem relati-
ven Größenmaß. Ziel ist es dabei, am Ende Stories vergleichen und Dinge sagen zu können
wie: »Na ja, wenn die Ticket-herstellen-Story eine 2 ist, dann ist die Nach-Ticket-suchen-
Story eine 8.« Es wird also implizit ausgesagt, dass die Such-Story etwa viermal größer ist
als die Herstellungs-Story.
In dem Beispiel am Anfang dieses Kapitels wurde der Ansatz verfolgt, die PBI-Größen zu
schätzen und dann die Dauer abzuleiten, indem die Summe der Größen durch die durch-
schnittliche Velocity dividiert wurde. Da Größenmaße genau wie Story-Punkte irgendwann
dazu benutzt werden, eine Zeit (Dauer) zu berechnen, müssen die Story-Punkte den Auf-
wand widerspiegeln, der aus Sicht des Entwicklungsteams mit der Story verbunden ist.
7.4.2 Idealtage
Einen alternativen Ansatz zum Schätzen von PBIs bieten Idealtage. Idealtage sind eine ver-
traute Einheit: Sie repräsentieren die Anzahl der Personentage, die benötigt werden, um
eine Story abzuschließen. Die Idealzeit ist nicht das Gleiche wie die verstrichene Zeit. So
besteht beispielsweise ein American-Football-Spiel im Idealfall aus vier Vierteln, die jeweils
166
7.5
Planungspoker
15 Minuten lang sind (das Spiel wird also in einer Idealstunde gespielt). Allerdings dauert
ein Spiel tatsächlich in der Regel eher drei bis dreieinhalb Stunden.
Ich sagte ja bereits, dass es keine richtige oder falsche Antwort gibt, wenn man sich zwi-
schen Story-Punkten und Idealtagen entscheidet. Ein wichtiges Argument gegen die Ideal-
zeit ist allerdings das Risiko der Fehlinterpretation.
Nehmen wir z.B. an, es wäre Dienstag, früher Nachmittag, und ich zeige Ihnen ein PBI
und frage: »Wie groß ist dieses PBI?« Sie antworten: »Zwei Tage.« Darauf sage ich: »Okay,
Sie können also Donnerstag am frühen Nachmittag fertig sein.« Sie entgegnen nun: »Nein,
ich bin heute Nachmittag und morgen [Mittwoch] noch mit einer Zwei-Tage-Aktivität
beschäftigt. Dafür brauche ich den ganzen Tag, also kann ich wahrscheinlich am Donners-
tag mit diesem Element anfangen. Da ich aber nicht den ganzen Tag für das PBI Zeit habe,
schätze ich, dass ich irgendwann am nächsten Montag fertig sein werde.« Ich sage darauf-
hin: »Das verstehe ich nicht. Sie haben doch von einem Zwei-Tage-PBI gesprochen, dann
müssten Sie doch am Donnerstag fertig sein.« Und schließlich erklären Sie: »Ich habe von
zwei Idealtagen gesprochen, nicht von Kalendertagen. Bilden Sie meine Idealtage bitte
nicht auf Kalendertage ab. Das funktioniert nicht.«
Die 30% der Organisationen, mit denen ich arbeite, die erfolgreich die Idealzeit einsetzen,
würden das folgendermaßen kommentieren: »Tja, aber wir haben das Problem mit der
Fehlinterpretation gar nicht. Wenn wir den Leuten sagen, dass es zwei Tage dauert, dann
wissen sie, dass es sich nicht um zwei Kalendertage handelt.«
Wenn in Ihrer Organisation lediglich ein geringes Risiko besteht, dass es bei derartigen
Zeitangaben zu Missverständnissen kommt, könnte die Idealzeit ganz gut funktionieren.
Sollten Sie jedoch glauben, dass sie fehlinterpretiert werden könnten, dann sollten Sie bes-
ser Story-Punkte verwenden.
Es gibt zwar noch weitere Unterschiede zwischen Story-Punkten und Idealzeit, die Fehlin-
terpretation stellt allerdings definitiv eins der größten Probleme dar. Eine meiner Kursteil-
nehmerinnen fasste ihre Meinung zu diesem Thema gegenüber ihren Kollegen einmal so
zusammen: »Wir haben die Idealzeit in den ganzen 15 Jahren benutzt, die ich hier arbeite,
und das hat nie funktioniert. Ehrlich, ich würde gern mal etwas anderes ausprobieren.«
7.5 Planungspoker
Der Planungspoker ist eine Technik zum Schätzen von Product-Backlog-Elementen, die
zuerst von James Grenning (Grenning 2002) beschrieben und dann von Mike Cohn (Cohn
2006) bekannt gemacht wurde. Diese Methode basiert auf einigen wichtigen Konzepten
(siehe Abbildung 7.9).
Beim Planungspoker handelt es sich um eine konsensbasierte Technik zur Aufwands-
schätzung. Sachkundige Leute (die Experten), die eingeteilt wurden, an einem Product-
Backlog-Element zu arbeiten, führen eine intensive Diskussion, um Hypothesen zu erar-
beiten, zu einem Konsens zu gelangen und die Größe der PBIs zu bestimmen. Der Pla-
nungspoker ergibt relative Größenschätzungen, indem Elemente ähnlicher Größe akkurat
gruppiert oder zusammengefasst werden. Und das Team macht sich dabei seine bereits
vorhandenen Erkenntnisse über die PBI-Schätzwerte zunutze, um die nächste Elemente-
gruppe zu schätzen.
167
Kapitel 7
Schätzung und Velocity
Konsensbasiert
Expertenmeinung
Intensive Diskussion
Planungspokerkonzepte
Relative Größenschätzungen
Akkurate Gruppierung/Zusammenfassung
7.5.1 Schätzskala
Um Planungspoker zu »spielen«, muss das Team entscheiden, welche Skala oder Abfolge
von Zahlen für die Zuweisung der Schätzwerte benutzt werden soll. Da wir genau, aber
nicht übermäßig präzise sein wollen, verwenden wir nicht alle Zahlen. Stattdessen bevor-
zugen wir eine Skala, die am unteren Ende des Bereichs mehr Zahlenwerte ausweist, wäh-
rend sie zum anderen Ende hin seltener werden und weiter auseinanderliegen.
Die am häufigsten verwendete Skala wurde von Mike Cohn vorgeschlagen und beruht zum
Teil auf einer abgewandelten Fibonacci-Folge: 1, 2, 3, 5, 8, 13, 20, 40 und 100. Eine alterna-
tive Skala, die manche Teams einsetzen, basiert auf Zweierpotenzen: 1, 2, 4, 8, 16, 32, ...
Wenn wir eine derartige Skala verwenden, fassen wir ähnlich große PBIs zusammen und
weisen ihnen dieselbe Zahl auf der Skala zu. Um dieses Konzept zu verdeutlichen, sollten
wir uns vorstellen, wir würden auf dem Postamt arbeiten und müssten Pakete ähnlicher
Größe in dieselbe Kiste legen (siehe Abbildung 7.10).
Wenn wir ein Paket erhalten, müssen wir entscheiden, in welche Kiste wir es legen. Nicht
alle Pakete in einer Kiste werden exakt dieselbe Form, Größe oder Gewicht haben. Deshalb
müssen wir die Pakete untersuchen, die sich momentan in der Kiste befinden, um die am
besten passende Kiste für das einzuordnende Paket zu finden, das wir gerade schätzen.
Sobald wir diese Kiste identifiziert haben, legen wir das Paket hinein und gehen dann zum
nächsten Paket über. und je mehr Pakete wir in die Kisten legen, umso einfacher wird es
natürlich auch, künftige Pakete zu gruppieren, weil wir immer mehr Vergleichspunkte
haben.
Um eine übermäßige Präzision zu vermeiden, haben wir keine »4-Kiste« (falls unsere
Skala auf der Fibonacci-Folge beruht). Wenn wir also zu einem Paket kommen, das unserer
Meinung nach größer als 2, aber kleiner als 8 ist, müssen wir es entweder in die »3-Kiste«
oder die »5-Kiste« legen.
168
7.5
Planungspoker
3 5
1 2
169
Kapitel 7
Schätzung und Velocity
Karte Interpretation
0 Nicht in Abbildung 7.11 zu sehen, aber in manchen Spielen zu finden. Zeigt
an, dass das Element bereits abgeschlossen wurde oder so klein ist, dass es
sinnlos wäre, ihm einen Größenwert zuzuweisen.
1/2 Wird für winzig kleine Elemente benutzt.
1, 2, 3 Wird für kleine Elemente benutzt.
5, 8, 13 Wird für mittelgroße Elemente benutzt. Für viele Teams ist 13 der größte Wert,
den sie in einen Sprint eintakten würden. Elemente, die größer als 13 sind,
würden in kleinere Elemente zerlegt.
20, 40 Wird für große Elemente benutzt (Stories auf Funktions- oder Theme-Ebene).
100 Entweder eine sehr große Funktion oder ein Epic.
(unend- Zeigt an, dass das Element so groß ist, dass es sinnlos wäre, ihm einen Wert
lich) zuzuweisen.
? (Frage- Zeigt an, dass ein Teammitglied das Element nicht versteht, so dass der Pro-
zeichen) duct Owner gefordert ist, für weitere Klärung zu sorgen. Manche Teammitglie-
der nutzen das Fragezeichen auch als eine Methode, um sich aus der
Schätzung des aktuellen Elements herauszuhalten – meist, weil die betref-
fende Person so wenig mit dem Element zu tun hat, dass sie keine Ahnung hat,
wie sie es schätzen soll. Es ist zwar, akzeptabel, nicht zu schätzen, nicht akzep-
tabel ist dagegen, sich gar nicht zu beteiligen! Nur weil sich jemand nicht wohl
dabei fühlt, eine Schätzung abzugeben, darf er sich dem Gespräch oder der
Verantwortung gegenüber dem Team, einen Konsens bei der Schätzung zu
erreichen, nicht gänzlich entziehen.
q (pi) In diesem Kontext bedeutet q nicht 3,1415926! Vielmehr wird die Pi-Karte
benutzt, wenn ein Teammitglied sagen möchte: »Ich bin müde und hungrig
und möchte Kuchen [pie] essen!« Bei manchen Planungspokerspielen gibt es
dafür eine Karte mit einer Kaffeetasse. In jedem Fall weist die Karte jedoch auf
einen wichtigen Punkt hin: Die Teammitglieder können sich nur eine
begrenzte Zeit in eine intensive Diskussion über die Schätzungen einbringen
(vielleicht eine oder zwei Stunden). Irgendwann brauchen sie eine Pause, sonst
besteht die Gefahr, dass der Enthusiasmus für die Diskussion in das Bestreben
umschlägt, die Schätzungen so schnell wie möglich hinter sich zu bringen –
egal, wie exakt sie sind oder was man daraus lernen könnte. Wenn die Pi-Karte
ausgespielt wird, braucht das Team eine Pause.
Tabelle 7.1: Allgemeine Interpretation der Planungspokerkarten
170
7.6
Was ist Velocity?
5. Wählen alle die gleiche Karte, herrscht Konsens. Diese Konsenszahl ist dann der PBI-
Schätzwert.
6. Sind die Schätzwerte nicht identisch, beginnen die Teammitglieder eine konzentrierte
Diskussion, um Hypothesen aufzustellen und Missverständnisse aufzudecken. Typi-
scherweise werden diejenigen mit sehr hohen und sehr niedrigen Schätzwerten gebe-
ten, ihre Entscheidungen zu erklären oder zu rechtfertigen.
7. Nach der Diskussion kehren wir zu Schritt 3 zurück und wiederholen ihn, bis ein Kon-
sens erreicht wird.
Beim Planungspoker ermitteln wir keine Durchschnittswerte oder benutzen Zahlen, die
nicht auf der Skala/den Karten stehen. Das Ziel ist es nicht, Kompromisse zu machen, son-
dern aus Sicht des Teams einen echten Konsens über die geschätzte Gesamtgröße (den
geschätzten Aufwand) der Story zu schaffen. Normalerweise erreicht man diesen Konsens
in zwei oder drei Abstimmrunden. Die konzentrierte Diskussion der Teammitglieder hilft
dabei, ein gemeinsames Verständnis von der Story zu entwickeln.
7.5.3 Vorteile
Der Planungspoker bringt die sehr unterschiedlichen Leute des Teams, das die Arbeit erle-
digen soll, zusammen und erlaubt es ihnen, einen Konsens über die genaue Schätzung zu
erreichen. Oft ist dieses Ergebnis viel besser als alles, was eine einzelne Person schaffen
könnte.
Wie ich bereits erwähnte, gibt es in der agilen Gemeinde Leute, die glauben, dass sich das
Schätzen von PBIs nicht lohnt. Die intensive Diskussion der PBIs, die durch den Planungs-
poker gefördert wird, ist jedoch unglaublich wertvoll. Meiner Erfahrung nach motivieren
Sie die Leute wirklich, über die Details der Product-Backlog-Elemente nachzudenken und
alle Annahmen und Hypothesen auf den Tisch zu legen, wenn Sie sie auffordern, sie mit
Zahlen zu unterlegen.
Der größte Nutzen, den man mit dem Planungspoker verbindet, liegt in der Diskussion
und dem besseren Verständnis, das die Teammitglieder in Bezug auf die PBIs entwickeln.
Ich hoffe natürlich auch immer auf gute Schätzwerte, wünsche mir aber noch mehr, dass
sie etwas über die PBIs lernen. Wenn sie das tun, werden die Bemühungen des Teams
irgendwann reiche Früchte tragen.
171
Kapitel 7
Schätzung und Velocity
geschäftlichen Wert als die Fertigstellung eines PBIs der Größe 3. Möglicherweise hat das
PBI der Größe 3 einen hohen Wert, weshalb wir früh daran arbeiten (wegen seines hohen
Wertes und seiner niedrigen Kosten), während wir mit der Arbeit an einem PBI der Größe
8 erst später beginnen (weil es einen niedrigeren Wert und dafür höhere Kosten besitzt).
Die Velocity erfüllt zwei wichtige Zwecke: Erstens stellt sie ein wesentliches Konzept für die
Scrum-Planung dar. Für die Planung auf Release-Ebene, wie in Abbildung 7.1 gezeigt, tei-
len wir die Größe des Release durch die durchschnittliche Velocity des Teams, um die
Anzahl der Sprints zu berechnen, die nötig sind, um das Release fertigzustellen. Bei der
Sprint-Planung wird die Velocity eines Teams außerdem als Eingabewert benutzt, um seine
Kapazität für den kommenden Sprint zu ermitteln (mehr dazu in Kapitel 19).
Und zweitens liefert die Velocity einen diagnostischen Maßstab, anhand dessen das Team
seinen Einsatz von Scrum zur Lieferung von Kundenwerten beurteilen und verbessern
kann. Indem das Team seine Velocity über die Zeit beobachtet, kann es sich einen Über-
blick darüber verschaffen, wie bestimmte Prozessänderungen die Lieferung eines messba-
ren Kundenwerts beeinflussen.
Funktion ZX | 5 10
5
Funktion ZY | 2
Release 1 0
1 2 3 4 5 6 7
Funktion ZZ | 1
Funktion … |…
172
7.8
Die Velocity vorhersagen
Mit einem Velocity-Bereich können wir genauere Antworten auf Fragen liefern wie: »Wann
werden wir fertig sein?«, »Wie viele Elemente können wir abschließen?« oder »Wie viel
wird das alles kosten?« Da die meisten dieser Fragen bereits frühzeitig in einer Produktent-
wicklung aufkommen werden, also wenn wir die wenigsten Informationen über das Pro-
dukt besitzen, ist es unmöglich, eine sehr präzise Antwort zu geben. Mithilfe eines
Bereichs können wir diese Unsicherheit ausdrücken (siehe Abbildung 7.12).
In diesem Beispiel (einer Revision von Abbildung 7.1) wird nicht der genaue Sprint
bestimmt, in dem alle Elemente in dieser Version abgeschlossen sein werden (was wir ver-
mutlich nur raten könnten), sondern ein Bereich angegeben, um die Frage zu beantworten.
Um diesen Bereich zu berechnen, brauchen wir für unser Team zwei Velocity-Werte. Teilen
wir die Release-Größe durch die schnellere Velocity des Teams, erhalten wir die kleinstmög-
liche Anzahl an erforderlichen Sprints. Und wenn wir die Release-Größe durch die langsa-
mere Velocity teilen, erhalten wir die maximale Anzahl an Sprints.
Mittels einfacher Mathematik (wie hohe und niedrige Durchschnitte, 90%-Konfidenzinter-
valle usw.) können wir aus den historischen Velocity-Daten unseres Teams ganz leicht zwei
Velocity-Zahlen ermitteln (in diesem Beispiel 17 und 20). In Kapitel 18 erkläre ich näher,
wie Sie diese Berechnungen ausführen, um Fragen über das Wann und Wie Viel zu beant-
worten.
173
Kapitel 7
Schätzung und Velocity
Trend 1
Trend 2
Zeit
Abb. 7.13: Die Velocity eines Teams im Zeitverlauf
Er argumentierte, dass die Velocity des Teams doch immer besser werden müsse, weil es
sein Vorgehen doch stets untersuchte und anpasste (und damit verbesserte).
Ich würde bei einem Team, das aggressiv versucht, sich zu verbessern und sich darauf kon-
zentriert, Funktionen entsprechend einer robusten Definition von Fertig und mit geringen
technischen Schulden (siehe Kapitel 8) zu liefern, durchaus erwarten, dass sich seine Velo-
city immer weiter steigert. Oder zumindest würde ich eine Steigerung bis zu einem
bestimmten Punkt erwarten, an dem die Velocity mit hoher Wahrscheinlichkeit abflacht
(vergleichbar Trend 2 in Abbildung 7.13).
Nur weil sich die Velocity eines Teams auf einem bestimmten Niveau eingepegelt hat, heißt
das noch lange nicht, dass das Potenzial nach oben ausgeschöpft ist. Es gibt eine Reihe von
Maßnahmen, mit denen das Scrum-Team und die Manager die Velocity auf die nächste
Ebene hieven können. So haben z.B. die Einführung neuer Tools oder weitere Schulungen
und Trainings einen positiven Effekt auf die Velocity. Die Manager könnten auch die strate-
gische Zusammensetzung des Teams ändern, in der Hoffnung, dass diese Umstrukturie-
rung zu einer größeren Gesamt-Velocity führt. Allerdings müssen diese Manager dabei
natürlich vorsichtig vorgehen, weil die willkürliche Umbesetzung von Teammitgliedern
auch zu einem Abfall der Velocity führen könnte (und vermutlich auch wird).
Diese ganzen Aktionen können zwar einen positiven Effekt auf die Velocity haben, norma-
lerweise führen sie aber zunächst einmal zu einem Einbruch der Velocity, während das
174
7.10
Missbrauch der Velocity
Team diese Änderungen annimmt und verarbeitet (siehe Abbildung 7.13, Trend 2). Nach
dem Absinken kommt es dann wahrscheinlich wieder zu einem Anstieg bis zu dem Punkt,
an dem ein neues Niveau erreicht ist. Und dieses Niveau wird anschließend gehalten, bis
andere Änderungen eine weitere Verbesserung erreichbar erscheinen lassen.
Natürlich gibt es eine offensichtliche Maßnahme, die wir ausprobieren könnten, um die
Velocity zu steigern: Wir könnten länger arbeiten. Viele Überstunden könnten zunächst tat-
sächlich zu einer Verbesserung der Velocity führen (siehe »Überstunden« in Abbildung
7.14).
1. Überstunden
2. Überstunden enden
Velocity
4. Zurück zu Grundwert
Zeit
Abb. 7.14: Die Auswirkung von Überstunden auf die Velocity (basierend auf einer Abbildung aus
Cook 2008)
Diesem Anstieg folgt dann allerdings mit hoher Wahrscheinlichkeit ein rasanter Abfall der
Velocity, gepaart mit einem gleichzeitigen Nachlassen der Qualität. Außerdem braucht das
Team auch nach Beendigung der Überstundenperiode erst einmal Zeit, um sich zu erho-
len, bevor es wieder zu einer vernünftigen Grund-Velocity zurückfindet. Ich habe Beispiele
gesehen, bei denen die Senke (Bereich der verringerten Velocity) während der Erholungs-
phase größer war als der Scheitel (Bereich der erhöhten Velocity) während der Überstun-
denphase.
Am Ende ist es so, dass viele Überstunden zwar kurzfristig Vorteile mit sich bringen, diese
aber oft durch die langfristigen Konsequenzen aufgefressen werden.
175
Kapitel 7
Schätzung und Velocity
Nehmen wir z.B. an, ich hätte beschlossen, dem Team mit der höchsten Velocity den größ-
ten Bonus zu geben. Oberflächlich betrachtet scheint diese Idee vernünftig zu sein: Das
Team mit der höchsten Velocity schafft während der einzelnen Sprints immerhin ganz
offensichtlich die meiste Arbeit, oder? Warum sollte man dieses Verhalten nicht belohnen?
Nun, falls ich Teams vergleiche, die ihre PBIs nicht anhand eines gemeinsamen Maßstabs
schätzen (was vermutlich der Fall sein wird), wäre ein Vergleich der Zahlen ziemlich sinn-
los. Nehmen wir an, Team A weist einem PBI einen Wert von 5 zu, während Team B dem-
selben PBI einen Wert von 50 beimisst. In diesem Fall möchte Team A eigentlich nicht,
dass ich seine Velocity mit der von Team B vergleiche – denn die Velocity von Team B wäre
zehnmal höher als die von Team A, selbst wenn beide Teams in den Sprints genauso viel
Arbeit abschließen.
Sobald Team A das Problem erkennt, werden seine Mitglieder beginnen, das System auszu-
tricksen, um dafür zu sorgen, dass ihre Velocity-Werte höher sind. Am einfachsten wäre es,
die Skala zu ändern, mit der das Team die PBIs schätzt. Team A schätzt nun also dasselbe
Element (das ursprünglich eine Größe von 5 besaß) mit 500 ein. Ich bezeichne dieses Ver-
halten als Punkteinflation, denn es dient keinem weiteren Zweck als dem, das Verhalten
eines Teams an ein fehlgeleitetes Messsystem anzupassen. Machen Sie das nicht.
Selbst wenn Teams im Sinne konsistenter PBI-Schätzungen die gleichen Einheiten verwen-
den, bekomme ich, wenn ich ein System zur Belohnung größerer Zahlen einrichte, auch
nichts anderes präsentiert – eben größere Zahlen (Punkteinflation).
Noch schlimmer als eine Punkteinflation ist es, wenn das Team beginnt, die Kurven zu
schneiden, um mehr »fertig« zu bekommen, damit es höhere, erstrebenswertere Velocity-
Werte erreicht. Das führt dann zu zunehmend steigenden technischen Schulden.
Am Ende sollten wir die Velocity danach beurteilen, wie gut sie uns bei unserer genauen
Planung unterstützt und wie sehr sie einem Team dabei hilft, sich intern zu verbessern.
Alle anderen Anwendungsfälle werden wahrscheinlich nur das falsche Verhalten fördern.
176
Kapitel 8
Technische Schulden
In diesem Kapitel erläutere ich das Konzept der technischen Schulden. Ich beginne mit
einer ausführlicheren Definition, die auch die drei Variationen »naive Schulden«, »unver-
meidliche Schulden« und »strategische Schulden« umfasst. Danach untersuche ich einige
allgemeine Ursachen für die Entstehung technischer Schulden und zeige auf, welche Fol-
gen es hat, wenn man sie in hohem Maße anhäuft. Anschließend beschreibe ich drei Akti-
vitäten, die in unmittelbarem Zusammenhang mit dieser Problematik stehen: die
organisatorische Handhabung, das Sichtbarmachen und den Abbau angehäufter techni-
scher Schulden. Hier gehe ich insbesondere darauf ein, wie sich diese Aktivitäten unter
Anwendung des Scrum-Entwicklungsverfahrens durchführen lassen.
8.1 Überblick
Ward Cunningham war der Erste, der über das Konzept der technischen Schulden
geschrieben hat (Cunningham 1992). Er definierte es folgendermaßen:
Wenn man das erste Mal Code ausliefert, dann ist das, als würde man sich verschulden. Ein
paar kleine Schulden beschleunigen die Entwicklung, solange sie pünktlich mit einer Überar-
beitung zurückgezahlt werden. . . . Gefährlich wird es, wenn man die Schulden nicht zurück-
zahlt. Jede Minute, die man an nicht ganz richtigem Code verbringt, zählt als Zins auf diese
Schulden. Ganze Entwicklungsorganisationen können unter der Schuldenlast einer ungeeig-
neten Implementierung zum Stillstand gebracht werden. . . .
Cunningham nutzte die Metapher der technischen Schulden, um seinen Managern zu
erklären, wieso es von großem Vorteil ist, Software schnell herzustellen und zügig entspre-
chendes Feedback zu bekommen. Dabei betonte er vor allem zwei maßgebliche Punkte:
Das Team und die Organisation müssen stets auf die Begleichung der Schulden achten,
während ihr Verständnis hinsichtlich des betreffenden Geschäftsbereichs wächst, und das
Design und die Implementierung des Systems müssen sich weiterentwickeln, um diesem
neu hinzugewonnenen Verständnis besser gerecht zu werden.
Seit der Einführung dieses Konzepts Anfang der 1990er Jahre wurde Cunninghams
ursprüngliche Definition in der Softwarebranche allerdings immer freizügiger interpre-
tiert. Heutzutage bezieht sich der Begriff »technische Schulden« sowohl auf die Abstriche,
die wir innerhalb des Entwicklungsprozesses bewusst herbeiführen und in Kauf nehmen,
als auch auf die vielen Defizite und Mängel, die Softwaresysteme plagen. Dazu gehören:
쐽 Unpassendes (schlechtes) Design – Ein Design, das irgendwann einmal sinnvoll er-
schien, es jetzt aber angesichts bedeutender Veränderungen in Bezug auf den Ge-
schäftsbereich oder die verwendeten Technologien nicht mehr ist.
쐽 Defekte – Bekannte Probleme in der Software, die wir bisher noch nicht entfernt haben.
177
Kapitel 8
Technische Schulden
쐽 Unzureichende Testabdeckung – Bereiche, von denen wir wissen, dass wir in ihnen
mehr testen sollten, es aber noch nicht getan haben.
쐽 Übermäßiges manuelles Testen – Händisches Testen, obwohl wir eigentlich automati-
sierte Tests haben sollten.
쐽 Schlechtes Integrations- und Release-Management – Durchführen dieser Aktivitäten
auf eine Weise, die zeitraubend und fehleranfällig ist.
쐽 Mangelnde Plattformerfahrung – Wir haben z.B. Mainframe-Anwendungen in COBOL
geschrieben, haben aber nicht mehr viele erfahrene COBOL-Programmierer.
쐽 Und vieles mehr, weil der Begriff der »technischen Schulden« heutzutage oft als Indika-
tor für ein mehrdimensionales Problem gilt
Nach Cunninghams ursprünglicher Definition war der Begriff »technische Schulden«
eigentlich nicht als Synonym für die Unzulänglichkeiten von Teammitgliedern, Branchen-
bedingungen oder auch Prozessen gedacht, die zu nachlässigem Design, schlechten Ent-
wicklungspraktiken und einem Mangel an Tests führen. Diese Art von Schulden kann
durch anständiges Training, ein gutes Verständnis der technischen Praktiken und fundierte
geschäftliche Entscheidungsvorgänge eliminiert werden. Da solche Schulden oft ohne Sinn
für die Verantwortung und häufig auch versehentlich entstehen, bezeichne ich sie als naive
technische Schulden. Sie sind auch unter anderen Namen bekannt: waghalsige Schulden
(Fowler 2009), ungewollte Schulden (McConnell 2007) und Schlamperei (Martin 2008).
Ebenso gibt es unvermeidliche technische Schulden, die normalerweise unvorhersehbar
sind und nicht abgewendet werden können. So entsteht z.B. unser Verständnis für das, was
ein gutes Design ausmacht, aus der eigentlichen Designarbeit und der Erstellung der für
den Anwender wertvollen Funktionen auf der Grundlage dieser Arbeit. Wir können im Vor-
hinein nicht mit absoluter Sicherheit wissen, wie sich unser Produkt und sein Design im
Laufe der Zeit entwickeln müssen. Design- und Implementierungsentscheidungen, die wir
sehr früh treffen, müssen sich also möglicherweise ändern, wenn wir wichtige Lernschlei-
fen schließen und validiertes Wissen ansammeln. Und solche Änderungen, die in den
betroffenen Bereichen erforderlich sind, sind unvermeidliche technische Schulden.
Nehmen wir in einem anderen Beispiel an, dass wir eine Komponente eines Drittanbieters
lizenziert haben, um sie in unserem Produkt einzusetzen. Im Laufe der Zeit entwickeln
sich die Schnittstellen zu dieser Komponente weiter. Dadurch häuft unser Produkt, das ein-
mal sehr gut mit besagter Drittanbieterkomponente funktioniert hat, ohne jedes Versäum-
nis oder Fehlverhalten unsererseits technische Schulden an. Eine solche Situation mag
zwar vorhersehbar sein (es ist nicht ungewöhnlich, dass der Hersteller seine Komponen-
tenschnittstelle irgendwann einmal ändert), sie ist aber nicht vermeidbar, weil wir nicht
vorhersagen können, wie die Komponentenentwickler die Komponente in der Zukunft wei-
terentwickeln.
Die letzte Variation der technischen Schulden sind die strategischen technischen Schulden.
Sie sind ein Werkzeug, das Organisationen helfen kann, die wirtschaftlichen Aspekte wich-
tiger, oft zeitgebundener Entscheidungen besser zu quantifizieren und auszunutzen. So
könnte eine Organisation z.B. absichtlich die strategische Entscheidung treffen, in der Pro-
duktentwicklung Abstriche zu machen, um ein wichtiges kurzfristiges Ziel zu erreichen –
etwa ein termingebundenes Produkt auf den Markt zu bringen. Auch wenn die Gefahr
besteht, dass einer Organisation das Geld ausgeht, bevor das Produkt fertig ist, ist die Auf-
nahme technischer Schulden möglicherweise die einzige Möglichkeit, einen vollständigen
178
8.2
Die Folgen technischer Schulden
Unvorhersehbarer Wendepunkt
Schwindende Vorhersehbarkeit
Leistungseinbruch
Allgemeiner Frust
Sinkende Kundenzufriedenheit
179
Kapitel 8
Technische Schulden
180
8.2
Die Folgen technischer Schulden
genden Kosten also nicht mehr so einfach an die sich weiterentwickelnde Umgebung
anpassen, in der sie existieren müssen.
Zeit
8.2.7 Leistungseinbruch
Leider schrauben alle Beteiligten bei einer wachsenden technischen Schuldenlast auch ihre
Erwartungen an die Entwicklungsleistungen zurück – also an das, was möglich ist. Und
diese gesenkten Erwartungen setzen sich automatisch durch die gesamte Wertekette hin-
durch fort und führen letztendlich zu einem organisationsweiten Leistungseinbruch.
181
Kapitel 8
Technische Schulden
182
8.3
Ursachen der technischen Schulden
nen fristgerecht fertigstellen und gleichzeitig so wenig wie möglich technische Schulden
anhäufen.
Tatsächliche Velocity–Rate,
mit der hochwertige Arbeit
Menge der Arbeit
abgeschlossen wird
Geplante
Velocity
Zeit
Gewünschter Wahr-
Freigabe- scheinlicher
termin Freigabe-
termin
Abb. 8.3: Der Druck hinsichtlich des Erreichens einer Deadline kann zu technischen Schulden
führen.
Nachdem wir jedoch mit der Arbeit begonnen haben, stellt sich heraus, dass die tatsächli-
che Velocity bei der Herstellung hochwertiger Ergebnisse niedriger ist als die geplante Velo-
city. Falls wir also mit der gegenwärtigen Velocity weiterarbeiten, verpassen wir den
gewünschten Freigabetermin und beenden die Arbeit stattdessen am wahrscheinlichen
Freigabetermin.
183
Kapitel 8
Technische Schulden
Geplante
Dieser Bereich verkörpert die
Velocity
angehäuften technischen Schulden
Zeit
Gewünschter Wahr-
Freigabe- scheinlicher
termin Freigabe-
termin
Abb. 8.4: Anhäufung technischer Schulden, um ein unvernünftig festgelegtes Ziel und einen
unrealistischen Termin zu schaffen
Gerücht Zunehmende
Schulden
Testen reduzieren
Es geht schneller
Realität Zunehmende
Schulden
Schneller, schneller! Testen reduzieren
Es geht langsamer
Gute Praxis
Niedrigere Schulden
Nutze gute technische
Praktiken (wie TTD)
Es geht schneller
Abb. 8.5: Wie Tests die Velocity beeinflussen – Gerücht, Realität und bewährte Praxis
184
8.3
Ursachen der technischen Schulden
Die Realität sieht so aus, dass eine Verringerung der Tests sowohl die Schulden erhöht als
auch dafür sorgt, dass wir noch langsamer werden, weil Probleme erst später entdeckt wer-
den, wenn es viel mehr Zeit kostet, sie zu beheben. Erfahrene Teams liefern Ergebnisse
guter Qualität schneller und mit geringeren technischen Schulden aus, wenn das Testen
grundlegend im Entwicklungsprozess verankert ist. Diese Teams nutzen gute technische
Praktiken wie etwa eine testgetriebene Entwicklung (Test-Driven Development; TDD) – bei
der der Entwickler einen kleinen Unit Test schreibt und automatisiert, bevor er den Code
schreibt, der den Test besteht (Crispin und Gregory 2009).
Zeit
Release 1 Release 2
Abb. 8.6: Wenn die technischen Schulden zunehmen, sinkt die Velocity.
Wenn sich dieses Muster fortsetzt, verläuft die Velocity-Linie schließlich waagerecht. In die-
sem Zustand wären die technischen Schulden im System so hoch, dass die effektive Velo-
city bei Null läge. Das Ergebnis wäre die Art von Produkt, bei der wir uns davor fürchten,
irgendwelche Änderungen vorzunehmen, weil eine kleine Änderung in einem Bereich
dafür sorgen könnte, dass 18 andere Dinge in scheinbar völlig unzusammenhängenden
Bereichen des Produkts ausfallen. Was aber noch viel schlimmer ist: Wir haben keine Mög-
lichkeit vorherzusagen, ob diese 18 Dinge kaputtgehen. Und natürlich haben wir auch kein
185
Kapitel 8
Technische Schulden
nennenswertes Test-Framework, das uns helfen könnte festzustellen, wann sie kaputtge-
hen – aber keine Panik, unsere Kunden werden uns das schon wissen lassen!
Wenn wir uns erst einmal in einer Situation mit hohen technischen Schulden wiederfin-
den, sind alle Entscheidungen übel:
쐽 Wir machen nichts und das Problem verschlimmert sich.
쐽 Wir investieren immer mehr in die Reduzierung der technischen Schulden, die unsere
wertvollen Produktentwicklungsressourcen zunehmend auffressen.
쐽 Wir erklären den technischen Bankrott, tilgen die technischen Schulden und ersetzen
das schuldengeplagte Produkt durch ein neues Produkt mit all den Kosten und Risiken,
die die Entwicklung eines neuen Produkts mit sich bringt.
Wenn uns solche Entscheidungen drohen, ist es entscheidend, dass wir unsere technischen
Schulden richtig organisieren, bevor wir vollends die Kontrolle verlieren.
186
8.5
Die Zunahme technischer Schulden überwachen
187
Kapitel 8
Technische Schulden
Zeit in Monaten
13 Monate bis zum erreichbaren
Freigabetermin (keine spürbaren
technischen Schulden)
10 Monate bis zum gewünschten Freigabetermin
(die Einhaltung dieses Termins
erfordert technische Schulden)
188
8.5
Die Zunahme technischer Schulden überwachen
Lassen Sie uns zwei mögliche Alternativen in Betracht ziehen. Erstens: Verschieben des
Auslieferungstermins um drei Monate, so dass wir die Arbeit an den geforderten Funktio-
nen mit minimalen technischen Schulden nach 13 Monaten sinnvoll und professionell
abschließen können. Die gesamten Entwicklungskosten würden dann bei 1,3 Millionen
Dollar liegen. In Gesprächen mit Verkauf und Marketing stellen wir außerdem klar, dass
bei einer dreimonatigen Verzögerung mit einem Verlust von 450.000 Dollar an Verkaufs-
erträgen zu rechnen ist.
Zweitens: Beschleunigen der Entwicklung, indem Abstriche gemacht werden, um den
ursprünglichen Auslieferungstermin nach 10 Monaten zu schaffen. Um die wirtschaftliche
Seite dieser Möglichkeit korrekt quantifizieren zu können, müssen wir wissen, wie viel es
kostet, die technischen Schulden aufzunehmen.
Und das ist genau die Stelle, an der es schwierig wird. Angenommen, wir fragen das Ent-
wicklungsteam: »Wenn ihr heute Kompromisse hinsichtlich des Designs und der Imple-
mentierung machen müsstet, um die unverzichtbaren Funktionen zum ursprünglichen
Auslieferungstermin fertig zu bekommen, wie viel würde es zusätzlich kosten, die Schul-
den nach der ersten Freigabe wieder abzubauen?«
Nehmen wir an, das Team diskutiert die Frage und glaubt, dass es vier Monate brauchen
würde, um das System aufzuräumen. Dann würde das bedeuten, dass es einen Monat län-
ger als die drei Monate braucht, die es ursprünglich durch die eingegangenen Kompro-
misse »gespart« hat. Außerdem kommen noch 100.000 Dollar mehr an
Entwicklungskosten hinzu (insgesamt also 1,4 Millionen Dollar statt der 1,3 Millionen Dol-
lar für die erste Option). Das sind 100.000 Dollar, die die Organisation nicht aufbringen
müsste, wenn wir die Arbeit gleich richtig gemacht und nicht erst technische Schulden auf
das Produkt aufgenommen hätten.
Oberflächlich betrachtet, scheint die korrekte ökonomische Entscheidung klar zu sein: Sol-
len wir technische Schulden in Höhe von 100.000 Dollar aufnehmen, um einen Ertragszu-
wachs in Höhe von 450.000 Dollar zu generieren? Sicher, wer würde das nicht tun? Und
das wäre gegebenenfalls auch die richtige Antwort, wenn wir glauben, dass wir alle (oder
zumindest die meisten) wichtigen Kostenfaktoren berücksichtigt haben, die mit den tech-
nischen Schulden verbunden sind.
Hier wurden jedoch mindestens zwei von vermutlich vielen weiteren Faktoren nicht
bedacht:
쐽 Was ist mit den Verzögerungskosten für die Rückzahlung der technischen Schulden?
Die 100.000 Dollar decken die Kosten ab, die das Team für die Reduzierung der techni-
schen Schulden in der Zukunft braucht. Was aber ist mit den Kosten für die Zeit, die
nötig ist, um den Schuldenabbau zu realisieren? Zeit, die damit zugebracht wird, Schul-
den zu tilgen, verursacht wiederum Verzögerungskosten für irgendein anderes Produkt
oder die nächste Version desselben Produkts. Was kostet diese Verzögerung? Wenn das
189
Kapitel 8
Technische Schulden
Team einen Monat extra braucht, um die Schulden zurückzuzahlen, wird wahrschein-
lich die Freigabe eines anderen Produkts um einen Monat verschoben. Die Kosten für
eine verpasste Gelegenheit haben also echte wirtschaftliche Auswirkungen, die man be-
achten muss.
쐽 Die meisten Organisationen gehen nicht besonders gut mit der Rückzahlung techni-
scher Schulden um. Wenn es hart auf hart kommt, zieht es das Management häufig vor,
neue Funktionen zu entwickeln, statt Funktionen zu überarbeiten, die bereits existie-
ren. In Wirklichkeit bauen wir unsere Schulden also unter Umständen gar nicht ganz
oder teilweise ab, sondern häufen obendrein höchstwahrscheinlich sogar noch »Soll-
zinsen« an. Das muss ebenfalls bedacht werden.
Tabelle 8.1 fasst die Zahlen aus diesem Beispiel zusammen.
190
8.6
Technische Schulden sichtbar machen
Die Tentakel technischer Schulden reichen somit ganz offensichtlich an viele unterschied-
liche Aspekte der gesamten wirtschaftlichen Berechnung heran. Und wenn man es unter-
lässt, wenigstens die wichtigsten dieser Aspekte in Betracht zu ziehen, wird man es nicht
schaffen, die ökonomischen Gegebenheiten, mit denen man rechnen muss, wenn man
technische Schulden aufnimmt, korrekt zu quantifizieren.
Sollten natürlich die Zahlen dafür sprechen, die Schulden aufzunehmen – weil z.B. unsere
Organisation ruiniert wäre, wenn wir die Schulden nicht aufnehmen und das Produkt mit
allen unverzichtbaren Funktionen auf den Markt bringen würden, oder wir es nicht schaf-
fen, die ersten am Markt zu sein und damit den Löwenanteil unserer Gewinne verlieren –,
müssen wir nicht erst über die weniger wichtigen Faktoren nachgrübeln, weil wir ja schon
wissen, dass es ökonomisch sinnvoll ist, die Schulden aufzunehmen.
Oft ist die Entscheidung allerdings nicht ganz so klar. Die Beantwortung der Frage, ob man
nun Schulden aufnehmen sollte oder nicht, erfordert normalerweise eine detaillierte Ana-
lyse, um die beste Option zu ermitteln. Wenn Sie sich nicht ganz sicher sind, dann nehmen
Sie die Schulden lieber nicht auf. Meiner Erfahrung nach unterschätzen die meisten Orga-
nisationen die wahren Kosten, die bei der Aufnahme technischer Schulden entstehen, ganz
erheblich und sind zudem in Bezug auf deren Abbau auch nicht annähernd so eifrig, wie
sie glauben.
191
Kapitel 8
Technische Schulden
Güter Belastungen
Bargeld 600.000 Dollar Aktuelle Belastungen
Außenstände 450.000 Dollar Wechselverbindlichkeiten 100.000 Dollar
Abrechnungsverbindlichkeiten 75.000 Dollar
Kurzfristige technische Schul- 90.000 Dollar
den
Werkzeuge und 250.000 Dollar Langfristige Belastungen
Ausrüstungen
Verbindlichkeiten 300.000 Dollar
Langfristige technische 650.000 Dollar
Schulden
... ... ... ...
Tabelle 8.2: Technische Schulden in der Bilanzaufstellung der Organisation
Ich kenne eigentlich keine Organisation, die ihre kurzfristigen und langfristigen Schulden
in ihrer Bilanz mit aufführt (obwohl ich das für eine gute Idee halten würde). Dieses Bei-
spiel soll daher lediglich verdeutlichen, dass jede Organisation eine Methode finden muss,
das Ausmaß der technischen Schulden eines Produkts auf eine Art zu kommunizieren, die
auch das Management versteht – ansonsten bekommt die Organisation keinen richtigen
Eindruck vom wahren Zustand des Produkts und kann keine sinnvollen wirtschaftlichen
Entscheidungen treffen.
Manche Organisationen machen die Folgen der technischen Schulden sichtbar, indem sie
die Velocity, also die Entwicklungsgeschwindigkeit, über die Zeit verfolgen. Abbildung 8.6
zeigt, wie eine Zunahme an technischen Schulden zu einem Abfall der Entwicklungsge-
schwindigkeit führt. Dieser Abfall kann in finanziellen Begriffen erklärt werden. Nehmen
wir z.B. an, wir hätten ein Scrum-Team mit Fixkosten in Höhe von 20.000 Dollar pro
Sprint und einer Entwicklungsgeschwindigkeit von 20 Punkten pro Sprint. Mithilfe dieser
Zahlen können wir ausrechnen, dass die Kosten pro Punkt 1.000 Dollar betragen. Wenn
die Anhäufung technischer Schulden dafür sorgen würde, dass die Entwicklungsgeschwin-
digkeit des Teams auf 10 Punkte pro Sprint sinkt, würden die Kosten pro Punkt auf 2.000
Dollar ansteigen. Müsste das Team nun etwa 200 Punkte abschließen und würde die Ent-
wicklungsgeschwindigkeit auf die Hälfte sinken, dann würde Arbeit, die eigentlich
200.000 Dollar kostet, nun 400.000 Dollar kosten. Die Entwicklungsgeschwindigkeit hilft
uns also dabei, die finanziellen Auswirkungen der Zinszahlungen auf die angehäuften
technischen Schulden zu erkennen.
192
8.6
Technische Schulden sichtbar machen
umsetzen lässt. Abbildung 8.9 zeigt drei Methoden, mit denen man technische Schulden
auf der technischen Ebene sichtbar machen kann.
Erstens sollten technische Schulden genau wie Defekte in einem vorhandenen Fallbearbei-
tungs- bzw. Ticket-System aufgezeichnet werden (Abbildung 8.9 links). Das hat den Vorteil,
dass man die Schulden mit bekannten Tools und Techniken an einer vertrauten Stelle fest-
hält. Wenn die Informationen über die Schulden neben den Informationen über die
Defekte stehen, ist es wichtig, dass man die Schulden mit einem Etikett versieht, das das
Wiederfinden erleichtert, weil das Team beschließen könnte, die Schulden anders zu bedie-
nen als die Defekte (wie ich in Kürze diskutieren werden).
Abb. 8.9: Möglichkeiten, technische Schulden auf der technischen Ebene sichtbar zu machen
Man kann auch so vorgehen, dass man Product-Backlog-Elemente anlegt, die die techni-
schen Schulden repräsentieren (Abbildung 8.9 Mitte). Damit verleiht man den wichtigen
technischen Schulden eine Sichtbarkeit, die mit der der neuen Funktionen im Product
Backlog gleichauf ist. Teams nutzen diesen Ansatz typischerweise, wenn die Kosten für den
Abbau der technischen Schulden relativ hoch sind und der Product Owner in die Entschei-
dung einbezogen werden muss, wie diese Arbeit im Verhältnis zu der Arbeit an den neuen
Funktionen im Product Backlog eingeordnet werden soll.
Ein dritter Ansatz sieht vor, ein spezielles Backlog für die technischen Schulden anzulegen,
das die einzelnen Schuldenobjekte sichtbar macht (Abbildung 8.9 rechts). Immer wenn
neue technische Schulden entdeckt oder in das Produkt eingeführt werden, kann ein Mit-
glied des Entwicklungsteams einen neuen Eintrag im Technische-Schulden-Backlog vor-
nehmen. Dadurch sieht das Entwicklungsteam nicht nur den Stellenwert der einzelnen
technischen Schulden, sondern kann auch proaktiv festlegen, wann es diese jeweils bedie-
nen möchte.
Für Teams, die am selben Ort arbeiten, ist es am einfachsten, an irgendeiner Wand eine
Tafel für die technischen Schulden zu installieren und die einzelnen Schuldenobjekte mit
Klebezetteln oder Karten darzustellen. Normalerweise platziert man die Schuldentafel
193
Kapitel 8
Technische Schulden
direkt neben dem Sprint Backlog, damit das Team die Schulden während der Sprint-Pla-
nung sieht und in Betracht ziehen kann, sie im nächsten Sprint abzubauen (auf diesen
Ansatz komme ich im nächsten Abschnitt).
Die meisten Teams behandeln das Schulden-Backlog relativ formlos, indem sie einfach
die Karten mit den technischen Schulden an die Wand hängen. Man könnte sich aber
auch die Zeit nehmen, es etwas aufwendiger zu pflegen, indem man die Karten sortiert
oder wenigstens grob beschreibt, welcher Aufwand nötig wäre, um die jeweiligen Schul-
den abzuarbeiten.
194
8.7
Technische Schulden abbauen
Wegwerf-Prototyp
Manchmal ist es wirtschaftlich am sinnvollsten, technische Schulden, die man absichtlich
aufgenommen hat, niemals zurückzuzahlen. Ein Beispiel dafür ist die Entwicklung eines
Wegwerf-Prototypen, den man nur geschaffen hat, um etwas daraus zu lernen (Goldberg
und Rubin 1995). Der Wert des Prototyps besteht nicht im Code, sondern in dem validier-
195
Kapitel 8
Technische Schulden
ten Wissen, das wir erworben haben (Ries 2011). Da der Prototyp nicht für ein Leben im
Markt entwickelt wurde, lasten vermutlich große technische Schulden auf ihm. Weil es sich
aber um einen Wegwerf-Prototypen handelt, gibt es keinen Grund, die Schulden zu beglei-
chen. Falls wir natürlich einen Wegwerf-Prototypen herstellen und dann beschließen, ihn
doch nicht wegzuwerfen, sondern wie einen evolutionären Prototypen zu behandeln,
beginnen wir die ganze Sache schon mit einer Grundlage, die tief in technischen Schulden
steckt.
196
8.7
Technische Schulden abbauen
Normalerweise bauen Organisationen keine Produkte, die nur eine Lebensdauer von drei
Monaten haben. Meist soll ein Produkt länger am Markt bestehen.
8.7.2 Wenden Sie die Pfadfinderregel an (Bauen Sie die Schulden ab,
sobald sie Ihnen begegnen)
Bei den Pfadfindern gibt es eine Regel: »Verlasse den Lagerplatz immer sauberer, als du ihn
vorgefunden hast.« Wenn es unordentlich ist, räumen sie es auf, ganz egal, wer die Unord-
nung verursacht hat. Sie verbessern bewusst die Umgebung für die nächste Gruppe Cam-
per. Bob Martin (und andere) hat ganz gut erklärt, wieso diese Regel auch für die
Produktentwicklung und technische Schulden gilt (Martin 2008).
Indem wir uns an diesen Grundsatz halten, versuchen wir, unser Produktdesign und die
Implementierung mit jedem Mal, wenn wir beides anfassen, ein bisschen besser zu
machen. Arbeitet ein Mitglied des Entwicklungsteams an einem Bereich des Produkts und
findet ein Problem (zufällig gefundene technische Schulden), dann wird es behoben. Und
zwar nicht etwa, weil es nur für dieses Teammitglied vorteilhaft wäre (obwohl es das zwei-
fellos ist), sondern weil es gut für das gesamte Entwicklungsteam und die Organisation ist.
Gemäß dem oben angegebenen Algorithmus bauen wir die zufällig entdeckten Schulden
bis zu einem vernünftigen Schwellenwert ab. Wir können das Team nicht einfach anwei-
sen, die gesamten zufälligen Schulden zu tilgen, sobald es sie entdeckt, denn das könnte
einen beträchtlichen Aufwand verursachen – und das Team befindet sich ja immerhin mit-
ten im Sprint und hat eigentlich andere Dinge zu tun. Und wenn es doch versucht, die
gesamten Schulden abzutragen, ist es möglicherweise nicht in der Lage, das ursprüngliche
Sprint-Ziel zu erreichen.
Deshalb könnte das Team einen gewissen Prozentsatz seiner Zeit für den Abbau zufällig
entdeckter Schulden reservieren, falls welche auftauchen. Dazu könnte man einerseits die
geschätzte Größe der einzelnen PBIs erhöhen, um zusätzlich anfallenden Schuldenabbau
zu ermöglichen. Alternativ könnte das Team bei der Sprint-Planung auch einen Teil seiner
Kapazität für zufällige Schulden reservieren, so habe ich in der Vergangenheit beispiels-
weise Teams erlebt, die sich zu diesem Zweck zwischen 5% und 33% der Sprint-Kapazität
vorbehalten haben. Falls Sie diesen Ansatz wählen, sollten Sie sich von Ihren speziellen
Umständen leiten lassen.
Nicht getilgte zufällige Schulden sollten nach ihrer Entdeckung als bekannte Schulden
klassifiziert und mit der von Ihrem Team verwendeten Visualisierungstechnik sichtbar
gemacht werden.
197
Kapitel 8
Technische Schulden
Ich mache mir immer Sorgen, wenn ich Teams über »Technische-Schulden-Sprints« oder
»Refactoring Sprints« diskutieren höre. Dabei handelt es sich um Sprints, deren einziges
Ziel darin besteht, die technischen Schulden zu reduzieren. Für mich klingt das nach
Schlussratenzahlung. Solche Sprints vermitteln den Eindruck, dass die Schulden
ursprünglich angehäuft wurden, ohne dass sich jemand Gedanken um die Rückzahlung
gemacht hat – bis es schließlich so weit gekommen ist, dass das Team im nächsten Sprint
keinen Kundenwert liefern kann, sondern sich stattdessen nun mit diesem Problem befas-
sen muss, dessen es sich eigentlich in jedem Sprint zumindest ein bisschen hätte anneh-
men sollen. Wenn das Schuldenmaß jedoch bereits sehr stark angewachsen ist und die
Rückzahlung tatsächlich noch so gut wie gar nicht in Angriff genommen wurde, ist es
manchmal allerdings unumgänglich, das ganze Team einen vollen Sprint lang an dem
Abbau der technischen Schulden arbeiten zu lassen. In der Regel sollte man solche Sprints
aber nach Möglichkeit vermeiden. Stattdessen sollte die Rückzahlung schrittweise erfolgen.
Bei diesem Ansatz nehmen wir uns eine bestimmte Menge an bekannten technischen
Schulden vor und erklären die Tilgung dieser Schulden zum Ziel unseres nächsten Sprints.
Wie viele Schulden in jedem Sprint abgetragen werden, kann das Sprint-Team während der
Sprint-Planung festlegen.
198
8.7
Technische Schulden abbauen
199
Kapitel 8
Technische Schulden
Wenn Teammitglieder während der Sprint-Planung zusammen mit dem Product Owner
für den Kunden werthaltige Elemente aus dem Product Backlog auswählen, die im nächs-
ten Sprint bearbeitet werden sollen, schauen sie sich auch die Karten im Schulden-Backlog
an. Auf diese Weise stellen sie fest, ob die geplante Arbeit von sich aus in einen Bereich hin-
einspielt, der auf einer der Schuldenkarten steht. Ist das der Fall, nimmt jemand die Karte
von der Schuldentafel und platziert sie als Aufgabe für diesen Sprint im Sprint Backlog.
Und somit kümmern sich die Teammitglieder beim Erledigen der Arbeit für das Product-
Backlog-Element gleichzeitig um die Aufgaben, die mit den technischen Schulden zu tun
haben.
Abb. 8.11: Eine Technik zur Handhabung der technischen Schulden in Scrum
Das ist eine sehr einfache und elegante Methode, um den Abbau technischer Schulden an
der Erschaffung von Kundenwerten auszurichten.
200
Teil II
Rollen
In diesem Teil:
쐽 Kapitel 9
Der Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . 203
쐽 Kapitel 10
ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
쐽 Kapitel 11
Das Entwicklungsteam . . . . . . . . . . . . . . . . . . . . . . 235
쐽 Kapitel 12
Die Strukturen des Scrum-Teams. . . . . . . . . . . . . . 253
쐽 Kapitel 13
Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
201
Kapitel 9
In diesem Kapitel gehe ich genauer auf die Rolle des Product Owners ein und zeige
zunächst auf, in welchem Zusammenhang sie mit den anderen Scrum-Rollen steht.
Danach beschreibe ich die Hauptaufgaben und Eigenschaften des Product Owners und
skizziere seinen »Alltag« über einen Zeitraum von mehreren Wochen hinweg. Außerdem
erläutere ich, wer für die verschiedenen Arten der Produktentwicklung als Product Owner
infrage kommt. Und schließlich beschreibe ich auch, inwiefern sich die Rolle des Product
Owners mit anderen Rollen kombinieren und zu einem Product-Owner-Team erweitern
lässt.
9.1 Überblick
Der Product Owner ist die zentrale Anlaufstelle für alle Belange der Produktentwicklung
und repräsentiert eine der drei gemeinsam agierenden Rollen, aus denen jedes Scrum-
Team besteht (die anderen beiden Rollen werden vom ScrumMaster und dem Entwick-
lungsteam wahrgenommen).
Er muss sich stets in wenigstens zwei Richtungen gleichzeitig orientieren (siehe Abbil-
dung 9.1).
Stakeholder Scrum-Team
Interne Stakeholder
Kunden/Anwender Entwicklungsteam
Abb. 9.1: Der Product Owner orientiert sich stets in mindestens zwei Richtungen gleichzeitig
203
Kapitel 9
Der Product Owner
Einerseits muss der Product Owner die Bedürfnisse und Prioritäten nicht nur der Stakehol-
der der Organisation, sondern auch der Kunden und der Anwender gut genug verstehen,
um in deren Sinne handeln zu können. In dieser Beziehung fungiert er als Produktmana-
ger, der dafür sorgt, dass die richtige Lösung entwickelt wird.
Und andererseits muss er dem Entwicklungsteam vermitteln, was gebaut werden muss
und in welcher Reihenfolge dies geschehen soll. Außerdem muss der Product Owner
gewährleisten, dass die Akzeptanzkriterien für die Funktionen festgelegt und später auch
die entsprechenden Tests durchgeführt werden, die diese Kriterien verifizieren, damit die
vollständige Fertigstellung der Funktionen sichergestellt ist. Er selbst schreibt zwar keine
detailorientierten Tests, er sorgt aber dafür, dass für das Team anhand der Akzeptanztests,
auch High-Level Tests genannt, erkennbar wird, wann der Product Owner die Funktion als
fertiggestellt akzeptiert. In dieser Hinsicht ist der Product Owner also teils Wirtschaftsana-
lyst, teils Tester.
9.2 Hauptaufgaben
Abbildung 9.2 zeigt die Hauptaufgaben des Product Owners.
Hier ist unschwer zu erkennen, dass es sich bei dieser Rolle um eine Vollzeitbeschäftigung
mit wichtigen Verantwortungsbereichen handelt. Die Lektüre dieses Abschnitts könnte
durchaus Zweifel daran wecken, ob derartig viel Verantwortung tatsächlich nur einer einzi-
gen Person aufgebürdet werden sollte bzw. ob überhaupt jemand alle erforderlichen Eigen-
schaften in sich vereint, die notwendig sind, um dieser Rolle gerecht zu werden. In den
meisten Fällen wird und sollte die Rolle des Product Owners allerdings tatsächlich nur von
einer einzigen Person wahrgenommen werden – wenngleich es unter bestimmten
Umständen sicher auch nicht verkehrt ist, Product-Owner-Teams oder -Stellvertreter einzu-
setzen. Diese beiden Konzepte werde ich später noch genauer erläutern.
204
9.2
Hauptaufgaben
205
Kapitel 9
Der Product Owner
Produkt inzwischen auslieferungsreif ist und zusätzliche Ausgaben daher nicht gerechtfer-
tigt sind. Nehmen wir z.B. an, wir hätten ein über die Dauer von zehn Sprints zu entwi-
ckelndes Release geplant. Nach dem siebten Sprint schaut sich der Product Owner die
verbleibenden Product-Backlog-Elemente an und kommt zu dem Schluss, dass die Kosten
für die Herstellung dieser Elemente höher sind als der Wert, den sie erbringen. In diesem
Fall könnte er den Standpunkt vertreten, dass eine frühere Auslieferung des Produkts öko-
nomisch vernünftiger wäre als eine Fortsetzung der Arbeiten bis zum Ende der ursprüng-
lich geplanten zehn Sprints. Diese Flexibilität wird insbesondere auch dadurch unterstützt,
dass sich Elemente mit höherem Wert an der Spitze des Product Backlogs befinden und
somit zuerst bearbeitet werden und das Team bei seiner Arbeit eine starke Definition von
Fertig verfolgt.
Und natürlich könnte der Product Owner auch verfügen, die Finanzierung am Ende eines
Sprints einzustellen, wenn sich wichtige wirtschaftliche Faktoren geändert haben. Stellen
Sie sich z.B. vor, wir würden ein landesspezifisches Produkt herstellen und eine Regulie-
rungsbehörde in diesem Land ändert die Gesetze, so dass es unprofitabel oder vielleicht
sogar illegal wäre, das betreffende Produkt zu verkaufen. Auch in einem solchen Fall
könnte ein Product Owner die Entwicklung abbrechen, obwohl sie ansonsten ganz gut
läuft.
206
9.2
Hauptaufgaben
207
Kapitel 9
Der Product Owner
kann das Team den Product Owner aktiv dabei unterstützen, eine Testinfrastruktur aufzu-
bauen, die es ihm bzw. den Fachexperten erlaubt, diese Tests effizienter durchzuführen –
die abschließende Beurteilung, ob ein Element die Erwartungen erfüllt, obliegt am Ende
aber allein dem Product Owner.
Wichtig dabei ist, dass er die Akzeptanzkriterien bereits während der Sprint-Durchführung
verifiziert und nicht bis zum Sprint Review damit wartet. So hat er die Möglichkeit, Fehler
und Missverständnisse früh genug aufzudecken, damit das Team sie noch rechtzeitig vor
dem Sprint Review ausräumen kann. Die Akzeptanztests sind auch deshalb vor dem
Review nötig, weil das Team im Review ausschließlich abgeschlossene Funktionen
demonstrieren darf – und ohne die Tests wüsste es gar nicht, welche Funktionen tatsäch-
lich der Definition von Fertig entsprechen.
208
9.2
Hauptaufgaben
Scrum
Traditionell
Zeit
209
Kapitel 9
Der Product Owner
9.3 Eigenschaften/Fähigkeiten
Abbildung 9.5 zeigt wichtige Eigenschaften der Product-Owner-Rolle.
Ein guter Product Owner sollte zahlreiche Eigenschaften mitbringen, die sich in vier Kate-
gorien gliedern lassen: Fachwissen, soziale Kompetenz, Entscheidungsfähigkeit und Ver-
antwortung.
9.3.1 Fachwissen
Der Product Owner ist ein Visionär, der eine greifbare Vorstellung von dem Produkt ver-
mitteln und das Team anleiten kann, diese Vision zu verwirklichen. Eine Vision zu haben,
bedeutet aber nicht, dass jedes Detail oder der genaue Weg für deren Umsetzung absolut
klar sein müssen. Ein guter Product Owner weiß, dass man nicht alles im Voraus erahnen
kann und ist bereit, sich anzupassen, wenn eine Änderung erforderlich ist.
Um eine Vision auf möglichst effiziente Weise vermitteln und verwirklichen zu können,
benötigt der Product Owner entsprechendes fachliches Hintergrundwissen. Wer in dem
jeweiligen geschäftlichen Fachbereich neu ist, wird es schwer haben, als Product Owner
effizient zu arbeiten – denn wie soll man die Prioritäten der miteinander konkurrierenden
Funktionen richtig festlegen können, wenn man sich nicht mit dem Thema auskennt?
210
9.3
Eigenschaften/Fähigkeiten
9.3.3 Entscheidungsfindung
Der Product Owner muss mit diversen Entscheidungsvollmachten ausgestattet sein. In
Organisationen, die das Scrum-Entwicklungsverfahren gerade erst eingeführt haben, ist
die Person, die als Product Owner ausgewählt wurde, oftmals nicht befugt, wichtige Ent-
scheidungen zu treffen – doch das stellt ein großes Hindernis dar, denn: Eine solche Per-
son ist kein Product Owner.
Darüber hinaus muss der Product Owner natürlich auch bereit sein, gegebenenfalls
schwere Entscheidungen zu fällen, die üblicherweise mit Abstrichen in Bezug auf den
Umfang, die Terminplanung und das Budget des Projekts in Zusammenhang stehen – und
zeitnah erfolgen müssen sowie nicht ohne triftigen Grund widerrufen werden dürfen. Mit
anderen Worten: Der Product Owner muss ein entschlussfreudiger Macher sein.
Wenn er diese Entscheidungen fällt, muss ein Product Owner die richtige Balance zwi-
schen geschäftlichen Bedürfnissen und technischen Realitäten wahren. Zwar ist das
Scrum-Team als Ganzes verantwortlich, wenn Systeme unakzeptable Mengen an techni-
schen Schulden anhäufen, allerdings sind häufig naive Entscheidungen des Product
Owners und Entscheidungen, die Auswirkungen auf Systemebene nicht in Betracht zie-
hen, die größten zum Scheitern beitragenden Faktoren.
9.3.4 Verantwortung
In der Hauptsache zeichnet zwar der Product Owner für die Lieferung guter Unterneh-
mensergebnisse verantwortlich, das entbindet die anderen Mitglieder des Scrum-Teams
jedoch nicht von ihrer Verantwortung, ebenfalls ihren Teil zu der Generierung einer guten
Rendite beizutragen. Faktisch ist allerdings der Product Owner derjenige, der dafür sorgen
muss, dass die verfügbaren Ressourcen auf wirtschaftlich vernünftige Weise eingesetzt
werden, und der die Verantwortung trägt, wenn das nicht geschieht – immerhin hat er im
211
Kapitel 9
Der Product Owner
212
9.4
Der Alltag eines Product Owners
Daily Scrum
Sprint-Planung
Sprint Backlog
Product Backlog Sprint-Ausführung
Funktionen prüfen
Pflege
Potenziell
auslieferungsfähiges
Produkt-
inkrement
Stakeholder-Meetings
Sprint Review
Sprint-Retrospektive
Teilnehmen
Nach dem Workshop zum Schreiben der Product-Backlog-Elemente nimmt der Product
Owner an einem Schätz-Workshop teil (vermutlich eher eine Folge von Meetings über ein
oder zwei Tage), in dem die Mitglieder des Entwicklungsteams (oder, wenn das Team noch
nicht endgültig feststeht, eines Ersatzteams) die Größe der höherwertigen Product-Back-
log-Elemente schätzen.
Anschließend führt der Product Owner eine erste Sitzung zur Release-Planung durch (län-
gerfristige Planung). Da inzwischen bereits einige der Product-Backlog-Elemente geschätzt
wurden, konzentriert man sich bei der Release-Planung darauf, die Prioritäten im Product
Backlog zu bestimmen und die aus dem Umfang, Zeitplan und Budget resultierenden Ein-
schränkungen auszugleichen (siehe Kapitel 18). In diesem Fall sind die Stakeholder die
wichtigsten Teilnehmer, jedoch müssen an irgendeiner Stelle auch einige oder alle Mitglie-
der des Entwicklungsteams einbezogen werden, um technische Abhängigkeiten zu identi-
fizieren, die die Anordnung der Elemente im Product Backlog beeinflussen könnten.
213
Kapitel 9
Der Product Owner
Das Ziel besteht darin, das Release so weit zu planen, dass ein akzeptables Maß an Klarheit
über die komplette Version herrscht und erste Antworten auf geschäftliche Fragen gegeben
werden können, wie etwa was und wann geliefert werden kann. Bei den meisten Produkten
sollte diese Aktivität nicht mehr als einen oder zwei Tage dauern. Wie ich in Kapitel 18 aus-
führen werde, ist die Release-Planung ein fortlaufender Prozess, so dass wir an dieser Stelle
nicht versuchen sollten, übermäßig präzise zu sein – schließlich werden wir den Release-
Plan immer wieder überarbeiten, sobald weiterführende relevante Informationen verfüg-
bar werden.
Nach der Release-Planung führt das Scrum-Team den ersten Sprint durch (Abbildung 9.6
zeigt einen zweiwöchigen Sprint in den Wochen 4 und 5). Zu Beginn des Sprints über-
wacht der Product Owner die Sprint-Planung (siehe Kapitel 19) und im weiteren Verlauf
der Sprint-Durchführung (siehe Kapitel 20) versucht er in der Regel auch, an den Daily
Scrums des Teams teilzunehmen. Das mag nicht immer möglich sein, ist aber eine
bewährte Praxis. Beim Daily Scrum hört der Product Owner zu und versucht einen Ein-
druck davon zu gewinnen, wie der aktuelle Sprint vorangeht und wie er dem Entwicklungs-
team helfen kann. Vielleicht merkt ein Teammitglied an, dass ihm die Spezifika eines der
Product-Backlog-Elemente nicht ganz klar sind und er daher weitere Informationen
braucht, um seine aktuelle Aufgabe abschließen zu können. Eine schnelle Erklärung
könnte der Product Owner bereits während des Daily Scrums liefern. Fällt die Antwort hin-
gegen umfangreicher und somit langwieriger aus, dann sollte er anbieten: »Ich bleibe nach
dem Daily Scrum gern hier und diskutiere das Problem mit dir.«
Generell muss der Product Owner möglichst jeden Tag zur Verfügung stehen, um Fragen
zu beantworten und Funktionen zu testen, sobald diese kontrollbereit sind. Sollte von vorn-
herein klar sein, dass er diese Aufgaben nicht täglich wahrnehmen kann, dann muss er sie
an einen geeigneten Stellvertreter delegieren, damit das Entwicklungsteam nicht blockiert
wird. Auf dieses Konzept werde ich weiter hinten in diesem Kapitel noch eingehen.
Während der Sprint-Durchführung trifft sich der Product Owner darüber hinaus auch mit
den internen und externen Stakeholdern, um sicherzustellen, dass die Prioritäten für den
kommenden Sprint stimmen und Informationen einzuholen, die die für künftige Sprints
ausgewählten Funktionen beeinflussen.
Er pflegt außerdem regelmäßig das Product Backlog, d.h., er schreibt neue Product-Back-
log-Elemente, verfeinert vorhandene Elemente, lässt sie vom Team schätzen und sowohl
vom Team als auch von den Stakeholdern priorisieren.
Am Ende des Sprints nimmt der Product Owner an den zwei Aktivitäten zum Untersuchen
und Anpassen teil: dem Sprint Review (siehe Kapitel 21) und der Sprint-Retrospektive
(siehe Kapitel 22). Sind diese abgeschlossen, wiederholt sich der Sprint-Zyklus und der Pro-
duct Owner nimmt an der nächsten Sprint-Planung teil.
214
9.5
Wer sollte Product Owner sein?
holdern und andererseits am Entwicklungsteam. Die Rolle des Product Owners repräsen-
tiert somit eine Verschmelzung der Art von Autorität und Verantwortung, wie sie auch mit
verschiedenen traditionellen Rollen einhergeht. In seiner umfassendsten Ausprägung
vereint ein Product Owner Elemente aus den Rollen des Produktmanagers, Produktver-
markters, Projektmanagers (siehe dazu auch Kapitel 13), Wirtschaftsanalysten und Akzep-
tanztesters.
Wer nun genau als Product Owner auftreten soll, hängt von der Art des Entwicklungspro-
jekts und der speziellen Organisation ab. Tabelle 9.1 beschreibt gute Kandidaten für ver-
schiedene Entwicklungsarten.
Marketingabteilung IT-Abteilung
Marketing-
system
Abb. 9.7: Beispiel für einen Product Owner in einer internen Entwicklung
215
Kapitel 9
Der Product Owner
Manche Organisationen (üblicherweise solche, die bisher noch nicht realisiert haben, wie
wichtig es ist, einen Geschäftsmann bzw. kaufmännischen Mitarbeiter als täglich beteilig-
ten Product Owner einzusetzen) bitten möglicherweise einen IT-Mitarbeiter, die täglichen
Aufgaben des Product Owners zu übernehmen. Auf die Probleme, die dieser Ansatz mit
sich bringt, werde ich an anderer Stelle in diesem Kapitel noch zu sprechen kommen.
Kundenprodukt
Abb. 9.8: Beispiel für einen Product Owner in einer gewerblichen Entwicklung
Scrum-Anwender liefern sich eine erbitterte Debatte hinsichtlich der Frage, ob die Rolle des
Product Owners lediglich die Scrum- (und agile) Umbenennung der Produktmanager-Rolle
darstellt oder nicht. Manche glauben, die beiden Rollen seien synonym, andere behaupten,
dass die Product-Owner-Rolle umfangreicher sei als die Produktmanager-Rolle. Und wie-
der andere argumentieren natürlich, dass die Rolle des Produktmanagers größer sei. Also
ich sehe das so:
Die Bereiche des Produktmanagements und des Produktmarketings sind sehr umfassend.
Pragmatic Marketing, Inc., ein renommiertes Unternehmen auf dem Gebiet des Produkt-
managements/-marketings hat ein viel beachtetes Framework geschaffen, das die Rollen
und Verantwortlichkeiten für Produktmanagement- und Produktmarketing-Teams aus
dem Technologiesektor definiert (siehe Abbildung 9.9).
Um all diese Aktivitäten abzudecken, empfiehlt Pragmatic Marketing die Einrichtung meh-
rerer Rollen, unter anderem in Form von Produktstrategen, technischen Produktmanagern
und Marketing-Produktmanagern. Und die meisten Leute würden sicher zustimmen, dass
216
9.5
Wer sollte Product Owner sein?
ein gewerbliches Unternehmen, das diese ganzen Aktivitäten für ein größeres Produkt
durchführen lassen möchte, wahrscheinlich ein ganzes Team benötigt.
Soll der Product Owner diese ganzen Arbeiten durchführen? Diejenigen, die glauben, die
Product-Owner-Rolle sei lediglich ein Teil der traditionellen Produktmanager-Rolle, werden
anführen, dass ein Product Owner einfach nur der »technische Produktmanager« ist und
beschränken sich deshalb hauptsächlich auf die wenigen Aktivitäten innerhalb der gestri-
chelten Linie in Abbildung 9.9. Sie glauben, dass der Product Owner keine Zeit hat, sich
auf die anderen Aktivitäten zu konzentrieren, weil er jeden Tag für das Team zur Verfügung
stehen muss.
Busines s
Positioning
Marketing Pragmatic
Plan Plan
Marketing
Market Market
Pricing
Buying Customer Framework ™
TACTICAL
STRATEGIC
Sicherlich ist der Product Owner dafür verantwortlich, die Arbeiten zu erledigen, die in der
gestrichelten Linie gezeigt werden. Allerdings vertrete ich den Standpunkt, dass er noch
mehr machen muss. Um genau zu sein, glaube ich, dass der Product Owner für die Durch-
führung so vieler Aktivitäten in Abbildung 9.9 verantwortlich sein sollte, wie notwendig
und praktisch für ihn sind. Das Ausmaß dieser Verantwortung würde natürlich von der
Organisation, dem speziellen Produkt und den Fertigkeiten der Person abhängen, die zum
Product Owner ernannt wurde. So würde eine Organisation, die einen einfachen Einheiten-
rechner zum Verkauf in einem App Store für Mobilgeräte herstellt, weniger Aktivitäten ver-
langen als eine Organisation, die die nächste Version ihrer Unternehmenssoftware
vorbereitet – und deshalb ist es nicht besonders praktisch, den Umfang des Verantwor-
217
Kapitel 9
Der Product Owner
(Gut)
(Schlecht)
Abb. 9.10: Beispiel für einen Product Owner in einer ausgelagerten Entwicklung
Kompliziert wird die Rolle des Product Owners, wenn Unternehmen A und Unternehmen
B einen traditionellen Entwicklungsvertrag mit festem Preis abschließen. In diesem Fall
wird Unternehmen B aller Wahrscheinlichkeit nach der Meinung sein haben, dass es den
überwiegenden Teil der ProductOwner-Verantwortung übernehmen sollte, weil es das
Risiko eines Festpreisvertrags schultert. In Wirklichkeit sollte jedoch Unternehmen A als
der eigentliche Kunde die Rolle des Product Owners füllen. Ein passenderer Vertrag würde
vorsehen, dass Unternehmen A das leistungsstarke Entwicklungsteam und den Scrum-
Master von Unternehmen B »mietet« und Unternehmen A den Product Owner stellt.
218
9.5
Wer sollte Product Owner sein?
9.5.4 Komponentenentwicklung
Und schließlich könnten Unternehmen auch Komponententeams einsetzen (siehe Kapitel
12), die Teile der Kundenlösungen erstellen, aber nicht die komplette Kundenlösung. Sol-
che Teams stellen üblicherweise Komponenten oder andere Bestandteile her, die dann von
anderen Teams benutzt werden, um die für den Kunden vorgesehenen Lösungen zusam-
menzubauen. Da sie sich auf die technische Komponentenebene konzentrieren, handelt es
sich bei deren Product Ownern in der Regel um technisch orientierte Personen, die in der
Lage sind, die technischen Funktionen in ihren Backlogs zu definieren und zu priorisieren
(siehe Abbildung 9.11).
Funktionsteams Komponententeam
Unternehmens-
orientiert
Technisch
orientiert
Abb. 9.11: Beispiel für einen Product Owner bei einer Komponentenentwicklung
219
Kapitel 9
Der Product Owner
Dieselbe Person
ScrumMaster als Product Owner ScrumMaster
Entwicklungsteam Entwicklungsteam
Abb. 9.12: Ein und dieselbe Person als Product Owner in mehr als einem Scrum-Team
In der Regel ist es sogar einfacher, als Product Owner für mehrere Teams in derselben Ent-
wicklung zu fungieren, da die Arbeit dieser Teams mit hoher Wahrscheinlichkeit eng mit-
einander verknüpft ist.
Außerdem kann es auch vorkommen, dass ein und dieselbe Person sowohl Product Owner
als auch Mitglied des Entwicklungsteams ist. Grundsätzlich ist das jedoch keine so gute
Idee, denn in diesem Fall wäre die betreffende Person sowohl Product Owner als auch
ScrumMaster im selben Scrum-Team. Diese beiden Rollen bilden jedoch Gegengewichte
zueinander – und wenn eine einzige Person beide Rollen wahrnimmt, könnte dies zu
einem Interessenkonflikt führen, den wir möglichst vermeiden sollten.
220
9.7
Das Product-Owner-Team
nehmen könnte dagegen die Arbeitsbelastung für den Product Owner schlicht das Maß
dessen übersteigen, was eine in Vollzeit beschäftigte Person realistischerweise schaffen
kann. In diesen Fällen delegiert der Product Owner einen Teil seiner Aufgaben an andere.
Unter den genannten Umständen ist die Einrichtung eines Product-Owner-Teams durch-
aus akzeptabel, solange es eine Person in dem Team gibt, die am Ende die Entscheidungen
trifft, so dass die ganze Angelegenheit nicht in eine Art »Komitee-Verhalten« abrutschen
kann und jede Entscheidung womöglich erst von acht anderen Leuten abgenickt werden
muss.
Seien Sie vorsichtig, wenn Sie Product-Owner-Teams bilden. Product Owner, die nicht die
nötigen Fertigkeiten besitzen, um als mächtige zentrale Anlaufstelle der Produktentwick-
lung aufzutreten, brauchen kein Komitee – sie brauchen eine andere Rolle. Und auch Pro-
duct Owner, die zu beschäftigt sind, um ihre Aufgaben zu erfüllen, brauchen nicht
unbedingt ein Team – vielleicht liegt das wirkliche Problem darin, dass die Organisation zu
viele Entwicklungen auf einmal begonnen hat oder es nicht genügend Product Owner gibt,
um die notwendigen Produkte zu betreuen.
Vielleicht ist auch das Produkt, das wir bauen wollen, einfach zu groß und sollte in eine
Reihe kleinerer Teile mit häufigeren Releases zerlegt werden. Bei kleineren Teilen könnte
eine Person die Rolle des Product Owners viel einfacher ausfüllen. Aber auch wenn wir
unsere Teams schlecht strukturiert haben (siehe Kapitel 12) oder die Strukturen des Pro-
duct Backlogs nicht stimmen (siehe Kapitel 6), könnte die Arbeit für einen einzigen Pro-
duct Owner zu schwierig sein. Vergewissern Sie sich, dass Ihre Product-Owner-Teams
tatsächlich notwendig sind und nicht nur ein darunter verborgenes Problem verdecken –
ansonsten wird Ihre Situation nur noch komplizierter und Sie gefährden Ihr Gesamt-
ergebnis.
9.7.1 Product-Owner-Stellvertreter
Wie ich bereits erwähnte, bitten manche Unternehmen, die interne Entwicklungen vorneh-
men, einen IT-Mitarbeiter (z.B. einen Wirtschaftsanalysten oder einen Entwicklungsmana-
ger), als Product Owner zu agieren, weil der Kandidat aus dem kaufmännischen Bereich zu
sehr mit anderen Arbeiten ausgelastet ist. Da jeder weiß, dass der IT-Mitarbeiter eigentlich
nicht berechtigt ist, die wichtigen endgültigen Entscheidungen zu treffen (eine der wesent-
lichen Aufgaben jedes Product Owners), haben Organisationen, die dies tun, die Rolle des
Product Owners damit ineffektiv und verwirrend ausgefüllt. Besser wäre es, den Zeitplan
des geschäftlichen Mitarbeiters so weit freizuräumen, dass er als Product Owner handeln
kann, als den IT-Mitarbeiter bei bestimmten Interaktionen mit dem Team stellvertretend
vorzuschicken.
Ein Product-Owner-Stellvertreter ist eine Person, die vom Product Owner gebeten wird, in
bestimmten Situationen in seinem Namen zu handeln. Jeder im Scrum-Team weiß, dass
der Stellvertreter nicht der tatsächliche Product Owner ist, aber auch, dass der Product
Owner diese Person bevollmächtigt hat, zumindest einige taktische Entscheidungen in sei-
nem Namen zu treffen. Das kommt z.B. oft vor, wenn der Product Owner viel Zeit in Mee-
tings mit Kunden und Anwendern verbringt, um sicherzugehen, dass er seinen Finger am
Puls des Marktes behält. Diese Person steht dem Entwicklungsteam auf keinen Fall täglich
zur Verfügung. Hier könnte der Product Owner auf einen Stellvertreter zurückgreifen, der
221
Kapitel 9
Der Product Owner
Chef-
Product Owner
Produktlinie-
Owner
Funktions-
Product Owner
In Abbildung 9.13 ist am Ende die Person mit der Bezeichnung Chief Product Owner der
eigentliche Product Owner für das gesamte Produkt. Der »Chef« steht allerdings einem
ganzen Team aus Product Ownern vor, die gewährleisten, dass die Rolle des Product
Owners in allen tieferen Ebenen der Hierarchie korrekt wahrgenommen wird. Falls Sie sich
für diesen Ansatz entscheiden, müssen Sie dafür sorgen, dass die einzelnen Product
Owner die Befugnis erhalten, die Mehrzahl der Entscheidungen auf ihrer Ebene der Hie-
rarchie zu treffen, anstatt solche Entscheidungen nach oben durchreichen zu müssen.
222
9.8
Abschließende Bemerkungen
223
Kapitel 10
ScrumMaster
In diesem Kapitel befasse ich mich ausführlich mit der Rolle des ScrumMasters. Nach
einer Erläuterung der grundlegenden Zusammenhänge zwischen dieser und den anderen
Scrum-Rollen stelle ich zunächst die wichtigsten Aufgaben und Eigenschaften des Scrum-
Masters vor. Danach beschreibe ich den typischen »Alltag« eines ScrumMasters und unter-
suche, ob es sich bei dieser Rolle um einen Vollzeitjob handelt. Und zum Schluss gehe ich
auf die Frage ein, wer üblicherweise für die Rolle des ScrumMasters geeignet ist.
10.1 Überblick
Der ScrumMaster repräsentiert eine der drei Rollen, aus denen jedes Scrum-Team besteht
(die anderen sind der Product Owner und das Entwicklungsteam). Während sich der Pro-
duct Owner darauf konzentriert, das richtige Produkt zu bauen und das Entwicklungsteam
sich bemüht, das Produkt richtig zu bauen, lautet die Aufgabenstellung des ScrumMasters,
allen Beteiligten dabei behilflich zu sein, die Werte, Prinzipien und Praktiken von Scrum
zu verstehen und anzunehmen. Der ScrumMaster ist sozusagen der Coach sowohl des Ent-
wicklungsteams als auch des Product Owners. Darüber hinaus leitet er die Mitarbeiter auch
in punkto Prozessführung an und unterstützt sowohl das Scrum-Team als auch die
gesamte Organisation dabei, einen individuellen, organisationsspezifischen und effizien-
ten Zugang zu Scrum zu entwickeln.
10.2.1 Coach
Der ScrumMaster betätigt sich als agiler Coach für das Scrum-Team – sowohl für das Ent-
wicklungsteam als auch für den Product Owner. (In Adkins 2010 finden Sie eine umfas-
sende Beschreibung des Konzepts des agilen Coachings.) In dieser Eigenschaft hat er die
Möglichkeit, jedwede Barrieren zwischen diesen beiden Rollen aus dem Weg zu räumen
und es dem Product Owner zu ermöglichen, die Entwicklung direkt zu unterstützen.
Wie der Trainer einer Sportmannschaft beobachtet auch der ScrumMaster, wie das Team
Scrum anwendet und hilft ihm nach Kräften, seine Leistung zu steigern. Wenn Probleme
auftreten, die das Team selbst lösen kann, hält sich der ScrumMaster genau wie jeder
andere gute Coach an die Devise: »Ich bin nicht dafür zuständig, eure Probleme zu lösen,
sondern helfe euch lediglich dabei.« Handelt es sich bei dem Problem hingegen um ein
225
Kapitel 10
ScrumMaster
gravierendes Hindernis, das das Team alleine nicht meistern kann, greift er jedoch auch
aktiv ein.
Coach
Servant Leader
Prozessautorität
ScrumMaster-
Aufgaben
Schutz vor Störungen
Einem neuen Product Owner steht der ScrumMaster insofern als Coach zur Seite, als dass
er ihm hilft, seine Aufgaben zu verstehen und durchzuführen und ihm auch anschließend
bei Aktivitäten wie der Pflege des Product Backlogs weiterhin Unterstützung gewährt. In
Analogie zur Welt des Sports lässt sich die Beziehung des ScrumMasters zum Product
Owner in etwa mit der eines Mannschaftscoachs zum Besitzer eines Sportteams verglei-
chen: Er soll dem Eigentümer helfen, das Geschäftsergebnis mithilfe von Scrum zu maxi-
mieren, sich um das Erwartungsmanagement, sprich das Abwägen und Steuern der
Erwartungen kümmern, dafür sorgen, dass der Eigentümer dem Team alles Notwendige
zur Verfügung stellt sowie die Beanstandungen und Änderungswünsche des Eigentümers
vertreten und so kommunizieren, dass sie in nachweislichen Verbesserungen für das Team
resultieren.
226
10.2
Wichtigste Aufgaben
10.2.3 Prozessautorität
Der ScrumMaster ist die Prozessautorität des Scrum-Teams. In dieser Eigenschaft ist er
bevollmächtigt, dafür zu sorgen, dass das Scrum-Team sich nicht nur an seine eigenen
Ansätze und Vorgehensweisen, sondern auch an die Scrum-Werte, -Prinzipien und -Prakti-
ken hält. Der ScrumMaster unterstützt das Scrum-Team bei der fortlaufenden Optimie-
rung der Arbeitsprozesse, um den gelieferten Geschäftswert zu maximieren.
Der Begriff »Autorität« ist in diesem Kontext nicht identisch mit der Art von Autorität zu
sehen, die ein Abteilungsleiter oder Projektmanager innehat. So stellt der ScrumMaster
beispielsweise niemanden ein und entlässt auch keine Mitarbeiter. Ebenso wenig kann er
dem Team vorschreiben, welche Aufgaben es als Nächstes bewerkstelligen sollte oder wie
es das tun muss. Der ScrumMaster muss auch nicht dafür sorgen, dass die Arbeit erledigt
wird. Stattdessen hilft er dem Team, seinen eigenen Prozess zu definieren und diesen ein-
zuhalten, um die Arbeit zu schaffen.
227
Kapitel 10
ScrumMaster
sächlich auf allen Ebenen der Organisation Veränderungen stattfinden, damit nicht nur
kurzfristige Erfolge erzielt werden, sondern auch langfristig ein Nutzen aus Scrum gezo-
gen werden kann. In großen Organisationen könnten sich die ScrumMaster auch zusam-
menschließen, um noch nachdrücklicher auf eine Änderung hinzuwirken.
10.3 Eigenschaften/Fähigkeiten
Abbildung 10.2 zeigt wichtige Eigenschaften eines ScrumMasters.
Sachkundig
Neugierig
Geduldig
ScrumMaster-
Eigenschaften
Zur Zusammenarbeit fähig
Schützend
Transparent
10.3.1 Sachkundig
Um ein effizienter Prozesscoach sein zu können, muss sich der ScrumMaster selbstver-
ständlich sehr gut mit Scrum auskennen. Er sollte die technischen Probleme, denen sich
das Team gegenübersieht, ebenso gut verstehen wie die Technologien, die das Team für die
Entwicklung seiner Lösungen verwendet. Ein ScrumMaster muss zwar nicht unbedingt ein
Experte auf diesem Gebiet sein, ein vernünftiges technisches Verständnis schadet jedoch
auf keinen Fall. Ebenso wenig muss er im geschäftlichen Bereich allzu versiert sein (dazu
ist der Product Owner da), dennoch gilt auch hier, dass ein gewisses Grundverständnis vor-
handen sein sollte.
10.3.2 Neugierig
ScrumMaster kombinieren ihre Fähigkeiten als Coach und ihre Kenntnisse hinsichtlich der
Arbeitsprozesse, der eingesetzten Technik und den geschäftlichen Aspekten, um zielfüh-
228
10.3
Eigenschaften/Fähigkeiten
rende Fragen zu stellen. Sie initiieren bewusst investigative Gespräche, in denen sie Fragen
stellen, die ihre Gesprächspartner innehalten und sagen lassen: »Hm, darüber habe ich
noch nie nachgedacht. Aber jetzt, wo du es sagst, denke ich, dass es auch einen anderen
Weg geben könnte.« Richtig gute ScrumMaster beantworten Fragen fast nie direkt, sondern
reagieren automatisch mit einer Gegenfrage – allerdings nicht etwa einer lästigen oder um
des Fragens willen gestellten, sondern einer wohlüberlegten, tiefgreifenden, bohrenden
Frage –, mit der sie den Beteiligten erkennen helfen, dass sie selbst genug wissen, um
eigene Antworten darauf zu finden (eine Form des Sokratischen Gesprächs).
10.3.3 Geduldig
Da es ScrumMaster vorziehen, keine unmittelbaren Lösungen bzw. Antworten auf irgend-
welche Problemstellungen vorzugeben, müssen sie natürlich auch Geduld aufbringen und
dem Team Zeit geben, der Sache von selbst auf den Grund zu kommen. Für mich persön-
lich ist es manchmal recht schwierig, ScrumMaster zu sein – eben weil ich das Problem
erkenne, mit dem sich das Team herumschlägt, und die Lösung »weiß«. Nun, zumindest
glaube ich, die Lösung zu wissen! Es gibt einem schon ein gewisses Gefühl der Überlegen-
heit (und das geht mir und jedem anderen ScrumMaster so), wenn man selbst den Ein-
druck hat, man sei cleverer als die geballte Intelligenz des Teams. Deshalb muss ich mir
manchmal einfach auf die Zunge beißen, das Team die Lösung erarbeiten lassen und nur
gelegentlich zielführende Fragen stellen, um die Dinge ein wenig voranzubringen.
10.3.4 Teamfähig
Der ScrumMaster muss in der Lage sein, mit dem Product Owner, dem Entwicklungsteam
und allen anderen Parteien zusammenzuarbeiten, selbst wenn diese nicht unmittelbar mit
Scrum an sich zu tun haben. Als Prozesscoach hält der ScrumMaster außerdem immer
nach Gelegenheiten Ausschau, um die Mitglieder des Scrum-Teams dabei zu unterstützen,
eine mustergültige Zusammenarbeit innerhalb des Teams zu erreichen, beispielsweise
indem er selbst außergewöhnlichen Teamgeist beweist.
10.3.5 Schützend
Der ScrumMaster sollte sich schützend vor das Team stellen. Ähnlich wie ein Hütehund
seine Schäfchen vor den angriffslustigen Wölfen schützt, wacht auch der ScrumMaster
sorgsam über sein Team. Bildlich gesprochen, könnte es sich bei den Wölfen um organisa-
torische Hindernisse oder Personen mit abweichenden Zielen handeln. Im größeren Kon-
text, wenn es um wirtschaftlich sinnvolle Geschäftsentscheidungen geht, fungiert der
ScrumMaster als zuverlässiger »Bodyguard« des Teams. Er hat ein gutes Gespür sowohl für
die Belange des Teams als auch die Bedürfnisse der Organisation und hilft dem Scrum-
Team dabei, einen gesunden Mittelweg zu finden.
Darüber hinaus kümmert sich der ScrumMaster aber auch um Teammitglieder, die den
Anschluss an die »Herde« zu verlieren drohen. Wenn Schwierigkeiten auftreten, kann der
ein oder andere schnell mal in vertraute, nicht-agile Arbeitsweisen zurückfallen – und dann
ist es Aufgabe des ScrumMasters, Abweichler wieder einzufangen und ihnen zu helfen,
ihre Probleme zu überwinden, indem er ihnen aufzeigt, wie sie Scrum effizienter nutzen
können.
229
Kapitel 10
ScrumMaster
10.3.6 Transparent
Und schließlich sorgt der ScrumMaster auch dafür, dass in allen Formen der Kommunika-
tion höchstmögliche Transparenz herrscht. In der Zusammenarbeit mit dem Team ist kein
Platz für Heimlichtuerei und verborgene Motive. Was man vom ScrumMaster sieht und
hört, muss absolut verlässlich sein. Nichts weniger als das erwarten die Mitarbeiter von
einer »dienenden Führungskraft«. Und auch außerhalb des Scrum-Teams fördert der
ScrumMaster eine transparente Kommunikation – denn ohne einen transparenten Infor-
mationszugang kann sich die Organisation kaum selbst auf den Prüfstand stellen und ggf.
nötige Anpassungen und Veränderungen vornehmen, um mit Scrum die gewünschten
Geschäftsergebnisse zu erzielen.
10.4 Alltag
Aber wie genau sieht denn nun der Alltag eines ScrumMasters während eines Sprints aus?
In Abbildung 10.3 ist zu sehen, wie viel Zeit der ScrumMaster eines neu gebildeten Teams
ungefähr für jede der verschiedenen Aktivitäten im Laufe eines Sprints aufwenden könnte.
Sollte er allerdings ein leistungsstarkes Scrum-Team coachen, das schon mehrere Jahre
zusammenarbeitet, fallen die hier dargestellten Prozentwerte voraussichtlich etwas anders
aus.
100%
Aufgewendete Zeit
0%
1 2 3 4 5 6 7 8 9 10
Tag in einem Sprint
Wie in der Abbildung gezeigt, wendet der ScrumMaster jeden Tag ein gewisses Zeitkontin-
gent für die Organisation und Unterstützung der Scrum-Aktivitäten auf. Dazu gehören die
Sprint-Planung und -Durchführung, die Sprint-Reviews und -Retrospektiven sowie der
Daily Scrum. Diese Aktivitäten müssen angeschoben und überwacht werden, so dass das
restliche Scrum-Team in der Lage ist, auf einem Niveau zu arbeiten, auf dem es hochwer-
tige Ergebnisse erzielen kann.
Das Coaching der Teammitglieder zwecks einer verbesserten Nutzung sowohl von Scrum
als auch von den technischen Praktiken findet tagtäglich statt. Außerdem führt der Scrum-
Master ggf. auch Trainingseinheiten zur Auffrischung durch – indem er z.B. ein neues
Team beim Schätzen von Product-Backlog-Elementen an die Regeln des Planungspokers
230
10.5
Die Rolle ausfüllen
erinnert. Ein bestimmtes tägliches Zeitkontingent ist überdies der Kommunikation gewid-
met (etwa zur Aktualisierung von Sprint und Release Burndown oder Burnup Charts oder
für Gespräche mit Nicht-Scrum-Teammitgliedern).
Während des Sprints arbeitet der ScrumMaster mit dem Product Owner an der Pflege des
Product Backlogs (wie etwa dem Schreiben und Priorisieren neuer Product-Backlog-
Elemente). Zudem sorgt er ebenfalls gemeinsam mit dem Product Owner dafür, dass
wirtschaftlich vertretbare Kompromisse hinsichtlich wichtiger Variablen wie dem Funk-
tionsumfang, der Terminplanung, dem Budget und der Qualität geschlossen werden.
Ebenso verwendet der ScrumMaster einen Teil seiner Zeit darauf, der Organisation behilf-
lich zu sein, in ihrer Wertekette (Verkauf, Marketing, Personal, Subunternehmer usw.) ein
besseres Verständnis für Scrum zu entwickeln.
Ein (variabler) Zeitanteil seines Arbeitstages ist der Beseitigung von Hindernissen gewid-
met. Prinzipiell könnte der ScrumMaster zwar für diese Aktivität einen festen täglichen
Zeitrahmen reservieren, aber natürlich können jederzeit Hindernisse auftauchen und noch
dazu umfangreich und vordringlich sein. Deshalb muss er die Möglichkeit haben, seine
Zeitkontingente möglichst flexibel auf die diversen Aktivitäten verteilen zu können, um
auch auf unvorhergesehene Ereignisse bzw. Umstände reagieren zu können.
Die meisten Teams und Organisationen, die sich noch nicht mit Scrum auskennen, haben
anfänglich mit einer Menge Probleme zu kämpfen und konzentrieren sich dabei in aller
Regel vorrangig auf diejenigen, die offensichtlich und einfach zu beseitigen sind. Das
bedeutet jedoch nicht, dass man alle Hindernisse so leicht wieder loswird. Im Gegenteil:
Die nächste Problemstufe wird vermutlich sogar viel schwieriger und zeitaufwendiger zu
bewältigen sein. Die Aufgabe der Beseitigung von Hindernissen ist eine große Unbekannte
im Alltag eines ScrumMasters – denn sie kann die Zeitplanung, die in Abbildung 10.3 zu
sehen ist, schnell über den Haufen werfen.
231
Kapitel 10
ScrumMaster
che Leute sehr gut als ScrumMaster geeignet sein – möglicherweise aber auch nicht, denn
schließlich bekleiden sie nicht ohne Grund eine technische Führungsposition: Weil sie in
dem, was sie tun, sehr gut sind. Die ScrumMaster-Rolle kann diese Art von technischer
Expertise jedoch nicht in vollem Umfang ausnutzen. Und immer wenn technische Leiter
die Arbeit eines ScrumMasters erledigen, sinkt dadurch notgedrungen auch das Ausmaß
ihrer Effizienz als technische Führungskraft. Und in der Folge könnte es durchaus passie-
ren, dass das technische Ergebnis des Entwicklungsprojekts negativ beeinflusst wird, wenn
man solche Leute zum ScrumMaster macht. Ich werde später in diesem Kapitel noch da-
rauf eingehen, ob ein Mitglied des Entwicklungsteams gleichzeitig als ScrumMaster agie-
ren kann.
Auch Manager aus funktionalen Bereichen oder Ressourcenmanager können als Scrum-
Master erfolgreich sein, sofern sie die Fähigkeiten für den Job mitbringen. Allerdings wäre
es am besten, wenn sie dann nicht länger für die Personalverwaltung zuständig wären –
zumindest nicht für die Mitglieder ihrer Scrum-Teams. Da ein ScrumMaster keine betrieb-
liche Autorität besitzt, könnte dies andernfalls zu Verwirrung unter den Teammitgliedern
führen, weil sie nicht wissen, ob die Person in einem speziellen Fall als ScrumMaster oder
als Manager handelt. Aus diesem Grund versuche ich, solche Situationen zu vermeiden.
Manchmal ist es jedoch trotzdem unumgänglich, so dass wir in solchen Fällen lernen müs-
sen, mit potenziellen Interessenkonflikten zurechtzukommen.
232
10.6
Abschließende Bemerkungen
sen. Verkompliziert wird die Lage zusätzlich noch dadurch, dass unerwartete Hindernisse
auftreten können, deren Beseitigung möglicherweise viel Zeit beansprucht. Damit wird es
noch schwieriger vorherzusagen, wie viel Zeit ein ScrumMaster als Teammitglied tatsäch-
lich noch für die Verrichtung der eigentlichen Aufgaben zur Verfügung hat.
Es gibt jedoch einen anderen Ansatz, der oft besser funktioniert: Sofern ein ScrumMaster
wirklich noch freie Kapazitäten hat, finde ich es meist sinnvoller, wenn diese Person als
ScrumMaster für mehrere Scrum-Teams arbeitet (siehe Abbildung 10.4).
Um ein guter ScrumMaster zu werden, braucht man wertvolle, nicht besonders häufig
anzutreffende Fertigkeiten. Insofern ziehe ich persönlich die Variante vor, bei der eine Per-
son, die diese Fertigkeiten mitbringt, mehreren Teams zur Verfügung steht, statt Zeit mit
Aktivitäten zu vergeuden, die nichts mit der ScrumMaster-Tätigkeit zu tun haben. Das ist
allerdings nur meine persönliche Ansicht, faktisch habe ich aber durchaus schon Scrum-
Teams erlebt, die mit beiden Ansätzen erfolgreich waren. In dieser Frage gibt es also keine
richtige oder falsche Antwort, aber es könnte ein falsches oder richtiges Vorgehen in einem
speziellen organisatorischen Kontext geben könnte.
Dieselbe Person
Product Owner als ScrumMaster Product Owner
Entwicklungsteam Entwicklungsteam
Abb. 10.4: Dieselbe Person als ScrumMaster für mehr als ein Team
Wie ich in Kapitel 9 bereits erwähnte, ist von der Rollenkombination aus ScrumMaster und
Product Owner dringend abzuraten, denn in seiner Eigenschaft als Coach des Scrum-
Teams ist der ScrumMaster auch der Scrum-Coach für den Product Owner – und man
kann ja schlecht sein eigener Coach sein. Darüber hinaus verfügt der Product Owner über
echte Produktautorität und kann Forderungen an das Team stellen. Der ScrumMaster tritt
hingegen meist als Vermittler in Bezug auf die Forderungen des Product Owners und die
Bedürfnisse und Fähigkeiten des Entwicklungsteams auf. Wenn Product Owner und
ScrumMaster eine Personalunion bilden, führt das nur zu unnötiger und noch dazu leicht
vermeidbarer Verwirrung.
233
Kapitel 10
ScrumMaster
dig auf Problemlösungsvorschläge des Teams warten, mit allen Beteiligten zusammenar-
beiten, das Team vor unnötigen Störungen schützen sowie auf sichtbare und transparente
Weise kommunizieren können sollte. Als Nächstes ging ich dann zur Verdeutlichung die-
ser wichtigen Rolle auf die Einteilung des Zeitkontingents des ScrumMasters während
eines Sprints ein. Und zum Schluss zeigte ich die wichtigsten Kriterien für die Entschei-
dungsfindung in Bezug auf die Fragen auf, wer in der Organisation zum ScrumMaster
ernannt werden sollte, ob es sich um eine Vollzeitbeschäftigung handelt und wie man die
Rolle des ScrumMasters mit anderen Scrum-Rollen kombinieren könnte.
Im nächsten Kapitel werde ich genauer untersuchen, welche Rolle das Entwicklungsteam
in Scrum spielt.
234
Kapitel 11
Das Entwicklungsteam
In diesem Kapitel beschreibe ich die Rolle des Entwicklungsteams. Ich untersuche zuerst
die fünf wichtigsten Aufgaben dieser Rolle und schließe mit einer Beschreibung von zehn
Eigenschaften, die ein Entwicklungsteam aufweisen sollte.
11.1 Überblick
Traditionelle Softwareentwicklungsansätze definieren verschiedene Tätigkeitsarten wie
etwa Softwarearchitekt, Programmierer, Tester, Datenbankadministrator, UI (User Inter-
face)-Designer usw. Scrum definiert dagegen die Rolle des Entwicklungsteams. Im Prinzip
handelt es sich dabei einfach um eine funktionsübergreifende Ansammlung all dieser ver-
schiedenen Fachleute. Insbesondere repräsentiert das Entwicklungsteam eine der drei Rol-
len, die es in jedem Scrum-Team gibt. Die Mitglieder des Entwicklungsteams besitzen
zusammen alle Fähigkeiten, die nötig sind, um den vom Product Owner angeforderten
Geschäftswert zu liefern.
Der Begriff »Entwicklungsteam« mag vielleicht die falsche Bezeichnung für ein Team sein,
das aus mehr als nur den Entwicklern besteht. Es wurden auch schon andere Namen ver-
wendet, wie etwa »Delivery Team«, »Design-Bau-Test-Team« und auch nur »Team« – es ist
allerdings fraglich, ob eine dieser Bezeichnungen passender, weniger missverständlich
oder einfacher zu benutzen ist. Im Moment hat sich die Scrum-Gemeinde auf den Begriff
»Entwicklungsteam« geeinigt, weshalb auch ich ihn in diesem Buch benutzen werde.
235
Kapitel 11
Das Entwicklungsteam
manchmal notwendig sein kann, ein Team zu haben, das sich eigens auf die Tests konzen-
triert – weil z.B. eine behördliche Anordnung ein separates Team für die Durchführung
bestimmter Tests vorschreibt – meist ist das aber nicht erforderlich. In der Regel sollte das
Testen vielmehr vollständig in die Arbeit integriert sein, die während der einzelnen Sprints
stattfindet – und aus diesem Grund sollte das Entwicklungsteam, das die Arbeit während
des Sprints erledigt, auch die Tests durchführen.
Schaffen Sie nach Möglichkeit immer funktionsübergreifende Teams. Der erfolgreiche Ein-
satz von Scrum wird durch die Verteilung der Arbeit an unterschiedliche, rollenspezifische
Teams ernsthaft behindert. Wenn Sie auf diese Weise vorzugehen planen, sollten Sie
zunächst sicherstellen, dass dies nicht aus reiner Gewohnheit geschieht, sondern zweifels-
frei ein echter Bedarf an rollenspezifischen Teams besteht.
Daily Scrum
Sprint-Planung
Sprint Backlog
Product Backlog
Sprint-Ausführung
Pflege
Potenziell
auslieferungsfähiges
Produktinkrement
Sprint Review
Sprint-Retrospektive
236
11.3
Wichtigste Aufgaben
organisiert sich das Team selbst und entscheidet gemeinschaftlich, wie die Arbeit geplant,
aufgeteilt, ausgeführt und kommuniziert werden soll (mehr dazu in Kapitel 20). Das Ent-
wicklungsteam bringt also einen Großteil seiner Zeit mit der Sprint-Durchführung zu.
237
Kapitel 11
Das Entwicklungsteam
11.4 Eigenschaften/Fertigkeiten
Abbildung 11.2 zeigt wichtige Eigenschaften des Entwicklungsteams.
Selbstorganisierend
Funktionsübergreifend vielseitig
T-förmige Fertigkeiten
Musketier-Einstellung
Entwicklungsteam-
Breitbandige Kommunikation
Eigenschaften
Transparente Kommunikation
Richtige Größe
Nachhaltiges Arbeitstempo
Langlebig
11.4.1 Selbstorganisierend
Die Teammitglieder organisieren sich selbst, um die beste Methode zum Erreichen des
Sprint-Ziels zu finden. Das bedeutet, es gibt keinen Projekt- oder anderen Manager, der
ihnen sagt, wie sie arbeiten sollen (und ein ScrumMaster sollte sich niemals erdreisten, das
zu tun). Die Selbstorganisation ist eine Bottom-Up-Eigenschaft des Systems, d.h., sie ver-
läuft von unten nach oben, es gibt keine externe Kraft, die ein traditionelles, von oben auf-
oktroyiertes Management durchzusetzen versucht.
Ich möchte das an einem Beispiel verdeutlichen. In der Nähe meines Wohnortes in Colo-
rado gibt es einen Teich. Im Winter kommt immer ein Schwarm Kanadagänse und rastet
dort. Jedes Jahr haben wir also mehrere Hundert Gänse bei uns, die gleichzeitig nett anzu-
sehen sind und eine riesige Sauerei veranstalten. Nun besitze ich allerdings zwei Hunde
namens Letti und Toast. Normalerweise bleiben sie innerhalb des umzäunten Grund-
stücks, gelegentlich lassen wir sie jedoch draußen herumlaufen und wenn sie die Gänse
am Teich sehen, dann laufen sie hin, um sie zu begrüßen. Ich glaube nicht, dass sie die
Gänse jagen würden, aber wenn die Gänse Letti und Toast kommen sehen, dann entschei-
den sie üblicherweise, ihnen den Teich zu überlassen und fliegen auf.
238
11.4
Eigenschaften/Fertigkeiten
Haben Sie sich schon mal gefragt, woher ein auffliegender Vogelschwarm weiß, dass er das
charakteristische V-Muster (Schwarmmuster) formen muss? Glauben Sie, es gibt irgendwo
einen »Managervogel« mit einem imaginären Klemmbrett, der am Teich ein Treffen aller
Vögel einberuft, um sie anzuweisen, wie sie im Schwarm fliegen sollen (siehe Abbildung
11.3)?
Ich lebe nun schon sehr lange neben dem Teich und kann mich nicht erinnern, jemals ein
solches Treffen erlebt zu haben. (Obwohl mein Sohn Jonah vor einigen Jahren erklärte:
»Dad, du hast das noch nie gesehen, weil sie sich in der Nacht treffen!« Hm, da könnte
etwas dran sein...)
Die Gänse bilden ihren Schwarm natürlich durch Selbstorganisation, eine von unten nach
oben verlaufende Eigenschaft eines komplexen adaptiven Systems – es sei denn natürlich,
mein Sohn hat recht und die Vögel sind viel schlauer, als ich dachte. In solchen Systemen
interagieren viele Einheiten auf verschiedene Arten miteinander. Und diese Interaktionen
werden durch einfache, lokalisierte Regeln bestimmt, die in einem Kontext aus konstantem
Feedback arbeiten (siehe Abbildung 11.4).
Hört zu!
Wenn wir abheben, fliege ich
voran. George, du bleibst 1 Meter
links hinter mir, und Cindy, du fliegst
1 Meter rechts hinter mir. Der
Rest verteilt sich fächerförmig
dahinter.
Ich
Solche Systeme weisen interessante Eigenschaften auf, sind bemerkenswert robust und
produzieren erstaunliche Innovationen.
239
Kapitel 11
Das Entwicklungsteam
Genau wie bei den schwärmenden Vögeln gibt es auch beim Entwicklungsteam keine
befehlsgebende Autorität von oben, die dem Team vorgibt, wie es seine Arbeit tun soll.
Stattdessen organisiert sich ein funktionsübergreifendes Team aus ganz unterschiedlichen
Leuten selbst auf die bestmögliche Weise, um die anstehende Arbeit erledigen zu können.
Im Prinzip bildet das Team seine Variante des V-Musters.
• Drängelt nicht
• Fliegt in ungefähr dieselbe
Richtung wie die Nachbarn
• Fliegt an derselben Position
relativ zu den Nachbarn
Dennoch spielen die Manager eine wichtige Rolle in Scrum: Sie schaffen (und erhalten) die
Umgebung für das sich selbst organisierende Team. Auf die Rolle der Manager werde ich in
Kapitel 13 noch ausführlicher zu sprechen kommen.
240
11.4
Eigenschaften/Fertigkeiten
Funktionsübergreifende Teammitglieder
Funktionsübergreifend
vielseitig
Unterschiedliche Hintergründe
Interpretationen
Strategien/Heuristiken
Entwicklungsteam- Unterschiedliche
Vielseitigkeit Perspektiven
Mentale Modelle
Vorlieben
Schnellere Lösungen
Größere Innovationen
241
Kapitel 11
Das Entwicklungsteam
ence (UX) – das ist ihr Spezialgebiet, in dem sie am liebsten arbeitet. Sie kann aber auch
außerhalb ihres Kernbereichs tätig werden und z.B. Tests durchführen oder für die Doku-
mentation sorgen. Vermutlich ist sie darin zwar nicht so gut wie jemand, der sich auf diese
Tätigkeiten spezialisiert hat, dennoch kann sie durchaus aushelfen, wenn das Team in die-
sen Bereichen einen Engpass erfährt. So gesehen, besitzt Sue breit gefächerte Fertigkeiten,
die es ihr erlauben, auch außerhalb ihres Kernbereichs zu arbeiten.
Funktionsbereich,
Disziplin oder Spezialgebiet
Es ist unrealistisch zu glauben, dass jede Person in einem Team an jeder Aufgabe arbeiten
könnte. Das wäre ein ziemlich hochtrabendes Ziel. So wäre es in Bereichen mit einer star-
ken Spezialisierung wie beispielsweise der Videospielentwicklung, in denen ein Team
einen Grafikdesigner, einen Animator, einen Tontechniker, einen KI (Künstliche Intelli-
genz)-Programmierer und einen Tester umfassen könnte, unvernünftig anzunehmen, dass
jeder alle Aufgaben leisten kann. Wäre ich in einem Team, das ein Videospiel entwickelt,
dann könnte ich an der KI arbeiten und einige Tests durchführen, für die künstlerischen
Aspekte wäre ich jedoch definitiv nicht geeignet (das würde sich niemand wünschen!). Ich
könnte allerdings den Grafikdesignern bei einigen nicht kreativen Arbeiten helfen, etwa
beim Konvertieren von Dateiformaten mit Photoshop oder beim Anlegen von Skripten
zum Bearbeiten mehrerer Dateien.
Manager sollten sich darauf konzentrieren, Teams zusammenzustellen, in denen sich die
besten T-förmigen Fertigkeiten vereinen, die mit dem verfügbaren Personal zu bekommen
sind. Allerdings ist es manchmal nicht möglich, gleich von Anfang an die gewünschten
Teamfähigkeiten abzurufen, aber glücklicherweise können sich die Fertigkeiten im Laufe
der Produktentwicklung weiterentwickeln. Aus diesem Grund ist es wichtig, eine Umge-
bung zu schaffen, in der die Mitarbeiter kontinuierlich lernen und neue Fertigkeiten erwer-
ben können, egal, ob es sich dabei um Fachwissen, technische Kenntnisse, neue
Denkweisen oder andere Fähigkeiten handelt. Das Management muss den Teammitglie-
dern also stets auch Zeit zum Lernen und Experimentieren einräumen (siehe Kapitel 13).
242
11.4
Eigenschaften/Fertigkeiten
Aber ist es in Ordnung, reine Spezialisten im Team zu haben? Kommen wir noch einmal
auf unser Beispiel mit Sue zurück und nehmen wir an, sie sei zwar eine großartige UX-
Designerin, wäre für andere Aufgaben allerdings nur äußerst bedingt geeignet. Da wir
jedoch tatsächlich so wenige UX-Designer haben, wollen wir auch gar nicht, dass sie
etwas anderes macht als wichtige UX-Designarbeit. Wir brauchen ihre Fertigkeiten im
Team, können aber nur etwa 10% ihrer Zeit mit teambezogener Arbeit füllen. In einem
solchen Fall würde die offensichtliche Lösung darin bestehen, Sues Zeit auf mehrere
Teams aufzuteilen.
Dennoch müssen wir auch dabei realistisch bleiben. Sue wäre zweifellos völlig überfordert,
wenn sie ihre Zeit in 10%-Häppchen auf viele Teams gleichzeitig aufteilen würde – das
würde sehr schnell ein massives »Flaschenhalsproblem« nach sich ziehen (siehe den
Abschnitt »Fokussiert und verpflichtet« weiter hinten in diesem Kapitel). Rufen Sie sich
aus Kapitel 3 ins Gedächtnis zurück, dass unser Ziel nicht darin bestehen sollte, Leute wie
Sue zu 100% auszulasten. Stattdessen sollten wir uns mehr Sorgen um die unerledigte
Arbeit machen (den Staffelstab, der auf dem Boden liegt), die sich anhäuft, wenn wir uns
zu stark auf eine übermäßig beanspruchte Ressource verlassen. Deshalb würden wir Sue
lediglich einer vertretbaren Anzahl an Projekten als Spezialistin zuweisen, nicht aber gleich
so vielen, dass sie in der Endkonsequenz Verzögerungen verursachen würde.
Da unser Ziel darin besteht, einen guten Workflow für die Teammitglieder zu erreichen,
die breit gefächerte T-förmige Fertigkeiten besitzen, sollten wir Sue alternativ dazu ermun-
tern, anderen Teammitgliedern ihr Wissen auf dem Gebiet des UX-Designs zu vermitteln,
damit wir uns nicht mehr so stark auf Spezialisten verlassen müssen.
Zusammenfassend lässt sich also sagen, dass unsere Zielsetzung lautet, ein Team zu bil-
den, dessen Mitglieder die passenden Fertigkeiten besitzen, um die wichtigsten Spezialge-
biete abzudecken. Zusätzlich sollten einige Überschneidungen bei den Fertigkeiten
vorhanden sein, damit eine gewisse Flexibilität gewährleistet ist. Dazu sollten viele Team-
mitglieder T-förmige Fertigkeiten besitzen, aber natürlich brauchen wir weiterhin einige
Spezialisten in unserer Teamzusammenstellung.
243
Kapitel 11
Das Entwicklungsteam
Durch die Zusammenstellung eines Teams, dessen Mitglieder T-förmige Fertigkeiten auf-
weisen, unterstützt man diese Einstellung und setzt sie aktiv in die Praxis um, weil die ein-
zelnen Mitarbeiter in der Lage sind, mehrere verschiedene Aufgaben zu übernehmen. In
diesen Teams wird niemand, der eine Arbeit erledigen kann, sagen: »Das ist nicht mein
Job.«
Da jedoch nicht immer wirklich jedes Teammitglied so flexibel in mehreren Arbeitsberei-
chen eingesetzt werden kann, wird es schon mal den ein oder anderen geben, der sagt: »Ich
bin nicht in der Lage, diese Arbeit zu erledigen.« In diesem Fall könnte das Team beschlie-
ßen, die betreffende Person einem anderen Teammitglied zur Seite zu stellen, das die benö-
tigte Fertigkeit besitzt und ihr Wissen auf diese Weise weitervermittelt.
Doch selbst wenn die begrenzten eigenen Fertigkeiten jemanden daran hindern, funktions-
übergreifend zu arbeiten, können die Teammitglieder ihre Arbeit immer noch so organisie-
ren, dass im Laufe des Sprints ein guter Workflow erreicht und kein Teammitglied
überlastet wird. Sollten Sie hingegen z.B. die ganze Testarbeit bis zum Ende des Sprints
aufsparen, damit der »Tester« die Arbeit erledigen kann, ist ein Scheitern quasi schon vor-
programmiert. In Kapitel 20 finden Sie eine ausführlichere Diskussion zu der Frage, wie
das Team den Workflow während der Sprint-Durchführung organisieren sollte.
Abb. 11.7: Die Teammitglieder müssen handeln, als würden sie alle im selben Boot sitzen
Bei einer Musketier-Einstellung gibt es keine »Mitläufer«. Jedes Teammitglied trägt die Ver-
antwortung, sich jederzeit vollständig in das Team einzubringen. Oft bedeutet das auch,
dass man sich an Aktivitäten außerhalb des eigenen Spezialgebiets beteiligt und beispiels-
weise neue Sichtweisen in die projektbezogenen Diskussionen einbringt. Sollte z.B. ein
Teammitglied, das auf das Testen spezialisiert ist, der Meinung sein, ein Problem in dem
Design entdeckt zu haben, das das Team für eine künftige Funktion vorgesehen hat, ist es
seine Pflicht, diesen Punkt im Team anzusprechen, statt mit den Schultern zu zucken und
zu sagen: »Ist nicht mein Job. Außerdem kennen die sich damit sowieso besser aus als
ich.«
244
11.4
Eigenschaften/Fertigkeiten
245
Kapitel 11
Das Entwicklungsteam
schaffen. Wenn die Teammitglieder z.B. erst drei Umwege nehmen müssen, bevor sie mit
einem realen Kunden oder Anwender reden können, stellt diese Vorgehensweise für »Mit
einem Kunden sprechen« eher ein echtes Hemmnis für eine breitbandige Kommunikation
dar, weil die Bandbreite sinkt, wenn man erst sinnlose Dokumente erstellen oder langwie-
rige und potenziell unnötige Genehmigungsverfahren durchlaufen muss. Solche Hinder-
nisse gilt es zu erkennen und zu eliminieren, um die Teamkommunikation als Ganzes zu
verbessern.
Der Kommunikationsbandbreite zuträglich ist dagegen, wenn man nur kleine Teams hat.
Die Kommunikationskanäle in einem Team skalieren nicht proportional zur Anzahl der
Leute, sondern nehmen stattdessen entsprechend der Formel N(N-1)/2 quadratisch zu.
Wenn also 5 Leute im Team sind, gibt es 10 Kommunikationskanäle. Bei 10 Leuten sind es
schon 45 Kommunikationskanäle. Mehr Teammitglieder bedeuten somit einen höheren
Overhead für die Kommunikation und damit auch eine geringere Bandbreite.
246
11.4
Eigenschaften/Fertigkeiten
Natürlich ist es auch möglich, dass ein Team zu klein ist. Dies ist beispielsweise dann der
Fall, wenn es nicht genügend Leute enthält, um die Aufgabe zu erfüllen oder effizient zu
arbeiten.
Die Bevorzugung kleiner Teams soll allerdings nicht heißen, dass wir Scrum nicht für ein
größeres Entwicklungsprojekt einsetzen könnten. Im Gegenteil: Scrum wird häufig ver-
wendet, um Produkte zu bauen, die mehr als neun Leute erfordern. Anstatt jedoch ein gro-
ßes Scrum-Team mit z.B. 36 Mitgliedern im Entwicklungsteam zu haben, würden wir vier
oder mehr Scrum-Teams einrichten, deren Entwicklungsteams jeweils aus höchstens neun
Leuten bestehen würden.
Ein Scrum-Projekt skaliert nicht durch ein größeres Entwicklungsteam, sondern durch
mehrere Scrum-Teams. Es gibt verschiedene Möglichkeiten, um mehrere Scrum-Teams
miteinander zu koordinieren. Ein verbreiteter Ansatz ist als Scrum of Scrums bekannt.
Dabei kommen Mitglieder aus den einzelnen Scrum-Teams zusammen, um ein höher
angebundenes Äquivalent eines Daily Scrum zu »zelebrieren« (mehr dazu in Kapitel 12).
247
Kapitel 11
Das Entwicklungsteam
Es gibt zahlreiche Untersuchungen, die die weithin verbreitete Annahme stützen, dass eine
Beteiligung an mehreren Produkten (oder Projekten) oder an mehreren Teams die Produk-
tivität beeinträchtigt. Abbildung 11.8 zeigt ein entsprechendes Diagramm (Wheelwright
und Clark 1992).
90%
Zeit in Prozent, in der Werte
80%
70%
geschaffen werden
60%
50%
40%
30%
20%
10%
0%
1 2 3 4 5 6
Anzahl gleichzeitiger Projekte
Die in diesem Zusammenhang erhobenen Daten deuten darauf hin, dass niemand zu
100% produktiv ist – in jedem sozial verantwortlichen Unternehmen (Corporate Citizen)
gibt es einen Overhead. Allerdings scheint die Produktivität bei der Beteiligung an zwei
Projekten besser zu sein als bei einem einzelnen Projekt. Das hängt damit zusammen, dass
in Unterbrechungszeiten der Projektaktivität ein Alternativprojekt bereitsteht, zu dem die
Mitarbeiter wechseln können, so dass sie in der Summe produktiver sind.
Legt man diese Daten zugrunde, dann ist es aus wirtschaftlicher Sicht jedoch eine schlechte
Idee, an drei oder mehr Projekten gleichzeitig zu arbeiten, weil mehr Zeitaufwand erforder-
lich ist, um die Arbeit zu koordinieren, sich wieder in das betreffende Projekt hineinzufin-
den sowie Informationen einzuholen und dadurch weniger Zeit für die eigentliche Arbeit
bleibt. An wie vielen Projekten/Produkten (und möglicherweise unterschiedlichen Teams)
sollte eine Person also idealerweise gleichzeitig arbeiten? Wahrscheinlich an nicht mehr als
zwei. Ich persönlich tendiere sogar eher zu einem einzigen, denn in der heutigen vernetz-
ten und informationsgesättigten Welt mit E-Mail, Instant Messaging, Twitter, Facebook und
anderen Technologien ist »Corporate Citizenship«, also die soziale Verantwortung eines
Unternehmens, durchaus gleichbedeutend mit der Arbeit an nur einem einzigen Projekt
zu sehen!
Doch was machen wir mit unseren Spezialisten, die möglicherweise gleichzeitig mehreren
Produkten zugeordnet werden müssen? Greifen wir noch einmal auf das Beispiel von Sue
(der UX-Designerin) zurück, die zu 10% einem bestimmten Team zugeordnet war (die rest-
liche Zeit war anderen Teams gewidmet). Auch wenn wir uns wünschen würden, dass Sue
nur an einem oder zwei Produkten arbeiten müsste, ist es dennoch möglich, dass sie an
fünf Produkten gebraucht wird. Was dann? Nun, lassen Sie doch einfach den Spezialisten
selbst entscheiden, wie vielen Produkten/Projekten er seine Aufmerksamkeit gleichzeitig
248
11.4
Eigenschaften/Fertigkeiten
zuwenden kann. Wenn Sue also sagt, dass sie keine zusätzliche Arbeit mehr übernehmen
kann, dann weisen Sie sie auch keinem weiteren Produkt oder Team zu. Wahrscheinlich
wird ihre Entscheidung aus unternehmerischer Sicht problematisch sein, dennoch sollte in
einem solchen Fall eine andere Lösung für dieses Dilemma gefunden werden.
Und davon gibt es einige. Erstens: Reduzieren Sie die Anzahl Ihrer gleichzeitigen Projekte.
Meist ist das schon die richtige Lösung, denn viele Organisationen nehmen ganz einfach
von vornherein zu viele Projekte auf einmal in Angriff (siehe Kapitel 16 für eine ausführli-
chere Diskussion). Eine andere Lösung bestünde darin, mehr Spezialisten anzuheuern, um
die Arbeitslast aufzuteilen. Die dritte Lösung wäre, andere Mitarbeiter darin zu bestärken
und zu unterstützen, ihre Fertigkeiten in dem betreffenden Fachbereich zu verbessern.
Und als vierte Lösung käme natürlich auch eine Kombination aus den ersten drei Lösun-
gen infrage. Denn sollten Sie Ihre Mitarbeiter drängen, an zu vielen Projekten/in zu vielen
Teams gleichzeitig zu arbeiten, reduzieren Sie am Ende nur deren Fokus und Hingabe und
gefährden damit auch das Geschäftsergebnis.
Scrum
Traditionell
Intensität
Zeit
Abb. 11.9: Nachhaltige Geschwindigkeit im Zeitverlauf
Diese unglaublich arbeitsintensive Zeit ist durch »Superhelden« geprägt, die nächtelang
und auch an den Wochenenden arbeiten, um den Fertigstellungstermin zu schaffen. Man-
249
Kapitel 11
Das Entwicklungsteam
che Leute blühen in solchen Situationen regelrecht auf, sie lieben die Aufmerksamkeit und
Anerkennung, die ihnen für ihre außerordentlichen Bemühungen zuteil wird. Für alle
anderen ist der Stress allerdings einfach übermächtig. Als Organisation sollten wir uns
daher fragen: »Warum mussten wir in den Nächten und an den Wochenenden arbeiten
und was sollten wir ändern?«
Vergleichen Sie diese Ausgangssituation nun einmal mit dem typischen Intensitätsprofil
beim Einsatz von Scrum, wo wir in jedem Sprint kontinuierlich Funktionen entwickeln,
testen und integrieren. In jedem Sprint sollten die Teammitglieder gute technische Verfah-
ren wie das Refactoring, fortlaufende Integration und automatisierte Tests einsetzen, damit
sie häufig und regelmäßig funktionierende Werte abliefern können, ohne sich zu überar-
beiten.
Wir werden also vermutlich innerhalb eines Sprints merken, dass die Intensität zum Ende
hin, wenn es darum geht, alle zur Erfüllung unserer starken Definition von Fertig erforder-
lichen Arbeiten abzuschließen, ein wenig ansteigt. Dennoch sollte die Gesamtintensität des
Arbeitsaufkommens während eines Sprints grundsätzlich der Intensität vorhergehender
Sprints in etwa gleichen – damit gewährleistet ist, dass das Team in einer Geschwindigkeit
arbeitet, die sich auf Dauer auch durchhalten lässt.
Auf diese Weise erreichen wir eine ausbalancierte Arbeitsbelastung, die nicht in großen
Brocken oder intensiven Spitzen über uns hereinbricht, und vor allem nicht zu einem spä-
ten Zeitpunkt, wenn das den größten Schaden anrichten würde. Eine derartige Balance
bedeutet zudem, dass das Scrum-Team vermutlich nur wenige Überstunden machen muss
und deshalb weniger Burnouts erleidet.
11.4.10 Langlebig
Der effiziente Einsatz von Scrum erfordert keine Arbeitsgruppen, sondern echte Teams.
Ein Team besteht aus einer vielseitigen, funktionsübergreifenden Ansammlung von Leu-
ten, die eine gemeinsame Vision verfolgen und zusammenarbeiten, um diese Vision zu
erreichen. Eine Arbeitsgruppe ist dagegen lediglich eine Ansammlung von Leuten, die
unter einer gemeinsamen Bezeichnung referenziert wird. Außer diesem Namen haben die
Mitglieder einer Arbeitsgruppe allerdings nicht viel gemeinsam und würden daher die Auf-
gaben, die ich für die Rolle des Entwicklungsteams beschrieben habe, nicht effizient erfül-
len.
Teamaufstellungen sollten langlebig sein. Ich halte meine Teams in der Regel so lange
zusammen, wie es sich wirtschaftlich vernünftig vertreten lässt. Und die wirtschaftlichen
Aspekte sprechen für langlebige Teams. Untersuchungen von Katz haben gezeigt, dass
langlebige Teams produktiver sind als neu gebildete Arbeitsgruppen (Katz 1982). Darüber
hinaus demonstrieren Forschungen von Staats, dass die Vertrautheit des Teams (frühere
gemeinsame Arbeitserfahrungen der Teammitglieder) die Effizienz und die Qualität der
Teamergebnisse positiv beeinflussen kann (Staats 2011). Und höhere Produktivität, Effi-
zienz und Qualität führen zu besseren Geschäftsergebnissen.
Wenn wir mit einer Arbeitsgruppe beginnen, die aus Leuten besteht, die noch nie zusam-
mengearbeitet haben, müssen wir Zeit und Geld aufwenden, um sie zu einem echten Team
zusammenzuschweißen. Die meisten Arbeitsgruppen müssen bestimmte Phasen durch-
laufen (»Forming, Storming, Norming und Performing«), bis sie zu hochfunktionalen
250
11.4
Eigenschaften/Fertigkeiten
Teams zusammenwachsen (Tuckman 1965). Wenn es aber erst einmal soweit ist, stellen sie
einen echten Gewinn für unsere Organisation dar, weil alle Mitglieder dieser Teams wissen,
wie sie zusammenarbeiten müssen und sich gegenseitiges Vertrauen verdient haben. Da-
rüber hinaus hat jedes Team wichtige historische Informationen angehäuft, wie z.B. die Ent-
wicklungsgeschwindigkeit (Velocity) und eine gemeinsame Schätz-Historie (siehe Kapitel
7). Und wenn wir ein Team auflösen oder seine Zusammensetzung ändern, dann haben
diese wertvollen, teamspezifischen historischen Informationen keinen Kontext mehr, in
dem man sie direkt einsetzen könnte.
Leider erlebe ich viel zu oft Organisationen, die den wahren Wert ihrer Teams nicht zu
schätzen wissen. Die meisten Organisationen haben eigene Systeme und Verfahren entwi-
ckelt, um ihre Mitarbeiter dynamisch zu »Teams« (eigentlich handelt es hierbei eher um
Arbeitsgruppen) zusammenzustellen. Meiner Meinung nach verkennen solche Praktiken
allerdings einen wesentlichen Aspekt von Scrum: Der wahre Wert liegt im Team. Die
Währung des agilen Arbeitens ist das Team. So lautet etwa einer der Kernwerte des Agilen
Manifests »Individuen und Interaktionen«. Mit anderen Worten: Das Team ist der wert-
vollste Aktivposten.
Wenn man Mitarbeiter von einem Team zum anderen verschiebt, zerstört man die Integri-
tät des Teams. Ich bezweifle, dass die SWAT-Spezialeinheit (Special Weapons and Tactics)
der New Yorker Polizei regelmäßig umgebaut wird. Die Mitglieder dieses speziellen Teams
haben gelernt, zusammenzuarbeiten und einander in gefährlichen Situationen zu sichern.
Und würde ihre Zusammensetzung ständig verändert werden, würden Vertrauen, Integri-
tät und Effizienz auf die Dauer Schaden nehmen. (In unserer Situation wäre ein Abfall der
Entwicklungsgeschwindigkeit die Folge, im Fall der SWAT-Einheit ein Verlust an Sicher-
heit.)
Die meisten Organisationen wären viel besser dran, wenn sie es sich zur Regel machen
würden, wenigstens das Kernteam so lange wie möglich unverändert bestehen zu lassen
und die Teams von Produkt zu Produkt zu versetzen. Es ist wirtschaftlich immer sinnvoller,
gut aufgestellte Teams im Ganzen zu versetzen als einzelne Leute.
Das soll aber nicht heißen, dass Sie Ihre Teams unter allen Umständen über einen langen
Zeitraum zusammenhalten sollten und könnten. Es kann natürlich auch vorkommen, dass
sich ein Team nicht in der von uns erhofften Form zusammenfindet oder auf andere Art
dysfunktional ist. In solchen Fällen wäre es selbstverständlich wirtschaftlich sinnvoller, das
Team aufzulösen.
So war ich beispielsweise einmal als Coach für eine Organisation tätig, in der wir ganz
bewusst ein leistungsstarkes Scrum-Team auflösten, um eine weitreichendere Integration
von Scrum innerhalb der Organisation zu unterstützen. Hier erfolgte die Auflösung nicht
etwa, weil das Team seine Arbeit beendet hatte und es Zeit war, die Mitarbeiter für das
nächste Entwicklungsprojekt neuen Teams zuzuordnen, sondern weil wir es für besser
hielten, mit den Scrum-erfahrenen Personen sechs neue Scrum-Teams zu bilden, als das
Originalteam beizubehalten.
Da Teams generell ein so wertvoller Aktivposten sind, müssen sie auch als Maßstab dafür
gelten, wie viele und welche Arten von Produktentwicklungen wir gleichzeitig durchführen
sollten. Ich werde das in Kapitel 16 ausführlicher diskutieren.
251
Kapitel 11
Das Entwicklungsteam
252
Kapitel 12
Die Scrum-Teams sind die wichtigsten Eckpfeiler einer Scrum-Organisation. Wie sie struk-
turiert sind und in welcher Beziehung sie zueinander stehen, kann den Erfolg einer Orga-
nisation mit Scrum ganz beträchtlich beeinflussen. In diesem Kapitel zeige ich
unterschiedliche Möglichkeiten auf, um Scrum-Teams zu strukturieren. Beginnen werde
ich mit dem Unterschied zwischen einem Funktionsteam und einem Komponententeam.
Anschließend befasse ich mich mit der Frage, wie man mehrere zusammenwirkende
Scrum-Teams koordiniert.
12.1 Überblick
Wenn Sie ein kleines Produkt haben, dann müssen Sie sich nicht allzu viele Gedanken über
den Inhalt dieses Kapitels machen: Stellen Sie einfach ein funktionsübergreifendes Ent-
wicklungsteam auf, das die Eigenschaften besitzt, die ich in Kapitel 11 beschrieben habe,
und besetzen Sie die Rollen des ScrumMasters und des Product Owners mit geeigneten
Kandidaten. Aus Sicht des Scrum-Teams können Sie dann loslegen!
Nehmen wir jedoch einmal an, aus Ihrem einen funktionsübergreifenden Scrum-Team
wird eine leistungsstarke Maschinerie zum Abliefern von Geschäftswerten und Ihre Orga-
nisation beginnt zu wachsen. Oder Sie haben bereits eine größere Organisation und nach
der Entwicklung Ihres ersten Produkts mithilfe von Scrum wollen Sie dieses Entwicklungs-
verfahren in größerem Maßstab einsetzen. In beiden Fällen werden Sie bald die Arbeit
mehrerer Scrum-Teams koordinieren müssen, deren kombinierte Anstrengungen nötig
sind, um einen zunehmend größeren Geschäftswert abzuliefern.
Wie sollten Sie diese Teams strukturieren, damit Sie leistungsstark und gut koordiniert
sind? Ich gehe auf diese Frage ein, indem ich untersuche, ob Sie Funktions- oder Kompo-
nententeams haben sollten und mit welchen Verfahren Sie die Aktivitäten mehrerer Teams
koordinieren können.
253
Kapitel 12
Die Strukturen des Scrum-Teams
organisieren, der mit dem Ermitteln einer Route von einem Ausgangspunkt zu einem Ziel
einhergeht. Immer wenn es Bedarf an neuen GPS-Funktionen gibt, die eine Routenpla-
nung beinhalten, würden die Routenplaner-spezifischen Teile dieser Funktionen dem für
die »Routenplaner«-Komponente zuständigen Team zur Entwicklung zugewiesen.
Komponententeams werden manchmal auch als Subsystem-Teams bezeichnet. Oft funk-
tioniert eine Community of Practice, die aus Mitarbeitern mit den gleichen Spezialkenntnis-
sen besteht (siehe Abbildung 13.4), ebenfalls wie ein Komponententeam. In diesen Teams
sind alle Mitglieder vermutlich demselben Abteilungsleiter verantwortlich und agieren als
eine gemeinsame, zentralisierte Ressource für andere Teams. Ein Beispiel könnte die zent-
ralisierte UX-Abteilung sein, die Bedienoberflächen (User Interface, UI) für andere Teams
herstellt.
Scrum bevorzugt Funktionsteams. Leider ziehen viele Organisationen Komponententeams
vor – weil man davon ausgeht, dass ein bestimmter Codebereich in einem Expertenteam,
dem man sichere und effiziente Änderungen zutraut, am besten aufgehoben wäre. In der
Regel wird unterstellt, dass Leute, die nicht mit dem Code vertraut sind, ihn versehentlich
auf unvorhergesehene Weise beschädigen könnten, so dass es naheliegender erscheint, ein
Komponententeam mit der Entwicklung des betreffenden Codes zu beauftragen und im
Namen Dritter Änderungen daran vornehmen zu lassen.
Nehmen wir einmal an, wir entwickeln ein Produkt, dessen Funktionen oft in drei Kompo-
nentenbereiche hineinspielen (siehe Abbildung 12.1).
Product Backlog
K 1 PB K 2 PB K 3 PB
254
12.2
Funktionsteams versus Komponententeams
Product Backlog 1
Product Backlog 2
K 1 PB K 2 PB K 3 PB
255
Kapitel 12
Die Strukturen des Scrum-Teams
Stellen Sie sich vor, Sie seien der Product Owner eines der Komponententeams. Sie müs-
sen nun miteinander konkurrierende Anforderungen von zwei Produkten priorisieren,
während Sie sich gleichzeitig mit den anderen auf Komponentenebene arbeitenden Teams
koordinieren müssen, um sicherzustellen, dass die verschiedenen Teile zum passenden
Zeitpunkt integriert werden.
Bei zwei Produkten ist die Logistik dieses Problems vermutlich noch überschaubar. Doch
was ist, wenn die Organisation an 10 oder 15 Produkten gleichzeitig arbeitet und jedes die-
ser Produkte Teile auf Komponentenebene in die Backlogs der Komponententeams ein-
bringt? Bei dieser Größe ist die Logistik zum Ermitteln der richtigen Reihenfolge für die
Arbeit an den einzelnen Teilen innerhalb eines Komponententeam-Backlogs und die
gleichzeitige Koordination und Integration mit den anderen Komponententeams nicht
mehr zu bewältigen.
Meiner Erfahrung nach erkennen die meisten Organisationen, die Komponententeams
einsetzen, dass es ein Problem gibt, sobald die Dinge auseinanderzufallen drohen (wenn
quasi der Staffelstab zu Boden fällt). Normalerweise geht das so vonstatten: Ein Manager
fragt einen der Product Owner auf der Funktionsebene: »Wie kann es sein, dass die Kun-
denfunktion noch nicht fertig ist?« Er erhält die Antwort: »Nun ja, alle Komponententeams
bis auf eins haben die Teile abgeschlossen, die wir ihnen zugewiesen haben. Aber weil das
letzte Team noch nicht fertig ist, konnte auch die Funktion nicht abgeschlossen werden.«
Daraufhin könnte der Manager sagen: »Und wieso hat das Team den ihm zugewiesenen
Teil nicht fertiggestellt?« Und die Antwort des Product Owners könnte nun lauten: »Ich
habe gefragt und man hat mir gesagt, dass sie 15 konkurrierende Änderungsanforderungen
in ihrem Komponentenbereich hatten und aus technischen Gründen der Meinung waren,
dass es sinnvoller wäre, zuerst an den Anforderungen für die anderen Produkte zu arbei-
ten. Aber sie versprechen, unseren Teil noch zu beenden – vielleicht im nächsten Sprint.«
Das ist natürlich keine Art, seine Organisation zu betreiben. Wir können uns nie sicher
sein, wann (oder gar ob) wir eine Funktion ausliefern können – weil die Verantwortung für
die Auslieferung auf zwei oder drei Komponententeams verteilt wurde, die jeweils ganz
unterschiedliche Prioritäten haben könnten. Wenn man Komponententeams auf diese
Weise einsetzt, erhöht sich die Wahrscheinlichkeit, dass eine Funktion nicht fertig wird,
um ein Vielfaches, weil es nun mehrere Stellen gibt, an denen etwas misslingen könnte
(jedes Komponententeam), und nicht nur eine (ein einziges Funktionsteam).
Gibt es eine Lösung für dieses Problem? Nun, eine sehr gute Lösung wäre die Schaffung
eines funktionsübergreifenden Funktionsteams, das alle Fertigkeiten in sich vereint, die
notwendig sind, um an mehreren Endbenutzerfunktionen zu arbeiten und sie abzuschlie-
ßen – ohne dass man Teile an Komponententeams auslagern müsste. Doch wie steht es um
den wichtigsten Grund, aus dem die meisten Organisationen Komponententeams aufstel-
len – um sicherzustellen, dass ein vertrauenswürdiges Team im Komponentenbereich
arbeitet? Würden Funktionsteams nicht zu einer chaotischen Entwicklung und Wartung
der wiederverwendbaren Komponenten mit riesigen Mengen an technischen Schulden
führen? Nicht wenn wir ordentlich aufgestellte Funktionsteams haben, die sich mit der Zeit
die Code-Eigentümerschaft teilen und ihn gemeinsam und in vertrauenswürdiger, zuver-
lässiger Weise betreuen.
Sie erleichtern sich den Übergang zu dem Modell mit mehreren Funktionsteams, die sich
die Code-Eigentümerschaft teilen, wenn Sie die Teams so organisieren, wie in Abbildung
12.3 gezeigt.
256
12.2
Funktionsteams versus Komponententeams
Product Backlog 1
Funktionsteam 1
Mit diesem Ansatz wurde das Konzept eines Funktionsteams wieder eingeführt. Es gibt
nun ein einziges Funktionsteam, das eine Endkundenfunktion aus dem Product Backlog
holen kann. Dieses Funktionsteam ist vollständig dafür verantwortlich, die Arbeit zu erledi-
gen und die entsprechende Logistik zu organisieren.
Weiterhin sind in diesem Modell vertrauenswürdige Komponententeams zu finden, die
dabei helfen, die Integrität der einzelnen Komponentenbereiche zu bewahren. Diese Kom-
ponententeams haben auch ein Product Backlog, das üblicherweise technisch orientierte
Arbeit enthält, die im Komponentenbereich erledigt werden muss (möglicherweise Arbeit
zum Abzahlen technischer Schulden).
Wie ebenfalls in Abbildung 12.3 dargestellt, kann ein Mitglied eines Komponententeams
auch einem Funktionsteam zugewiesen werden. Diese Person trägt nun die doppelte Ver-
antwortung sowohl eines »Bestäubers« als auch eines »Ernters« (Goldberg und Rubin
1995).
In der Rolle des Bestäubers »befruchten« die Mitglieder der Komponententeams die Funk-
tionsteams mit Wissen über die Komponentenbereiche, um das Konzept der gemeinsamen
Code-Eigentümerschaft innerhalb der Funktionsteams zu unterstützen. In der Rolle des
Ernters sammeln die Mitglieder der Komponententeams Änderungen, die die Funktions-
teams innerhalb der Komponentenbereiche vornehmen müssen, und diskutieren diese
dann mit ihren Kollegen in den anderen Komponententeams, die wiederum ebenfalls
Änderungen in denselben Komponentenbereichen sammeln könnten. Durch diese Diskus-
sionen können die Mitglieder der Komponententeams für eine bessere Koordination der
Änderungen im Komponentenbereich sorgen, die nötig sind, um die Anforderungen der
verschiedenen Funktionsteams zu erfüllen. Die Mitarbeiter, die die Änderungen im Kom-
ponentenbereich vornehmen, können dies außerdem in einer kohärenten, konfliktfreien
Weise erledigen und damit die konzeptuelle Integrität der Komponentenbereiche gewähr-
leisten. Und die Mitglieder der Komponententeams haben die Möglichkeit, einander über
257
Kapitel 12
Die Strukturen des Scrum-Teams
258
12.3
Koordination mehrerer Teams
Scrum of Scrums
Diese Praxis erlaubt es mehreren Teams, ihre Arbeiten zu koordinieren. Das Team, das das
SoS durchführt, besteht aus einzelnen Mitgliedern der verschiedenen Entwicklungsteams.
Jedes Entwicklungsteam legt selbst fest, welches Mitglied zum Scrum of Scrums geschickt
wird – am besten eignet sich derjenige, der etwas zu den Abhängigkeiten zwischen den
Teams sagen kann. Ich finde zwar eine gewisse Konsistenz bei der Repräsentation der
Teams ganz gut, gestehe aber zu, dass im Laufe der Zeit unterschiedliche Mitarbeiter zum
SoS geschickt werden können – je nachdem, wer am besten in der Lage ist, das Team zu
vertreten und über die gerade aktuellen Probleme berichten kann.
Manche Teams schicken sowohl ein Mitglied des Entwicklungsteams als auch ihren Scrum-
Master (der für zwei oder mehr Scrum-Teams zuständig sein könnte) zum SoS – wobei
gemeinsam darauf geachtet werden muss, dass die Gesamtanzahl der Teilnehmer nicht zu
groß wird. Es kann sogar sinnvoll sein, für das Scrum of Scrums einen eigenen ScrumMas-
ter zu haben. Falls eine solche Rolle existiert, könnte man sie einem ScrumMaster eines der
Teams übertragen oder einem ScrumMaster, der nicht direkt mit einem der Teams zusam-
menarbeitet.
Es gibt mehrere Vorgehensweisen, um ein Scrum of Scrums durchzuführen. Die Teilneh-
mer müssen selbst entscheiden, was für sie am besten funktioniert. Typisch ist immer, dass
das SoS nicht jeden Tag, sondern nur einige Male pro Woche bei Bedarf durchgeführt wird.
Die Teilnehmer beantworten hier ähnliche Fragen wie beim Daily Scrum:
쐽 Was hat mein Team seit dem letzten Treffen geleistet, das die anderen Team beeinflus-
sen könnte?
쐽 Was wird mein Team vor dem nächsten Treffen tun, das die anderen Teams beeinflus-
sen könnte?
쐽 Bei welchen Problemen meines Teams könnten die anderen Teams helfen?
259
Kapitel 12
Die Strukturen des Scrum-Teams
Manche Teams beschränken ihre Scrum of Scrums genau wie die Daily Scrums der einzel-
nen Teams auf maximal 15 Minuten. Und sie verschieben die Problemlösung auf die Zeit
nach dem SoS, damit nur diejenigen Teilnehmer anwesend sein müssen, deren Beteili-
gung unmittelbar für die Problemlösung erforderlich ist.
Alternativ kann man das Scrum of Scrums aber auch über die 15-minütige Zeitbegrenzung
hinaus ausdehnen: Obwohl die Teilnehmer jedes SoS mit einer 15-Minuten-Timebox zum
Beantworten der drei Fragen beginnen, wird das SoS nach den 15 Minuten fortgesetzt und
den Teilnehmern somit Gelegenheit geboten, Probleme zu besprechen.
Theoretisch kann das Scrum of Scrums auf mehrere Ebenen ausgeweitet werden. Nehmen
wir einmal an, es sind viele Teams an einer Produktentwicklung beteiligt. Typischerweise
würden sich diese Teams in Clustern im Funktionsbereich zusammenfinden. Innerhalb
eines solchen Team-Clusters kann ein traditionelles SoS dazu dienen, die Arbeit eines
Funktionsbereichs zu koordinieren. Sinnvollerweise hält man ein übergeordnetes SoS ab,
das sogenannte Scrum of Scrum of Scrums (oder einfacher: ein Scrum auf Programme-
bene), mit dem man die Arbeit zwischen den Clustern koordiniert. Dieser Ansatz kann
funktionieren, allerdings gibt es auch andere Techniken zum Koordinieren sehr vieler
Teams. Eine davon ist der Release-Train, zu dem wir als Nächstes kommen.
260
12.3
Koordination mehrerer Teams
쐽 Damit Teams auf ähnlichen Konstrukten aufbauen können, müssen im Vorfeld be-
stimmte Infrastrukturkomponenten – Schnittstellen, Systementwicklungs-Kits, ge-
meinsame Installations- und Lizenzierungsprogramme, UX-Frameworks, Daten- und
Webservices und dergleichen – eingerichtet werden.
Abbildung 12.5 zeigt einen teilweisen Release-Train, der auf Leffingwells Definition beruht.
Der Release-Train ist ein sehr umfassendes Konzept mit mehreren Detailstufen, darunter
Portfolio- und Release-Ebenen. Wie ich in Kapitel 6 erwähnte, basiert der Release-Train auf
einem Unternehmens-Backlog-Modell, das drei Ebenen von Backlogs enthält: das Portfolio-
Backlog (mit Epics, die dem Portfolio-Management gehören), das Programm-Backlog (mit
Funktionen, die dem Programmmanagement gehören) und die Team-Backlogs (mit sprint-
fähigen User Stories, die den Product Ownern gehören). Abbildung 12.5 zeigt nur die
Team-Ebene. Die Details der Planungen auf Portfolio- und Release-Ebene werden in Kapitel
16 bzw. Kapitel 18 diskutiert.
Der Train auf Team-Ebene aus Abbildung 12.5 zeigt insgesamt neun Teams in drei Funk-
tionsbereichen. Jedes Team innerhalb eines Funktionsbereichs führt seine eigenen Sprints
durch. Die Arbeit hierfür holt es sich aus dem dazugehörenden Backlog im Funktionsbe-
reich. Alle Teams innerhalb eines Funktionsbereichs koordinieren und integrieren ihre
Arbeit mit einer Technik wie etwa dem Scrum of Scrums.
Untersuchen und Anpassen
Release-Planung
Sprints
PSI/Release
PSI/Release
Team-
Ebene
Zeit
261
Kapitel 12
Die Strukturen des Scrum-Teams
So oft es sich praktisch einrichten lässt, sollte es eine systemweite Integration und Tests
über die Funktionsbereiche hinweg geben. Manche Teams halten sich den letzten Sprint
vor der Abfahrt des Zuges für das Hardening (»Erhärten«) dessen, was in den vorherigen
Sprints entwickelt wurde, sowie für das Integrieren und Testen der Ergebnisse über die
Funktionsbereiche hinaus frei (so könnte z.B. Sprint 4 in Abbildung 12.5 ein Hardening-
Sprint sein). Mit zunehmender Verbesserung der Fertigkeiten des Teams sollte der Bedarf
an Hardening-Sprints jedoch sinken.
Die Sprints sind für alle Teams, die am Release-Train teilnehmen, gleich lang und syn-
chron. Das bedeutet, dass sie für alle Teams zum selben Zeitpunkt beginnen und enden.
Damit ist nicht nur innerhalb eines Funktionsbereichs, sondern bei allen Teams, die am
Produkt arbeiten, eine Synchronisation möglich.
Schließlich steht nach einer festen Anzahl von Sprints ein potenziell auslieferbares Inkre-
ment (Potentially Shippable Increment; PSI) zur Verfügung. Im Fall von Abbildung 12.5
sind dies vier Sprints. Wenn die Organisation weiß, dass zuverlässig zu bestimmten Zeit-
punkten Release-Punkte eintreten, kann sie ihre anderen Aktivitäten entsprechend syn-
chronisieren. Zu den Release-Punkten kann die Organisation entweder ein PSI an ihre
Kunden ausliefern (falls das unternehmerisch sinnvoll ist) oder bestätigen, dass die Arbeit
innerhalb der einzelnen Funktionsbereiche über die Bereichsgrenzen hinaus integriert und
getestet wurde und ein internes Review einleiten.
Jeder Release-Train beginnt mit einem Release-Planungstreffen, das alle Teams umfasst,
die an dem PSI arbeiten (siehe Abbildung 12.5). Das bedeutet, dass potenziell Hunderte
Leute gleichzeitig an einem gemeinsamen Planungstreffen teilnehmen. Ich muss zuge-
ben, dass dies faszinierend anzusehen ist. Hier ein Überblick über eine Planung dieser
Größe:
Erstens brauchen Sie einen großen Raum! Der Chief Product Owner (siehe Abbildung 9.13)
leitet im Normalfall diese Aktivität. Die Mitglieder der einzelnen Scrum-Teams sitzen meist
am selben Tisch oder halten sich zumindest im gleichen Bereich auf (vorzugsweise in der
Nähe einer freien Wand, an der sie ihre Artefakte aufhängen können). Scrum-Teams, die
im selben Funktionsbereich arbeiten, bleiben zusammen. Nachdem der Chief Product
Owner einen Überblick über das PSI gegeben hat, treffen sich die Teams mit den anderen
Teams aus dem Funktionsbereich. Die Product Owner aus dem Funktionsbereich geben
dann einen Überblick über ihren Funktionsbereich für den kommenden Release-Train.
Anschließend fangen die einzelnen Scrum-Teams an, ihre Sprints zu planen, indem sie
Funktionen auf die einzelnen Sprints verteilen. Diese Aktivität wird als Sprint Mapping
bezeichnet und in Kapitel 18 noch eingehender thematisiert. Da die Scrum-Teams eigent-
lich an einem Gemeinschaftsprojekt mehrerer Teams arbeiten, gibt es Abhängigkeiten zwi-
schen den Teams. Um diese Abhängigkeiten zu organisieren, kann ein Mitglied eines
Scrum-Teams zu einem beliebigen Zeitpunkt aufstehen, zu einem anderen Scrum-Team
gehen (mit einer Karteikarte oder einem Klebezettel) und dieses Team fragen, ob es wäh-
rend des kommenden Release-Trains die Arbeit fertigstellen kann, die auf die Karte
geschrieben wurde. Falls das möglich ist, kann sich das Team, das die Anfrage stellt, zu der
abhängigen Funktion verpflichten.
Während dieser Zeit können Leute, die für mehrere Teams verantwortlich sind, wie etwa
der Chief Product Owner, die Funktionsbereich-Product-Owner und gemeinsame Architek-
ten, von Tisch zu Tisch gehen, um sicherzustellen, dass der übergreifende Plan verstanden
262
12.4
Abschließende Bemerkungen
wurde. Natürlich kann ein Scrum-Team auch jederzeit fordern, dass eine dieser Personen
kommt und weiterhilft.
Sobald die Release-Train-Sprints abgeschlossen und wir am PSI-Release-Punkt (Abfahrt des
Zuges) angekommen sind, führen wir auf Release-Train-Ebene Untersuchungen und
Anpassungen durch. Die erste entsprechende Aktivität ist ein PSI-Review der kompletten
Fracht, die auf den Release-Train geladen wurde. Die zweite ist eine Retrospektive auf
Release-Train-Ebene, die sich darauf konzentriert, wie man künftige Release-Trains noch
effizienter gestalten könnte. Und dann geht es schon mit der Release-Planung für den
nächsten Release-Train weiter.
263
Kapitel 13
Manager
Gibt es in einer Welt, in der sich die Teams selbst organisieren, noch Platz für Manager?
Auf jeden Fall. Auch wenn diese Rolle nicht unmittelbar im Scrum-Framework vorgesehen
ist, ist der Manager trotzdem ein wichtiger Bestandteil einer agilen Organisation. Immer-
hin finden sich auch eine Menge »Nicht-Scrum-Rollen« in den Organisationen, die durch-
aus für deren Betrieb entscheidend sind. (Beispiel: Der Lohnbuchhalter ist ebenfalls keine
Scrum-Rolle, allerdings habe ich auch noch kein Scrum-Teammitglied kennengelernt, das
nicht bezahlt werden wollte!)
In diesem Kapitel gehe ich zunächst auf die Aufgaben von Managern verschiedener Funk-
tionsbereiche (auch Ressourcenmanager genannt) in einer Scrum-Organisation ein – wie
beispielsweise Entwicklungs- und Qualitätssicherungsmanager, Art Directors etc. – und
erläutere anschließend die Projektmanager-Rolle innerhalb einer Scrum-Organisation.
Die Informationen in diesem Kapitel sind in erster Linie für Organisationen interessant, in
denen es Abteilungsleiter und Projektmanager gibt. Sollte Ihre Organisation vergleichs-
weise klein sein und nur wenige Manager beschäftigen, können Sie die folgenden Seiten
auf Wunsch überspringen – andererseits werden Ihnen hier aber auch einige grundle-
gende Erkenntnisse vermittelt, die Ihnen später, wenn Ihre Organisation gewachsen ist,
zweifelsohne von Nutzen sein können.
13.1 Überblick
Laut einer Branchenumfrage aus dem Jahr 2011 stellt die Furcht vor dem Verlust der
Managementkontrolle das größte Hindernis beim Übergang zu Scrum dar (siehe Abbil-
dung 13.1, aus Version-One 2011).
Abb. 13.1: Die größten Bedenken in Bezug auf die Übernahme der agilen Arbeitsweise
265
Kapitel 13
Manager
Die Angst, dass der Manager-Rolle weniger Relevanz beigemessen würde, ist jedoch unbe-
gründet: Auch in einer Scrum-Organisation nehmen die Manager weiterhin wichtige Auf-
gaben wahr (siehe Abbildung 13.2).
Insbesondere sind die Ressourcenmanager, also die Leiter bestimmter Funktionsbereiche,
in einer Scrum-Organisation dafür verantwortlich, die Teams zu koordinieren, zu fördern,
ihre Umgebung auszurichten und anzupassen sowie den Wertschöpfungsfluss zu organi-
sieren.
Grenzen definieren
Teamzusammensetzung ändern
Teams bevollmächtigen
Mitarbeiter anspornen
Kompetenz entwickeln
Teams fördern
Fachliche Anleitung bieten
Partner ausrichten
Wertschöpfungsfluss
Wirtschaftliche Aspekte organisieren
organisieren
266
13.2
Teams koordinieren
Abb. 13.3: Manager definieren die Grenzen für den Aktionsradius des Teams
267
Kapitel 13
Manager
Ressourcenmanager/
Team 1 Team 2 Team 3 Team 4 Community Leader
Community of
Practice:
Programmierer
Community of
Practice:
UI-Designer
Community of
Practice:
Tester
Community of
Practice:
DBA
In dieser Abbildung repräsentiert jede horizontale Zeile ein Sachgebiet bzw. eine Commu-
nity of Practice (CoP), das bzw. die aus Personen mit ähnlichen Spezialkenntnissen besteht
(z.B. eine Community aus Entwicklern, Oberflächendesignern, Testern oder Datenbankad-
ministratoren). Und jede Community hat einen eigenen Ressourcenmanager.
Die Ressourcenmanager sind gemeinsam dafür verantwortlich, die jeweils richtigen Leute
aus jedem Sachgebiet für die Scrum-Teams auszuwählen, die in Abbildung in den vertika-
len Reihen dargestellt sind. Im Allgemeinen sind die Manager bemüht, Teams zusammen-
268
13.2
Teams koordinieren
269
Kapitel 13
Manager
lautet hierbei, dass selbstorganisierte Teams die Möglichkeit erhalten, ihre Angelegenhei-
ten besser verwalten zu können. Das bedeutet jedoch nicht, dass die Teams alle »Manage-
mententscheidungen« treffen können (wie wir bereits festgestellt haben, sind Freds
Teamkollegen nicht bevollmächtigt, ihn aufgrund seiner schlechten Leistungen einfach
rauszuwerfen) – aber der Manager kann sie durchaus dazu ermächtigen, einige typische
Managementaktivitäten zu übernehmen.
Grundsätzlich legt der Manager für jede zu delegierende Aktivität oder spezielle Entschei-
dung jeweils auch das individuelle Maß an Autorität fest, mit dem das Team ausgestattet
wird. Appelo definiert hierzu insgesamt sieben Autoritätsstufen, die mit jeweils einem Bei-
spiel in Tabelle 13.1 zusammengefasst sind (Appelo 2011).
Diese Stufen reichen von der niedrigsten Ausprägung Mitteilen – wobei der Manager eine
Entscheidung trifft und das Team darüber informiert – bis zur höchsten Ausprägung Dele-
gieren – wobei er dem Team die volle Autorität überträgt, die Entscheidung selbst zu treffen.
Wenn Manager Aufgaben delegieren, müssen sie darauf vertrauen, dass die Teams ihre
Verantwortung wie erwartet erfüllen. Und die Teams wiederum müssen darauf vertrauen,
dass ihre Manager keine Aktionen unternehmen, die der delegierten Autorität entgegenste-
hen. So sollten Manager dem Team nicht erst die Autorität für eine Entscheidung zugeste-
hen und sie dann anschließend doch selbst treffen.
Außerdem sollten die Manager den Teammitgliedern Hilfestellung beim Aufbau gegensei-
tigen Vertrauens bieten, indem sie die Grenzen definieren, innerhalb derer das Team arbei-
tet. Auf diese Weise zeigen sie dem Team auf, wie weit das gegenseitige Vertrauen reichen
muss. Darüber hinaus müssen die Manager den Teammitgliedern ein hinreichendes Ver-
ständnis darüber vermitteln, welchen hohen Stellenwert die Einhaltung der persönlichen
Verpflichtungen in einem selbstorganisierten Team hat, da es ja keinen Teamleiter im
270
13.3
Teams fördern
eigentlichen Sinne gibt, der die Leute antreibt, ihre Arbeit zu erledigen. Und schließlich
sollten Manager auch eine Musketier-Einstellung unter den Teammitgliedern fördern,
damit sie sich darauf verlassen können, dass alle Beteiligten auch wirklich gewillt sind, die
gesteckten Ziele gemeinsam zu erreichen.
271
Kapitel 13
Manager
272
13.4
Die Umgebung ausrichten und anpassen
273
Kapitel 13
Manager
Ich war einmal beim Mittagstisch an einer Diskussion mit dem Managementteam einer
Organisation beteiligt, die gerade begonnen hatte, Scrum zu übernehmen. Während unse-
res Gesprächs merkte ich an, dass die Manager vermeiden sollten, jemanden aus einem
arbeitenden Team abzuziehen, um ihn zeitweise an einer anderen Stelle einzusetzen, weil
das eine ziemliche Störung sein könnte. Schüchtern, aber ehrlich sagte einer der Manager
im Raum: »Okay, aber ich mache das ständig und ich habe nicht gewusst, dass das schlecht
ist. Was sollte ich als Manager in einer aufstrebenden agilen Organisation denn sonst noch
beachten, um mein Verhalten und die Umgebung besser abstimmen und die Agilität för-
dern zu können?«
Als Reaktion auf die Frage begann ich, die wesentlichen agilen Werte und Prinzipien zu
erläutern (vergleichbar zu meinen Ausführungen in Kapitel 3), um den Anwesenden klar-
zumachen, wie ein Manager dabei helfen kann, die agilen Prinzipien zu stärken, anstatt
unwissentlich dagegenzuarbeiten. Natürlich können Manager die agilen Werte nur durch
ihr tägliches Verhalten tatsächlich fördern.
274
13.5
Den Wertschöpfungsfluss organisieren
275
Kapitel 13
Manager
nicht vorstellen, dass wir diese Dinge wirklich tun werden, deshalb kann [oder werde] ich
die Änderung in meinem Bereich nicht vornehmen, um unsere Arbeit besser an den
Scrum-Werten und -Prinzipien und dem Rest der agilen Organisation auszurichten.«
Solch eine lokal begrenzte Denkweise gestaltet es natürlich schwierig, irgendeine vernünf-
tige interne agile Ausrichtung zu erreichen und kann dazu führen, dass verschiedene Teile
der Organisation im wahrsten Sinne des Wortes gegen das übergeordnete, größere Wohl
des Systems arbeiten. Manager in einer Scrum-Organisation müssen gewillt sein, das
Gesamtbild zu betrachten, wenn sie die langfristigen Vorteile von Scrum ausnutzen wollen.
276
13.6
Projektmanager
ten), verlieren Sie dabei aber nicht die Variablen aus dem Blick (Termin, Umfang, Bud-
get und Qualität), die nötig sind, um wirklich aussagefähige Werte zu liefern.
쐽 Sorgen Sie für schnelle Feedbacks. Richten Sie Ihre Messungen so ein, dass Sie feststel-
len können, wie schnell der Lernzyklus abgeschlossen wird (Einschätzen, Bauen, Zu-
rückmelden, Untersuchen und Anpassen).
Die letztgenannte Messung bildet den Kern des Innovation Accountings, das in jeder
Organisation, die ein Produkt oder eine Dienstleistung unter Bedingungen extremer
Unsicherheit erbringt (Ries 2011), von Bedeutung ist. Diese Messvariante macht sich nach-
vollziehbare Metriken zunutze, um eine zuverlässige Beurteilung der Lerngeschwindigkeit
zu ermöglichen, und stellt einen wichtigen Maßstab für die Feststellung des erzielten Fort-
schritts auf dem Weg zu einem unternehmensrelevanten Ergebnis dar. Das Innovation
Accounting basiert auf drei Eckpfeilern:
1. Erstellen Sie ein Minimum Viable Product (MVP), um realistische Grundwerte für die
nachvollziehbaren Metriken zu ermitteln, anhand derer bemessen wird, wo die Organi-
sation oder das Produkt zum aktuellen Zeitpunkt steht.
2. Nehmen Sie eine Reihe von inkrementellen Verbesserungen an dem Produkt vor, um die
nachvollziehbaren Werte von den Grundwerten ausgehend auf möglichst ideale oder
gewünschte Werte zu verbessern.
3. Wenn die nachverfolgbaren Werte belegen, dass das Produkt einen merklichen Fort-
schritt auf das gewünschte Ziel zu macht, dann wird der eingeschlagene Weg durchge-
halten – ansonsten wird zu einer neuen Strategie abgewichen und der Prozess erneut
begonnen.
Ich werde die Konzepte des Abweichens und Durchhaltens in den Kapiteln 14, 16 und 17
noch ausführlicher erläutern.
13.6 Projektmanager
Bisher haben wir in diesem Kapitel hauptsächlich die Rolle des Ressourcenmanagers bzw.
Community Leaders betrachtet. Aber wie sieht es mit der Projektmanager-Rolle aus? Gibt
es eine solche Rolle in einer Scrum-Organisation überhaupt?
277
Kapitel 13
Manager
Projektmanage- Beschreibung
mentaktivität
Integration Identifizieren, Definieren, Kombinieren, Vereinheitlichen und
Koordinieren der verschiedenen Prozesse und Projektmanage-
mentaktivitäten
Umfang Definieren und Steuern dessen, was in das Projekt eingebunden
wird und was nicht, um sicherzustellen, dass das Projekt alle erfor-
derlichen Arbeiten umfasst
Zeit (Termin- Organisieren der pünktlichen Fertigstellung des Projekts durch
einhaltung) Definition dessen, was zu tun ist, wann es zu tun ist und welche
Ressourcen dafür erforderlich sind
Kosten Schätzen, Kalkulieren und Kontrollieren der Kosten, um das
genehmigte Budget einzuhalten
Qualität Definieren der Qualitätsanforderungen und/oder Standards,
Durchführen der Qualitätssicherung sowie Überwachen und Auf-
zeichnen der Ergebnisse der qualitätssichernden Maßnahmen
Team (Personal) Organisieren und Managen des Projektteams
Kommunikation Generieren, Sammeln, Verteilen, Speichern, Beschaffen und Ver-
werfen von Projektinformationen
Risiko Planen, Identifizieren, Analysieren, Überwachen und Steuern der
Projektrisiken
Beschaffung Bereitstellen von Produkten, Dienstleistungen oder Ergebnissen,
die das Projektteam von außerhalb braucht
All diese Aufgaben bleiben definitiv gleichermaßen bedeutsam und müssen bewerkstelligt
werden. Doch wer beaufsichtigt denn nun diese Aktivitäten, wenn es keinen Projektmana-
ger gibt?
Tabelle 13.3 zeigt, dass diese traditionellen Projektmanageraufgaben auf die verschiedenen
Rollen im Scrum-Team und möglicherweise auf andere Manager verteilt werden.
278
13.6
Projektmanager
Gemäß Tabelle 13.3 könnte eine Person, die bereits als Projektmanager tätig war, eine der
drei Scrum-Rollen annehmen. Welche das ist, hängt sicher von den Fähigkeiten und Wün-
schen dieser Person ab. Viele Projektmanager sind ausgezeichnete ScrumMaster, wenn sie
auf den Kontrollzwang verzichten können, der traditionellen Managern zu eigen ist.
Wie jedoch ebenfalls aus Tabelle 13.3 ersichtlich ist, übernimmt der Product Owner mindes-
tens genauso viele Projektmanagementaufgaben wie der ScrumMaster. Projektmanager
können also den Übergang in die Rolle des Product Owners wagen, wenn sie das passende
Domänenwissen und andere Fertigkeiten besitzen, um die Project-Owner-Rolle auszufüh-
ren. Ein Projektmanager mit technischen Kenntnissen könnte aber auch beschließen, Mit-
glied des Entwicklungsteams zu werden, obwohl das seltener vorkommt.
279
Kapitel 13
Manager
könnte es uns auch helfen, alle beweglichen Faktoren zu koordinieren, wenn wir einen
oder mehrere Projekt- oder Programmmanager behalten.
Bevor wir nun aber vorpreschen und nur aus dem Grund, dass wir viele Teams haben, eine
koordinationsspezifische Rolle retten, sollten wir innehalten und uns die Kommunika-
tionskanäle zwischen den Teams anschauen. Ich habe die Erfahrung gemacht, dass sie in
solchen Situationen selten komplett vernetzt sind (siehe Abbildung 13.5).
In der Regel wird es eher so sein, dass sich die Teams in Funktionsbereichen oder einem
Äquivalent dazu zu Clustern zusammenfinden, und innerhalb dieser Cluster werden die
Kommunikationskanäle dann intensiver genutzt, während sie zwischen den Clustern
lockerer verbunden sind (siehe Abbildung 13.6).
In solchen Fällen sollte die Teamkoordination für die Scrum-Teams kein Problem darstel-
len. Doch wer fühlt sich für die Koordination zwischen den Clustern zuständig? Die Stan-
dardantwort lautet: Die Teams selbst. Oft funktioniert das auch ganz prima. Die
Zusammenarbeit kann wie bei einem Scrum of Scrums erfolgen, bei dem sich ein Vertreter
280
13.6
Projektmanager
jedes Clusters mit den Vertretern der anderen Cluster trifft, um die Koordination von
Abhängigkeiten zu besprechen.
Abb. 13.6: Teams schließen sich zwecks Zusammenarbeit oft zu Clustern zusammen
281
Kapitel 13
Manager
Projektmanager
Abb. 13.7: Die Koordination wird von einem Projekt- oder Programmmanager abgewickelt
Auf die gleiche Weise kann ein Projektmanager auch bei den Entwicklungsbemühungen
behilflich sein, wenn der Einsatz von Scrum lediglich einen kleineren Teil eines viel umfas-
senderen Produkt- oder Dienstleistungsentwicklungprojekts ausmacht. So könnte es z.B.
Subunternehmer, interne Nicht-Scrum-Teams und andere interne Stationen geben, die
ebenfalls an der Auslieferung des Produkts beteiligt sind – und speziell die Logistik beim
Umgang mit Subunternehmern oder Zulieferern kann dann zeitraubend und anstrengend
sein. Bei so vielen beweglichen Faktoren hilft es, wenn man jemanden hat, der sich aus-
schließlich auf die Logistik konzentriert (siehe Abbildung 13.8).
Auch hier ist es nicht das Ziel des Projektmanagers, der Chef zu sein. Vielmehr ist er derje-
nige, der dafür sorgt, dass die Abhängigkeiten zwischen den verschiedenen Fachbereichen
verstanden und auf eine Weise kommuniziert werden, die es den Teams erlaubt, ihre
Arbeit auf die effizienteste Weise mit den anderen Teams zu koordinieren.
282
13.7
Abschließende Bemerkungen
Interne
Nicht-Scrum-
Teams
Projektmanager
Interne
Nicht-Scrum-
Teams
Subunternehmer
Subunternehmer
Interne
Nicht-Scrum-
Teams
Traditionell Scrum
Weist den Projekten Mitarbeiter zu Koordinieren gemeinschaftlich großartige
Teams
Stellt ein und entlässt Dasselbe
Tabelle 13.4: Vergleich der Verantwortungsbereiche von Ressourcenmanagern in traditionellen
und Scrum-Umgebungen
283
Kapitel 13
Manager
Traditionell Scrum
Konzentriert sich auf die Personalentwick- Dasselbe
lung
Überprüft die Leistung Immer noch beteiligt, aber die Häufigkeit
der teamrelevanten Feedbacks ist deutlich
höher
Weist den Teammitgliedern Aufgaben zu Erlaubt es den Teammitgliedern, sich selbst
(manchmal) zu organisieren und Aufgaben auszuwählen
Etabliert projektübergreifende Standards in Dasselbe
den Fachbereichen
Ermutigt fachbereichsspezifische Initiativen Dasselbe
Besitzt sehr gute Kenntnisse in dem Fachge- Dasselbe
biet und kann notfalls mit anpacken
Versteht sich auf die Berichtsweitergabe von Konzentriert sich darauf, die Teamintegrität
Team zu Team zu wahren
Räumt Hindernisse aus dem Weg Dasselbe
Konzentriert sich auf den eigenen Fachbe- Nimmt für Ausrichtung und Wertschöp-
reich fung eine ganzheitliche Perspektive ein
Organisiert die wirtschaftlichen Aspekte Dasselbe
Überwacht Messungen und Berichte Richtet Messungen und Berichte zwecks
gezielter Fokussierung auf den Wertschöp-
fungsfluss an agilen Prinzipien aus
Tabelle 13.4: Vergleich der Verantwortungsbereiche von Ressourcenmanagern in traditionellen
und Scrum-Umgebungen (Forts.)
Im ersten Teil dieses Kapitels konzentrierte ich mich auf die Rolle des Ressourcenmana-
gers und zum Schluss ging ich auch ein wenig auf die Rolle des Projektmanagers ein. Ich
zeigte auf, wie die traditionellen Aufgaben der Manager-Rolle auf die drei im Scrum-Team
üblichen Rollen aufgeteilt werden, erläuterte aber auch, dass es bei komplexen Entwicklun-
gen hilfreich sein kann, neben den drei prinzipiellen Scrum-Rollen auch weiterhin einen
oder mehrere Projektmanager zu haben.
Dieses Kapitel beschließt Teil II. Im nächsten Kapitel wende ich mich der Planung sowie
der Beschreibung der wichtigen Scrum-Planungsprinzipien zu.
284
Teil III
Planen
In diesem Teil:
쐽 Kapitel 14
Scrum-Planungsprinzipien. . . . . . . . . . . . . . . . . . . 287
쐽 Kapitel 15
Planung auf mehreren Ebenen. . . . . . . . . . . . . . . . 297
쐽 Kapitel 16
Portfolio-Planung. . . . . . . . . . . . . . . . . . . . . . . . . . . 307
쐽 Kapitel 17
Visionsfindung (Produktplanung) . . . . . . . . . . . . . 329
쐽 Kapitel 18
Release-Planung (längerfristige Planung) . . . . . . . 349
285
Kapitel 14
Scrum-Planungsprinzipien
Ein alter Mythos besagt, dass Entwicklungsprojekte unter Anwendung des Scrum-Verfah-
rens keine Planung erfordern. Demnach fangen wir also quasi einfach mit dem ersten
Sprint an und erarbeiten uns die Details so nebenbei. Das ist allerdings nicht wahr. Auch in
Scrum führen wir Planungen durch. Um genau zu sein, planen wir sogar auf unterschied-
lichen Ebenen und an vielen verschiedenen Stellen. Es mag für manche vielleicht so schei-
nen, als würde Scrum keinen großen Wert auf die Planung legen, weil ein Großteil davon
nicht im Vorfeld geschieht, sondern erst dann, wenn es nötig ist. Meiner Erfahrung nach
bringen Scrum-Teams jedoch häufig sogar mehr Zeit mit der Planung zu als bei der tradi-
tionellen Entwicklung – es fühlt sich einfach nur anders an.
Auf den folgenden Seiten werde ich einige der Scrum-Prinzipien erläutern, die ich
bereits in Kapitel 3 erwähnt habe. Dabei konzentriere ich mich darauf, wie sie sich auf
die Planung auswirken und lege damit den Grundstock für die Diskussion in Kapitel 15,
wo es um die diversen Ebenen geht, auf denen die Scrum-Planung stattfindet. In den
nachfolgenden Kapiteln werde ich dann ausführlicher auf die Portfolio-, die Produkt-,
die Release- und die Sprint-Planung eingehen.
14.1 Überblick
In Kapitel 3 habe ich bereits die wesentlichen Scrum-Prinzipien angesprochen, von denen
eine ganze Reihe richtungsweisend dafür sind, wie wir uns der Planung nähern, wenn wir
Scrum einsetzen. In diesem Kapitel werde ich die Planungsprinzipien beschreiben, die in
Abbildung 14.1 dargestellt sind.
Scrum-Planungsprinzipien Konzentrieren Sie sich mehr auf das Anpassen und Neuplanen, als auf das Befolgen eines Plans
287
Kapitel 14
Scrum-Planungsprinzipien
288
14.4
Halten Sie sich die Planungsoptionen bis zum letzten verantwortbaren Augenblick offen
irgendeiner Stelle eine Kurve zu fahren und das dann tatsächlich machen würde, könnte
ich in solchen Bäumen landen. Außerdem kann man nicht vorhersagen, ob nicht auf ein-
mal ein 15-Jähriger mit einem Snowboard angeschossen kommt, der schreit 'Pass auf,
Alter!' Du weißt nie, wann du den Kurs ändern musst oder warum.«
Nachdem er mit seiner Erklärung fertig war, dachte ich: »Wow, das klingt genau wie jedes
interessante Entwicklungsprojekt, an dem ich schon mal mitgearbeitet habe.« Man kann
nie mit Sicherheit vorhersagen, wann oder warum man seinen Kurs ändern muss. Wenn
ich bei manchen Produkten gebeten wurde, im Voraus einen ausführlichen Plan anzuferti-
gen, habe ich das getan. Ich kann mich aber an keine einzige Entwicklung erinnern, bei der
dieses Vorgehen funktioniert hätte. Nach Abschluss eines Projekts habe ich nie auf den
ursprünglichen Plan zurückschauen und feststellen können: »Das habe ich perfekt hinbe-
kommen!« In gewisser Weise ist eine übermäßige Vorausplanung genau das Gleiche, als
würde man jede Kurve planen wollen, während man oben auf dem Berg steht. Eine derart
detaillierte Planung ist reine Zeitverschwendung – und zu glauben, der Plan sei felsenfest
korrekt und darüber die Echtzeitdaten zu vernachlässigen, ist geradezu gefährlich.
Wir waren alle schon mal an einer Produktentwicklung beteiligt, bei der auf geradezu
absurde Weise im Vorfeld detaillierte Pläne ausgearbeitet wurden. Aber soll das nun hei-
ßen, dass wir überhaupt nichts im Voraus planen sollten? Nein, das wäre nachlässig und
vermessen. Auch John plant sicherlich ein bisschen voraus: Er schaut sich die wichtigsten
Eigenschaften des Geländes an, um sich damit vertraut zu machen, bevor er losfährt. Glei-
chermaßen vermessen wäre es aber auch, bis zu dem Punkt zu planen, an dem es schwie-
rig oder kostspielig würde, auf die Realität zu reagieren. Genau wie John müssen wir die
richtige Balance zwischen den im Vorfeld getroffenen Vorhersagen und den im entschei-
denden Augenblick vorzunehmenden Just-in-time-Anpassungen finden.
289
Kapitel 14
Scrum-Planungsprinzipien
und der Meinung sind, dass alles richtig ist, dann fühlen wir uns in gewisser Weise genö-
tigt, diesem Plan zu folgen, anstatt ihn zu aktualisieren und auf individuell auf veränderte
Bedingungen zu reagieren. Glauben wir dagegen, wie bei Scrum üblich, dass man Pläne
nicht 100-prozentig korrekt im Voraus aufstellen kann und dass sich Änderungen nicht
vermeiden lassen, dann haben wir auch kein Problem damit, später alle Planungen umzu-
stoßen und auf die tatsächliche Situation einzugehen.
In den 1980er Jahren war ich entweder damit beschäftigt, große Pläne auszuarbeiten oder
als Berater für Unternehmen tätig zu sein, die selbst solche großen Pläne entwickelt hatten.
Sie wissen sicher schon, von welchen Plänen hier die Rede ist – solchen, die ein riesiges
Gantt-Diagramm ergeben und dann seitenweise ausgedruckt, zusammengeklebt und an
die Wand gehängt werden (siehe Abbildung 14.2).
ID Task Name 1/12 2/12 3/12 4/12 5/12 6/12 7/12 8/12 9/12 10/12 11/12 12/12 1/13 2/13 3/13 4/13 5/13 6/13
1 Task #1
2 Task #2
3 Task #3
4 Task #4
5 Task #5
6 Task #6
7 Task #7
8 Task #8
9 Task #9
10 Task #10
11 Task #11
12 Task #12
13 Task #13
14 Task #14
15 Task #15
16 Task #16
17 Task #17
18 Task #18
19 Task #19
20 Task #20
21 Task #21
22 Task #22
23 Task #23
24 Task #24
25 Task #25
26 Task #26
27 Task #27
28 Task #28
29 Task #29
30 Task #30
31 Task #31
32 Task #32
George in 18 Monaten
Abb. 14.2: Großer, im Voraus aufgestellter Gantt-Plan
Bei mehreren solcher Entwicklungsprojekte haben wir bis zu sechs Wochen aufgewandt,
um im Voraus überaus exakte Pläne aufzustellen. Anschließend wurden diese Pläne zu den
Wegweisern für die Projekte. Fast wie im Rechtssystem, wo die Unschuldsvermutung gilt
(»unschuldig, bis das Gegenteil bewiesen wird«), wurden diese Pläne als korrekt betrachtet,
bis etwas anderes bewiesen wurde. Dabei wäre es besser, auf die alte Regel zurückzugrei-
fen, die ihren Ursprung angeblich im Schweizer Heer hat, aber vermutlich eher aus dem
SAS Survival Guide stammt (Wiseman 2010): »Wenn man sich verläuft und die Karte nicht
mit dem Gelände übereinzustimmen scheint, dann glauben Sie in allen Fällen dem
Gelände.« (Siehe Abbildung 14.3.)
290
14.5
Konzentrieren Sie sich stärker auf das Anpassen und Neuplanen als darauf, einem Plan zu genügen
Bei jedem Produkt führt unser falsches Vertrauen in die »Karte« zu dem Schluss, dass ein
erzielter Fortschritt als eine Übereinstimmung mit dem Plan gewertet werden kann und
sollte. Tritt dann eine Abweichung vom Plan auf, dann macht uns unser Drang zur Einhal-
tung des Plans blind für die Tatsache, dass die Karte selbst falsch sein könnte. Und wird der
Karte mehr Bedeutung beigemessen als dem echten Gelände, dann haben wir den Bezug
zur Realität verloren, in der wir uns zurechtfinden müssen.
Abb. 14.3: Wenn die Karte und das Gelände voneinander abweichen, dann glauben Sie dem
Gelände.
Bei Scrum sehen wir den Vorausplan zwar als hilfreich an, glauben aber, dass es ebenso
notwendig ist, das Gelände zu erkunden und uns daran anzupassen. Und das ist auch ver-
nünftig, wenn man sich bewusst macht, dass wir den Vorausplan zu einem Zeitpunkt
erstellt haben, an dem wir am wenigsten über unser Produkt wussten. Daher führen uns
Vorauspläne normalerweise auch sehr deutlich unsere frühe Ignoranz vor Augen.
In Scrum ziehen wir es vor, häufig umzuplanen, während wir unsere Annahmen überprü-
fen. Wir nutzen unsere validierten Erkenntnisse, um ständig bessere, nützlichere Pläne zu
erstellen. Es ist uns egal, dass unsere Pläne falsch sein könnten, da wir wissen, dass wir sie
sowieso bald durch genauere Pläne ersetzen. Und da wir nur kurze Sprints mit einer Dauer
291
Kapitel 14
Scrum-Planungsprinzipien
von maximal einem Monat durchführen, werden wir einem möglicherweise falschen Weg
nur kurz folgen, bevor wir den Kurs korrigieren.
Auch wenn die meisten Scrum-Teams, die ich kenne, zwar kein Gantt-Diagramm erstellen,
planen auch sie und wissen einen längerfristigen Plan durchaus zu schätzen. Wie ich in
Kapitel 15 aufzeigen werde, erarbeiten Scrum-Teams ihre Pläne auf mehreren Detailebe-
nen. Wir wollen uns unseren Plänen jedoch nicht mit Haut und Haar verschreiben, so dass
es uns am Ende schwerfällt, sie zu ändern, sobald dies nötig werden sollte.
292
14.7
Bevorzugen Sie kleinere und häufigere Releases
uns stellen müssen. Wir dürfen uns allerdings nicht vormachen, die richtige Antwort zu
kennen, nur weil wir im Nebel gestochert haben. Auf diese Planungsfragen werde in den
nächsten Kapiteln noch detaillierter eingehen.
Profit
Investition
Kosten
Release
Breakeven
Eigenfinanzierung
Zeit
Abb. 14.4: Wirtschaftliche Aspekte einer Entwicklung mit nur einem Release
Um die Vorteile kleinerer, häufigerer Releases zu verdeutlichen, stellen Sie sich vor, wir
würden zwei Releases herausbringen und nicht nur eins (siehe Abbildung 14.5). In diesem
Fall erreichen wir die Eigenfinanzierung, die Rentabilitätsgrenze und die Phase der Wirt-
schaftlichkeit bedeutend eher, was den Gesamtgewinn für das Produkt verbessert.
Die Gewinnsteigerung wird in dem in der folgenden Abbildung gezeigten Modell deutlich,
das den Annahmen aus Tabelle 14.1 folgt (nach Patton 2008).
293
Kapitel 14
Scrum-Planungsprinzipien
Profit Inkrementelles
Release (früher)
Eigenfinanzierung
Breakeven
Ein Release
Kosten
(später)
Release
Zeit
Variable Wert
Gewinn (alle Funktionen) 300.000 Dollar/Monat
Gewinn (1/2 Funktionen) 200.000 Dollar/Monat
Gewinn (1/3 Funktionen) 150.000 Dollar/Monat)
Verzögerung zwischen Auslieferung und 1 Monat
Gewinnnphase
Entwicklungskosten 100.000 Dollar/Monat
Release-Kosten 100.000 Dollar pro Release
Tabelle 14.1: Beispielannahmen für den Gewinn
Die Ergebnisse, die Sie in Tabelle 14.2 sehen, zeigen, dass wir bei einem einzigen Release
nach 12 Monaten einen Gewinn von 9,1% erzielen. Würden wir stattdessen zwei halbjährli-
che Releases herausbringen, stiege die Ertragsrate auf 15,7% an und bei vierteljährlichen
Releases sogar auf 19,5%.
294
14.8
Lernen Sie schnell dazu und weichen Sie vom Plan ab, wenn es nötig sein sollte
Dieses Vorgehen hat aber auch Grenzen: Erstens gibt es für jedes Produkt eine Mindest-
menge an vermarktbaren Funktionen. Wir können das erste Release deshalb nicht immer
noch kleiner machen, weil es dann irgendwann so klein wäre, dass es sich nicht mehr ver-
markten lässt. Und zweitens sind in einigen Märkten kleinere und häufigere Releases
keine Option. Falls Ihr Markt jedoch offen für kleinere und dafür häufigere Releases ist,
sollten Sie diesem Prinzip unbedingt folgen.
14.8 Lernen Sie schnell dazu und weichen Sie vom Plan ab,
wenn es nötig sein sollte
Keine noch so umfangreiche Vorausplanung kann Sie davor bewahren, schnell dazuzuler-
nen und notfalls vom ursprünglichen Plan abweichen zu müssen. Mit »Abweichen« meine
ich eine Richtungsänderung, die sich an Ihren neu hinzugewonnenen Erkenntnissen ori-
entiert. Ries definiert das Abweichen als »eine strukturierte Kurskorrektur, die dazu dienen
soll, eine neue, grundlegende Hypothese über das Produkt, die Strategie und den Motor
des Wachstums zu testen« (Ries 2011). Genau wie mein Freund John, der Skifahrer, müs-
sen wir darauf vorbereitet sein, schnell auszuweichen, wenn wir feststellen, dass unser
aktueller Plan nicht mehr bestandsfähig ist.
Wie ich in Kapitel 3 ausgeführt habe, ist es unser Ziel, uns schnell und ökonomisch durch
die Lernschleife zu bewegen. Deshalb sollten wir unsere Pläne so strukturieren, dass der
Wissenserwerb bzw. das Lernen eine wesentliche Zielsetzung darstellen. Anhand schneller
Feedbacks können wir feststellen, ob unsere Pläne uns in eine vertretbare Richtung führen.
Sollte das nicht der Fall sein, können wir entsprechend abweichen.
295
Kapitel 15
Bei Scrum-Projekten planen wir auf mehreren Detailebenen und zu verschiedenen Zeit-
punkten im Verlauf der gesamten Produktentwicklung. In diesem Kapitel liefere ich Ihnen
eine allgemeine und umfassende Beschreibung der verschiedenen Scrum-Planungsaktivi-
täten und deren Beziehungen zueinander. In den folgenden Kapiteln werde ich dann
genauer auf die Portfolio-, Produkt-, Release- und Sprint-Planung eingehen.
15.1 Überblick
Bei Produktentwicklungen unter Anwendung des Scrum-Verfahrens findet die Planung
auf mehreren Ebenen statt (siehe Abbildung 15.1).
Strategie
Portfolio
Produkt
Umfang
Release
Sprint
Auf der obersten Ebene befindet sich die Strategieplanung. Diese stellt zwar einen entschei-
denden Faktor für den Erfolg einer Organisation dar, wird aber im Rahmen dieses Buches
nicht eingehender behandelt, weil sie kein unmittelbarer Bestandteil des Scrum-Verfah-
297
Kapitel 15
Planung auf mehreren Ebenen
rens ist. Scrum definiert formell nur die Sprint-Planung und die tägliche Planung (über
den Daily Scrum). Allerdings profitieren die meisten Organisationen ebenso von der Port-
folio-, Produkt- und Release-Planung, weshalb ich diese Ansätze im Folgenden zunächst
zusammenfassend vorstellen und in den nächsten Kapiteln dann ausführlicher beschrei-
ben werde.
Tabelle 15.1 fasst fünf Planungsebenen mit ihren jeweils zugehörigen Zeithorizonten, den
an dem Prozess beteiligten Personen, den Schwerpunkten und den auf jeder Ebene zu
erzielenden Lieferergebnissen in einer Übersicht zusammen.
Um das Planungsvorgehen auf jeder dieser Ebenen zu verdeutlichen, werde ich das
Redesign der Website der Scrum Alliance (www.scrumalliance.org) als Beispiel verwen-
den. Der relevante Kontext für dieses Produkt lautet: 2006 hatte die Scrum Alliance, eine
nicht kommerzielle Organisation, deren Ziel die weltweite Bekanntmachung von Scrum
ist, eine furchtbare Website. Sie sah nicht gut aus, war nur schwer bedienen und enthielt
nicht gerade besonders aussagekräftige Inhalte. Als ich Ende 2006 Geschäftsführer der
Scrum Alliance wurde, gehörte eine neue, deutlich verbesserte Website zu den ersten Din-
gen, die der Vorstand forderte. Ich war der Product Owner für diese Maßnahme und
beschreibe nachfolgend einmal die Planungshierarchie, die wir durchliefen, um die neue
Website zu realisieren.
298
15.2
Portfolio-Planung
15.2 Portfolio-Planung
Die Portfolio-Planung (bzw. das Portfolio-Management) ist eine Aktivität, in deren Verlauf
festgelegt wird, an welchen Produkten, in welcher Reihenfolge und über welchen Zeitraum
gearbeitet wird. Obwohl die Portfolio-Planung konzeptuell auf einer höheren Ebene statt-
findet als die Produktplanung (weil es dabei um eine Sammlung von Produkten geht),
gehören neue, im Rahmen der Produktplanung erarbeitete Produktvisionen zu ihren wich-
tigsten Einflussfaktoren.
2006 war die Scrum Alliance noch eine relativ neue Organisation, deren Portfolio lediglich
die laufende Entwicklung ihrer vorhandenen Website enthielt. Nachdem eine erste Vorstel-
lung von der neuen Scrum-Alliance-Website erarbeitet worden war, genehmigte der Vor-
stand (die Stakeholder des Portfolio-Backlogs der Scrum Alliance) die Entwicklung einer
ersten Version der neuen Website.
299
Kapitel 15
Planung auf mehreren Ebenen
15.3.3 Produkt-Roadmap
Sobald eine Produktvision und ein allgemeines Product Backlog etabliert wurden, bietet es
sich an, eine Produkt-Roadmap (manchmal auch als Release Roadmap bezeichnet) anzule-
gen. Sie kommuniziert die inkrementelle Natur der Herstellung und Auslieferung des Pro-
dukts im Laufe der Zeit sowie die einzelnen Faktoren, die jedes einzelne Release lenken.
Heutzutage streben viele Organisationen nach einer kontinuierlichen Implementierung,
bei der sie lauffähige Funktionen in die Produktion übergeben, sobald sie zur Verfügung
stehen. Falls das auch in Ihrer Organisation der Fall ist, müssen Sie möglicherweise keine
Produkt-Roadmap erstellen. Doch selbst wenn Sie kontinuierlich ausliefern wollen, könnte
eine Produkt-Roadmap ganz nützlich sein, um über größere Funktionssammlungen,
Beschränkungen, die möglicherweise darüber entscheiden, welche Funktionen gleichzeitig
fertiggestellt werden sollten, und die Frage, wann bestimmte Funktionen verfügbar sein
müssen, nachzudenken.
Abbildung 15.2 zeigt eine Produkt-Roadmap in einem von Luke Hohmann empfohlenen
Format (Hohmann 2003).
In dieser Roadmap sind zwei Releases zu sehen, jeweils eins in den ersten beiden Quarta-
len des Jahres 2007. Das Release »0.5« im ersten Quartal 2007 war die erste Fassung der
neuen Website – diese Bezifferung lag darin begründet, dass die betreffende Version weni-
300
15.3
Produktplanung (Visionsbildung)
ger als die Hälfte der Funktionen der alten Scrum-Alliance-Website, darüber hinaus aber
auch neue Funktionen enthalten sollte, die besser als die der alten Website waren. Die
gewünschten Funktionen drehten sich alle um das Auflisten der öffentlich verfügbaren
Scrum-Kurse irgendwo auf der Welt sowie die Unterstützung für zertifizierte Scrum-Trai-
ner. Release 0.5 war ein Release mit festem Umfang – schließlich wussten wir ja, welche
speziellen Funktionen die neue Website bieten sollte, bevor wir die alte Site außer Dienst
stellen konnten. Wir wussten allerdings nicht, wie lange es dauern würde, diese Funktio-
nen startklar zu bekommen. In Kapitel 18 werde ich zeigen, wie man das Auslieferungsda-
tum für ein Release mit festem Umfang bestimmen kann.
Release 1.0 war ein Release mit festem Termin. Wir wussten, dass dieses Release mit einer
Scrum-Alliance-Konferenz (einem sogenannten Scrum Gathering) zusammenfallen sollte,
die am 7. Mai 2007 in Portland, Oregon, begann. Unser Ziel war es, gleich am ersten Tag
dieser Konferenz einen ganzen Haufen aufregender Funktionen zur Verfügung zu stellen,
wir wussten allerdings nicht, wie viele Funktionen wir in dieses Release implementiert
bekommen würden. In Kapitel 18 werde ich zeigen, wie man den Inhalt eines Release mit
festem Termin ermittelt.
In der ersten Produkt-Roadmap für die Scrum-Alliance-Website legten wir also sowohl ein
Release mit festem Umfang (0.5) als auch ein Release mit festem Termin fest (1.0).
Egal, was für ein Produkt Sie herstellen, am Ende der Planung auf Produktebene sollten Sie
eine Vision von dem Produkt, ein allgemeines Product Backlog mit geschätzten User Sto-
ries und (optional) eine Produkt-Roadmap haben. Darüber hinaus könnten Sie auch noch
andere Artefakte erstellen, um die Entscheider zu motivieren, das Produkt entwickeln zu
lassen.
Die Ergebnisse unserer Planung auf Produktebene dienten dann als Grundlage für die
Portfolio-Planung, in der die erste 0.5-Fassung der neugestalteten Website vom Vorstand
befürwortet wurde.
301
Kapitel 15
Planung auf mehreren Ebenen
15.4 Release-Planung
Bei der Release-Planung geht es darum, Kompromisse hinsichtlich Umfang, Termin und
Budget zu finden, um inkrementelle Auslieferungen realisieren zu können.
Für die meisten Entwicklungsarbeiten ist es sinnvoll und notwendig, nach der eigentlichen
Produktplanung und vor dem Beginn des ersten Sprints eine erste Release-Planung durchzu-
führen. Sie können an dieser Stelle einen ersten Release-Plan erstellen, in dem Sie den
Umfang der Entwicklung für das jeweilige Release gegen den Auslieferungstermin abwägen.
Um eine Vorstellung davon zu bekommen, was Sie zu einem festen Termin abliefern kön-
nen oder wann Sie eine festgelegte Menge an Funktionen fertig haben, müssen Sie eine
ausreichende Anzahl an Product-Backlog-Elementen anlegen und schätzen.
Ein Release lässt sich ganz einfach visualisieren, indem Sie eine Linie durch das Product
Backlog ziehen (siehe Abbildung 15.3). Alle Elemente oberhalb der Linie werden für das
Release geplant, Elemente unterhalb der Linie sind dagegen nicht für dieses Release vorge-
sehen. Entsprechend Ihren Erkenntnissen über das Produkt kann diese Linie dann im Pro-
duct Backlog nach oben oder unten verschoben werden. In Kapitel 18 werde ich zeigen, wie
man die Position einer solchen Linie festlegt.
Funktion A | 5
Funktion B | 3
Release 1 Funktion C | 2
Defekt 234 | 5
Restrukt. X | 2
Funktion D | 5
Defekt 123 | 8
Release 2 Funktion E | 2
...
Funktion Z | ?
Product Backlog
Abb. 15.3: Eine Release-Linie im Product Backlog
Nun können Sie die Produkt-Roadmap ganz leicht mit dem Product Backlog verbinden, um
eine ausführlichere Darstellung des Inhalts zumindest der Quartals-Releases zu erhalten,
die in der Produkt-Roadmap gekennzeichnet sind (siehe Abbildung 15.4). Ein Release in der
Produkt-Roadmap entspricht einer Funktionsgruppe im Product Backlog.
Im Release-Plan ist eine Zeitkomponente erkennbar, die in Form der Anzahl der für die
Fertigstellung des Releases nötigen Sprints ausgedrückt wird. Die meisten Releases sind
recht umfangreich und enthalten mehr Funktionen, als in einem Sprint gebaut werden
können (siehe Abbildung 15.5).
302
15.4
Release-Planung
Während der Release-Planung könnten Sie so weit gehen und die Funktionen schätzen, die
in den ersten Sprints geliefert werden. Das ist unter Umständen hilfreich, wenn mehrere
Teams ihre Arbeit miteinander koordinieren müssen oder wenn ein Team im Voraus
zusätzliche Hardware, Werkzeuge oder Hilfe anfordern muss. Allerdings ist es fast immer
unnötig, mehr als einige wenige Sprints im Voraus zu schätzen – und es verletzt außerdem
das Prinzip, dass die Planung immer zum passenden Zeitpunkt erfolgt und nicht unnötig
ausgeweitet wird.
Product Backlog
Release-Plan
Abb. 15.5: Ein Release kann ein oder mehrere Sprints umfassen
303
Kapitel 15
Planung auf mehreren Ebenen
15.5 Sprint-Planung
Bei der Sprint-Planung, die jeweils am Anfang eines Sprints stattfindet, einigt sich das
Scrum-Team auf die speziellen Product-Backlog-Elemente, an denen es im nächsten Sprint
arbeiten wird. Im Rahmen dieser Aktivität generiert das Team ein Sprint-Backlog: eine
Beschreibung der Arbeiten auf Aufgabenebene, die abgeschlossen werden müssen, um die
Product-Backlog-Elemente fertigzustellen (siehe Abbildung 15.6).
Sprint 1
Sprint-Backlog
PBIs Aufgaben
Während der Sprint-Planung erledigt das Team auch die nächste Ebene der detaillierten
Just-in-time-Planung. In Kapitel 19 werde ich noch weiter auf die Sprint-Planung eingehen.
304
15.7
Abschließende Bemerkungen
an der Business-Logic-Aufgabe arbeiten wird, sollte daran denken, dass sie entscheidend
dafür ist, dass wir unsere Arbeit in diesem Sprint beenden können. Er oder sie sollte des-
halb bereit sein, gleich nach dem Mittagessen daran weiterzuarbeiten.« Durch eine solche
Kommunikation kann man ganz schnell Engpässe im Arbeitsablauf erkennen und einen
besseren Workflow bei der Sprint-Durchführung gewährleisten.
Produktvision
Release-Plan Sprint-Backlog
PBIs Aufgaben
Sprint 1
In den nächsten Kapiteln werde ich näher auf die Themen Portfolio-, Produkt-, Release-
und Sprint-Planung eingehen.
305
Kapitel 16
Portfolio-Planung
Die meisten Organisationen wollen oder müssen mehr als ein Produkt zur gleichen Zeit
herstellen – und dementsprechend müssen sie wirtschaftlich sinnvoll entscheiden, wie sie
ihre Produkt-Portfolios organisieren. Darüber hinaus müssen sie ihre Portfolio-Manage-
mentprozesse aber auch an den agilen Kernpraktiken ausrichten, da sonst eine grundle-
gende Diskrepanz zum agilen Vorgehen auf den einzelnen Produktebenen entsteht. Dieses
Kapitel stellt 11 Strategien für die Portfolio-Planung vor, die nach Zeitplanung, Produktzu-
fluss und Produktabfluss gruppiert sind. Zum Schluss erläutere ich außerdem, wie man
festlegt, ob für Produkte, die bereits in Bearbeitung sind (Work in Process; WIP), mehr
Arbeit investiert werden sollte oder nicht.
16.1 Überblick
Im Rahmen der Portfolio-Planung (bzw. des Portfolio-Managements) wird festgelegt, in
welcher Reihenfolge, wie lange und vor allem auch an welchen Portfolio-Backlog-Elemen-
ten gearbeitet werden soll. Ein Portfolio-Backlog-Element kann ein Produkt, ein Produktin-
krement (ein Release eines Produkts) oder ein Projekt sein (falls die Arbeitsplanung in
Ihrer Organisation vorzugsweise in Projektform erfolgt). Ich verwende in diesem Kapitel
das Wort Produkt als übergeordnete Bezeichnung für alle Arten von Portfolio-Backlog-Ele-
menten.
Meiner Erfahrung nach schlagen sich die meisten Organisationen (ob agil oder nicht) bei
der Portfolio-Planung nicht allzu gut. Viele von ihnen haben sogar Planungsprozesse etab-
liert, die den agilen Kernprinzipien grundlegend zuwiderlaufen. In diesen Fällen werden
auf Portfolio-Ebene Entscheidungen getroffen, die einen schnellen, flexiblen Workflow
behindern. Im Folgenden werde ich ausführlich beschreiben, wie sich diese Diskrepanz
durch ein den agilen Prinzipien entsprechendes Portfolio-Management vermeiden lässt.
307
Kapitel 16
Portfolio-Planung
tige Grundlage für die Portfolio-Planung dar. Anhand der Daten aus der Produktplanung
wird bei der Portfolio-Planung entschieden, ob das Produkt finanziert wird und an welcher
Stelle man es im Portfolio-Backlog einsortiert. Die Portfolio-Planung ist jedoch nicht nur
für neue Produkte gedacht – sie findet auch regelmäßig statt, um Produkte zu bewerten,
die bereits in Bearbeitung sind (d.h. in der Entwicklung, bereits in der Produktion oder im
Verkauf).
16.1.2 Teilnehmer
Da sich die Portfolio-Planung sowohl auf neue Produkte als auch auf in Arbeit befindliche
Produkte konzentriert, sind Vertreter der internen Stakeholder, die Product Owner der ein-
zelnen Produkte und optional oft auch die leitenden Architekten und das technische Füh-
rungspersonal daran beteiligt.
Die Stakeholder müssen eine hinreichend breit gefächerte unternehmerische Perspektive
mit einbringen, um das Portfolio-Backlog richtig priorisieren und Entscheidungen
hinsichtlich der in Bearbeitung befindlichen Produkte treffen zu können. In manchen
Organisationen bilden die Stakeholder zusammen ein Genehmigungskomitee, ein Füh-
rungsgremium oder eine äquivalente Einheit, die die Portfolio-Planung überwacht.
Die Product Owner nehmen an der Portfolio-Planung teil, um ihre jeweiligen Produkte zu
vertreten und die dafür notwendigen Ressourcen einzufordern.
Zusätzlich ist häufig auch die Teilnahme der leitenden Architekten oder Cheftechniker
erforderlich, um sicherzustellen, dass wichtige technische Einschränkungen bei den Pla-
nungsentscheidungen berücksichtigt werden.
308
16.1
Überblick
Teilnehmer
Vorgaben Ergebnisse
Portfolio-Planung
Neuproduktdaten
Portfolio-Backlog
WIP-Daten
WIP-Produkte
Zeitplanung
Abflüsse organisieren
309
Kapitel 16
Portfolio-Planung
Zeitplanung
Zuflüsse Portfolio-Backlog
Abflüsse
Produkt C WIP-Limit
Sich bietende
Gelegenheiten
Produkt D
Kleinere, häufigere Komplette
Releases Teams
–
Grenznutzenrechnung
In Bearbeitung
Abb. 16.2: Portfolio-Planungsstrategien
Auf den nachfolgenden Seiten werde ich die 11 Strategien dieser vier Kategorien detailliert
vorstellen.
16.2 Zeitplanungsstrategien
Die Portfolio-Planung dient der wirtschaftlich sinnvollen Zuweisung der begrenzten Res-
sourcen einer Organisation zu den einzelnen Produkten. Es gibt viele Möglichkeiten, die
Abfolge der Produkte festzulegen, ich werde mich hier jedoch auf die folgenden drei Strate-
gien beschränken:
쐽 Optimierung der Rendite über die Lebensdauer (Lifecycle Profits)
쐽 Kalkulation der Verzögerungskosten
쐽 Schätzungen mit Genauigkeit statt Präzision
310
16.2
Zeitplanungsstrategien
Wenn alle Produkte die gleichen Verzögerungskosten haben, dann sollte man den schnells-
ten zu bewerkstelligenden Job zuerst erledigen. Sind alle Produkte gleich umfangreich
(bzw. haben dieselbe Dauer), dann sollte man zuerst an den Produkten arbeiten, die die
höchsten Verzögerungskosten verursachen. Und sollten sowohl die Verzögerungskosten
als auch die Dauer variieren (was in der Produktentwicklung der Normalfall ist), dann wird
eine wirtschaftlich optimale Anordnung über den Weighted Shortest Job First (WSJF), zu
Deutsch »gewichtet kürzester Job zuerst«, erreicht. Die Gewichtung erfolgt hierbei nach
der Formel Verzögerungskosten geteilt durch die Dauer (bzw. den Aufwand für die Imple-
mentierung).
Im nächsten Abschnitt beschreibe ich sowohl die Berechnung der Verzögerungskosten als
auch die Aufwands-/Kostenschätzung für die Produkte im Portfolio genauer.
311
Kapitel 16
Portfolio-Planung
Projekt A Projekt B
Return on Investment (ROI) 20% 15%
Verzögerungskosten (1 Monat) 5.000 Dollar 75.000 Dollar
Tabelle 16.2: Beispiel für die Berücksichtigung der Verzögerungskosten bei der Sortierung des
Portfolios
In diesem Beispiel hat Projekt A eine Rendite (ROI) von 20% und Projekt B von 15%. Wenn
wir die Zeitplanungsstrategie »Hohe Rendite zuerst« anwenden würden, dann müssten wir
Projekt A vorziehen und Projekt B erst danach ausführen. Dieser Ansatz scheint zwar ver-
nünftig zu sein, allerdings lässt er die Verzögerungskosten für die jeweiligen Produkte
außer Acht, die die Gewinnrechnungen deutlich verändern könnten. Was wäre z.B., wenn
Projekt A Verzögerungskosten von 5.000 Dollar/Monat verursachte und Projekt B im
Unterschied dazu von 75.000 Dollar/Monat (siehe Tabelle 16.2)? In diesem Fall hätte das
Aufschieben von Projekt B, um zuerst an Projekt A zu arbeiten, einen deutlich größeren
Einfluss auf die Profitabilität des Portfolios über die Lebensdauer.
Die Verzögerungskosten verdeutlichen die Tatsache, dass der Faktor Zeit die meisten Varia-
blen beeinflusst bzw. beeinflussen kann. In dem soeben gezeigten Beispiel wurden die
Renditen von Projekt A und Projekt B anhand von spezifischen, zeitabhängigen Annahmen
berechnet (z.B. wann die Entwicklung beginnt und endet, welche Ressourcen zu diesem
Zeitpunkt zur Verfügung stehen, wie viel die Ressourcen die Leute gewillt wären, im Laufe
der Zeit für das Produkt zu bezahlen, welche technischen und unternehmerischen Risiken
es gibt, wie wahrscheinlich es ist, dass diese Risiken auftreten, und was dies kosten
könnte). Verzögern oder beschleunigen Sie die Entwicklung, werden sich die Werte dieser
Variablen in den meisten Fällen ebenfalls ändern. Die Verzögerungskosten sind also nicht
der einzige Faktor, den es bei der Priorisierung der Elemente im Portfolio zu beachten gilt
– vielmehr muss auch die Zeitdimension berücksichtigt werden, weil sie alle anderen Prio-
risierungsvariablen wie Kosten, Nutzen, neu hinzugewonnene Erkenntnisse und Risiko
beeinflusst.
312
16.2
Zeitplanungsstrategien
Die häufigste Beschwerde, die ich in Bezug auf die Verzögerungskosten zu hören
bekomme, lautet, dass nicht klar wäre, wie sie zu kalkulieren seien. Im Prinzip gibt es dafür
allerdings keinen Grund, denn man kann die Verzögerungskosten normalerweise ganz
leicht berechnen kann, indem man zwei unterschiedliche Tabellenkalkulationen ausführt,
die die Profitabilität berechnen (einmal mit und einmal ohne Verzögerung).
Leffingwell bietet sogar das passende Modell zur Kalkulation der Verzögerungskosten an,
das drei Produkteigenschaften einbezieht (Leffingwell 2011):
쐽 Kundenwert – Der potenzielle Wert aus Sicht des Kunden
쐽 Zeitwert – Der Abfall des Kundenwertes im Laufe der Zeit
쐽 Risikoreduzierung/Chancennutzung – Der Wert des Produkts im Falle einer Risiko-
minderung oder unter Ausnutzung einer sich bietenden Gelegenheit
Um die Verzögerungskosten für ein Produkt zu berechnen, wird jeder dieser Eigenschaften
eine eigene Verzögerungskosten-Kennzahl auf einer Skala von 1 (am niedrigsten) bis 10
(am höchsten) zugewiesen. Die gesamten Verzögerungskosten eines Produkts ergeben
sich dann aus der Summe der drei einzelnen Verzögerungskosten-Faktoren.
Ein alternativer und oft auch effektiver Ansatz zur Findung qualifizierter Zeitplanungsent-
scheidungen besteht darin, das allgemeine Profil der Verzögerungskosten zu charakterisie-
ren (siehe Abbildung 16.3).
Kosten
Kosten
Kosten
Kosten
313
Kapitel 16
Portfolio-Planung
Profilname Beschreibung
Linear Ein Produkt mit Verzögerungskosten, die mit einer konstanten
Rate steigen.
Hohe Festkosten Ein Produkt, das einmalig hohe Kosten anhäuft, wenn nicht
sofort gehandelt wird, z.B. erhalten wir eine bedeutende Zahlung
erst nach der Auslieferung des Produkts.
Sofortige Durchführung Ein Produkt, das eine »sofortige Durchführung« erfordert, weil
wir sonst umgehend aggressiv zunehmende Verzögerungskosten
ansammeln, z.B. ein Produkt, ohne das wir einen sofortigen
Gewinneinbruch erleiden oder das unsere Rücklagen im Laufe
der Zeit immer stärker belastet.
Fester Termin Ein Produkt, das zu einem festgelegten künftigen Termin ausge-
liefert werden muss, so dass Verzögerungskosten erst dann anfal-
len, wenn der Termin eingetreten ist. Nach dem Termin schlagen
die vollen Kosten zumindest der ersten Verzögerung zu Buche.
Logarithmisch Ein Produkt, das die meisten der Verzögerungskosten bereits
sehr früh anhäuft, während sie später spürbar weniger ansteigen.
Nicht greifbar Ein Produkt (oder Teilprodukt), das über einen längeren Zeit-
raum keine »offensichtlichen« Verzögerungskosten verursacht
und ganz plötzlich sehr hohe Verzögerungskosten anhäuft. Ein
Beispiel hierfür wäre die Handhabung der technischen Schulden
in vielen Organisationen: Zunächst scheinen nur wenige oder
keine Verzögerungskosten anzufallen, obwohl keine technischen
Schulden zurückgezahlt werden. Wie ich aber in Kapitel 8
beschrieben habe, können technische Schulden einen Wende-
punkt erreichen, an dem die Kosten für die Verzögerung anderer
Arbeiten merklich und sehr hoch anwachsen.
Tabelle 16.3: Beschreibung der Verzögerungskostenprofile
In den USA müssen Organisationen aus dem Gesundheitsbereich z.B. bestimmte Codes
verwenden, um spezielle Diagnosen und klinische Prozeduren auf Anträgen, Anamnese-
bögen und in anderen elektronischen Transaktionen zu kennzeichnen. Der Standard für
diese Code war zum Zeitpunkt der Entstehung dieses Buches [in der amerikanischen Origi-
314
16.2
Zeitplanungsstrategien
315
Kapitel 16
Portfolio-Planung
Der Vorteil der T-Shirt-Größenschätzung besteht darin, dass sie schnell zu realisieren und
normalerweise auch genau genug ist sowie verwertbare Informationen auf Portfolio-Ebene
bietet.
Nur: Wie genau ist genau genug? Lassen Sie mich dazu ein kleines Beispiel anführen. Die
Technikabteilung der vorerwähnten Organisation hatte bislang stets eine nicht unerhebli-
che Menge Zeit darauf verwendet, sehr exakte Schätzungen zu erstellen. Und obwohl man
sich nicht sicher war, ob T-Shirt-Größenangaben genau genug sein würden, waren doch
alle Mitarbeiter damit einverstanden, sie einmal auszuprobieren. Bald darauf trat das Mar-
keting mit einer Projektidee an die Techniker heran, die Technikabteilung diskutierte sie
und wies ihr eine Größe zu: Medium (Mittel).
Nun konnten die Marketing-Mitarbeiter entscheiden, ob der durch die Realisierung dieses
Projekts erzielte Nutzen größer wäre als die für ein mittelgroßes Projekt anfallenden Kos-
ten (50.000 bis 125.000 Dollar). Und das war genauso hilfreich wie die viel präziser klin-
gende, aber dennoch ungenauere Schätzung von 72.381,27 Dollar, für die die Techniker
früher sehr viel Zeit aufgewendet hätten. Im Fall dieser Beispielorganisation stellte man
also fest, dass die Bereichswerte der Schätzung nach T-Shirt-Größen einerseits genau
genug waren und andererseits auch eine Verschwendung von Zeit und Potenzial verhinder-
ten, ohne dass die Erwartungen zu hoch geschraubt wurden oder ein falsches Gefühl von
Sicherheit suggeriert wurde.
16.3 Zuflussstrategien
Wie ich in Kapitel 17 ausführen werde, werden beim Entwickeln der Vision eines Produkts
die Details für dieses Produkt herausgestellt und Informationen gesammelt, die die Ent-
scheider brauchen, um sich zu einer Finanzierung zu entschließen (oder eben auch nicht).
Bei den Zuflussstrategien geht es darum, wie man den wirtschaftlichen Filter der Organisa-
tion anwendet, um eine Pro/Kontra-Entscheidung zu treffen. Außerdem dienen sie dazu,
ein ausgewogenes Verhältnis zwischen der Frequenz, mit der Produkte in das Portfolio-
Backlog aufgenommen werden, und der Frequenz, mit der sie herausgezogen werden, her-
zustellen. Sie bestimmen, wie man sich bietende Gelegenheiten ergreift und wie man Port-
folio-Flaschenhälse vermeidet, indem man kleinere, häufigere Releases verwendet.
316
16.3
Zuflussstrategien
schnelle Zustimmung für die Nutzung jeder Gelegenheit erkennen lassen, deren Wert im
Verhältnis zu den mit ihr verbundenen Kosten deutlich überwiegt – alles andere sollte
abgelehnt werden (es sei denn, es existieren irgendwelche »mildernden Umstände«).
Wenn der Wert, der sich aus der Entwicklung des Produkts ergibt, die Kosten sehr deutlich
übersteigen, dann sollte es nicht notwendig sein, länger darüber zu diskutieren – genehmi-
gen Sie es einfach und sortieren Sie es in das Portfolio-Backlog ein. Sollte sich allerdings
herausstellen, dass selbst eine geringfügige Differenz bei den Kosten oder dem Wert zu
Diskussionen führt, bevor eine Entscheidung getroffen werden kann, sollten Sie das Pro-
dukt ablehnen, da es dann ganz offensichtlich keinen so überwältigenden wirtschaftlichen
Erfolg verspricht, dass seine Entwicklung gerechtfertigt wäre – für die meisten Organisa-
tionen ergeben sich ohnehin ganz einfach zu viele unzweifelhaft wertvolle Gelegenheiten
für Produktentwicklungen, als dass es sich lohnen würde, Zeit mit dem Diskutieren frag-
würdiger Chancen zu verplempern.
Portfolio-Planung
Los
Lieber nicht
317
Kapitel 16
Portfolio-Planung
und wenig zufriedenstellenden Aufenthalt durchleiden. Vielleicht sollten Sie sich doch lie-
ber wieder in Ihr Auto setzen und zu einem anderen Restaurant fahren!
318
16.3
Zuflussstrategien
viele Produkte verarbeitet werden müssen, sondern einfach weil eine große Anzahl an Ele-
menten im Portfolio-Backlog die Zeitplanung verkompliziert, die ich weiter vorn in diesem
Kapitel erläutert habe. Das Ermitteln einer guten Anordnung ist viel einfacher, wenn man
weniger Elemente sortieren muss. Bei wenigen Portfolio-Backlog-Elementen ist im Prinzip
jede Sortierung, die eine übermäßig und offenkundig unsinnige Priorisierung vermeidet,
ausreichend.
Um eine Überbeanspruchung des Portfolio-Backlogs zu vermeiden, können wir dazu über-
gehen, häufiger Produkte in das Portfolio einzuführen, z.B. monatlich (oder vierteljährlich)
statt nur einmal im Jahr. Auf diese Weise erreichen wir eine deutliche Reduzierung des
Aufwands (und der Kosten), der nötig ist, um neue Produkte zu bewerten und in das Port-
folio einzuführen, und sorgen insgesamt für eine größere Stabilität und Vorhersagbarkeit
der Portfolio-Planung.
Wir sollten uns außerdem auf weniger umfangreiche Produkte konzentrieren (siehe die
Strategie für kleinere, häufigere Releases). Dies sollte zu einem konstanten Strom von Pro-
dukten führen, die auch tatsächlich abgeschlossen werden, was wiederum Kapazitäten frei-
setzt, um neue Produkte in einer normalen Geschwindigkeit aus dem Portfolio-Backlog zu
ziehen. Dieses häufige Entfernen von Produkten aus dem Portfolio-Backlog hilft, eine gute
Balance zwischen dem Produktzufluss und dem Produktabfluss des Portfolio-Backlogs zu
erzielen.
Wenn irgendwann die Größe des Portfolio-Backlogs zunimmt, können wir den Produkt-
strom in das Backlog begrenzen. Dazu ändern wir den wirtschaftlichen Filter so, dass nur
höherwertige Produkte genehmigt werden und den Filter passieren dürfen. Es gelangen
weniger Produkte in das Backlog und damit wird ein besserer Ausgleich zur Abflussrate
geschaffen.
319
Kapitel 16
Portfolio-Planung
planung zusammenkommen (bevor die Gesetze geändert wurden), dann hätte sie die Gele-
genheit verpasst, diese sich bietende Chance wahrzunehmen – es sei denn, sie wäre gewillt
gewesen, eine Wettplattform für einen Markt aufzuba