
Scrum kompakt für Dummies
Description
Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.
Reviews / Votes
"... Das Handbuch des erfahrenenAutors ist ein gut strukturierter, praxisnaher, kompakter Einstieg für alle, die sofort mit Scrum beginnen möchten."
(GetAbstract im Juni 2019)
More details
Other editions
Additional editions

Person
Content
Vorwort 9
Über den Autor 11
Danksagung 13
Einleitung 23
Warum Scrum? 23
Törichte Annahmen über die Leser 24
Wie dieses Buch aufgebaut ist 25
Teil I: Die Rollen 25
Teil II: Die Listen 25
Teil III: Die Meetings 25
Teil IV: Der Top-10-Teil 25
Symbole, die in diesem Buch verwendet werden 26
Teil I Die Rollen 27
Kapitel 1 Das ist Scrum und so funktioniert es 29
Scrum und agile Softwareentwicklung 29
Wie funktioniert Scrum? 30
Drei Rollen 31
Zwei Listen 33
Vier Meetings 33
Kapitel 2 Der Product Owner 35
Die Rolle des Product Owners 35
Backlog-Management 37
Stakeholder-Management 38
Inventarisieren der Stakeholder 38
Meetings mit den Stakeholdern 39
Die Arbeit mit dem Development-Team 40
Release Management 41
Vision Statement 42
Dann aber auch releasen 44
Eigenschaften eines Product Owners 44
Product Owner und Technik 46
Ein Tag im Leben eines Product Owners 47
Kapitel 3 Der Scrum Master 53
Die Rolle des Scrum Masters 53
Unterstützung für Scrum organisieren 54
Die Spielregeln durchsetzen 56
Hilfsmittel für den Scrum Master 59
Die fünf Scrum-Prinzipien 60
Das Agile Manifest 61
Hindernisse aus dem Weg räumen 63
Der Veränderungsmanager 67
Ein Tag im Leben eines Scrum Masters 68
Kapitel 4 Das Team 73
Die Rolle des Teams 73
Arbeiten in Iterationen 75
Warum schätzen? 78
Arbeit schätzen 80
Im Sprint 82
Sprint Planning I 82
Sprint Planning II 82
Die eigentliche Arbeit 84
Sprint Review 89
Sprint-Retrospektive 89
Ein Tag im Leben eines Teammitglieds 91
Teil II Die Listen 95
Kapitel 5 Das Product Backlog 97
Das Ziel des Product Backlogs 97
Priorisieren 99
User Storys 102
Schätzen 104
Product Backlog Items aufteilen 107
Beispiel für ein Product Backlog 113
Kapitel 6 Das Sprint Backlog 115
Das Ziel des Sprint Backlogs 115
Von Storys zu Aufgaben 117
Berichte und Tools 119
Kapitel 7 Definition of Done 123
Das Ziel der Definition of Done 123
Bestandteile der Definition of Done 125
Die Definition of Done erfüllen 127
Kapitel 8 Burndowns 129
Den Fortschritt im Auge behalten 129
Der Release Burndown 130
Der Sprint Burndown 132
Scrumboard 134
Teil III Die Meetings 137
Kapitel 9 Sprint Planning Meeting 139
Product Backlog Refinement 140
Die Definition of Ready 140
Sprint Planning I 142
Umfang festlegen 142
Wie viel Arbeit? 143
Ablauf des Meetings 143
Sprint Planning II 145
Product Owner anwesend 147
In Aufgaben zerlegen 147
Noch einmal schätzen? 148
Commitment 149
Kapitel 10 Der Daily Scrum 151
Arbeitsbesprechung 151
Chicken and Pigs 153
Soziale Kontrolle? 154
Der Product Owner 155
Das Scrumboard aktualisieren 155
Kapitel 11 Sprint Review 157
Die Bedeutung von Feedback 157
Das Meeting: Mehr als eine Demo 158
Die Demo 159
Das Feedback 161
Aktionen definieren 162
Kapitel 12 Sprint-Retrospektive 163
Nehmen Sie sich Zeit zur Reflexion 163
Stimmung schaffen 164
Product Owner bei der Retrospektive? 165
War da was? 166
Einsichten gewinnen 167
Aktionen 169
Die Routine durchbrechen: Retro-Formen 171
Kapitel 13 Der Sprint 175
Ziel eines Sprints 175
Die Dauer eines Sprints 176
Kapitel 14 Scrum mit mehreren Teams 179
Regel 1: Finger weg! 179
So wird skaliert 180
Phase 1 180
Phase 2 183
Phase 3 184
Teil IV Der Top-Ten-Teil 187
Kapitel 15 Zehn Gründe, mit Scrum zu arbeiten 189
Mehr Ware fürs Geld 189
Mehr Kontrolle 189
Zufriedene Nutzer 189
Bessere Qualität 190
Business-Case-Validierung 190
Besserer Anschluss beim Auftraggeber 190
Weniger Bürokratie 190
Kleine Organisationen skalieren 191
Wissen teilen 191
Mehr Spaß 191
Kapitel 16 Zehn Tipps für Ihr erstes Scrum-Projekt 193
Nehmen Sie ein Business-Projekt 193
Nehmen Sie ein kleines Projekt, ... 193
... aber nicht zu klein ... 194
... und außerdem wichtig! 194
Verkaufen Sie kein Scrum 194
Sorgen Sie für Unterstützung auf allen Ebenen der Organisation 195
Haben Sie keine Angst vor einem Misserfolg 195
Kommunizieren Sie und seien Sie transparent 195
Haben Sie Mut 195
Feiern Sie Ihre Erfolge 196
Kapitel 17 Zehn Schritte zum Start eines Scrum-Projekts 197
Sorgen Sie dafür, dass Sie einen Product Owner haben 197
Schreiben Sie ein Vision Statement 197
Legen Sie die erste Version des Product Backlogs an 197
Suchen Sie einen Scrum Master 198
Sorgen Sie für Vollmacht vom Management 198
Suchen Sie ein Team 198
Formulieren Sie eine Definition of Done 198
Organisieren Sie ein Product Backlog Refinement Meeting mit dem Team 198
Richten Sie einen Teamraum ein 199
Beginnen Sie mit dem ersten Sprint 199
Kapitel 18 Zehn Tipps zur Arbeit mit Planungspoker 201
Schätzen 201
Reihenfolge 201
Ausreißer 201
Fragezeichen 202
Exponentiell 202
Konzentration 202
Keine Annahmen 202
Fixpunkte 202
Relativ 203
Priorität 203
Stichwortverzeichnis 205
Kapitel 1
Das ist Scrum und so funktioniert es
IN DIESEM KAPITEL
- Scrum und agile Softwareentwicklung
- Drei Rollen in Scrum
- Zwei Listen und vier Meetings
Scrum ist eine Methode, sehr effektiv im Team zu arbeiten und Dinge zu erledigen, die zu komplex sind, um sie auf Autopilot abzuwickeln. Das trifft auf sehr viele unserer Projekte zu. Scrum zielt konsequent auf effektive Arbeit. Scrum ist bei der Softwareentwicklung entstanden, ist aber auch in anderen Bereichen sehr nützlich.
Scrum und agile Softwareentwicklung
Scrum wurde 1995 von Jeff Sutherland und Ken Schwaber entwickelt. Sie untersuchten, welche Prinzipien äußerst erfolgreichen Projekten zugrunde liegen. Diese Prinzipien sind letztlich die Basis für Scrum. Scrum liefert eine geringe Anzahl wirksamer Regeln, die in Situationen, in denen es keine einfache Lösung gibt, für Stabilität sorgen. Dann sind Kreativität, Engagement und Zusammenarbeit im Team nötig, um schnell zu immer besseren Lösungen zu gelangen. Also eigentlich immer.
Scrum betont die Tatsache, dass neue Erkenntnisse sich immer dann einstellen, wenn man mit der Arbeit begonnen hat, und dass ein Team so flexibel sein sollte, die besten Erkenntnisse zu seinem Vorteil zu nutzen. Scrum ist die beliebteste agile Methode. Agil ist die Philosophie, in der Flexibilität eine herausragende Rolle spielt, festgelegt im »Agilen Manifest«.
Scrum hat nur wenige Regeln, die alle auf ein paar Seiten Platz haben. (Warum dann ein ganzes Buch?) Scrum enthält zwei Listen, drei Rollen und vier Meetings. Das ist alles. Scrum ist einfach. Fast so einfach wie Schach: leicht zu erklären, schwierig zu gewinnen.
Scrum wurde bewusst klein gehalten. Dadurch ist es breit anwendbar und leicht zu memorisieren. Das Wichtigste dabei aber ist vielleicht, dass Sie immer selbst nachdenken müssen. Scrum schreibt so wenig vor, dass Sie jederzeit selbst entscheiden, wie Sie Scrum in einer bestimmten Situation anwenden. Gleichzeitig ist das wohl auch der größte Nachteil: Scrum ist nicht die Antwort auf alle Probleme, es schreibt nicht vor, was in jeder denkbaren Situation zu tun ist. Scrum ist also eigentlich keine »Methode«, die Schritt für Schritt konkrete Anweisungen gibt. Scrum ist ein Rahmen, der Ihnen hilft, schnell herauszufinden, was Sie tun müssen.
Wenn Sie die Prinzipien oder Regeln von Scrum genau einhalten, gewinnen Sie sehr schnell sehr viele Erkenntnisse, und Sie werden mit der Nase auf die Fakten gestoßen. Scrum ist der ultimative Prozess, um alle Möglichkeiten und Unmöglichkeiten sichtbar zu machen und damit das Beste aus dem Team herauszuholen. Die Scrum-Regeln schreiben vor, dass alles transparent und sichtbar gemacht wird, vom Arbeitsanfall bis zu Vereinbarungen, von Ergebnissen bis zur Zusammenarbeit, von der Planung bis zum Fortschritt.
Scrum »zwingt« Teams, die wichtigsten Dinge zuerst anzugehen, und das auf der Basis konkret sichtbarer Ziele, von denen Menschen profitieren. Scrum sorgt außerdem dafür, dass Sie über einen langen Zeitraum so weiterarbeiten können, durch einen festen Rhythmus und starke Betonung der Qualität.
Wie funktioniert Scrum?
Scrum funktioniert in Iterationen. Eine Iteration ist ein kurzer Zeitraum von wenigen Wochen, der zu einem Ergebnis (meist zu einem Produkt) führt, das tatsächlich fertig ist. Diese Iterationen heißen Sprints. Jeder Sprint liefert ein echtes Ergebnis. In Scrum-Begriffen sagen wir, das Ergebnis einer Iteration sei »a potentially shippable product increment«. Mit anderen Worten: ein Teil der Lösung, der (so klein er auch sein mag) schon gut genug ist, um geliefert und verwendet zu werden. Ja, Sie lesen richtig: an Kunden und Nutzer geliefert. An echte Menschen. Das Ergebnis ist also dokumentiert, getestet, integriert und so weiter. Es muss nichts mehr daran getan werden. Vielleicht enthält es noch nicht genug Funktionalität, um wirklich verkäuflich zu sein, aber funktionieren würde es.
Ein Sprint liefert ein echtes Ergebnis. Wenn Sie also Software entwickeln, heißt das, dass Sie produktionsreife Software liefern. Wenn Sie mit Scrum ein neues Fahrrad bauen, dann führt jeder Sprint zu einem Fahrrad oder Fahrradteil, nicht nur zu Entwürfen und Dokumentationen. Scrum zwingt Sie dazu, Dinge fertigzustellen, sodass Sie Feedback zu echten Produkten bekommen. So sieht echtes Risikomanagement aus.
Arbeiten Sie lieber in kurzen als in langen Sprints. Je kürzer der Sprint, desto eher wird ein Wert geliefert, desto schneller lernen Sie und können Feedback umsetzen. In der ursprünglichen Scrum-Literatur ist von Sprints von maximal einem Monat die Rede. Zurzeit arbeiten die meisten Teams in Sprints von zwei bis drei Wochen, aber auch eine Woche ist nicht ungewöhnlich. Kurze Sprints geben Ihnen die Möglichkeit, öfter etwas zu verändern, früher auf Feedback zu reagieren und schneller besser zu werden.
Drei Rollen
Der Product Owner ist die erste der drei Rollen in Scrum. Der Product Owner ist verantwortlich für das »Was« und vertritt alle interessierten Parteien. Was wollen wir entwickeln? Wie viel darf es kosten? Wann ist es fertig? Er legt fest, ob etwas wirklich genug Funktionalität enthält, um in Produktion zu gehen.
Um das alles richtig definieren zu können, ist es wichtig, dass der Product Owner auch das »Warum« erklären kann. Schließlich hat das »Was« allein selten einen Wert. Der Product Owner vertritt alle interessierten Parteien, die wir in Scrum Stakeholder nennen. Mit seinem Wissen um alle Stakeholder und ihre Interessen sortiert der Product Owner das Product Backlog. Das ist die vorrangige Aufgabe des Product Owners: dafür zu sorgen, dass es ein gutes Product Backlog gibt, und es nach Wert zu priorisieren.
Die eigentliche Arbeit wird vom Team ausgeführt, auch Development-Team genannt. Diese Menschen erledigen die anfallende Arbeit. Ein Development-Team, und also auch jedes Teammitglied, ist vollkommen engagiert. Das Team arbeitet zusammen, um die Ziele zu erreichen, die der Product Owner gesetzt hat, Sprint um Sprint. Das Team legt selbst fest, wie es das tut, also auch, wer was tut, und gibt selbst Schätzungen ab. Niemand sagt dem Team, wie es die gesetzten Ziele erreichen soll, also auch nicht, wie lange es für eine bestimmte Aufgabe brauchen darf. Es übernimmt Verantwortung für die eigene Arbeit. Diese Art Selbstbestimmung ist eine wichtige Motivation, die bei allen im Team Begeisterung für Scrum auslöst.
Der Scrum Master hat die Aufgabe, dafür zu sorgen, dass Scrum richtig angewendet wird. Anders ausgedrückt: Der Scrum Master achtet darauf, dass die Spielregeln eingehalten werden. Der Scrum Master ist wie das Öl in der Maschine, er sorgt dafür, dass alles so glatt wie möglich läuft. Störungen, die das Team erlebt, räumt er aus dem Weg. Außerdem erklärt der Scrum Master allen Beteiligten Scrum und die Konsequenzen seiner Anwendung - auch dem Management. Er tritt nach außen proaktiv auf und fördernd gegenüber dem Team und dem Product Owner. So kann der Scrum Master helfen, die Meetings zu organisieren, für das Team Dinge regeln oder den Product Owner bei der Formulierung der Anforderungen und Wünsche unterstützen.
Kann das Team selbst bestimmen, wie lange es dauert, bis das Produkt fertig ist? Nein, natürlich nicht. Das legt der Product Owner fest, der schließlich auch entscheidet, welche Features in welcher Reihenfolge bearbeitet werden. Wenn die Schätzungen des Teams damit nicht übereinstimmen, findet immer eine Diskussion statt, um zu sehen, ob etwas anders gemacht werden kann, und alle suchen nach einer Lösung. Nach jedem Sprint ist allerdings ein Product Increment fertig. Der Product Owner kann also nach jedem Sprint entscheiden, ob es ausgeliefert beziehungsweise releast werden soll oder nicht. Dadurch wird das Release zu einer taktischen oder strategischen Überlegung, nicht zu einer operativen. Das Produkt ist nämlich jederzeit »releaseable«.
Bei Scrum ist jeder total engagiert, nicht nur in Gedanken, sondern mit der ganzen Person, fünf Tage pro Woche. Bei Scrum arbeitet man an nur einem Projekt gleichzeitig, über ein Product Backlog, das vom Product Owner verwaltet wird. Das sorgt für viel Klarheit: Alle arbeiten gemeinsam und gleichzeitig an der Sache, die den höchsten Wert hat, und bringen sie außerdem tatsächlich zum Abschluss.
Bei Scrum arbeiten Sie mit einem festen Team, dem sogenannten Scrum-Team. Dieses Scrum-Team besteht aus dem Product Owner, dem Scrum Master und dem Development-Team. Alle zusammen arbeiten auf dasselbe Ziel hin: so schnell wie möglich das (Teil-)Produkt entwickeln, das den größten Mehrwert liefert und Menschen Freude bereitet. Es liegt auf der Hand, dass man ein solches Team, das gut zusammenarbeitet und immer besser wird, möglichst nicht trennen sollte.
Die Terminologie bei Scrum ist manchmal verwirrend. Mit dem Scrum-Team sind alle gemeint: Product Owner, Scrum Master und Development-Team. Dieses Development-Team wird oft auch verkürzt Team genannt. Wenn wir in diesem Buch irgendwo nur »Team« schreiben, meinen wir das...
System requirements
File format: ePUB
Copy protection: Adobe-DRM (Digital Rights Management)
System requirements:
- Computer (Windows; MacOS X; Linux): Install the free reader Adobe Digital Editions prior to download (see eBook Help).
- Tablet/smartphone (Android; iOS): Install the free app Adobe Digital Editions or the app PocketBook before downloading (see eBook Help).
- E-reader: Bookeen, Kobo, Pocketbook, Sony, Tolino and many more (not Kindle).
The file format ePub works well for novels and non-fiction books – i.e., „flowing” text without complex layout. On an e-reader or smartphone, line and page breaks automatically adjust to fit the small displays.
This eBook uses Adobe-DRM, a „hard” copy protection. If the necessary requirements are not met, unfortunately you will not be able to open the eBook. You will therefore need to prepare your reading hardware before downloading.
Please note: We strongly recommend that you authorise using your personal Adobe ID after installation of any reading software.
For more information, see our ebook Help page.