Mike Burrows ist Geschäftsführer und Principal Consultant von David J. Anderson and Associates (djaa.com). In seiner beruflichen Laufbahn, die sich von der Luftfahrt über das Bankwesen, 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 eingeladen, 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 Fachrichtung 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. Wolfgang ist akkreditierter Kanban Trainer (AKT) und Kanban Coaching Professional (KCP). Außerdem ist er Co-Founder der Limited WIP Society München. Er bloggt auf agilemanic.com und twittert als @wwiedenroth.
|
Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+: www.dpunkt.de/plus |
Verstehen, einführen, anwenden
Übersetzt aus dem Englischen
von Florian Eisenberg und Wolfgang Wiedenroth
Übersetzung: |
Florian Eisenberg (post@florianeisenberg.de) |
|
Wolfgang Wiedenroth (wolfgang.wiedenroth@it-agile.de) |
Lektorat: |
Christa Preisendanz |
Copy-Editing: |
Ursula Zimpfer, Herrenberg |
Herstellung: |
Birgit Bäuerlein |
Umschlaggestaltung: |
Helmut Kraus, www.exclam.de |
Druck und Bindung: |
M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn |
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Buch 978-3-86490-253-6
PDF 978-3-86491-805-6
ePub 978-3-86491-806-3
mobi 978-3-86491-807-0
Deutsche Ausgabe der 1. amerikanischen Auflage 2015
Translation Copyright für die deutschsprachige Ausgabe © 2015 dpunkt.verlag GmbH
Wieblinger Weg 17
69123 Heidelberg
Copyright der amerikanischen Originalausgabe © 2014 by Mike Burrows
Title of American original: Kanban from the Inside
Blue Hole Press · 72 Buckhorn Road · Sequim, WA 98382 · www.blueholepress.com
ISBN 978-0-9853051-9-2
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten.
Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Für Sharon
Ich bin ein Amerikaner, der in der glücklichen Lage ist, einen ordentlichen Teil der Welt gesehen zu haben. Während meiner Reisen habe ich festgestellt, dass Amerikaner eine einzigartige Vorliebe für das Genre der »Selbsthilfe«-Bücher haben: Amerikaner lieben es, gesagt zu bekommen, dass sie etwas falsch machen und dass das atemberaubende Buch in ihren Händen den geheimen Code darüber enthält, wie sie dünner, schneller, stärker oder sogar schöner werden.
Mike ist Brite und die Welt kann sich glücklich schätzen, dass er sich entschieden hat, dieses Buch zu schreiben. Denn das Letzte, was wir brauchen, ist ein weiteres »Selbsthilfe-Software-Methode«-Buch, in dem der Autor verspricht, Entwicklungsorganisationen den geheimen Code dafür zu geben, wie ihre Leute besseren Programmcode schreiben, der besser zu den Kunden-, Stakeholder- und Marktbedürfnissen passt, mit weniger Fehlern und den aktuellsten Technologien. Das bedeutet bedauerlicherweise, dass einige Amerikaner – und möglicherweise auch einige andere, die von der Schule der »Selbsthilfe« genährt wurden – dieses Buch meiden könnten.
Das wäre äußerst schade.
In diesem ausführlichen Buch gibt uns Mike keinen Rat zur »Selbsthilfe«. Stattdessen gibt er uns etwas, was noch viel, viel mächtiger und beständiger ist: Werkzeuge und Prozesse zur Selbsterkenntnis.
Da Erkenntnis die Fähigkeit ist, das wirkliche Wesen einer Sache zu verstehen, ist Selbsterkenntnis die Fähigkeit, uns selbst zu verstehen. Aus der Perspektive dieses Buches meint das »Selbst« nicht uns als Individuen, sondern unser »Organisations-Selbst« – unser Unternehmen oder Entwicklungsteam oder unsere Entwicklungsorganisation.
Die mächtigen Werkzeuge, die Mike beschreibt – beispielsweise das Kanban-Board oder das Cumulative Flow Diagram –, werden auf der Grundlage einer Reihe von Werten eingeführt, die uns wirklich umfassende Mittel zur Verfügung stellen, um anhaltende Veränderungen zu erzielen.
Das Überraschendste ist vielleicht, dass Mike das tut, ohne zu fordern, zu beschwatzen, zu nötigen oder überhaupt darum zu bitten, dass Sie als Leser auch nur eines dieser Dinge tun. Stattdessen beginnt Mike mit einer tiefen Erkundung der Werte und zeigt uns dann, wie wir so handeln können, dass es kongruent zu diesen Werten ist. Wenn Sie diese Dinge »wert«-schätzen, werden Sie diese Aktionen umsetzen wollen. Und wenn Sie sie umsetzen, werden Sie feststellen, dass Sie beginnen, die Verbesserungen zu erzielen, die Sie die ganze Zeit haben wollten.
Luke Hohmann
Gründer und CEO der Conteneo, Inc.
Die Diskussion über die Werte von Kanban wurde emotional geführt, als Mike sie in seinem Blog publizierte. Wieso sollte Kanban Werte bekommen? Die Community hatte sicher aus den Erfahrungen gelernt, die ein Teil der Gruppe mit den Werten von Scrum (Offenheit, Mut, Respekt, Commitment, Fokus) gemacht hatte: Wenige Menschen kennen sie und noch weniger Menschen wenden sie tatsächlich auch an. Warum sollten also Werte für Kanban wichtig sein? Sie bilden eine gemeinsame Sprache, aber das tun die Grundprinzipien und -praktiken auch. Sie geben diesen beiden allerdings eine »wertvolle« Grundlage: Sie verankern das Gefühl, das Kanban-Anwender kennen, wenn sie über die Methode sprechen, in der Sprache. Die meisten Kanban-Enthusiasten wissen, wie schwer es ist, Kanban allein anhand der Praktiken und Prinzipien zu vermitteln, denn es steht immer auch eine Philosophie, eine Geisteshaltung dahinter. Die ließ sich schwer in Worte fassen – bis die Werte die Brücke zwischen den Daten und den Emotionen bildeten. Die Community diskutierte intensiv über den Zweck, die Zusammensetzung, das Hinzufügen oder Weglassen einzelner Werte. Herausgekommen sind neun Werte, die in Beziehung zu den Praktiken und Prinzipien der Kanban-Methode stehen. Dieses Buch orientiert sich stark an diesen Werten und zeigt dabei, wie eng diese Beziehung ist. Wenn wir als Kanban-Trainer oder Coaches in Unternehmen gehen und uns eine bestehende Kanban-Implementierung ansehen, erkennen wir häufig anhand der Struktur und der Stimmung bei Meetings oder schon allein anhand des Kanban-Boards, dass etwas schiefläuft: fehlende WIP-Limits, Risiken werden nicht besprochen, Kundenwünsche nicht berücksichtigt, Überlast bei einzelnen Mitarbeitern, Aufgabenzuteilung auf einzelne Mitarbeiter etc. Denn obwohl einige Praktiken von Kanban augenscheinlich implementiert wurden, klingen viele Implementierungen trotzdem blechern, wenn man dagegen klopft – bildlich gesprochen. Bei jeder Kanban-Implementierung geben uns die Werte einen Ansatzpunkt, um über unsere spezifische Interpretation der recht allgemein gehaltenen Praktiken zu urteilen: Sind wir auf den Kunden fokussiert? Fließt unsere Arbeit tatsächlich? Verstehen wir das System und die bestehende Unzufriedenheit zur Genüge? Handeln wir mit dem Einverständnis aller und respektieren wir die Menschen im System? Nachdem Sie dieses Buch gelesen und sich hoffent-lich die Werte zu eigen gemacht haben, werden Sie diese Fragen ganz natürlich für eine bestehende oder neue Implementierung stellen können. Fragen wie diese stellen erfahrene Kanban-Anwender ständig – sie sind für die richtige Implementierung der Prinzipien und Praktiken ungemein hilfreich und wichtig.
In der Reflexion über die Werte und ihre Anwendung liegt viel Lernpotenzial. Auch wir beide haben während der Bearbeitung des Buches wieder viele neue Aspekte und Interpretationen der Kanban-Methode gefunden. Ihnen wird das Buch natürlich nicht nur die Werte vermitteln, sondern auch den aktuellsten Stand der Kanban-Methode. Falls Sie die Methode bereits anwenden, aber die Werte noch nicht kennen, wird Ihnen das Buch einen neuen Blick auf Kanban bescheren. Und auch wenn bei der täglichen Arbeit selten die Zeit vorhanden ist, um über die Prozesse und ihre Anwendung zu reflektieren: Es lohnt sich, mit neuem Blick auf die eigene Arbeit zu schauen. Die Kanban-Methode sieht diese Feedbackzyklen zum Glück explizit vor!
Wir wünschen Ihnen viel Erfolg und freuen uns über einen Dialog mit Ihnen!
Florian Eisenberg |
Wolfgang Wiedenroth |
post@florianeisenberg.de |
wolfgang.wiedenroth@it-agile.de |
Hamburg, Juli 2015 |
|
Vielleicht haben Sie schon von Menschen mit T-förmiger Qualifikation gehört. Nun, dies ist ein T-förmig qualifiziertes Buch! Es besitzt in seinem Kern die Tiefe, die man erwartet, gleichzeitig aber auch eine gewisse Breite. Seine Tiefe bezieht sich natürlich auf die Kanban-Methode: Was sie ist; wie Anwender denken; Ratschläge, wie man sie anwendet; und so weiter. Die Breite kommt in Form einiger wichtiger Referenzpunkte außerhalb der Methode hinzu. Diese sind hoffentlich sowohl für die hilfreich, die Kanban noch nicht verwenden und von außen hineinsehen, als auch für jene, die Kanban anwenden und auf der Suche nach frischen Quellen der Inspiration sind.
Ich habe es mir zur Aufgabe gemacht, die »menschliche ›Beginne mit dem, was du gerade tust‹-Vorgehensweise für Veränderung« nicht als Produktivitätswerkzeug zu beschreiben, sondern als Managementmethode. Eine Methode, die um ein starkes Framework von Werten herum gebaut ist. Sie ist ein Weg, um Organisationen zu helfen, besser für ihre Mitarbeiter, Kunden und Stakeholder zu arbeiten.
Eine wichtige Eigenschaft dieser Managementmethode ist, dass sie auf vielen verschiedenen Ebenen angewendet werden kann: von der Ebene einzelner und kleiner Teams bis ganz nach oben zu strategischen Businessinitiativen. Seien Sie also nicht überrascht, wenn wir uns innerhalb weniger Abschnitte von einer Ebene auf die andere bewegen. Die Einfachheit, mit der das möglich ist, gibt schon eine deutliche Vorstellung davon, wie die Kanban-Methode funktioniert.
Ich schreibe als erfahrener Manager mit einem ausgeprägten technischen Hintergrund. In den vergangenen Jahren bin ich Entwicklungsleiter von Teams auf vier Kontinenten, Geschäftsführer, IT-Leiter und Interimsmanager gewesen. Es ist schon einige Zeit her, dass ich dafür bezahlt wurde, Anwendungen zu programmieren. Es ist aber immer noch eine meiner Leidenschaften und auch heute noch zieht es mich in Diskussionen über Systemarchitektur und Design.
Natürlich lässt sich das Buch ein wenig leichter lesen, wenn man etwas Wissen über die Softwareentwicklung besitzt, es ist aber keinesfalls eine Voraussetzung. Genauso werde ich keine Annahmen über Kenntnisse in Bereichen wie Lean und Agile treffen – dazu kommen wir, wenn wir sie brauchen. Sie sollten vielmehr eine Art professioneller Neugier über das Management kreativer Wissensarbeit mit mir teilen und wie ich daran interessiert sein, wie man diese für alle Betroffenen verbessern kann.
Das Buch ist in drei Hauptteile gegliedert:
Teil I stellt die Kanban-Methode (oder auch nur »Kanban«) auf eine neue Art vor – mit einem System von neun Werten. Ich begann Anfang 2013, über die Werte zu schreiben, und sie sind seitdem das Herzstück meiner Arbeit. Teil I schließt mit zwei noch jüngeren Konzepten: den drei Agenden und der Kanban-Linse. Die Agenden sind das Ergebnis der Zusammenarbeit mit meinem Freund und Kollegen David J. Anderson (dem Urheber der Kanban-Methode), die Kanban-Linse stammt von David direkt.
In Teil II geht es um Breite. Statt zu behaupten, alle Antworten zu haben, beinhaltet die Kanban-Methode in einer ihrer Kernpraktiken den Term »unter Verwendung von Modellen«. Diese wenigen Worte ermutigen Anwender dazu, Anleihen aus anderen etablierten Wissensgebieten zu machen. Diese beinhalten Systemdenken, Lean, Agile und die Engpasstheorie, aber es gibt viele weitere, aus denen man wählen kann. Es ist nicht möglich, alle eingehend zu behandeln, aber ich hoffe, dass meine Kanban-zentrierte Perspektive dazu führt, dass Sie diese weiter erforschen und in Ihr Denken integrieren.
Teil III beschreibt einen wiederholbaren Prozess, um die Kanban-Methode in einer Organisation zu implementieren. David nennt diesen Prozess STATIK oder »Systems Thinking approach to introducing Kanban«. STATIK stellt das Rückgrat unserer Basisschulung zu Kanban dar. Ich habe den Prozess aktualisiert, indem ich ihn mit den Agenden und Werten aus Teil I zusammengeführt habe und einige Modelle aus Teil II explizit referenziere.
Es ist Ihnen vielleicht schon aufgefallen, dass ich Kursivschrift verwende, wenn ich ein Wort oder eine Phrase bewusst als technischen Ausdruck verwende – beginne mit dem, was du gerade tust zum Beispiel ist Kanbans erstes Grundprinzip; Serious Games bezieht sich auf etwas Wohldefiniertes. Viele dieser Begriffe und Ausdrücke finden sich im Glossar wieder. Begriffe wie Balance und Kundenfokus, die fett gedruckt sind, beziehen sich auf die Werte von Kanban.
Teil I Kanban durch seine Werte verstehen
1 Transparenz
2 Balance
3 Kooperation
Reflexion: Transparenz, Balance und Kooperation
4 Kundenfokus
5 Arbeitsfluss
6 Führung
Reflexion: Kundenfokus, Arbeitsfluss und Führung
7 Verständnis
8 Vereinbarung
9 Respekt
10 Muster und Agenden
Teil II Modelle
11 Systemdenken, Komplexität und die lernende Organisation
12 Engpasstheorie (TOC)
13 Agile
14 TPS und Lean
15 Ökonomische Ansätze zum Arbeitsfluss
16 Die Kanban-Methode
17 Kleinere Modelle
Teil III Implementierung
18 Quellen der Unzufriedenheit erkennen
19 Anforderungen und Leistungsfähigkeiten analysieren
20 Den Workflow modellieren
21 Serviceklassen finden
22 Kanban-Systeme gestalten
23 Ein Kanban-System einführen
Anhang
A Demings 14 Punkte für gutes Management
B Danksagung
C Glossar
D Literatur
Index
Teil I Kanban durch seine Werte verstehen
1 Transparenz
1.1 Kernpraktik 1: Visualisiere
1.1.1 Visualisierung und Veränderung
1.2 Kernpraktik 4: Mache Prozessregeln explizit
1.2.1 Prozessregeln und Veränderung
1.3 Kernpraktik 5: Implementiere Feedbackzyklen
1.3.1 Das Standup-Meeting
1.3.2 Replenishment-Meetings
1.3.3 Weitere Meetings
1.3.4 Feedbackzyklen, die auf Metriken basieren
1.4 Transparenz als Wert
2 Balance
2.1 Kernpraktik 2: Parallele Arbeit (Work in Progress, WIP) limitieren
2.2 Pull-Systeme in der Wissensarbeit
2.3 Balance zwischen Arbeitslast und Kapazität
2.4 Andere Möglichkeiten, WIP zu limitieren
2.5 Balance zwischen dringlichkeits- und termingetriebener Arbeit
2.6 Risikobasierte Kategorisierung und Serviceklassen
2.7 Balance zwischen Anforderungen und Leistungsfähigkeit
2.8 Stakeholder-Balance
2.9 Balance suchen
3 Kooperation
3.1 Kernpraktik 6: Erziele Verbesserung kooperativ und entwickle experimentell
3.2 Kooperation ist eine ernste Sache
3.3 Erziele Verbesserung kooperativ
3.4 Zu Kooperation ermutigen
3.5 Fokus auf Kooperation legen
3.6 Entwickle experimentell
3.7 Die und wir
Reflexion: Transparenz, Balance und Kooperation
4 Kundenfokus
4.1 Kernpraktik 3: Manage den Arbeitsfluss
4.2 Warum Kundenfokus?
4.3 Zufriedenheit garantiert
4.4 Quer über das Board
4.5 Upstream-Kanban
4.6 Bedürfnisse vorwegnehmen
5 Arbeitsfluss
5.1 Kernpraktik 3: Manage den Arbeitsfluss (nochmal)
5.2 Gleichmäßigkeit
5.2.1 Wie sieht Arbeitsfluss aus?
5.3 Quer über das Board (nochmal)
5.4 Es gibt immer einen größeren Kontext
5.5 Einige einfache Beispiele
5.6 Arbeitsfluss quer durch die Organisation
5.7 Arbeitsfluss managen, um Pünktlichkeit zu erzielen
6 Führung
6.1 Grundprinzip 4: Führung auf allen Ebenen
6.2 Möglichkeiten finden sich überall
6.3 Führung erzeugt Führung
6.4 Warum Führung wertschätzen?
6.5 Wie sieht Führung in Kanban aus?
Reflexion: Kundenfokus, Arbeitsfluss und Führung
7 Verständnis
7.1 Änderungen ohne Verständnis – drei Anti-Pattern
7.1.1 Selbstzufriedenheit
7.1.2 Draufgängertum
7.1.3 Einmischung
7.2 Einführung der J-Kurve
7.3 Ein Muster für zielgerichtete Veränderung
8 Vereinbarung
8.1 Verfolge evolutionäre Veränderung
8.2 Vereinbare das Verfolgen
8.3 Change Management
8.3.1 Der Change Agent
8.3.2 Der betreute Change Agent
8.3.3 Das Change-Team
9 Respekt
9.1 Fange nicht bei den Rollen an
9.2 »Sei wie Wasser«
9.3 Respekt für Menschen
9.3.1 Transparenz
9.3.2 Balance
9.3.3 Kooperation
9.3.4 Kundenfokus
9.3.5 Arbeitsfluss
9.3.6 Führung
9.3.7 Verständnis
9.3.8 Vereinbarung
9.4 Die menschliche »Beginne mit dem, was du gerade tust«-Methode
10 Muster und Agenden
10.1 »Noble Muster«
10.2 Agenden für Veränderung
10.3 Die Nachhaltigkeits-Agenda
10.4 Die Serviceorientierungs-Agenda
10.4.1 Die Kanban-Linse
10.5 Die Überlebensfähigkeits-Agenda
10.6 Die Agenda Ihrer Organisation
10.7 Wie erging es uns?
10.8 Fünf Jahre später
Teil II Modelle
11 Systemdenken, Komplexität und die lernende Organisation
11.1 Systemdenken
11.1.1 Hebelpunkte und Systemdynamiken
11.2 Komplexität
11.2.1 Kausalität und das Cynefin-Framework
11.2.2 Komplexe adaptive Systeme
11.3 Wissen, lernen und die lernende Organisation
11.3.1 Demings System vom umfassenden Wissen
11.3.2 Argyris und das Doppelschleifen-Lernen
11.3.3 Die lernende Organisation
11.4 Systemdenken und Kanban
11.4.1 Das Design der Methode
11.4.2 Anwendung
12 Engpasstheorie (TOC)
12.1 Die fünf Fokussierungsschritte und der Process of Ongoing Improvement (POOGI)
12.2 Drum-Buffer-Rope (DBR)
12.3 Thinking Processes – Denkprozesse
12.4 Critical-Chain-Projektmanagement (CCPM)
12.5 Throughput Accounting – Durchsatzrechnung
12.6 Die Beziehung von TOC zu Kanban
12.6.1 POOGI und die fünf Fokussierungsschritte
12.6.2 DBR und CCPM
12.6.3 Die Denkprozesse
12.7 Dennoch ...
13 Agile
13.1 Drei agile Methoden
13.1.1 Feature-Driven Development (FDD)
13.1.2 Extreme Programming (XP)
13.1.3 Scrum
13.2 Kanban und Agile
13.2.1 Kompatibilität
13.2.2 Wann ist Kanban zu benutzen?
13.3 Das Modell Agile
14 TPS und Lean
14.1 Drei Lean-Werkzeuge
14.2 TPS und Lean im richtigen Licht
14.3 Verbesserungen bei Lean
14.4 Lean Product Development
14.5 Lean Startup
14.6 Lean/Agile-Hybriden
14.7 Kanban und Lean
15 Ökonomische Ansätze zum Arbeitsfluss
15.1 ROI und die Pareto-Diät
15.2 Verzögerungskosten
15.2.1 Die Kosten von Warteschlangen
15.3 Haltekosten
15.4 Optionen
15.4.1 Optionen haben einen Wert
15.4.2 Optionen verfallen
15.4.3 Binde dich nie frühzeitig, es sei denn, du weißt warum
15.5 Alles zusammengeführt
16 Die Kanban-Methode
16.1 Eine sehr kurze Historie
16.2 Grundprinzipien
16.3 Kernpraktiken
16.4 Kontextualisiertes Kanban
16.4.1 Personal Kanban
16.4.2 Portfolio-Kanban
16.4.3 Scrumban
16.5 Unterstützende Konzepte und Werkzeuge
16.6 Implementierungshilfe: STATIK
17 Kleinere Modelle
17.1 Zwei, die davongekommen sind
17.1.1 Littles Gesetz
17.1.2 Das Satir-Modell für Veränderung
17.2 Denkwerkzeuge und Coaching-Modelle
17.2.1 GROW
17.2.2 A3
17.2.3 Exkurs: Wie ein Profi überprüfen!
17.2.4 Der Lean Change Canvas
17.3 Gruppenmoderation und Spiele
17.3.1 Kaners Moderationsmodell
17.3.2 Serious Games
17.4 Modelle für kooperative Führung: Triaden und T-Formen
Teil III Implementierung
18 Quellen der Unzufriedenheit erkennen
18.1 Zwei Perspektiven
18.2 Zwei Fragen
18.3 Formate
18.4 Organisiere und erforsche
18.5 Folgemaßnahmen
19 Anforderungen und Leistungsfähigkeiten analysieren
19.1 Wissen, was Sie wem liefern und warum
19.1.1 Was
19.1.2 Wem
19.1.3 Warum
19.2 Quantitative Analyse
19.2.1 Flusseffizienz
19.3 Wie Arbeit ankommt
19.4 Passt alles zusammen?
20 Den Workflow modellieren
20.1 Grob aufzeichnen
20.2 Top-down-Dekomposition
20.3 Bottom-up-Organisation
20.4 Fazit
21 Serviceklassen finden
21.1 Entdecken, überprüfen
21.2 Beispiele
21.3 In Richtung einer gesunden Arbeitszusammenstellung
22 Kanban-Systeme gestalten
22.1 Umfang, Granularität und Status der Arbeitseinheiten
22.1.1 Aufeinanderfolgende Status
22.1.2 Parallele Status
22.1.3 Fehler
22.1.4 Abhängigkeiten
22.2 Andere Dimensionen
22.3 Hierarchische Boards und das Aufbrechen/Zusammenführen-Muster
22.4 Work in Progress limitieren
22.5 Review
23 Ein Kanban-System einführen
23.1 Den Einsatz planen
23.2 Die Agenda zusammenstellen: die drei P
23.2.1 Positionierung
23.2.2 Zweck (Purpose)
23.2.3 Prioritäten
23.3 Veränderung durch das System vorantreiben
23.3.1 Veränderungsinkremente identifizieren
23.3.2 Veränderung visualisieren
23.4 Abschließende Gedanken
Anhang
A Demings 14 Punkte für gutes Management
B Danksagung
C Glossar
D Literatur
Weiterführende Literatur zu einzelnen Themen
Index
Kanban durch seine Werte verstehen
Die Herangehensweise, die ich zur Einführung von Kanban wähle, ist ein wenig unüblich, denn meist wird Kanban durch die Grundprinzipien und Kernpraktiken erklärt. Ich gehe einen halben Schritt zurück und beginne bei einem System von neun Werten. In der Reihenfolge der ersten neun Kapitel in Teil I sind dies die Werte Transparenz, Balance, Kooperation, Kundenfokus, Arbeitsfluss (Flow), Führung (Leadership), Verständnis, Vereinbarung und Respekt.
Durch diese Vorgehensweise entfallen keine Prinzipien und Praktiken von Kanban; jedes Kapitel referenziert eine oder mehrere direkt.
Der Einfachheit halber kennzeichne ich die Grundprinzipien als GP1 – 4:
GP1: Beginne mit dem, was du gerade tust.
GP2: Vereinbare, dass evolutionäre Veränderung verfolgt wird.
GP3: Respektiere initial bestehende Prozesse, Rollen, Verantwortlichkeiten und Jobtitel.
GP4: Ermutige dazu, Führung auf jeder Ebene der Organisation zu zeigen – vom einzelnen Mitarbeiter bis zum höheren Management.
Ebenso bezeichnen KP1 – 6 die sechs Kernpraktiken:
KP1: Visualisiere.
KP2: Limitiere die Menge paralleler Arbeit (Work in Progress, WIP).
KP3: Manage den Arbeitsfluss.
KP4: Mache Prozessregeln explizit.
KP5: Implementiere Feedbackzyklen.
KP6: Erziele Verbesserung kooperativ, entwickle experimentell (unter Verwendung von Modellen und der wissenschaftlichen Methode).
Statt eine detaillierte technische Rechtfertigung für jede Technik darzustellen, hoffe ich, einen Einblick geben zu können, der erklärt, wie Kanban-Anwender organisatorische Probleme angehen. Mit Kanban-Anwendern meine ich Manager, Mitarbeiter und externe Experten, die die Methode kennen und anwenden. Die Werte helfen, die Intention der Prinzipien und Praktiken zu betonen, sodass Sie sie einfacher mit den Bedürfnissen Ihrer aktuellen Organisationssituation übereinbringen können.
Das zehnte und letzte Kapitel des ersten Teils fügt die 10 Werte in drei Agenden zusammen und führt ein weiteres nützliches Werkzeug ein, die KanbanLinse.
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.
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.
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 sehr großem Hebel.
Hier ist ein positiver Kreislauf im Spiel:
Das Kanban-System organisiert die Arbeit.
Die Menschen organisieren sich um die Arbeit herum.
Aus ihrer neuen Perspektive sehen die Menschen, dass das Kanban-System die Arbeit besser organisieren könnte, als es das im Moment tut, und sie verändern es.
Kanban-Boards sind sehr effektiv darin, Arbeit zu organisieren, aber einige Aspekte des Systems werden manchmal nicht optimal durch die visuelle Sprache von Tickets, Farben, Spalten und Ähnlichem beschrieben. Manchmal machen ein paar wenige Worte in Form von Prozessregeln den Unterschied. Es handelt sich dabei nicht um Verordnungen von oben: Vielmehr sind sie ein Weg, um zwischen den Teilnehmern ein gemeinsames Verständnis darüber aufrechtzuerhalten, wie das System betrieben wird.
Ein weiterer Aspekt der Transparenz: Parallel zur Strategie, das Unsichtbare sichtbar zu machen, machen wir das Implizite explizit, und zwar dann (und nur dann), wenn wir glauben, dass es uns hilft, bessere und vorhersagbarere Entscheidungen zu treffen. Auch hier möchten wir einen Hebel ansetzen – wenige Worte, die vorsichtig ausgewählt werden, um die Absicht darzulegen, keine dicken Dokumente, die alle Eventualitäten abdecken. Ich habe schon Prozessregeln gesehen, die so kurz waren wie »Demo!« und über der betroffenen Spalte auf dem Board gehängt waren – das war alles, was benötigt wurde, um eine effektive Vereinbarung über die Arbeitsweisen zu stützen.
Viele Prozessregeln beschreiben, welche Kriterien Arbeitspakete erfüllen sollen, wenn sie eine Spalte erreichen oder sie verlassen, zum Beispiel:
Tickets in der »Bereit«-Spalte sollten nicht mehr als fünf Tage Arbeit in der Entwicklung benötigen. In Budapest nannten wir sie die »Fünf-Tage-Regel«; später wurde sie zur »Zwei-Tage-Regel.«
Tickets dürfen nicht in die »Test«-Spalte rutschen, bis sie ein Peer-Review absolviert haben und die Ergebnisse dem Team demonstriert wurden.
Auf unserem Board waren Stichworte wie »< 5 Tage Implementierung«, »Codereview« und »Demo!« als Erinnerung an die Erwartung des Teams absolut ausreichend.
Andere Prozessregeln können auch globalerer Natur sein:
Die Stabilität der Produktionsumgebung hat eine höhere Priorität als das Lösen von Fehlern in der Qualitätssicherung; beide haben höhere Priorität als Neuentwicklungen.
Wird ein neues Stück Arbeit gezogen, wird der Auftraggeber informiert, falls es wahrscheinlich ist, dass es Auswirkung auf bestehende Arbeit hat.
Diese Beispiele für Prozessregeln sind nicht universal anwendbar, aber sie können einfach in vergleichbare Kontexte übernommen werden. Das ist nicht untypisch. Manchmal existiert ein unterliegendes Prinzip, das sich leichter übertragen lässt als die Regel – »Das Lernen feiern« statt »Kuchen essen« zum Beispiel. Es ist aber auch keine Schande, wenn eine Regel komplett einmalig für die Situation ist. Der Kontext ist wichtig!
Wir fügen Prozessregeln hinzu, wenn wir glauben, dass die zusätzliche Klarheit uns dabei helfen wird, bessere Entscheidungen zu treffen oder diese effizienter zu treffen. Das ist häufig ein guter Zeitpunkt, um die darunterliegenden Denkweisen zu diskutieren, wie zum Beispiel:
Große Arbeitspakete haben verglichen mit kleineren eine überproportional große Wahrscheinlichkeit, problematisch zu sein. (Das könnte auch mehr als nur ein Bauchgefühl sein – wir könnten Daten haben, die diese Hypothese belegen.)
Allgemein gesagt ist es besser, etwas fertigzustellen als etwas weiteres Neues zu beginnen. (Das könnte als hausgemachte Lebensweisheit anerkannt sein – »Stop starting, start finishing!« – oder auf solider Theorie aufgebaut sein.)
Indem wir Prozessregeln explizit machen, erzwingen wir, dass das darunterliegende Denken überprüft wird. Passt die Realität nicht zu unserem Denken, sind wir ständig dabei, uns an den Regeln zu reiben. Das erzeugt Unbehagen, aus dem eine Reevaluation und weiteres Lernen entsteht.
Aus diesem Grund ist es gut, mit einfachen Prozessregeln zu beginnen, die die aktuelle Praxis wiedergeben (das, was wirklich in den meisten Fällen getan wird, unabhängig von den offiziellen Regeln), und von dort aus nach Bedarf zu verfeinern. Beginne mit dem, was du gerade tust ergibt hier genauso viel Sinn wie auch sonst. Schreib sie nieder, dann stelle dich der Herausforderung. Ist es immer sinnvoll, hier eine Demo zu machen? Könnte diese Zehn-Tage-Aufgabe vielleicht trotz allem doch okay sein?
Diese Strategie – vorher implizite Dinge explizit zu machen – bezieht sich auch auf die Kanban-Methode selbst. Das Vorhandensein von Feedbackzyklen und ihre Implementierung waren so offensichtlich, dass niemand daran dachte, sie im ursprünglichen Entwurf der Methode mit aufzunehmen.
Trotzdem sie anfangs ausgelassen wurden, sind Feedbackzyklen essenziell. Ohne frühes Feedback werden Anzeichen, dass das System ungesund ist, übersehen. Oder sie werden ignoriert oder so halbherzig adressiert, dass niemand sicher ist, ob wir wirklich eine Verbesserung erzielt haben. Feedbackzyklen sind deshalb essenziell, damit Transparenz zu einem effektiven Treiber für die Veränderung gemacht werden kann.
Wie bei »Visualisiere« ist viel Platz für Interpretation und kreative Implementierung in der Formulierung dieser Praktik. Das ist Absicht. Um es etwas konkreter zu machen, schauen wir uns drei allgemein implementierte Beispiele für Meetings an, die regelmäßig die Möglichkeit für verschiedene Arten von Feedback bieten. Wir beenden diesen Abschnitt mit Feedbackzyklen, die auf Metriken basieren.
Sollte ich eine agile Praktik vor allen anderen empfehlen, so wäre es diese. Ich habe erlebt, wie Teams Standup-Meetings abschaffen, weil sie ihren Wert nicht erkennen, um sie dann nur wenige Tage oder Wochen später wieder einzuführen, wenn die Dinge langsam auseinanderfallen. Vielleicht macht gerade die Vertrautheit mit dieser Praktik es so einfach, den Wert dahinter zu übersehen.
Standup-Meetings sind kurze Treffen – kurz genug, dass alle Teilnehmer für die Dauer komfortabel stehen können (oder sollten) –, die regelmäßig durchgeführt werden (häufig täglich). Die Geschwindigkeit kommt mit der Übung: den Ablauf kennen, Aktualisierungen auf einem angemessenen Detailniveau darstellen und die Disziplin besitzen, Konversationen auf danach zu vertagen.
Standup-Meetings können verschiedene Formen haben:
