Scrum in der Praxis (eBook)
368 Seiten
dpunkt (Verlag)
978-3-86491-770-7 (ISBN)
Dipl.-Inform. Sven Röpstorff ist freiberuflicher Projektmanager und Agile Coach mit knapp 20 Jahren Berufserfahrung, Wandler zwischen der traditionellen und der agilen Welt mit Schwerpunkt in agilen Methoden (Scrum, Kanban). Er ist immer auf der Suche nach Verbesserungen und neuen Wegen, um Agilität einem immer größer werdenden Publikum auf interessante und spielerische Weise nahezubringen. Seiner Meinung nach kann man agile Vorgehensweisen am besten dadurch veranschaulichen, dass man sie für die Menschen sichtbar, fühlbar, erlebbar macht. Seine Erfahrungen aus vielen Jahren in unterschiedlichen Projekten teilt er als Autor, Konferenzsprecher und Blogger. Dipl.-Kaufm. Robert Wiechmann unterstützt mit Herzblut Organisationen bei ihrer agilen Transition. Neben dem Aufbau und der Beratung von Scrum- und Kanban-Teams in der Softwareentwicklung lässt er auch alle weiteren Unternehmensbereiche nicht aus dem Auge. Er hat Freude daran, Teams jeglicher Fasson zu einer Einheit zusammenzuschweißen und sich dabei ständig weiterzuentwickeln. Die Basis seiner Arbeit baut auf Respekt, Vertrauen sowie Wertschätzung auf. Wichtig ist ihm das Zusammenspiel von Zielorientierung, Klarheit, Einfachheit, Selbstverantwortung, Kreativität und Spaß. Durch seinen Mut, offen auch unbequeme Dinge anzusprechen, erfolgt die Arbeit mit ihm praxisorientiert und auf Augenhöhe. Seine Arbeit als Agile Coach ist von Kreativität geprägt und scheut auch nicht die Beschreitung neuer Wege.
Dipl.-Inform. Sven Röpstorff ist freiberuflicher Projektmanager und Agile Coach mit knapp 20 Jahren Berufserfahrung, Wandler zwischen der traditionellen und der agilen Welt mit Schwerpunkt in agilen Methoden (Scrum, Kanban). Er ist immer auf der Suche nach Verbesserungen und neuen Wegen, um Agilität einem immer größer werdenden Publikum auf interessante und spielerische Weise nahezubringen. Seiner Meinung nach kann man agile Vorgehensweisen am besten dadurch veranschaulichen, dass man sie für die Menschen sichtbar, fühlbar, erlebbar macht. Seine Erfahrungen aus vielen Jahren in unterschiedlichen Projekten teilt er als Autor, Konferenzsprecher und Blogger. Dipl.-Kaufm. Robert Wiechmann unterstützt mit Herzblut Organisationen bei ihrer agilen Transition. Neben dem Aufbau und der Beratung von Scrum- und Kanban-Teams in der Softwareentwicklung lässt er auch alle weiteren Unternehmensbereiche nicht aus dem Auge. Er hat Freude daran, Teams jeglicher Fasson zu einer Einheit zusammenzuschweißen und sich dabei ständig weiterzuentwickeln. Die Basis seiner Arbeit baut auf Respekt, Vertrauen sowie Wertschätzung auf. Wichtig ist ihm das Zusammenspiel von Zielorientierung, Klarheit, Einfachheit, Selbstverantwortung, Kreativität und Spaß. Durch seinen Mut, offen auch unbequeme Dinge anzusprechen, erfolgt die Arbeit mit ihm praxisorientiert und auf Augenhöhe. Seine Arbeit als Agile Coach ist von Kreativität geprägt und scheut auch nicht die Beschreitung neuer Wege.
Vorwort 7
Vorwort zur ersten Auflage 9
Wer dieses Buch lesen sollte 10
Wem wir zu Dank verpflichtet sind 11
Inhaltsverzeichnis 13
1 Einleitung 17
Wie das Buch aufgebaut ist 17
Wovon Sie profitieren werden 17
Wer Sie begleiten wird 18
Die SidP GmbH 19
Das Scrum-Projekt 19
Das Scrum-Team 20
2 Die Werte 21
Der falsche Ansatz 21
Der Mensch im Fokus 22
Agil sein beginnt im Kopf 23
2.1 Agile Werte 24
Spielerisch wertvoll 24
Commitment 25
Fokussierung (Focus) 26
Offenheit (Openness) 27
Respekt (Respect) 28
Mut (Courage) 28
Einfachheit (Simplicity) 29
Kommunikation 29
Feedback 30
2.2 Agile Prinzipien 31
Den Kunden zufriedenstellen 31
Änderungen willkommen heißen 32
Häufige Auslieferung 33
Crossfunktionale Zusammenarbeit 33
Unterstützung leisten und Vertrauen schenken 34
Direkte persönliche Kommunikation 35
Funktionierende Software 35
Nachhaltige Geschwindigkeit 36
Streben nach technischer Exzellenz 36
Einfach ist besser 37
Selbstorganisiert agieren 38
Überprüfen und Anpassen 38
2.2.1 Häufige Probleme 39
Fehlender Mut 39
Der Scrum Master als Einzelkämpfer 40
Agile Werte werden nicht aktiv gelebt 41
2.2.2 Checklisten 42
Agilität etablieren 42
3 Das Scrum-Team 43
Bevor es losgeht 43
Vertrauen, Wertschätzung und Verantwortung 45
Stabilität 48
Der vermeintliche Vorteil 49
Co-Location – standortgebunden agieren 51
Zusammenarbeit mit dem Projektsponsor 51
Auf ein klares Ziel hinarbeiten 52
3.1 Das Entwicklungsteam 53
3.1.1 Team-Charakteristika 54
Crossfunktionalität 54
Selbstorganisation 56
Teamplayer 57
Teamphasen 59
Teammotivation 59
Teamgröße 60
3.1.2 Häufige Probleme 61
Keine funktionierende Software 61
Teilzeitmitglieder 62
Komfortzone 63
Dein Leben in 6 Minuten und 40 Sekunden 64
Wo steht das Team? 65
3.1.3 Checklisten 65
Daran sollten Sie als Scrum Master denken 65
3.2 Der Scrum Master 66
Die goldene Regel 67
3.2.1 Unterstützung des Entwicklungsteams 69
Selbstorganisiertes und crossfunktionales Handeln 69
Entwicklung wertvoller Produkte 70
Unterschiedliche Wahrnehmungen 71
Beseitigung von Hindernissen 72
Moderation von Scrum-Events 73
Dominanz in Meetings 74
Coaching in schwierigen Projektumgebungen 74
3.2.2 Unterstützung des Product Owners 75
Kommunikation der Backlog Items, Ziele und Vision 75
Erfolgreiches Management des Product Backlog 76
Langfristige Produktplanung 76
Enge Zusammenarbeit fokussieren 76
3.2.3 Unterstützung der Organisation 77
Scrum in der Organisation etablieren 77
Zusammenarbeit mit anderen Scrum Mastern 78
3.2.4 Charaktereigenschaften 79
Servant Leadership 80
Bei sich selbst beginnen 80
Coaching des Scrum-Teams 81
Konfliktbewältigung 82
3.2.5 Häufige Probleme 83
Ein Scrum Master, zwei Teams 83
Das Beseitigen von Hindernissen dauert zu lange 84
Das Team lernt nicht 85
Unvorbereitete Meetings 86
3.2.6 Checklisten 87
Den richtigen Scrum-Coach für den Start finden 87
3.3 Der Product Owner 88
3.3.1 Hauptaufgaben 89
Erstellung von Backlog Items 90
Management des Product Backlog 90
Erstellung der Releaseplanung 91
Entwicklung der Produktvision 91
Kommunikationszentrale 92
3.3.2 Eigenschaften eines Product Owners 92
Charaktermerkmale 92
Führungsqualitäten 93
3.3.3 Häufige Probleme 94
Der Fokus fehlt 94
Das Product Backlog ist in einem schlechten Zustand 94
Der unerfahrene Product Owner 95
3.3.4 Checklisten 96
Worauf ein Scrum Master bei einem Product Owner achten sollte 96
3.4 Exkurs: Verteilte Teams 97
3.4.1 Ausgangssituation 97
Ein Sprint mit dem Mailänder-Team 98
3.4.2 Kulturelle Herausforderungen 101
3.4.3 Technische Herausforderungen 102
Chat und Videochat 102
Videokonferenzsysteme 102
Netzwerkanbindung 102
Scrum-Tools 102
Wiki 103
Gemeinsame Dateiablage 103
Screen Sharing 103
3.4.4 Organisatorische Herausforderungen 104
Räume für ungestörte Telefonate 104
Reisefreiheit 104
Unterschiedliche Zeitzonen 104
Status-Updates von Daily Scrums trennen 105
3.4.5 Häufige Probleme 105
Unterschätzung der Aufbauphase eines Teams 105
Architektur- und Designentscheidungen ohne das Entwicklungsteam 106
Verteilte Teams werden mit Teams vor Ort verglichen 106
Keine Anpassung bestehender Prozesse 107
Keine Kontakte für neue Kollegen 107
Vergessen der entfernten Kollegen 107
Nichtbeachten von Befindlichkeiten 108
Keine Rücksicht auf Fremdsprachler 108
Die frustrierte Kollegin 108
3.4.6 Checklisten 109
Arbeit mit verteilten Teams 109
4 Die Vorbereitung 111
Der Startschuss fällt 111
4.1 Kick-off-Workshop 113
Vision 113
Ziele 114
Vorbereitung 115
Inhalt 117
4.1.1 Projektspezifische Themen 117
4.1.2 Organisatorische Themen 119
4.1.3 Teamspezifische Themen 121
Umgang mit Fehlern 121
4.1.4 Teamdefinitionen 125
Definition of Ready (DoR) 126
Definition of Done (DoD) 127
Ermittlung der DoR und DoD 128
Vorbereitung 129
Durchführung 130
Nachbereitung 132
4.1.5 Umgang mit Fehlern 132
Zero Bug Policy 132
Aufräumen 133
Zukünftiger Umgang mit Fehlern 134
Fehler im Entwicklungssystem 134
Fehler im Livesystem 135
Wie kommen die Fehler ins Team? 135
Bug-Stand-up 136
4.1.6 Teamprofessionalisierung 136
4.1.7 Häufige Probleme 138
Schlechte Vorbereitung 138
Unklares Verständnis 139
Mangelnde Beachtung der eigenen Regeln 139
4.1.8 Checklisten 140
Themenkreise eines Kick-offs 140
4.2 Product Backlog 140
Das dynamische Product Backlog 140
4.2.1 Struktur des Product Backlog 141
ID 142
Beschreibung (auch: User Story) 142
Akzeptanzkriterien 143
Rangfolge 143
Schätzung 143
Epic 143
Thema (auch: Theme, Feature, Gruppe) 143
Notizen 143
4.2.2 Anforderungsworkshops 144
Produktgestaltungsworkshop 144
Big-Picture-Workshop 145
4.2.3 User Stories 146
Akzeptanzkriterien 147
4.2.4 Story Maps 149
Erstellen einer Story Map 150
4.2.5 Zerlegung von User Stories 154
Schneiden macht das Team glücklich 154
Vertikales Schneiden 154
Zerlegen nach Workflow 155
Zerlegen nach Geschäftsregel 157
Zerlegen nach Komplexität 157
Zerlegen nach Datentyp 158
Zerlegen nach Dateneingabe 159
Zerlegen nach Aufwand 159
Zerlegen nach Komfort 160
Zerlegen nach Benutzerrolle 161
Zerlegen nach Performance 161
Zerlegen nach Forschungsanteil 162
Daumenregeln für die Zerlegung von User Stories 162
4.2.6 Things-that-matter-Matrix 163
Wie war das gleich noch mal? 163
Vorbereitungen 164
Durchführung 164
4.2.7 Technische Backlog Items 166
4.2.8 Häufige Probleme 168
Das Product Backlog ist nicht öffentlich sichtbar 168
Das Product Backlog ist nicht weit genug im Voraus durchdacht 168
Die Backlog Items sind zu detailliert beschrieben 169
Das Team ist nicht in die Erstellung der User Stories eingebunden 169
User Stories sind nicht aus der Sicht des Benutzers geschrieben 170
User Stories enthalten keinen Wert für den Benutzer 170
4.2.9 Checklisten 171
Product Backlog 171
Anforderungsworkshops 171
User Stories 172
Story Maps 172
TTM-Matrix 172
4.3 Schätzungen 172
4.3.1 Estimation 174
4.3.2 Schätzeinheiten 175
Story Points 176
Personentage oder -stunden 176
T-Shirt-Größen 176
4.3.3 Schätzskalen 177
Fibonacci-Reihe 177
Lineare Skala 177
Zweierpotenzen (Powers of Two) 178
4.3.4 Initiale Schätzverfahren 179
Schock im Kick-off 179
Team Estimation Game 181
Vorbereitungen 181
Durchführung 182
Spielende 183
Vorteile 185
Nachteile 185
Magic Estimation 185
Vorbereitung 185
Durchführung 186
Erste Runde 186
Zweite Runde 186
Vorteile 188
Nachteile 188
4.3.5 Schätzvarianten 188
Relativer Vergleich 189
Aus einer Hand 189
Laser Sword Estimation 190
Ouija Board Estimation 190
Technische Hilfsmittel wie iPhone oder iPad 190
4.3.6 Checklisten 191
Estimation 191
Was Sie im Blick behalten sollten 192
4.4 Releaseplanung 193
Die Konferenz rückt näher 193
4.4.1 Releaseplan 194
4.4.2 Releaseplanung zu Projektbeginn 196
4.4.3 Release-Burndown-Chart 197
Korridor 198
Balkendiagramm 198
4.4.4 Häufige Probleme 200
Vergleich mit traditionellen Projekten 200
Fester Umfang und fester Termin 201
Releaseplan wird nur nach Story Points erstellt 201
4.4.5 Checklisten 202
Releaseplan 202
Release-Burndown-Chart 202
4.5 Letzte Vorkehrungen 202
4.5.1 Sprint Zero 203
Bitte anschnallen und die Sicherheitsgurte schließen! 203
4.5.2 Teamraum 204
Raumgröße 205
Dedizierter Arbeitsbereich 206
Große Wandflächen 206
Persönlichkeit & Kontrolle
Büroausstattung 206
Hardware 207
Internetanbindung 207
Ruhe- und Rückzugsorte 208
Lichtquellen 208
Raumklima 208
Teammonitoring 209
Spaß und Spiel 209
Home Office 209
4.5.3 Scrum-Board 210
Urlaubsvertretung 210
Struktur des Scrum-Boards 211
Zeilen und Spalten 211
Backlog Item 212
Offen (Open) 212
In Arbeit (Work in Progress, WIP) 212
Fertig (Done) 212
Physis des Scrum-Boards 213
Wand 213
Glaswand 214
Klebestreifen 214
Planungstafel 214
Magnetwand 215
Virtuell 215
Empfehlung 215
Farben und Formen 216
Backlog Items 216
Tasks aus dem Sprint Planning II 216
Später hinzugekommene Tasks 217
Fehler im Sprint 217
Blocker 217
4.5.4 Häufige Probleme 218
Überstrukturierte Scrum-Boards 218
Verwirrende Farbvielfalt oder unübersichtliche Eintönigkeit 219
Unzureichende Pflege des Scrum-Boards 219
4.5.5 Checklisten 220
Sprint Zero 220
5 Die Durchführung 223
5.1 Sprint Planning I 224
Ready, Steady, Go! 224
5.1.1 Teamverfügbarkeit 226
Fremdaufwände 226
Abwesenheitskalender 228
Sonderaufgaben 229
5.1.2 Planung ohne Story Points 229
5.1.3 Akzeptanzkriterien (How to demo) 230
5.1.4 Sprint-Ziel 231
5.1.5 Slack 233
5.1.6 Häufige Probleme 234
Prognose zu niedrig 234
Intransparente Restaufwände 234
Anteilige Story Points bei Restarbeiten 235
Nichtbeachtung der Definition of Ready 235
Technische Diskussionen 235
Viele große Backlog Items 236
Ungleichmäßige Auslastung des Teams 236
Deployment nicht geplant 237
Ungutes Bauchgefühl 237
5.1.7 Checklisten 238
Sprint Planning I 238
5.2 Sprint Planning II 239
Jetzt geht es in die Details 239
5.2.1 Tasks 240
Taskkarten 240
Größe der Tasks 241
Schätzungen von Tasks 241
Farbcode 241
Codereview 242
Nachverhandeln 242
5.2.2 Story Owner 243
5.2.3 Sprint-Burndown-Chart 244
Der Anfang vom Ende 245
Das Team hat einen Lauf 247
5.2.4 Häufige Probleme 248
Dominante Teammitglieder 248
Zu große Tasks 248
Parallele Planung 248
Fehlende Realitätsprüfung 249
5.2.5 Checklisten 249
Sprint Planning II 249
5.3 Daily Scrum 250
Herstellen der Ordnung 250
Teamsynchronisation 252
5.3.1 Die vierte Frage 252
5.3.2 Happiness-Index 253
5.3.3 Häufige Probleme 254
Verspätungen 254
Abwesenheiten 255
Unvorbereitete Teilnehmer 256
Detailtiefe 256
Überziehen 257
Inhaltslosigkeit 257
Rechtfertigung 257
Selbstdarsteller 258
Sit-in statt Stand-up 258
Suche nach Lösungen 259
Hilfestellung bei Problemen 259
Mehrere Backlog Items gleichzeitig in Arbeit 259
Verspäteter Beginn 260
Unübersichtlichkeit 261
Sprechreihenfolge 261
Lautstärke 262
5.3.4 Checklisten 262
Daily Scrum 262
5.4 Backlog Refinement 263
Durchkämmt die Wüste! 263
5.4.1 Ziele 264
5.4.2 Agenda 265
5.4.3 Varianten 266
Zweistufige Backlog Refinements 266
Vorbereitete Backlog Refinements 267
5.4.4 Häufige Probleme 267
Der Releaseplan wird nicht aktualisiert 267
Eine Agenda fehlt 268
Ein Backlog Refinement findet nicht statt 268
5.4.5 Checklisten 269
Backlog Refinement 269
5.5 Review 270
Das Grande Finale 270
Ziele eines Reviews 271
Vorstellung der Arbeitsergebnisse 271
Feedback 272
Agenda 273
5.5.1 Vorbereitung 273
Der Weckruf 274
5.5.2 Varianten 275
Interaktives Review 275
Schauspiel 276
Reviews auf Epic-Ebene 276
5.5.3 Häufige Probleme 277
Team spricht zum Product Owner 277
Product Owner ist überrascht 278
Product Owner steht nicht zu seinen Entscheidungen 278
Vorstellung von Bugs während des Reviews 278
Nicht erledigte Backlog Items im Review 279
5.5.4 Checklisten 280
Review 280
5.6 Retrospektive 281
Ziel 282
Fokus 283
Moderationsrolle 283
5.6.1 Vorbereitung 285
5.6.2 Struktur 286
Phase 1: Startphase der Retrospektive 286
Phase 2: Informationen zusammentragen 287
Phase 3: Einsichten generieren 288
Phase 4: Entscheidung herbeiführen 288
Phase 5: Abschluss der Retrospektive 288
5.6.3 Varianten 289
Der Vertrag 289
Energieimpuls-Retrospektive 291
Startphase 291
Informationen zusammentragen 293
Einsichten generieren 293
Entscheidung herbeiführen 294
Endphase der Retrospektive 295
Gesundheitstropfen-Retrospektive 296
Startphase 297
Informationen zusammentragen und Einsichten generieren 297
Entscheidung herbeiführen 299
Endphase der Retrospektive 300
Agile-Werte-Retrospektive 301
Startphase 301
Informationen zusammentragen und Einsichten generieren 302
Entscheidung herbeiführen 303
Endphase der Retrospektive 304
Liebes- und Hassbrief-Retrospektive 304
Startphase 305
Informationen zusammentragen und Einsichten generieren 306
Der Hassbrief 306
Entscheidung herbeiführen 307
Endphase der Retrospektive 307
Online-Retrospektive 307
Vorbereitung 308
Startphase 308
Informationen zusammentragen und Einsichten generieren 309
Entscheidung herbeiführen 310
Endphase der Retrospektive 310
5.6.4 Häufige Probleme 311
Retrospektiven finden nicht statt 311
Retrospektiven erzielen kein Ergebnis 311
Der unterschätzte Zeitfaktor 312
5.6.5 Checklisten 313
Was Sie bei der Vor- und Nachbereitung einer Retrospektive beachten sollten 313
Die erste Retrospektive mit einem Team 314
Retrospektiven mit verteilten Teams 314
Ideen für Retrospektiven, die Sie ausprobieren sollten 315
6 Die Veröffentlichung 319
6.1 Release-Sprint 319
Glanzpolitur 319
6.1.1 Häufige Probleme 322
Es werden nur Fehler behoben 322
Release-Sprint nicht geplant 322
6.2 Lessons Learned 323
Der Anfang vom Ende 323
Ziele 326
Gründe 327
Erkenntnisse 328
Inhalte 329
Interview der Beteiligten 329
Aufbereitung der Informationen 329
Ergebnisse 331
6.2.1 Häufige Probleme 332
Zeitdruck 332
Sündenbock 333
Nachhaltigkeit 333
A Anhang 335
A.1 Literaturverzeichnis 335
A.2 Literaturempfehlungen 339
A.2.1 Kapitel 2: Die Werte 339
Literatur- und Blogartikel-Empfehlungen (Stand: 20.07.2015) 339
Website-Empfehlungen (Stand: 20.07.2015) 340
A.2.2 Kapitel 3: Scrum-Team 340
Literatur- und Blogartikel-Empfehlungen (Stand: 20.07.2015) 340
Website-Empfehlungen (Stand: 20.07.2015) 343
A.2.3 Kapitel 4: Die Vorbereitung 343
Literatur- und Blogartikel-Empfehlungen (Stand: 20.07.2015) 343
Website-Empfehlungen (Stand: 20.07.2015) 346
A.2.4 Kapitel 5: Die Durchführung 347
Literatur- und Blogartikel-Empfehlungen (Stand: 20.07.2015) 347
Website-Empfehlungen (Stand: 20.07.2015) 349
A.2.5 Kapitel 6: Die Veröffentlichung 350
Literatur- und Blogartikel-Empfehlungen (Stand: 20.07.2015) 350
B Glossar 351
Index 365
www.dpunkt.de 0
3 Das Scrum-Team
Bevor es losgeht
Als Finn von dem neuen Projekt erfuhr, machte er von Anfang an deutlich, dass er das Scrum-Team selbst zusammenstellen wollte. Herr Hold war von diesem Anspruch etwas überrascht, da die Besetzung des Teams schon geplant war. Finn erklärte ihm, dass die richtige Zusammensetzung einen großen Einfluss auf die Effizienz des Teams hat und er daher gerne mit ganz bestimmten Personen zusammenarbeiten wollte. Zudem fände er es gut, wenn die Mitglieder seines Teams selbst entscheiden dürften, ob sie im Team arbeiten wollen. Finn wollte nur Menschen im Team, die sich freiwillig für die Mitarbeit entschieden hatten. Er hatte vor, zunächst Sergio zu fragen, den er aus einem vorherigen Projekt gut kannte. Sergio war nicht nur auf fachlicher Ebene ein wichtiges Teammitglied, sondern verfügte auch über eine sehr integrative Persönlichkeit und war bereits mit Scrum vertraut. Damit wurde er ein wichtiger Bestandteil von Finns Plan, der vorhatte, das Team um Sergio herum aufzubauen.
Für Herrn Hold klang das plausibel, und er ließ Finn gewähren, gab ihm jedoch ein Zeitfenster von wenigen Wochen. Er bat ihn, ihm einen Vorschlag für das komplette Team zu unterbreiten, und Finn machte sich sofort an die Arbeit. Nach Sergio war Jordi der nächste Kandidat auf Finns Liste. In Gesprächen mit ihm hatte Finn bemerkt, dass Jordi pfiffig war, was die Schnittstellenprogrammierung anging. Obwohl er erst vor Kurzem von der Uni gekommen war, würde er nach Finns Ansicht sehr gut in das Team passen, da er in seinem letzten Projekt noch nicht vorhandene Erfahrung durch Lernfähigkeit und Engagement kompensiert hatte. Als Lara hörte, dass Finn ein Team zusammenstellte, meldete sie sich bei ihm. Sie wollte gern das Design für die Applikation erstellen. In einem Kennenlerngespräch mit ihr fand Finn heraus, dass Lara noch einige Zeit in einem anderen Projekt arbeiten sollte, das sich mit dem Starttermin des neuen Projekts überschnitt. Nach einem Gespräch mit Casper, der als Product Owner das neue Projekt übernehmen sollte, erfuhr er, dass Lara und Casper ein eingespieltes Team sind. Nach weiteren klärenden Gesprächen hatte Finn erreicht, dass Lara für das neue Projekt zur Verfügung stand. Bei Alva war es etwas schwieriger, denn Finn wollte sie unbedingt in seinem Team haben. Dazu musste er Alva jedoch zuerst überzeugen, ihr aktuelles Arbeitsverhältnis bei einem anderen Arbeitgeber zu beenden. Da Finn aber Alva aus früheren Projekten kannte, fiel es ihm nicht schwer, sie mit den richtigen Argumenten zu überzeugen. Aufgrund von Alvas Kündigungsfrist konnte sie zwar nicht gleich zu Beginn des Projekts dabei sein, aber das nahm Finn in Kauf, da es sich nur um eine Überschneidung von zwei Wochen handelte. Als Letztes bekam Finn die Zusage von Mina, die er über eine Stellenausschreibung fand. An diese hatte er sich gleich nach dem Gespräch mit Herrn Hold gesetzt und veröffentlicht. Nachdem er einige Bewerber persönlich gesprochen hatte, entschied er sich schnell für Mina. Ihre lockere Art und ihr Know-how im Bereich der Qualitätssicherung passten perfekt in sein Bild von einem Team. Herr Hold war beeindruckt von Finns Arbeit und stimmte der Besetzung schließlich zu.
Mit dem Einsatz von agilen Methoden ändern sich die Anforderungen an die Kompetenzen von Wissensarbeitern drastisch. Agile Methoden einzusetzen bedeutet auch, einen Wandel im Rollenverständnis zu vollziehen. Daher ist es essenziell, die Rollen richtig zu besetzen, denn die Rolleninhaber sind anfänglich sowohl fachlichen, methodischen, persönlichen als auch sozialen Veränderungen unterworfen. Die Auswahl der richtigen Mitarbeiter für ein Scrum-Team nimmt daher eine Schlüsselrolle für das spätere Gelingen und den Erfolg ein.
Scrum beschreibt drei Rollen, die zu einem Scrum-Team gehören: das Entwicklungsteam (siehe Abschnitt 3.1), den Scrum Master (siehe Abschnitt 3.2) und den Product Owner (siehe Abschnitt 3.3). Das Scrum-Team bildet die Klammer über die drei Rollen. In der Innenbeziehung gibt es wesentliche Aspekte, die für ein gut funktionierendes Scrum-Team notwendig sind: Vertrauen, Wertschätzung und Verantwortung.
Praxistipp
Wir empfehlen Ihnen bei der Suche nach neuen Mitarbeitern, ein bestehendes Scrum-Team mit einzubeziehen. Zum Beispiel könnte ein sich bewerbender Entwickler einen Tag mit dem Team verbringen und mit einer oder unterschiedlichen Personen im Pair Programming zusammenarbeiten. Dies gibt jedem die Möglichkeit, die infrage kommende Person kennenzulernen und nicht nur fachlich, sondern auch menschlich einzuschätzen.
Vertrauen, Wertschätzung und Verantwortung
Agile Teams sind anders als traditionell arbeitende Teams, denn ihnen obliegt es selbst, wie sie ihren Weg zum Erfolg des Projekts gestalten. Sie bestimmen eigenverantwortlich die Umsetzung der Anforderungen des Product Owners und die inkrementelle Entwicklung der Software. Alle Teammitglieder sind gemeinschaftlich für die Ergebnisse verantwortlich. Für die Qualität ist beispielsweise nicht allein der Tester im Team verantwortlich, sondern jeder im Team, da Qualität ein impliziter Bestandteil der agilen Entwicklung und Gesamtaufgabe des Scrum-Teams ist. Qualitätsbewusstsein geht jeden im Team etwas an. Hier ist ein Scrum Master gefordert, das notwendige Handeln und Denken zu beeinflussen, indem er zum Beispiel auf die Nachteile fehlender Refactorings, Regressionstests oder automatischer Tests hinweist oder das Prinzip technischer Schulden erläutert. Die Kombination aus eigenverantwortlichem und selbstorganisiertem Handeln des gesamten Teams sowie einer kontinuierlichen Entwicklung des Teams lässt die Rollen in einem Scrum-Team verschwimmen. Die Übernahme von Verantwortung für das eigene Handeln und Vertrauen in die Arbeit jedes Einzelnen sind essenzielle Grundpfeiler eines Scrum-Teams.
Wenn es um die Übernahme von Verantwortung geht, herrschen nicht selten noch alte Denkweisen vor, die lediglich auf die ordentliche Bearbeitung eines Arbeitspakets durch Einzelne abzielen und nicht durch die gemeinschaftliche Verantwortung für das Gesamtprodukt gekennzeichnet sind. Jeder Einzelne im Entwicklungsteam muss nun als Teil einer Gemeinschaft Verantwortung übernehmen. Dies ist häufig nicht einfach und bedarf der Erkenntnis, dass es wichtig ist, Entscheidungen zu treffen und dafür einzustehen. Für diese Erkenntnis ist der Scrum Master zuständig, der sowohl den Teammitgliedern als auch der Organisation vermitteln muss, dass Fehler dazugehören und in manchen Fällen sogar erwünscht sind. Scrum regelt dies durch den »Inspect & Adapt«-Gedanken, der besagt, dass man aus Fehlern lernen kann.
Abb. 3–1 Das Team arbeitet als Gemeinschaft Hand in Hand.
Entwickler, die Schwierigkeiten mit der Übernahme von Verantwortung haben, werden sich darüber beklagen, dass etwas nicht funktioniert oder nicht in ihrem Sinne ist. Wenn Sätze fallen wie »Ich warte jetzt schon den ganzen Morgen auf Person X, die mir beim Update meiner Software helfen wollte ...« oder »Ich habe schon etliche Personen via Chat angeschrieben und keiner kann mir sagen, wo das Problem liegt ...«, aber auch »Ich wollte eigentlich mit Teammitglied Y zusammenarbeiten, aber ich weiß nicht, was er gerade tut ...«, sollten bei einem Scrum Master die Alarmglocken läuten. Diese Mitarbeiter werden nicht gleich mit einer Idee kommen und lösungsorientiert versuchen, den jeweiligen Zustand zu verbessern. Ein Scrum Master muss hier eine aktive Rolle einnehmen und die Teammitglieder bei diesem Prozess begleiten.
Praxistipp
Achten Sie bei der Auswahl der Teammitglieder darauf, dass Sie nicht die besten »Einzelspieler« auswählen, sondern die Individuen, die am besten als Team harmonieren. Teamfähigkeit ist für die Arbeit in einem Scrum-Team unabdingbar (siehe Abschnitt 3.1.3).
Da in einem Scrum-Team nicht der Einzelne im Vordergrund steht, sondern alle Teammitglieder zu gleichen Teilen für Erfolg und Misserfolg verantwortlich sind, ist der respektvolle und wertschätzende Umgang untereinander wichtig. Manchmal fehlt die Akzeptanz für das Vorgehen, wenn plötzlich gefordert wird, dass alle gleichgestellt zusammenarbeiten. Nehmen wir zum Beispiel einen JavaScript-Spezialisten, der vielleicht gerade nicht seine spezialisierten Fähigkeiten einsetzen kann und der beim explorativen Testen unterstützen soll. Es ist wichtig, dass Individuen für ein Scrum-Team ausgewählt werden, die ihr eigenes Ego im Sinne der zielgerichteten Zusammenarbeit unterordnen können. Jeder bringt unterschiedliche Erfahrungen, Titel, Fachkenntnisse o.Ä. mit ein. Genau das ist auch so gewollt, denn ansonsten wäre der- oder diejenige nicht Bestandteil des Teams – jeder leistet seinen Beitrag zum Erfolg des Scrum-Teams und bringt sein Wissen ein.
Praxistipp
Spezialwissen ist wichtig für die Qualität der Arbeit und der Ergebnisse. Entwickler in einem Scrum-Team sollten Lust darauf haben, Wissen mit anderen zu teilen und von anderen zu lernen.
Verantwortung zu übernehmen und wertschätzend sowie offen...
| Erscheint lt. Verlag | 3.12.2015 |
|---|---|
| Verlagsort | Heidelberg |
| Sprache | deutsch |
| Themenwelt | Mathematik / Informatik ► Informatik |
| Wirtschaft ► Betriebswirtschaft / Management ► Logistik / Produktion | |
| Schlagworte | Agile Softwareentwicklung • Agiles Projektmanagement • Agilität • Produktmanagement • Projektmanagement • Scrum |
| ISBN-10 | 3-86491-770-0 / 3864917700 |
| ISBN-13 | 978-3-86491-770-7 / 9783864917707 |
| Haben Sie eine Frage zum Produkt? |
EPUB (Wasserzeichen)DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich
