Hoffmann / Roock Agile Unternehmen

Veränderungsprozesse gestalten, agile Prinzipien verankern, Selbstorganisation und neue Führungsstile etablieren
1. Auflage 2018
ISBN: 978-3-96088-437-8
Verlag: dpunkt
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 214 Seiten

Agile Softwareentwicklung ist in vielen Bereichen längst zum Status quo geworden. Die agilen Prinzipien lassen sich jedoch vielfältiger anwenden, um Abteilungen, Unternehmensbereiche oder auch komplette Unternehmen agiler zu gestalten. Solche Unternehmen agieren flexibler am Markt, sind innovativer und bieten ihren Mitarbeitern sinnstiftendere Arbeitsplätze.

Das Buch beschreibt, was solche agilen Unternehmen ausmacht, und bietet konkrete Praktiken an, mit denen das eigene Unternehmen schrittweise agiler gestaltet werden kann. Dabei werden viele Fallbeispiele aus der Praxis zur Illustration herangezogen.

Autoren/Hrsg.

Hoffmann, Jürgen

Roock, Stefan

Inhaltsverzeichnis

1;Agile Unternehmen;1
2;Inhaltsübersicht;7
3;Inhaltsverzeichnis;9
4;1 Einleitung;15
4.1;1.1 Echte Agilität;16
4.1.1;Abb. 1–1 Kernidee agiler Entwicklung;16
4.1.2;Abb. 1–2 Scrum zur Unterstützung der agilen Kernidee;16
4.1.3;Abb. 1–3 Unternehmensstrukturen stören die agile Kernidee.;17
4.1.4;Abb. 1–4 Selbstorganisiertes Team;18
4.1.5;Abb. 1–5 Lieferndes Team;18
4.1.6;Abb. 1–6 Kundenwertoptimierendes Team;19
4.2;1.2 Agile Fluency;19
4.2.1;Abb. 1–7 Das Agile Fluency Model™;20
4.3;1.3 Fokus dieses Buches: echte Agilität oder auch »Optimize Value«;21
4.3.1;1.3.1 Eigenschaften von »Optimize Value«-Unternehmen;22
4.3.2;1.3.2 »Focus on Value« und »Deliver Value«: Literaturempfehlungen;23
4.4;1.4 An wen richtet sich das Buch?;24
4.5;1.5 Überblick über das Buch;24
4.6;1.6 Danksagung;25
5;2 Begeisterte Kunden;27
5.1;2.1 Definieren, was Wert bedeutet und schafft;27
5.1.1;2.1.1 Wert aus Kundensicht;27
5.1.2;2.1.2 Bedürfnisse identifizieren;30
5.2;2.2 Drei Horizonte für Wachstum und Innovation;31
5.2.1;Abb. 2–1 3-Horizonte-Modell für Wachstum;31
5.2.2;Abb. 2–2 Das Wachstum des aktuellen Geschäfts ist endlich;32
5.2.3;2.2.1 Herausforderungen bei der Umsetzung des 3-Horizonte-Modells;33
5.2.4;2.2.2 Das 3-Horizonte-Modell und agile Entwicklung;34
5.2.4.1;Größere Marktdynamik;34
5.2.4.2;Fallbeispiel: DVDs (von Jürgen Hoffmann);35
5.2.4.3;Zeithorizonte;35
5.2.5;2.2.3 Wert bedeutet in jedem Horizont etwas anderes;35
5.3;2.3 Wert in Horizont 1;36
5.3.1;2.3.1 Umsatz als Indikator für Wertschöpfung;36
5.3.2;2.3.2 Net Promoter System (NPS);36
5.3.2.1;Abb. 2–3 NPS-Frage;37
5.3.2.2;Abb. 2–4 Bedeutung der NPS-Werte;37
5.3.2.3;Abb. 2–5 Berechnung des NPS-Wertes;37
5.3.2.4;NPS und offene Fragen;38
5.3.2.5;Fallbeispiel: Offene NPS-Frage (von Stefan Roock);38
5.3.3;2.3.3 NPS: Bitte beachten;38
5.3.3.1;Fallbeispiel: NPS-Wert als Zielvorgabe (von Stefan Roock);39
5.3.3.2;Fallbeispiel: Wundersame NPS-Wert-Verbesserung (von Stefan Roock);39
5.3.4;2.3.4 Produktreview/Sprint-Review;39
5.3.4.1;Fallbeispiel: Sprint-Review mit echten Kunden (von Jürgen Hoffmann);40
5.3.4.2;Produktreview mit Feedback aus dem Livebetrieb;40
5.4;2.4 Wert in Horizont 2;41
5.4.1;2.4.1 Produktvision;41
5.4.1.1;Abb. 2–6 Product Vision Board nach R. Pichler;42
5.4.1.2;Fallbeispiel: Produktvision bringt Klarheit (von Jürgen Hoffmann);43
5.4.2;2.4.2 Produktreview/Sprint-Review;44
5.4.3;2.4.3 Design Sprints;44
5.4.3.1;Montag: Ziel des Design Sprints festlegen;44
5.4.3.2;Dienstag: Lösungsansätze skizzieren;45
5.4.3.3;Mittwoch: Auswahl und Klärung von Lösungsansätzen;45
5.4.3.4;Donnerstag: Prototyp gestalten;45
5.4.3.5;Freitag: Feedback einsammeln;45
5.4.3.6;Fallbeispiel: Design Sprints (von Jürgen Hoffmann);45
5.4.3.7;Weitere Infos zu Design Sprints;45
5.5;2.5 Wert in Horizont 3;46
5.5.1;2.5.1 Vorgehen in Horizont 3 zur Produkt-/Serviceentwicklung;47
5.5.1.1;Abb. 2–7 Zyklisches Vorgehen in Horizont 3;47
5.5.1.2;Kundenbedürfnisse verstehen;48
5.5.1.3;Produkt-/Service-Idee entwickeln;49
5.5.1.4;Produkt-/Service-Idee validieren;49
5.5.2;2.5.2 Konkrete Techniken zum Einsatz in Horizont 3;49
5.6;2.6 Organisation für das 3-Horizonte-Modell;50
5.6.1;2.6.1 Freiraum in Horizont 1;50
5.6.1.1;Abb. 2–8 Innovationsbereiche;51
5.6.1.2;Fallbeispiel: Slack-Time (von Stefan Roock);51
5.6.2;2.6.2 Freiraum in Horizont 2;52
5.6.3;2.6.3 Freiraum in Horizont 3;53
5.6.4;2.6.4 Übergang von Horizont 3 nach Horizont 2;53
5.6.4.1;Ansoff-Matrix;54
5.6.4.1.1;Abb. 2–9 Ansoff-Matrix;54
5.6.5;2.6.5 Übergang von Horizont 2 nach Horizont 1;55
5.6.6;2.6.6 Personalstrategien der Horizonte;56
5.6.6.1;Horizont 1;56
5.6.6.2;Horizont 2;56
5.6.6.3;Horizont 3;57
5.6.6.4;Personalstrategien zusammengefasst;57
5.6.7;2.6.7 Entwicklung in den drei Horizonten;58
5.6.7.1;Fallbeispiel: Pflegeversicherung (von Jürgen Hoffmann);58
5.6.8;2.6.8 Produkt-Roadmaps in den drei Horizonten;59
5.6.8.1;Produkt-Roadmap und Business-Plan;61
5.7;2.7 Das Kapitel in Stichpunkten;61
6;3 Wertschöpfung als Teamaufgabe;63
6.1;3.1 Eigenständige Teams;64
6.1.1;Abb. 3–1 Unterschiedlicher Autonomiegrad von Teams nach Hackman;65
6.1.2;3.1.1 Manager-led Teams;65
6.1.3;3.1.2 Self-managing Teams;65
6.1.4;3.1.3 Self-designing Teams;66
6.1.5;3.1.4 Self-governing Teams;67
6.1.5.1;Fallbeispiel für self-managing Teams (von Jürgen Hoffmann);68
6.1.5.2;Fallbeispiel für self-designing Teams (von Jürgen Hoffmann);68
6.1.5.3;Fallbeispiel für self-governing Teams: Wooga (von Stefan Roock);68
6.2;3.2 Funktionsübergreifende Teams;69
6.2.1;Fallbeispiel: Funktionsübergreifendes Team (von Jürgen Hoffmann);70
6.2.2;Fallbeispiel: 24translate (von Stefan Roock);70
6.2.3;3.2.1 Zusammensetzung von Teams;70
6.2.3.1;Abb. 3–2 Wertfokussierende vs. kundenwertoptimierende Teams;71
6.2.3.2;Abb. 3–3 Notwendige Fähigkeiten ins wertoptimierende Team integrieren;71
6.2.3.3;Abb. 3–4 Wissenstransfer durch Pairing;72
6.2.3.4;Persönlichkeiten im Team;72
6.2.4;3.2.2 Product-Owner-Rolle;72
6.2.5;3.2.3 Teambegleitung;73
6.2.6;3.2.4 Effizienz vs. Effektivität;73
6.3;3.3 Entscheidungen im Team;75
6.4;3.4 Das Kapitel in Stichpunkten;75
7;4 Unterstützende Organisation;77
7.1;4.1 Störungen durch das Unternehmen;78
7.1.1;Abb. 4–1 Agiler Kernzyklus;78
7.1.2;Abb. 4–2 Unternehmen stören den agilen Kernzyklus.;79
7.2;4.2 Dezentrale Strukturen;79
7.2.1;Abb. 4–3 Teambasierte Unternehmensstruktur;81
7.2.2;Abb. 4–4 Peripheriezellen bilden ein Netzwerk.;82
7.2.3;Abb. 4–5 Peripherie und Zentrum;83
7.2.4;4.2.1 Zellmodell in der Praxis der Softwareentwicklung;83
7.2.4.1;Abb. 4–6 Softwareentwicklung im Zentrum;84
7.2.4.2;Abb. 4–7 Softwareentwicklung in der Peripherie;85
7.2.5;4.2.2 Mehr als ein Team pro Zelle;86
7.2.5.1;Fallbeispiel: Eigene Skalierungsstrukur finden (von Jürgen Hoffmann);87
7.2.6;4.2.3 Alles Illusion?;87
7.2.6.1;Fallbeispiel: Struktur der Bank-IT spiegelt Fachstruktur (von Stefan Roock);87
7.2.6.1.1;Abb. 4–8 Entwicklung organisiert nach Geschäftsfeldern;88
7.2.6.2;Fallbeispiel: Wooga (von Stefan Roock);88
7.3;4.3 Alignment bei dezentralen Strukturen;89
7.3.1;Abb. 4–9 Alignment und Autonomie stehen nicht im Widerspruch zueinander.;89
7.3.2;Abb. 4–10 Autonomie und Alignment als unabhängige Dimensionen;90
7.3.3;4.3.1 Management by Objectives (MbO);90
7.3.3.1;Abb. 4–11 Ziele (Objectives) auf allen Unternehmensebenen;91
7.3.3.2;Messbarkeit von Zielen und Anreizsysteme;92
7.3.4;4.3.2 Objectives and Key Results (OKR);92
7.3.4.1;Tab. 4–1 Gemeinsamkeiten und Unterschiede zwischen MbO und OKR;93
7.3.5;4.3.3 MbO-Beispiel – so bitte nicht;93
7.3.5.1;Abb. 4–12 Beispiel für eine falsche MbO-Anwendung;94
7.3.6;4.3.4 MbO-Beispiel – besser;95
7.3.6.1;Abb. 4–13 Besseres MbO-Beispiel;95
7.3.7;4.3.5 Nutzen und Gefahren von Management by Objectives;96
7.3.7.1;Unpassende Organisationsstruktur;96
7.3.7.2;Varianzen;97
7.3.7.2.1;Abb. 4–14 Geschäftsrelevante Ziele unterliegen meist Varianzen.;98
7.3.7.3;Lokale Optimierungen;98
7.3.7.4;Hands-off-Management;99
7.3.7.5;Außerordentliche Anstrengungen;99
7.3.7.6;Zielkonflikte;99
7.3.7.7;Innovationshemmnis;99
7.3.8;4.3.6 Ziele ohne die MbO-Gefahren;100
7.4;4.4 Feedbackschleifen statt statischer Ziele;101
7.4.1;4.4.1 Feedbackschleife für den Umweltschutz;101
7.4.1.1;Abb. 4–15 Das Problem: Fabriken verschmutzen Flüsse.;102
7.4.1.2;Abb. 4–16 Lösung durch Feedbackschleife;102
7.4.1.3;Fallbeispiel: Nearshore-Bugfixing;103
7.4.1.4;Fallbeispiel: Spesen bei it-agile;103
7.4.2;4.4.2 Feedbackschleifen bei Command & Control-Strukturen;104
7.4.2.1;Abb. 4–17 Managerbasierte Feedbackschleifen;104
7.4.3;4.4.3 Feedbackschleifen in einem agilen Unternehmen;105
7.4.3.1;Abb. 4–18 Causal-Loop-Diagramm;106
7.4.3.2;Abb. 4–19 Causal-Loop-Diagramm nach Abschaffung des Bugfixing-Teams;106
7.4.4;4.4.4 Das Unternehmen als Organismus;107
7.5;4.5 Übergreifende Entscheidungsfindung bei dezentralen Strukturen;107
7.5.1;4.5.1 Konsent;107
7.5.2;4.5.2 Advice-Prozess;109
7.5.2.1;Abb. 4–20 Ablauf eines konsultativen Einzelentscheids;110
7.5.2.2;Fallbeispiel: Einführung des konsultativen Einzelentscheids bei it-agile;110
7.5.3;4.5.3 Das Unternehmen verstehen;112
7.5.4;4.5.4 Bewertung und Vergleich von Konsent und Advice-Prozess;112
7.6;4.6 Neue Rolle für Führungskräfte;113
7.6.1;4.6.1 Klassische Mitarbeiterführung;113
7.6.1.1;Abb. 4–21 Klassische Hierarchie;113
7.6.1.2;Fachliche und disziplinarische Führung;114
7.6.2;4.6.2 Probleme klassischer Führung in einer dynamischen Welt;115
7.6.2.1;Matrixorganisation;115
7.6.2.1.1;Abb. 4–22 Matrixorganisation aus Abteilungen und Projekten;115
7.6.3;4.6.3 Supporting Lines statt Reporting Lines;116
7.6.3.1;Abb. 4–23 Supporting Lines statt Reporting Lines;116
7.6.4;4.6.4 Verteilte Führung;117
7.6.5;4.6.5 Situative Führung;118
7.6.5.1;Fallbeispiel: Gehalts-Checker bei it-agile (von Stefan Roock);119
7.6.6;4.6.6 Ausbildung;119
7.6.6.1;Abb. 4–24 Falsch verstandene Agilität: Hands-off-Management;120
7.6.6.2;Abb. 4–25 Gegenseitiges Lernen;120
7.7;4.7 Fallbeispiele zu moderner Mitarbeiterführung;121
7.7.1;4.7.1 ImmobilienScout24;121
7.7.1.1;Das Unternehmen;121
7.7.1.2;Scrum-Einführung 2008;121
7.7.1.2.1;Abb. 4–26 Teamleiter bei ImmobilienScout24;122
7.7.1.3;Abgrenzung Scrum Master und Teamleiter;122
7.7.1.4;Abteilungsleiter;122
7.7.1.5;Probleme;122
7.7.1.6;Reorganisation 2015;123
7.7.1.7;Neue Rolle Delivery Lead ersetzt Scrum Master und Teamleiter;123
7.7.1.7.1;Abb. 4–27 Delivery Leads bei ImmobilienScout24;123
7.7.1.8;Heads;124
7.7.1.9;Herausforderungen der Delivery-Lead-Rolle;124
7.7.2;4.7.2 sipgate;125
7.7.2.1;Das Unternehmen;125
7.7.2.2;Teams;125
7.7.2.3;Product Owner und Scrum Master;125
7.7.2.4;Keine Linienvorgesetzten;125
7.7.2.5;Einstellung neuer Mitarbeiter;126
7.7.2.6;Gehälter;126
7.7.2.7;Entlassungen;126
7.7.2.7.1;Abb. 4–28 Führung bei sipgate ohne Linienvorgesetzte;127
7.7.2.8;Persönliche Weiterentwicklung;127
7.7.2.9;Fürsorge;127
7.7.2.10;Der lange Weg zur Freiheit;128
7.7.3;4.7.3 it-agile;128
7.7.3.1;Das Unternehmen;128
7.7.3.2;Teams;128
7.7.3.3;Fürsorge;128
7.7.3.4;Rollen statt Positionen;128
7.7.3.5;Geschäftsführung;128
7.7.3.6;Einstellungen;129
7.7.3.7;Gehaltserhöhungen;129
7.7.3.8;Weiterentwicklung der Mitarbeiter;130
7.7.3.8.1;Abb. 4–29 Mitarbeiterführung bei it-agile;130
7.7.3.9;Kündigungen;131
7.7.4;4.7.4 Zusammenfassung der Fallbeispiele für Mitarbeiterführung;131
7.8;4.8 Unternehmenskultur;132
7.8.1;Abb. 4–30 Das PARC-Modell;132
7.8.2;4.8.1 Unternehmenskultur und agiles Arbeiten;133
7.8.2.1;Abb. 4–31 Im Kern stehen die agilen Werte und Prinzipien.;133
7.8.2.2;Fallbeispiel: Zu große Transparenz (von Jürgen Hoffmann);134
7.9;4.9 Das Kapitel in Stichworten;134
8;5 Organisationsentwicklung;137
8.1;5.1 Organisationsentwicklung als komplexe Aufgabe;137
8.1.1;5.1.1 Satir Change Model;138
8.1.1.1;Abb. 5–1 Satir Change Model;138
8.2;5.2 Erfolgsfaktoren für agile Organisationsentwicklung;141
8.2.1;Abb. 5–2 Kotter Change Model;141
8.2.2;5.2.1 Erfahrungen mit dem Kotter Change Model;143
8.3;5.3 Steuerung iterativer Organisationsentwicklung;144
8.3.1;5.3.1 Das agile Transitionsteam;145
8.3.1.1;Abb. 5–3 Transitionsteam steuert die Veränderung.;145
8.3.2;5.3.2 Transition Backlog und Product Owner;145
8.3.2.1;Abb. 5–4 Transitionsteam mit Transition Backlog;146
8.3.3;5.3.3 Produktvision und Produktinkremente des Transitionsteams;147
8.3.3.1;Einschub: Dimensional-Planning-Konzept;147
8.3.3.2;Dimensional Planning für agile Transitionen;148
8.3.4;5.3.4 Transitionsteam: Besetzung und Rollen;149
8.3.5;5.3.5 Sprints im Transitionsteam;150
8.3.6;5.3.6 Einbindung ins Unternehmen;151
8.3.7;5.3.7 Weitere Probleme im Transitionsteam;151
8.3.7.1;Kapazität des Transitionsteams;151
8.3.7.2;Arbeiten im Transitionsteam;152
8.3.7.3;Loslassen;152
8.4;5.4 Organisationsentwicklung über Experimente;153
8.4.1;5.4.1 Der PDCA-Zyklus;153
8.4.1.1;Abb. 5–5 PDCA-Zyklus nach Shewhart/Deming;153
8.4.1.2;Plan;153
8.4.1.3;Do;154
8.4.1.4;Check;154
8.4.1.5;Act;154
8.4.1.6;Und: Go & See;154
8.4.2;5.4.2 PDCA in der Praxis;155
8.4.2.1;Abb. 5–6 Anpassungen und Ausbreitung mit dem PDCA-Zyklus;156
8.4.3;5.4.3 Organisationsentwicklung als Abfolge von Experimenten;156
8.4.3.1;Abb. 5–7 Organisationsveränderungen sind Experimente.;156
8.4.4;5.4.4 Safe-to-Fail-Experimente;157
8.4.5;5.4.5 Experimente erleichtern die Veränderung;157
8.4.6;5.4.6 Organisation der Organisationsentwicklung;158
8.4.6.1;Abb. 5–8 Experimenteboard bei it-agile;159
8.4.6.2;Abb. 5–9 Experimentbeschreibung;159
8.5;5.5 Kultur der kontinuierlichen Verbesserung;160
8.5.1;Fallbeispiel: Regelmäßige Retrospektiven von Teams, gelegentlich von zwei oder mehr Teams (von Jürgen Hoffmann);160
8.5.2;Fallbeispiel: Bereichs- und Teamzuschnitte stehen zur Diskussion (von Jürgen Hoffmann);161
8.5.3;5.5.1 Transparenz in alle Richtungen;161
8.5.3.1;Fallbeispiel: Kennzahlen bei WEB.DE (von Jürgen Hoffmann);161
8.5.3.2;Wertbildungsrechnung bei dm-drogerie markt;161
8.6;5.6 Orientierung mit einem Nordstern (True North);162
8.6.1;Abb. 5–10 Verbesserung mit und ohne Nordstern;163
8.6.2;5.6.1 Nordstern bei Toyota;163
8.6.3;5.6.2 Nordsterne für die Wissensarbeit;164
8.6.3.1;Scrum-Projektteams;164
8.6.3.2;Interne Projektteams;164
8.6.3.3;Verlässlicher Webshop-Produzent;164
8.6.3.4;IT Operations;164
8.6.3.5;Internetplattform;164
8.6.3.6;Koch bei Jimdo;164
8.6.4;5.6.3 Eigenschaften eines guten Nordsterns;165
8.6.5;5.6.4 Arbeiten mit dem Nordstern;166
8.6.5.1;Abb. 5–11 Orientierung bei Verbesserungen mit einem Nordstern;166
8.6.5.2;Abb. 5–12 Zwischenziele (Target Conditions);167
8.6.6;5.6.5 Nordstern und der PDCA-Zyklus;167
8.6.7;5.6.6 Die A3-Technik;168
8.6.7.1;Abb. 5–13 Mögliches A3-Template;168
8.6.7.2;Abb. 5–14 Beispielhaftes A3;169
8.6.8;5.6.7 Der Weg zum eigenen Nordstern;169
8.6.8.1;Abb. 5–15 Auf dem Weg zum eigenen Nordstern;170
8.6.8.2;Schritt 1: Klarheit über den betrachteten Geltungsbereich;170
8.6.8.3;Schritt 2: Klarheit über das eigene Produkt bzw. den eigenen Service;170
8.6.8.4;Schritt 3: Vision für die internen Prozesse und Strukturen;170
8.7;5.7 Das Kapitel in Stichworten;171
9;Anhang;173
9.1;A User Research;175
9.1.1;A.1 Design Thinking konkret;175
9.1.1.1;Abb. A–1 Design-Thinking-Elemente;176
9.1.1.2;Abb. A–2 Design Thinking als Tanzschritte;177
9.1.1.3;A.1.1 Team;177
9.1.1.4;A.1.2 Raum;178
9.1.1.5;A.1.3 Prozess;179
9.1.2;A.2 Design Sprints;180
9.1.2.1;Team;181
9.1.2.2;Zeit und Raum;182
9.1.2.3;Vorlauf;182
9.1.2.4;Montag;182
9.1.2.5;Dienstag;183
9.1.2.6;Mittwoch;185
9.1.2.7;Donnerstag;186
9.1.2.8;Freitag;187
9.1.2.9;Ergebnis;188
9.1.3;A.3 Lean Startup;188
9.1.3.1;A.3.1 Die Historie und das Umfeld;189
9.1.3.2;A.3.2 Kundenbedürfnisse verstehen und Lösung validieren;189
9.1.3.2.1;Abb. A–3 Build-Measure-Learn-Zyklus;190
9.1.3.3;A.3.3 Den Markt validieren;190
9.1.3.4;A.3.4 Minimum Viable Product (MVP);191
9.1.3.4.1;Abb. A–4 MVPs (Minimum Viable Products);192
9.1.3.5;A.3.5 Pivots;193
9.1.3.5.1;Abb. A–5 Pivots betreffen die Strategie.;193
9.1.3.6;A.3.6 Skalierung;194
9.1.3.6.1;Abb. A–6 Lean-Startup-Lebenszyklus;194
9.1.3.7;A.3.7 Fallbeispiel bei it-agile;194
9.1.3.8;A.3.8 Fazit zu Lean Startup;195
9.1.4;A.4 Das Kapitel in Stichworten;196
9.2;B Große Produkte mit dem LeSS-Framework entwickeln;197
9.2.1;B.1 Veränderung folgt Notwendigkeiten;197
9.2.2;B.2 Agile Skalierungsprinzipien nach LeSS;197
9.2.2.1;Abb. B–1 LeSS-Prinzipien [Larman & Vodde 2017];198
9.2.2.2;Prinzip: Transparency (Transparenz);198
9.2.2.3;Fallbeispiel zum Prinzip Customer Centric (Kundenzentrierung) (von Jürgen Hoffmann);199
9.2.2.4;Prinzip: More with Less (mehr mit weniger erreichen);199
9.2.3;B.3 Durchstarten zur Skalierung;199
9.2.3.1;B.3.1 Schule alle Beteiligten;200
9.2.3.1.1;Fallbeispiel (von Jürgen Hoffmann);200
9.2.3.2;B.3.2 Definiere das »Produkt«;200
9.2.3.2.1;Fallbeispiel (von Stefan Roock);200
9.2.3.3;B.3.3 Definiere, wann es »fertig« ist;201
9.2.3.3.1;Fallbeispiel (von Jürgen Hoffmann);201
9.2.3.4;B.3.4 Baue angemessen strukturierte Teams auf;201
9.2.3.5;B.3.5 Nur der Product Owner versorgt die Teams mit Arbeit;202
9.2.3.5.1;Fallbeispiel (von Jürgen Hoffmann);202
9.2.3.5.2;Fallbeispiel (von Stefan Roock);202
9.2.4;B.4 Ein Produkt – mehrere Teams;203
9.2.4.1;Abb. B–2 LeSS-Struktur [Larman & Vodde 2017];203
9.2.5;B.5 Das Kapitel in Stichworten;204
9.3;Literaturverzeichnis;205
9.4;Index;211
10;www.dpunkt.de;0

