| Agile Unternehmen | 1 |
| Inhaltsübersicht | 7 |
| Inhaltsverzeichnis | 9 |
| 1 Einleitung | 15 |
| 1.1 Echte Agilität | 16 |
| Abb. 1–1 Kernidee agiler Entwicklung | 16 |
| Abb. 1–2 Scrum zur Unterstützung der agilen Kernidee | 16 |
| Abb. 1–3 Unternehmensstrukturen stören die agile Kernidee. | 17 |
| Abb. 1–4 Selbstorganisiertes Team | 18 |
| Abb. 1–5 Lieferndes Team | 18 |
| Abb. 1–6 Kundenwertoptimierendes Team | 19 |
| 1.2 Agile Fluency | 19 |
| Abb. 1–7 Das Agile Fluency Model™ | 20 |
| 1.3 Fokus dieses Buches: echte Agilität oder auch »Optimize Value« | 21 |
| 1.3.1 Eigenschaften von »Optimize Value«-Unternehmen | 22 |
| 1.3.2 »Focus on Value« und »Deliver Value«: Literaturempfehlungen | 23 |
| 1.4 An wen richtet sich das Buch? | 24 |
| 1.5 Überblick über das Buch | 24 |
| 1.6 Danksagung | 25 |
| 2 Begeisterte Kunden | 27 |
| 2.1 Definieren, was Wert bedeutet und schafft | 27 |
| 2.1.1 Wert aus Kundensicht | 27 |
| 2.1.2 Bedürfnisse identifizieren | 30 |
| 2.2 Drei Horizonte für Wachstum und Innovation | 31 |
| Abb. 2–1 3-Horizonte-Modell für Wachstum | 31 |
| Abb. 2–2 Das Wachstum des aktuellen Geschäfts ist endlich | 32 |
| 2.2.1 Herausforderungen bei der Umsetzung des 3-Horizonte-Modells | 33 |
| 2.2.2 Das 3-Horizonte-Modell und agile Entwicklung | 34 |
| Größere Marktdynamik | 34 |
| Fallbeispiel: DVDs (von Jürgen Hoffmann) | 35 |
| Zeithorizonte | 35 |
| 2.2.3 Wert bedeutet in jedem Horizont etwas anderes | 35 |
| 2.3 Wert in Horizont 1 | 36 |
| 2.3.1 Umsatz als Indikator für Wertschöpfung | 36 |
| 2.3.2 Net Promoter System (NPS) | 36 |
| Abb. 2–3 NPS-Frage | 37 |
| Abb. 2–4 Bedeutung der NPS-Werte | 37 |
| Abb. 2–5 Berechnung des NPS-Wertes | 37 |
| NPS und offene Fragen | 38 |
| Fallbeispiel: Offene NPS-Frage (von Stefan Roock) | 38 |
| 2.3.3 NPS: Bitte beachten | 38 |
| Fallbeispiel: NPS-Wert als Zielvorgabe (von Stefan Roock) | 39 |
| Fallbeispiel: Wundersame NPS-Wert-Verbesserung (von Stefan Roock) | 39 |
| 2.3.4 Produktreview/Sprint-Review | 39 |
| Fallbeispiel: Sprint-Review mit echten Kunden (von Jürgen Hoffmann) | 40 |
| Produktreview mit Feedback aus dem Livebetrieb | 40 |
| 2.4 Wert in Horizont 2 | 41 |
| 2.4.1 Produktvision | 41 |
| Abb. 2–6 Product Vision Board nach R. Pichler | 42 |
| Fallbeispiel: Produktvision bringt Klarheit (von Jürgen Hoffmann) | 43 |
| 2.4.2 Produktreview/Sprint-Review | 44 |
| 2.4.3 Design Sprints | 44 |
| Montag: Ziel des Design Sprints festlegen | 44 |
| Dienstag: Lösungsansätze skizzieren | 45 |
| Mittwoch: Auswahl und Klärung von Lösungsansätzen | 45 |
| Donnerstag: Prototyp gestalten | 45 |
| Freitag: Feedback einsammeln | 45 |
| Fallbeispiel: Design Sprints (von Jürgen Hoffmann) | 45 |
| Weitere Infos zu Design Sprints | 45 |
| 2.5 Wert in Horizont 3 | 46 |
| 2.5.1 Vorgehen in Horizont 3 zur Produkt-/Serviceentwicklung | 47 |
| Abb. 2–7 Zyklisches Vorgehen in Horizont 3 | 47 |
| Kundenbedürfnisse verstehen | 48 |
| Produkt-/Service-Idee entwickeln | 49 |
| Produkt-/Service-Idee validieren | 49 |
| 2.5.2 Konkrete Techniken zum Einsatz in Horizont 3 | 49 |
| 2.6 Organisation für das 3-Horizonte-Modell | 50 |
| 2.6.1 Freiraum in Horizont 1 | 50 |
| Abb. 2–8 Innovationsbereiche | 51 |
| Fallbeispiel: Slack-Time (von Stefan Roock) | 51 |
| 2.6.2 Freiraum in Horizont 2 | 52 |
| 2.6.3 Freiraum in Horizont 3 | 53 |
| 2.6.4 Übergang von Horizont 3 nach Horizont 2 | 53 |
| Ansoff-Matrix | 54 |
| Abb. 2–9 Ansoff-Matrix | 54 |
| 2.6.5 Übergang von Horizont 2 nach Horizont 1 | 55 |
| 2.6.6 Personalstrategien der Horizonte | 56 |
| Horizont 1 | 56 |
| Horizont 2 | 56 |
| Horizont 3 | 57 |
| Personalstrategien zusammengefasst | 57 |
| 2.6.7 Entwicklung in den drei Horizonten | 58 |
| Fallbeispiel: Pflegeversicherung (von Jürgen Hoffmann) | 58 |
| 2.6.8 Produkt-Roadmaps in den drei Horizonten | 59 |
| Produkt-Roadmap und Business-Plan | 61 |
| 2.7 Das Kapitel in Stichpunkten | 61 |
| 3 Wertschöpfung als Teamaufgabe | 63 |
| 3.1 Eigenständige Teams | 64 |
| Abb. 3–1 Unterschiedlicher Autonomiegrad von Teams nach Hackman | 65 |
| 3.1.1 Manager-led Teams | 65 |
| 3.1.2 Self-managing Teams | 65 |
| 3.1.3 Self-designing Teams | 66 |
| 3.1.4 Self-governing Teams | 67 |
| Fallbeispiel für self-managing Teams (von Jürgen Hoffmann) | 68 |
| Fallbeispiel für self-designing Teams (von Jürgen Hoffmann) | 68 |
| Fallbeispiel für self-governing Teams: Wooga (von Stefan Roock) | 68 |
| 3.2 Funktionsübergreifende Teams | 69 |
| Fallbeispiel: Funktionsübergreifendes Team (von Jürgen Hoffmann) | 70 |
| Fallbeispiel: 24translate (von Stefan Roock) | 70 |
| 3.2.1 Zusammensetzung von Teams | 70 |
| Abb. 3–2 Wertfokussierende vs. kundenwertoptimierende Teams | 71 |
| Abb. 3–3 Notwendige Fähigkeiten ins wertoptimierende Team integrieren | 71 |
| Abb. 3–4 Wissenstransfer durch Pairing | 72 |
| Persönlichkeiten im Team | 72 |
| 3.2.2 Product-Owner-Rolle | 72 |
| 3.2.3 Teambegleitung | 73 |
| 3.2.4 Effizienz vs. Effektivität | 73 |
| 3.3 Entscheidungen im Team | 75 |
| 3.4 Das Kapitel in Stichpunkten | 75 |
| 4 Unterstützende Organisation | 77 |
| 4.1 Störungen durch das Unternehmen | 78 |
| Abb. 4–1 Agiler Kernzyklus | 78 |
| Abb. 4–2 Unternehmen stören den agilen Kernzyklus. | 79 |
| 4.2 Dezentrale Strukturen | 79 |
| Abb. 4–3 Teambasierte Unternehmensstruktur | 81 |
| Abb. 4–4 Peripheriezellen bilden ein Netzwerk. | 82 |
| Abb. 4–5 Peripherie und Zentrum | 83 |
| 4.2.1 Zellmodell in der Praxis der Softwareentwicklung | 83 |
| Abb. 4–6 Softwareentwicklung im Zentrum | 84 |
| Abb. 4–7 Softwareentwicklung in der Peripherie | 85 |
| 4.2.2 Mehr als ein Team pro Zelle | 86 |
| Fallbeispiel: Eigene Skalierungsstrukur finden (von Jürgen Hoffmann) | 87 |
| 4.2.3 Alles Illusion? | 87 |
| Fallbeispiel: Struktur der Bank-IT spiegelt Fachstruktur (von Stefan Roock) | 87 |
| Abb. 4–8 Entwicklung organisiert nach Geschäftsfeldern | 88 |
| Fallbeispiel: Wooga (von Stefan Roock) | 88 |
| 4.3 Alignment bei dezentralen Strukturen | 89 |
| Abb. 4–9 Alignment und Autonomie stehen nicht im Widerspruch zueinander. | 89 |
| Abb. 4–10 Autonomie und Alignment als unabhängige Dimensionen | 90 |
| 4.3.1 Management by Objectives (MbO) | 90 |
| Abb. 4–11 Ziele (Objectives) auf allen Unternehmensebenen | 91 |
| Messbarkeit von Zielen und Anreizsysteme | 92 |
| 4.3.2 Objectives and Key Results (OKR) | 92 |
| Tab. 4–1 Gemeinsamkeiten und Unterschiede zwischen MbO und OKR | 93 |
| 4.3.3 MbO-Beispiel – so bitte nicht | 93 |
| Abb. 4–12 Beispiel für eine falsche MbO-Anwendung | 94 |
| 4.3.4 MbO-Beispiel – besser | 95 |
| Abb. 4–13 Besseres MbO-Beispiel | 95 |
| 4.3.5 Nutzen und Gefahren von Management by Objectives | 96 |
| Unpassende Organisationsstruktur | 96 |
| Varianzen | 97 |
| Abb. 4–14 Geschäftsrelevante Ziele unterliegen meist Varianzen. | 98 |
| Lokale Optimierungen | 98 |
| Hands-off-Management | 99 |
| Außerordentliche Anstrengungen | 99 |
| Zielkonflikte | 99 |
| Innovationshemmnis | 99 |
| 4.3.6 Ziele ohne die MbO-Gefahren | 100 |
| 4.4 Feedbackschleifen statt statischer Ziele | 101 |
| 4.4.1 Feedbackschleife für den Umweltschutz | 101 |
| Abb. 4–15 Das Problem: Fabriken verschmutzen Flüsse. | 102 |
| Abb. 4–16 Lösung durch Feedbackschleife | 102 |
| Fallbeispiel: Nearshore-Bugfixing | 103 |
| Fallbeispiel: Spesen bei it-agile | 103 |
| 4.4.2 Feedbackschleifen bei Command & Control-Strukturen | 104 |
| Abb. 4–17 Managerbasierte Feedbackschleifen | 104 |
| 4.4.3 Feedbackschleifen in einem agilen Unternehmen | 105 |
| Abb. 4–18 Causal-Loop-Diagramm | 106 |
| Abb. 4–19 Causal-Loop-Diagramm nach Abschaffung des Bugfixing-Teams | 106 |
| 4.4.4 Das Unternehmen als Organismus | 107 |
| 4.5 Übergreifende Entscheidungsfindung bei dezentralen Strukturen | 107 |
| 4.5.1 Konsent | 107 |
| 4.5.2 Advice-Prozess | 109 |
| Abb. 4–20 Ablauf eines konsultativen Einzelentscheids | 110 |
| Fallbeispiel: Einführung des konsultativen Einzelentscheids bei it-agile | 110 |
| 4.5.3 Das Unternehmen verstehen | 112 |
| 4.5.4 Bewertung und Vergleich von Konsent und Advice-Prozess | 112 |
| 4.6 Neue Rolle für Führungskräfte | 113 |
| 4.6.1 Klassische Mitarbeiterführung | 113 |
| Abb. 4–21 Klassische Hierarchie | 113 |
| Fachliche und disziplinarische Führung | 114 |
| 4.6.2 Probleme klassischer Führung in einer dynamischen Welt | 115 |
| Matrixorganisation | 115 |
| Abb. 4–22 Matrixorganisation aus Abteilungen und Projekten | 115 |
| 4.6.3 Supporting Lines statt Reporting Lines | 116 |
| Abb. 4–23 Supporting Lines statt Reporting Lines | 116 |
| 4.6.4 Verteilte Führung | 117 |
| 4.6.5 Situative Führung | 118 |
| Fallbeispiel: Gehalts-Checker bei it-agile (von Stefan Roock) | 119 |
| 4.6.6 Ausbildung | 119 |
| Abb. 4–24 Falsch verstandene Agilität: Hands-off-Management | 120 |
| Abb. 4–25 Gegenseitiges Lernen | 120 |
| 4.7 Fallbeispiele zu moderner Mitarbeiterführung | 121 |
| 4.7.1 ImmobilienScout24 | 121 |
| Das Unternehmen | 121 |
| Scrum-Einführung 2008 | 121 |
| Abb. 4–26 Teamleiter bei ImmobilienScout24 | 122 |
| Abgrenzung Scrum Master und Teamleiter | 122 |
| Abteilungsleiter | 122 |
| Probleme | 122 |
| Reorganisation 2015 | 123 |
| Neue Rolle Delivery Lead ersetzt Scrum Master und Teamleiter | 123 |
| Abb. 4–27 Delivery Leads bei ImmobilienScout24 | 123 |
| Heads | 124 |
| Herausforderungen der Delivery-Lead-Rolle | 124 |
| 4.7.2 sipgate | 125 |
| Das Unternehmen | 125 |
| Teams | 125 |
| Product Owner und Scrum Master | 125 |
| Keine Linienvorgesetzten | 125 |
| Einstellung neuer Mitarbeiter | 126 |
| Gehälter | 126 |
| Entlassungen | 126 |
| Abb. 4–28 Führung bei sipgate ohne Linienvorgesetzte | 127 |
| Persönliche Weiterentwicklung | 127 |
| Fürsorge | 127 |
| Der lange Weg zur Freiheit | 128 |
| 4.7.3 it-agile | 128 |
| Das Unternehmen | 128 |
| Teams | 128 |
| Fürsorge | 128 |
| Rollen statt Positionen | 128 |
| Geschäftsführung | 128 |
| Einstellungen | 129 |
| Gehaltserhöhungen | 129 |
| Weiterentwicklung der Mitarbeiter | 130 |
| Abb. 4–29 Mitarbeiterführung bei it-agile | 130 |
| Kündigungen | 131 |
| 4.7.4 Zusammenfassung der Fallbeispiele für Mitarbeiterführung | 131 |
| 4.8 Unternehmenskultur | 132 |
| Abb. 4–30 Das PARC-Modell | 132 |
| 4.8.1 Unternehmenskultur und agiles Arbeiten | 133 |
| Abb. 4–31 Im Kern stehen die agilen Werte und Prinzipien. | 133 |
| Fallbeispiel: Zu große Transparenz (von Jürgen Hoffmann) | 134 |
| 4.9 Das Kapitel in Stichworten | 134 |
| 5 Organisationsentwicklung | 137 |
| 5.1 Organisationsentwicklung als komplexe Aufgabe | 137 |
| 5.1.1 Satir Change Model | 138 |
| Abb. 5–1 Satir Change Model | 138 |
| 5.2 Erfolgsfaktoren für agile Organisationsentwicklung | 141 |
| Abb. 5–2 Kotter Change Model | 141 |
| 5.2.1 Erfahrungen mit dem Kotter Change Model | 143 |
| 5.3 Steuerung iterativer Organisationsentwicklung | 144 |
| 5.3.1 Das agile Transitionsteam | 145 |
| Abb. 5–3 Transitionsteam steuert die Veränderung. | 145 |
| 5.3.2 Transition Backlog und Product Owner | 145 |
| Abb. 5–4 Transitionsteam mit Transition Backlog | 146 |
| 5.3.3 Produktvision und Produktinkremente des Transitionsteams | 147 |
| Einschub: Dimensional-Planning-Konzept | 147 |
| Dimensional Planning für agile Transitionen | 148 |
| 5.3.4 Transitionsteam: Besetzung und Rollen | 149 |
| 5.3.5 Sprints im Transitionsteam | 150 |
| 5.3.6 Einbindung ins Unternehmen | 151 |
| 5.3.7 Weitere Probleme im Transitionsteam | 151 |
| Kapazität des Transitionsteams | 151 |
| Arbeiten im Transitionsteam | 152 |
| Loslassen | 152 |
| 5.4 Organisationsentwicklung über Experimente | 153 |
| 5.4.1 Der PDCA-Zyklus | 153 |
| Abb. 5–5 PDCA-Zyklus nach Shewhart/Deming | 153 |
| Plan | 153 |
| Do | 154 |
| Check | 154 |
| Act | 154 |
| Und: Go & See | 154 |
| 5.4.2 PDCA in der Praxis | 155 |
| Abb. 5–6 Anpassungen und Ausbreitung mit dem PDCA-Zyklus | 156 |
| 5.4.3 Organisationsentwicklung als Abfolge von Experimenten | 156 |
| Abb. 5–7 Organisationsveränderungen sind Experimente. | 156 |
| 5.4.4 Safe-to-Fail-Experimente | 157 |
| 5.4.5 Experimente erleichtern die Veränderung | 157 |
| 5.4.6 Organisation der Organisationsentwicklung | 158 |
| Abb. 5–8 Experimenteboard bei it-agile | 159 |
| Abb. 5–9 Experimentbeschreibung | 159 |
| 5.5 Kultur der kontinuierlichen Verbesserung | 160 |
| Fallbeispiel: Regelmäßige Retrospektiven von Teams, gelegentlich von zwei oder mehr Teams (von Jürgen Hoffmann) | 160 |
| Fallbeispiel: Bereichs- und Teamzuschnitte stehen zur Diskussion (von Jürgen Hoffmann) | 161 |
| 5.5.1 Transparenz in alle Richtungen | 161 |
| Fallbeispiel: Kennzahlen bei WEB.DE (von Jürgen Hoffmann) | 161 |
| Wertbildungsrechnung bei dm-drogerie markt | 161 |
| 5.6 Orientierung mit einem Nordstern (True North) | 162 |
| Abb. 5–10 Verbesserung mit und ohne Nordstern | 163 |
| 5.6.1 Nordstern bei Toyota | 163 |
| 5.6.2 Nordsterne für die Wissensarbeit | 164 |
| Scrum-Projektteams | 164 |
| Interne Projektteams | 164 |
| Verlässlicher Webshop-Produzent | 164 |
| IT Operations | 164 |
| Internetplattform | 164 |
| Koch bei Jimdo | 164 |
| 5.6.3 Eigenschaften eines guten Nordsterns | 165 |
| 5.6.4 Arbeiten mit dem Nordstern | 166 |
| Abb. 5–11 Orientierung bei Verbesserungen mit einem Nordstern | 166 |
| Abb. 5–12 Zwischenziele (Target Conditions) | 167 |
| 5.6.5 Nordstern und der PDCA-Zyklus | 167 |
| 5.6.6 Die A3-Technik | 168 |
| Abb. 5–13 Mögliches A3-Template | 168 |
| Abb. 5–14 Beispielhaftes A3 | 169 |
| 5.6.7 Der Weg zum eigenen Nordstern | 169 |
| Abb. 5–15 Auf dem Weg zum eigenen Nordstern | 170 |
| Schritt 1: Klarheit über den betrachteten Geltungsbereich | 170 |
| Schritt 2: Klarheit über das eigene Produkt bzw. den eigenen Service | 170 |
| Schritt 3: Vision für die internen Prozesse und Strukturen | 170 |
| 5.7 Das Kapitel in Stichworten | 171 |
| Anhang | 173 |
| A User Research | 175 |
| A.1 Design Thinking konkret | 175 |
| Abb. A–1 Design-Thinking-Elemente | 176 |
| Abb. A–2 Design Thinking als Tanzschritte | 177 |
| A.1.1 Team | 177 |
| A.1.2 Raum | 178 |
| A.1.3 Prozess | 179 |
| A.2 Design Sprints | 180 |
| Team | 181 |
| Zeit und Raum | 182 |
| Vorlauf | 182 |
| Montag | 182 |
| Dienstag | 183 |
| Mittwoch | 185 |
| Donnerstag | 186 |
| Freitag | 187 |
| Ergebnis | 188 |
| A.3 Lean Startup | 188 |
| A.3.1 Die Historie und das Umfeld | 189 |
| A.3.2 Kundenbedürfnisse verstehen und Lösung validieren | 189 |
| Abb. A–3 Build-Measure-Learn-Zyklus | 190 |
| A.3.3 Den Markt validieren | 190 |
| A.3.4 Minimum Viable Product (MVP) | 191 |
| Abb. A–4 MVPs (Minimum Viable Products) | 192 |
| A.3.5 Pivots | 193 |
| Abb. A–5 Pivots betreffen die Strategie. | 193 |
| A.3.6 Skalierung | 194 |
| Abb. A–6 Lean-Startup-Lebenszyklus | 194 |
| A.3.7 Fallbeispiel bei it-agile | 194 |
| A.3.8 Fazit zu Lean Startup | 195 |
| A.4 Das Kapitel in Stichworten | 196 |
| B Große Produkte mit dem LeSS-Framework entwickeln | 197 |
| B.1 Veränderung folgt Notwendigkeiten | 197 |
| B.2 Agile Skalierungsprinzipien nach LeSS | 197 |
| Abb. B–1 LeSS-Prinzipien [Larman & Vodde 2017] | 198 |
| Prinzip: Transparency (Transparenz) | 198 |
| Fallbeispiel zum Prinzip Customer Centric (Kundenzentrierung) (von Jürgen Hoffmann) | 199 |
| Prinzip: More with Less (mehr mit weniger erreichen) | 199 |
| B.3 Durchstarten zur Skalierung | 199 |
| B.3.1 Schule alle Beteiligten | 200 |
| Fallbeispiel (von Jürgen Hoffmann) | 200 |
| B.3.2 Definiere das »Produkt« | 200 |
| Fallbeispiel (von Stefan Roock) | 200 |
| B.3.3 Definiere, wann es »fertig« ist | 201 |
| Fallbeispiel (von Jürgen Hoffmann) | 201 |
| B.3.4 Baue angemessen strukturierte Teams auf | 201 |
| B.3.5 Nur der Product Owner versorgt die Teams mit Arbeit | 202 |
| Fallbeispiel (von Jürgen Hoffmann) | 202 |
| Fallbeispiel (von Stefan Roock) | 202 |
| B.4 Ein Produkt – mehrere Teams | 203 |
| Abb. B–2 LeSS-Struktur [Larman & Vodde 2017] | 203 |
| B.5 Das Kapitel in Stichworten | 204 |
| Literaturverzeichnis | 205 |
| Index | 211 |
| www.dpunkt.de | 0 |
