Kanban (eBook)
272 Seiten
dpunkt (Verlag)
978-3-86491-805-6 (ISBN)
Mike Burrows ist Geschäftsführer und Principal Consultant von David J. Anderson and Asso-ciates (djaa.com). In seiner beruflichen Laufbahn, die sich von der Luftfahrt über das Bank-wesen, das Energiewesen bis hin zum öffentlichen Dienst zieht, ist Mike bereits IT-Leiter, globaler Entwicklungsleiter und Softwareentwickler gewesen. Er ist akkreditierter Kanban Trainer (AKT) und Kanban Coaching Professional (KCP) und wird überall auf der Welt ein-geladen, um auf Veranstaltungen Vorträge zu halten. Er bloggt auf positiveincline.com und twittert als @asplake und @KanbanInside. Übersetzer: Florian Eisenberg hilft Unternehmen als Trainer, Berater und Coach auf ihrem Weg zur Agilität. Dabei setzt er am liebsten auf Kanban und unterstützt es durch andere Vorgehensmodelle wie beispielsweise Scrum. Er schätzt an Kanban besonders den respektvollen Umgang mit den Beteiligten und die lösungsoffene Herangehensweise. Nach seinem Studium der Informatik in Karlsruhe arbeitete er als Programmierer, Scrum Master und Product Owner, bevor er Berater wurde. Er ist einer der ersten akkreditierten Kanban Trainer (AKT) und Kanban Coaching Professionals (KCP). Sein Blog finden Sie auf florianeisenberg.de, er twittert als @fjeisenberg. Wolfgang Wiedenroth ist ausgebildeter Fachinformatiker der Fach-richtung Anwendungsentwicklung und arbeitete insgesamt fünf Jahre als Scrum Master in verschiedenen Bereichen der IT. 2010 entdeckte er Kanban und verliebte sich in dessen erstes Prinzip 'Beginne mit dem, was du gerade tust' und wurde ein wahrer Kanban-Enthusiast. Heute arbeitet er bei it-agile als Berater und hilft Unternehmen, mit Kanban ihre Prozesse und Umgebung zu verstehen und zu verbessern. Wolf-gang ist akkreditierter Kanban Trainer (AKT) und Kanban Coaching Pro-fessional (KCP). Außerdem ist er Co-Founder der Limited WIP Society München. Er bloggt auf agilemanic.com und twittert als @wwiedenroth.
Mike Burrows ist Geschäftsführer und Principal Consultant von David J. Anderson and Asso-ciates (djaa.com). In seiner beruflichen Laufbahn, die sich von der Luftfahrt über das Bank-wesen, das Energiewesen bis hin zum öffentlichen Dienst zieht, ist Mike bereits IT-Leiter, globaler Entwicklungsleiter und Softwareentwickler gewesen. Er ist akkreditierter Kanban Trainer (AKT) und Kanban Coaching Professional (KCP) und wird überall auf der Welt ein-geladen, um auf Veranstaltungen Vorträge zu halten. Er bloggt auf positiveincline.com und twittert als @asplake und @KanbanInside. Übersetzer: Florian Eisenberg hilft Unternehmen als Trainer, Berater und Coach auf ihrem Weg zur Agilität. Dabei setzt er am liebsten auf Kanban und unterstützt es durch andere Vorgehensmodelle wie beispielsweise Scrum. Er schätzt an Kanban besonders den respektvollen Umgang mit den Beteiligten und die lösungsoffene Herangehensweise. Nach seinem Studium der Informatik in Karlsruhe arbeitete er als Programmierer, Scrum Master und Product Owner, bevor er Berater wurde. Er ist einer der ersten akkreditierten Kanban Trainer (AKT) und Kanban Coaching Professionals (KCP). Sein Blog finden Sie auf florianeisenberg.de, er twittert als @fjeisenberg. Wolfgang Wiedenroth ist ausgebildeter Fachinformatiker der Fach-richtung Anwendungsentwicklung und arbeitete insgesamt fünf Jahre als Scrum Master in verschiedenen Bereichen der IT. 2010 entdeckte er Kanban und verliebte sich in dessen erstes Prinzip "Beginne mit dem, was du gerade tust" und wurde ein wahrer Kanban-Enthusiast. Heute arbeitet er bei it-agile als Berater und hilft Unternehmen, mit Kanban ihre Prozesse und Umgebung zu verstehen und zu verbessern. Wolf-gang ist akkreditierter Kanban Trainer (AKT) und Kanban Coaching Pro-fessional (KCP). Außerdem ist er Co-Founder der Limited WIP Society München. Er bloggt auf agilemanic.com und twittert als @wwiedenroth.
Kanban 3
Geleitwort 7
Vorwort zur deutschen Ausgabe 9
Vorwort 11
Inhaltsübersicht 13
Inhaltsverzeichnis 15
Teil I – Kanban durch seine Werte verstehen 23
1 Transparenz 25
1.1 Kernpraktik 1: Visualisiere 26
Abb. 1–1 Ein elektronisches Board 26
1.1.1 Visualisierung und Veränderung 27
1.2 Kernpraktik 4: Mache Prozessregeln explizit 29
1.2.1 Prozessregeln und Veränderung 30
1.3 Kernpraktik 5: Implementiere Feedbackzyklen 30
1.3.1 Das Standup-Meeting 31
1.3.2 Replenishment-Meetings 32
1.3.3 Weitere Meetings 32
1.3.4 Feedbackzyklen, die auf Metriken basieren 33
Abb. 1–2 Cumulative Flow Diagram (CFD) meines Projekts 33
1.4 Transparenz als Wert 34
2 Balance 35
2.1 Kernpraktik 2: Parallele Arbeit (Work in Progress, WIP) limitieren 35
2.2 Pull-Systeme in der Wissensarbeit 35
Abb. 2–1 Die TEST-Spalte besitzt ein WIP-Limit von 4. 35
Abb. 2–2 Zwei Tickets bewegen sich nach rechts über das Board. 36
2.3 Balance zwischen Arbeitslast und Kapazität 37
2.4 Andere Möglichkeiten, WIP zu limitieren 38
2.5 Balance zwischen dringlichkeits- und termingetriebener Arbeit 39
Abb. 2–3 Die Arbeitspakte in »TEST« 39
2.6 Risikobasierte Kategorisierung und Serviceklassen 40
2.7 Balance zwischen Anforderungen und Leistungsfähigkeit 42
2.8 Stakeholder-Balance 42
2.9 Balance suchen 43
3 Kooperation 45
3.1 Kernpraktik 6: Erziele Verbesserung kooperativ und entwickle experimentell 45
3.2 Kooperation ist eine ernste Sache 45
3.3 Erziele Verbesserung kooperativ 46
3.4 Zu Kooperation ermutigen 46
3.5 Fokus auf Kooperation legen 47
3.6 Entwickle experimentell 48
3.7 Die und wir 49
Reflexion: Transparenz, Balance und Kooperation 51
4 Kundenfokus 53
4.1 Kernpraktik 3: Manage den Arbeitsfluss 53
4.2 Warum Kundenfokus? 53
4.3 Zufriedenheit garantiert 54
4.4 Quer über das Board 55
4.5 Upstream-Kanban 55
Abb. 4–1 Ein Beispiel für ein Personal-Kanban-Board-Design 55
4.6 Bedürfnisse vorwegnehmen 58
5 Arbeitsfluss 59
5.1 Kernpraktik 3: Manage den Arbeitsfluss (nochmal) 59
5.2 Gleichmäßigkeit 59
5.2.1 Wie sieht Arbeitsfluss aus? 60
5.3 Quer über das Board (nochmal) 61
5.4 Es gibt immer einen größeren Kontext 62
5.5 Einige einfache Beispiele 63
5.6 Arbeitsfluss quer durch die Organisation 64
Abb. 5–1 Gemeinsam genutzte und abhängige Dienste umfassen zwei Hauptworkflows. 64
5.7 Arbeitsfluss managen, um Pünktlichkeit zu erzielen 67
6 Führung 69
6.1 Grundprinzip 4: Führung auf allen Ebenen 70
6.2 Möglichkeiten finden sich überall 70
6.3 Führung erzeugt Führung 71
6.4 Warum Führung wertschätzen? 72
6.5 Wie sieht Führung in Kanban aus? 73
Reflexion: Kundenfokus, Arbeitsfluss und Führung 75
7 Verständnis 77
7.1 Änderungen ohne Verständnis – drei Anti-Pattern 77
7.1.1 Selbstzufriedenheit 78
7.1.2 Draufgängertum 78
7.1.3 Einmischung 80
7.2 Einführung der J-Kurve 81
Abb. 7–1 Die J-Kurve 81
7.3 Ein Muster für zielgerichtete Veränderung 82
8 Vereinbarung 85
8.1 Verfolge evolutionäre Veränderung 85
Abb. 8–1 Eine Abfolge kleiner J-Kurven 86
Abb. 8–2 Nicht jedes Experiment wird erfolgreich sein. 87
8.2 Vereinbare das Verfolgen 87
8.3 Change Management 88
8.3.1 Der Change Agent 88
8.3.2 Der betreute Change Agent 89
8.3.3 Das Change-Team 91
9 Respekt 93
9.1 Fange nicht bei den Rollen an 93
9.2 »Sei wie Wasser« 94
9.3 Respekt für Menschen 95
9.3.1 Transparenz 95
9.3.2 Balance 96
9.3.3 Kooperation 96
9.3.4 Kundenfokus 96
9.3.5 Arbeitsfluss 97
9.3.6 Führung 97
9.3.7 Verständnis 97
9.3.8 Vereinbarung 98
9.4 Die menschliche »Beginne mit dem, was du gerade tust«- Methode 98
10 Muster und Agenden 99
10.1 »Noble Muster« 99
10.2 Agenden für Veränderung 100
10.3 Die Nachhaltigkeits-Agenda 101
10.4 Die Serviceorientierungs-Agenda 102
10.4.1 Die Kanban-Linse 102
10.5 Die Überlebensfähigkeits-Agenda 103
10.6 Die Agenda Ihrer Organisation 103
10.7 Wie erging es uns? 104
10.8 Fünf Jahre später 105
Teil II – Modelle 107
11 Systemdenken, Komplexität und die lernende Organisation 109
11.1 Systemdenken 109
11.1.1 Hebelpunkte und Systemdynamiken 110
11.2 Komplexität 111
Abb. 11–1 Teuflisch oder engelsgleich? Eine Feedbackschleife in der Qualität. 112
11.2.1 Kausalität und das Cynefin-Framework 113
11.2.2 Komplexe adaptive Systeme 114
11.3 Wissen, lernen und die lernende Organisation 115
11.3.1 Demings System vom umfassenden Wissen 115
11.3.2 Argyris und das Doppelschleifen-Lernen 116
Abb. 11–2 Doppenschleifen-Lernen 117
11.3.3 Die lernende Organisation 118
11.4 Systemdenken und Kanban 119
11.4.1 Das Design der Methode 119
11.4.2 Anwendung 120
12 Engpasstheorie (TOC) 121
12.1 Die fünf Fokussierungsschritte und der Process of Ongoing Improvement (POOGI) 122
12.2 Drum-Buffer-Rope (DBR) 123
12.3 Thinking Processes – Denkprozesse 124
Tab. 12–1 Efrat Goldratts Modell der neun Schichten des Widerstands gegen Veränderung 125
12.4 Critical-Chain-Projektmanagement (CCPM) 125
Abb. 12–1 Ein simpler Plan mit Projektpuffer und Versorgungspuffer 126
Abb. 12–2 Ein Fieberdiagramm 127
12.5 Throughput Accounting – Durchsatzrechnung 127
12.6 Die Beziehung von TOC zu Kanban 127
12.6.1 POOGI und die fünf Fokussierungsschritte 128
12.6.2 DBR und CCPM 129
12.6.3 Die Denkprozesse 129
12.7 Dennoch … 130
13 Agile 131
13.1 Drei agile Methoden 132
13.1.1 Feature-Driven Development (FDD) 132
Abb. 13–1 Feature-Driven Development 132
13.1.2 Extreme Programming (XP) 133
Abb. 13–2 Der XP-Prozess 134
13.1.3 Scrum 136
Abb. 13–3 Der Scrum-Prozess 136
13.2 Kanban und Agile 138
13.2.1 Kompatibilität 138
13.2.2 Wann ist Kanban zu benutzen? 139
13.3 Das Modell Agile 140
14 TPS und Lean 141
14.1 Drei Lean-Werkzeuge 142
14.2 TPS und Lean im richtigen Licht 144
14.3 Verbesserungen bei Lean 145
14.4 Lean Product Development 146
14.5 Lean Startup 148
14.6 Lean/Agile-Hybriden 149
14.7 Kanban und Lean 149
15 Ökonomische Ansätze zum Arbeitsfluss 151
15.1 ROI und die Pareto-Diät 152
Abb. 15–1 Der Projektwert als Funktion des Umfangs 153
Abb. 15–2 Wert und Kosten als Funktion des Umfangs 153
Abb. 15–3 Der ROI hat seinen Höhepunkt, wenn der Umfang limitiert ist. 154
15.2 Verzögerungskosten 156
15.2.1 Die Kosten von Warteschlangen 159
15.3 Haltekosten 159
15.4 Optionen 161
15.4.1 Optionen haben einen Wert 162
15.4.2 Optionen verfallen 163
15.4.3 Binde dich nie frühzeitig, es sei denn, du weißt warum 163
15.5 Alles zusammengeführt 164
16 Die Kanban-Methode 165
16.1 Eine sehr kurze Historie 165
16.2 Grundprinzipien 167
16.3 Kernpraktiken 167
16.4 Kontextualisiertes Kanban 168
16.4.1 Personal Kanban 168
16.4.2 Portfolio-Kanban 169
16.4.3 Scrumban 170
16.5 Unterstützende Konzepte und Werkzeuge 171
16.6 Implementierungshilfe: STATIK 172
17 Kleinere Modelle 175
17.1 Zwei, die davongekommen sind 175
17.1.1 Littles Gesetz 175
Abb. 17–1 Eine geometrische Interpretation des Gesetzes von Little 177
17.1.2 Das Satir-Modell für Veränderung 178
Abb. 17–2 Das Satir-Modell für Veränderung 179
17.2 Denkwerkzeuge und Coaching-Modelle 179
17.2.1 GROW 179
17.2.2 A3 180
17.2.3 Exkurs: Wie ein Profi überprüfen! 181
17.2.4 Der Lean Change Canvas 182
Abb. 17–3 Ein Lean Change Canvas (Dank an agileconsulting.blogspot.com) 182
17.3 Gruppenmoderation und Spiele 182
17.3.1 Kaners Moderationsmodell 182
Abb. 17–4 Das Kaner-Modell für Gruppenmoderation 183
17.3.2 Serious Games 184
Abb. 17–5 Kanban Knowsy 185
Abb. 17–6 Schnellboot (online) 185
17.4 Modelle für kooperative Führung: Triaden und T-Formen 186
Teil III – Implementierung 189
18 Quellen der Unzufriedenheit erkennen 191
18.1 Zwei Perspektiven 191
18.2 Zwei Fragen 192
18.3 Formate 193
18.4 Organisiere und erforsche 194
18.5 Folgemaßnahmen 195
19 Anforderungen und Leistungsfähigkeiten analysieren 197
19.1 Wissen, was Sie wem liefern und warum 198
19.1.1 Was 198
19.1.2 Wem 199
19.1.3 Warum 200
19.2 Quantitative Analyse 200
Abb. 19–1 Ein Verlaufsdiagramm (Run-Chart), das die Kundendurchlaufzeit zeigt 201
Abb. 19–2 Ein Histogramm mit denselben Durchlaufzeiten wie in Abbildung 19–1 202
Abb. 19–3 Ein Paretodiagramm 202
Abb. 19–4 Ein CFD aus verschiedenen Quellen gesammelt 203
19.2.1 Flusseffizienz 203
19.3 Wie Arbeit ankommt 204
19.4 Passt alles zusammen? 205
20 Den Workflow modellieren 207
20.1 Grob aufzeichnen 207
Abb. 20–1 Der ursprüngliche Prozess der XIT-Geschichte 208
Abb. 20–2 Eine alternative Darstellung der ursprünglichen XIT-Geschichte 208
20.2 Top-down-Dekomposition 208
20.3 Bottom-up-Organisation 210
20.4 Fazit 211
21 Serviceklassen finden 213
21.1 Entdecken, überprüfen 214
21.2 Beispiele 215
21.3 In Richtung einer gesunden Arbeitszusammenstellung 216
22 Kanban-Systeme gestalten 219
22.1 Umfang, Granularität und Status der Arbeitseinheiten 219
22.1.1 Aufeinanderfolgende Status 219
Abb. 22–1 Aufeinanderfolgende Status 220
22.1.2 Parallele Status 220
Abb. 22–2 Blockiert! 221
22.1.3 Fehler 221
22.1.4 Abhängigkeiten 222
Abb. 22–3 Eine Arbeitseinheit, die von einer anderen abhängt. 222
22.2 Andere Dimensionen 223
Abb. 22–4 Zwei parallele Kanäle für Arbeit 224
22.3 Hierarchische Boards und das Aufbrechen/Zusammenführen-Muster 224
Abb. 22–5 Epics und Features 224
Abb. 22–6 Eine Pipeline von Epics … 224
Abb. 22–7 … Feature-weise ausgeliefert 224
Abb. 22–8 Aufbrechen/Zusammenführen 225
22.4 Work in Progress limitieren 225
Abb. 22–9 Übergreifende WIP-Limits 226
22.5 Review 227
23 Ein Kanban-System einführen 229
23.1 Den Einsatz planen 229
23.2 Die Agenda zusammenstellen: die drei P 231
23.2.1 Positionierung 231
23.2.2 Zweck (Purpose) 232
23.2.3 Prioritäten 232
23.3 Veränderung durch das System vorantreiben 233
23.3.1 Veränderungsinkremente identifizieren 234
Transparenz 234
Balance 235
Kooperation 236
Kundenfokus 236
Arbeitsfluss 236
Führung und die Führungsdisziplinen 237
23.3.2 Veränderung visualisieren 238
Die Beurteilung visualisieren 238
Abb. 23–1 Kanban-Tiefe – nach Werten 238
Abb. 23–2 Kanban-Tiefe – mit Entwicklungsverlauf 239
Veränderung visuell managen 239
Abb. 23–3 Das »Problemboard« 239
Abb. 23–4 Ein Kanban-System für »validierte Veränderung« 240
Nicht jede Veränderung ist gleich 240
Abb. 23–5 Nicht jede Veränderung ist gleich. 241
23.4 Abschließende Gedanken 242
Anhang 243
A Demings 14 Punkte für gutes Management 245
B Danksagung 247
C Glossar 249
D Literatur 259
Weiterführende Literatur zu einzelnen Themen 262
Systemdenken (Kap. 11) 262
Lernen (Kap. 11) 262
Engpasstheorie (TOC) (Kap. 12) 263
Agile (Kap. 13) 263
TPS und Lean (Kap. 14) 264
Ökonomische Ansätze zum Arbeitsfluss (Kap. 15) 264
Die Kanban-Methode (Kap. 16) 264
Kleinere Modelle (Kap. 17) 265
Ein Kanban-System einführen (Kap. 23) 266
Index 267
www.dpunkt.de 0
1 Transparenz
Wir befinden uns ein paar Stockwerke weiter oben in unserem schönen, neuen Büro, von dem man die Nyugati-Haltestelle in Budapest überblicken kann. Es ist kurz nach 9:30 Uhr und unser Standup-Meeting läuft gerade. Unsere Stimmung ist ein wenig vergnügter als sonst, denn wir freuen uns auf Kaffee und Kuchen auf der anderen Straßenseite. Dort werden wir feiern, dass wir wieder etwas Neues gelernt haben. Die Rechnung geht dieses Mal auf mich – ich habe es am Tag zuvor geschafft, den Build über mehrere Stunden in einem schlimmen Zustand zu hinterlassen, und der Entwicklungsleiter sollte das eigentlich nicht tun.
Allerdings haben wir noch ein paar wichtige Dinge, um die wir uns kümmern müssen. Tibor und Maté drücken ihre Sorge über ein Ticket (eine gelbe Haftnotiz) aus, das seit Tagen in der »Released«-Spalte auf dem Whiteboard des Teams feststeckt. Gy bietet kurzerhand seine Hilfe an: Er ist sich recht sicher, dass er das Betriebsteam überzeugen kann, dass die neue Preiskurve, die durch das feststeckende Ticket repräsentiert wird, zuverlässiger ist als die alte; wir sollten damit rechnen, dass sie in ein bis zwei Tagen voll in der Produktion implementiert ist. Gys Angebot wird dankbar akzeptiert und wir nehmen uns das nächste Ticket vor.
Diese wenigen Momente reichen aus, um einige Beispiele für Kanbans ersten Wert zu demonstrieren, Transparenz:
-
Unsere Arbeit ist für alle sichtbar auf einem großen Whiteboard dargestellt. Auf dem Board sind Tickets, die Arbeitspakete repräsentieren, in Spalten organisiert; die Spalten korrespondieren zu Status, in denen sich Arbeitspakete befinden können, oder zu Schritten unseres Workflows.
-
Wir verstehen die Wichtigkeit von regelmäßigen Feedbacks und wir halten ein Standup-Meeting ab.
-
Wir haben einige der Regeln, die für unsere Arbeit gelten, herauskristallisiert; viele von ihnen sind in der Nähe des Boards aufgelistet. Eine dieser Regeln besagt, dass Entwickler die Verantwortung für ihre Arbeitspakete behalten, bis sie eine Kundenbestätigung bekommen haben, dass dieses Paket auch den gewollten Wert erzielt. Eine andere Regel schreibt vor, dass Lernen mithilfe von Kuchen verstärkt werden sollte – im ganz speziellen Fall die Ich-werde-diesen-Fehler-nie-wieder-machen-Art des Lernens.
Dieses Szenario spielte sich 2009-2010 ab, gerade als David Anderson Feedback zu den kürzlich formulierten Grundprinzipien und Kernpraktiken der Kanban-Methode einholte. Wir – Menschen wie ich, die die Ideen bereits anwendeten – diskutierten und verfeinerten sie über unsere Gruppenmailingliste. Innerhalb weniger Wochen gingen sie mit Davids »blauem Buch« [Anderson 2010] in den Druck. Wir hatten eine dokumentierte Methode!
Transparenz ist ein zentraler Aspekt von Kanban. Drei der sechs Kernpraktiken stehen damit in Verbindung:
KP1: Visualisiere.
KP4: Mache Prozessregeln explizit.
KP5: Implementiere Feedbackzyklen.
Sehen wir sie uns nacheinander an.
1.1 Kernpraktik 1: Visualisiere
Kanbans Ein-Wort-Praktik »Visualisiere« erscheint erst einmal sehr unspezifisch. Allerdings besitzen die meisten Kanban-Implementierungen eine bestimmte Art der Visualisierung, ein Kanban-Board. Diese Boards werden verwendet, um Kanban-Systeme zu implementieren. Das sind visuelle Arbeitsmanagementsysteme, die einige nützliche Eigenschaften haben. Wir werden diese Eigenschaften in den nachfolgenden Kapiteln genauer betrachten, für den Moment konzentrieren wir uns auf die visuellen Aspekte.
Hätten wir ein elektronisches Werkzeug verwendet, hätte unser Board vielleicht so wie in Abbildung 1–1 ausgesehen.
Abb. 1–1 Ein elektronisches Board
Statt Haftnotizen auf einem Whiteboard haben wir nun Icons, die wir über den Bildschirm ziehen können. Egal ob elektronisch oder physisch, diese werden als kanban bezeichnet, ein japanisches Wort, das als »visuelles Zeichen« oder auch »Platzhalter« übersetzt werden kann. Wir bevorzugen die etwas umgänglicheren Begriffe Karte (oder Ticket – ich verwende die beiden synonym) und Arbeitspaket. Denken wir an das visuelle Design, tendieren wir zum ersten Begriff. Wir verwenden eher den zweiten, wenn der Fokus darauf liegt, was sie repräsentieren.
In diesem Buch repräsentieren Arbeitspakete festgelegte Teilstücke von Wissensarbeit: Dinge wie Produkteigenschaften, die entwickelt werden müssen, oder Serviceanfragen, die zu erfüllen sind. Diese Dinge müssen keine Verbindung zu Software haben – es gibt Beispiele aus Rechtsabteilungen, Personalabteilungen, dem Vertrieb und dem Büro des Geschäftsführers. Sie haben typischerweise gemeinsam, dass ein großer Teil der Arbeit in den Köpfen von Menschen oder auf ihren Computern erfolgt. Ohne das Board wäre diese Arbeit unsichtbar.
Es hört sich vielleicht trivial an, aber es ist wichtig, dass diese Tickets beweglich sind. Man bewegt die Tickets von Spalte zu Spalte, während die Arbeit am dahinterliegenden Arbeitspaket voranschreitet. Das bedeutet, dass man mit einem Blick sehen kann, wie viel Arbeit sich in welchem Zustand der Fertigstellung befindet. Schaffen Sie das mal mit einer To-do-Liste!
Wenn das Board groß genug und das Ticketdesign deutlich genug ist, kann man von der anderen Seite des Raums erkennen:
-
Welche Arbeit gerade blockiert ist (wartet auf etwas)
-
Wer woran arbeitet
-
Welche unterschiedlichen Arten von Arbeit existieren und in welcher Verteilung
-
Wie viel Arbeit sich in welchem Grad der Fertigstellung befindet
Haben wir all diese Informationen ständig verfügbar, bekommen wir recht schnell ein Gefühl dafür, wie ein gesunder Zustand aussieht. Wenn man sich darauf einmal eingerichtet hat, lässt einen das Board sofort wissen, wenn Dinge von der Norm abgewichen sind und eine Untersuchung des Zustands oder korrigierende Maßnahmen notwendig sind.
1.1.1 Visualisierung und Veränderung
Die Visualisierung und andere Formen der Transparenz haben in Kanban einen doppelten Sinn: Zum einen soll die Notwendigkeit von Aktivität sichtbar gemacht werden und zum anderen soll den Menschen geholfen werden, gute Entscheidungen zu treffen. Beides funktioniert auf zwei Ebenen:
-
Aktivität in Form von Arbeit, die getan werden muss; gute Entscheidungen bei der Auswahl der Arbeitspakete
-
Aktivität in Form von Veränderung des Systems; gute Entscheidungen in der Rechtfertigung, im Umfang und in der Implementierung der Veränderung
Wie reagieren Sie, wenn das Board anzeigt, dass nicht alles so ist, wie es sein sollte? Hier sind einige übliche Antworten, die ein Manager oder Coach geben könnte:
-
Egal, es wird sich schon alles selbst regeln, wie es das normalerweise auch immer tut.
-
Ich werde durch ein straffes Management eingreifen, bis die Situation vorüber ist.
-
Ich werde durch eine Veränderung des Systems eingreifen.
-
Verstehen sie, wie die Dinge so gekommen sind? Wollen sie das System entsprechend verändern? Wie sollte ich ihnen helfen?
-
Ich respektiere ihre Fähigkeiten, angemessene Änderungen in dieser Situation durchzuführen.
Jede dieser Verhaltensweisen hat ihre Berechtigung, allerdings scheinen einige eine höhere Reife widerzuspiegeln als andere. Durch das Auslösen von Aktionen und das Unterstützen guter Entscheidungen führt Kanban die Menschen zu reiferem Verhalten wie in Punkt 4 oder 5. Organisationen, die diese Verhaltensweisen bewusst akzeptieren und die Führungsstile fördern, die solches Verhalten unterstützen, sind auf einem guten Weg zu höherer Reife.
Verhalten 5 (und zu einem geringeren Anteil Verhalten 4) enthält ein weiteres, sehr interessantes Element, die Selbstorganisation.
Selbstorganisation ist eine wunderbare Sache. Sie bedeutet nicht nur, dass Individuen autonom handeln können – obwohl das essenziell für ihr Wohlergehen ist. Selbstorganisation bedeutet auch, dass das System sich selbst neu organisieren und einstellen kann, um effektiver mit seinen Herausforderungen umgehen zu können. Selbstorganisation bringt in ihrer vollen Bedeutung Anpassungsfähigkeit und Resilienz. Da Selbstorganisation ohne Intervention von außen passieren kann, skaliert sie sehr gut. Sowohl für den Systembetrieb als auch für die Systemveränderung ist Selbstorganisation sowohl effektiv als auch menschenfreundlich.
Ein System zu verändern, das visuell gemanagt wird, sollte eine kostengünstige und schnelle Sache sein. Einfach eine Linie oder zwei auf dem Whiteboard ausradieren, eine weitere zeichnen und ein paar Klebezettel umherschieben (oder ein paar Klicks mit der Maus). Die Auswirkung dieser Änderungen kann sehr groß sein. Verglichen mit dem recht kleinen Implementierungsaufwand ist dieses Arbeiten am System eine Aktivität mit...
Erscheint lt. Verlag | 25.9.2015 |
---|---|
Übersetzer | Florian Eisenberg, Wolfgang Wiedenroth |
Verlagsort | Heidelberg |
Sprache | deutsch |
Themenwelt | Mathematik / Informatik ► Informatik |
Wirtschaft ► Betriebswirtschaft / Management ► Projektmanagement | |
Schlagworte | Agilität • KANBAN • Kanban Trainer • Lean Kanban University • Projektmanagement • Softwareentwicklung • Wissensarbeit |
ISBN-10 | 3-86491-805-7 / 3864918057 |
ISBN-13 | 978-3-86491-805-6 / 9783864918056 |
Haben Sie eine Frage zum Produkt? |
Größe: 6,3 MB
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: PDF (Portable Document Format)
Mit einem festen Seitenlayout eignet sich die PDF besonders für Fachbücher mit Spalten, Tabellen und Abbildungen. Eine PDF kann auf fast allen Geräten angezeigt werden, ist aber für kleine Displays (Smartphone, eReader) nur eingeschränkt geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür einen PDF-Viewer - z.B. den Adobe Reader oder 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 einen PDF-Viewer - z.B. die kostenlose Adobe Digital Editions-App.
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