Über Autor(innen)

Dr. Jürgen Hoffmann hat seit 2003 Erfahrung mit agilen Methoden und Scrum. Nach der ersten großen Scrum-Einführung in Deutschland bei der WEB.DE AG hat er in den Rollen als Coach, Trainer, Product Owner, Scrum Master und Teammitglied in unterschiedlichen Branchen und Firmengrößen gearbeitet. Diese Erfahrung aus Branchen wie Automotive, Energie, Finanzen, IT & Internet mit Soft- und Hardwareentwicklung fließen in jeden Beratungsprozess ein. Heute arbeitet er als Geschäftsführer und Managementberater bei der Emendare GmbH & Co KG, die er 2013 mitgründete. Als Certified Scrum Trainer (CST) und Certified Enterprise Coach (CEC) ist er Teil einer starken Gemeinschaft von über 280 Scrum-Trainern und Coaches der weltweiten Scrum Alliance®, die in ständigem Austausch miteinander ihre Trainings und Beratungsideen kontinuierlich verbessern und um aktuelle Fragestellungen ergänzen.

Dipl.-Inform. Stefan Roock ist Gründungsmitglied der it-agile GmbH. Ihm ist es in seiner Beratungstätigkeit wichtig, dass sich wirklich etwas ändert – hin zu erfolgreichen Unternehmen mit zufriedenen Mitarbeitern, die sich immer neuen Herausforderungen stellen. Stefan hat seit 1999 die Verbreitung agiler Ansätze in Deutschland maßgeblich mit beeinflusst. Zunächst hat er als Entwickler, später als Scrum Master und Product Owner in Scrum-Teams gearbeitet. Heute gibt er seine Erfahrung als Berater und Trainer weiter und hilft Unternehmen dabei, agiler zu werden. Neben seiner Beratungstätigkeit für it-agile ist er regelmäßiger Sprecher zu agilen Themen auf Konferenzen, schreibt Zeitschriftenartikel und hat mehrere Bücher veröffentlicht.