Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: dpunkt
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2011
Software-Kanban ist ein Change-Management-Ansatz, der Ideen aus dem Lean Thinking und der Engpasstheorie verbindet und die kontinuierliche Verbesserung in IT-Organisationen vorantreibt. Software-Kanban lässt sich evolutionär in kleinen Schritten einführen und führt schnell zu kürzeren Durchlaufzeiten, besserer Qualität, gleichmäßiger Arbeitsbelastung und höherer Kundenzufriedenheit. In diesem Buch hat David J. Anderson, "Vater" von Software-Kanban, seine Erfahrungen mit dem Einsatz dieser evolutionären Methode aus verschiedenen großen Softwareprojekten (Microsoft, Motorola) zusammengetragen.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 442
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Kanban
David J. Anderson leitet eine Beratungsfirma, die sich darauf konzentriert, die Leistungsfähigkeit von IT-Unternehmen zu verbessern. Seit beinahe 30 Jahren arbeitet er in der Softwareentwicklung und hat dabei Teams in agilen Entwicklungsprojekten bei Sprint, Motorola, Microsoft und Corbis gemanagt. Die erste Kanban-Implementierung für Softwareentwicklung im Jahre 2005 geht auf ihn zurück. David Anderson ist einer der Begründer agiler Softwareentwicklung, indem er mitgeholfen hat, Feature Driven Development zu entwickeln. Darüber hinaus hat er das Agile Project Leadership Network (APLN) gegründet, ist Erstunterzeichner der Declaration of Independence und Gründungsmitglied des Lean Software and Systems Consortium. Er moderiert mehrere Online-Communitys zu den Themen agile bzw. lean Softwareentwicklung. Und er ist Autor des Buches Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. In letzter Zeit hat er sich darauf konzentriert, Synergien zwischen dem CMMI-Modell für organisatorische Reife und agilen bzw. lean Methoden herzustellen, indem er Projekte mit Microsoft und dem SEI (Software Engineering Institute) durchgeführt hat. Er ist Koautor des Papers CMMI and Agile: Why not Embrace Both!, das vom SEI herausgegeben wurde.
Zu Hause ist David Anderson in Sequim, Washington, USA.
Übersetzer:
Arne Roock ist Prokurist bei it-agile GmbH in Hamburg. Er beschäftigt sich seit Längerem mit Lean Thinking und Software-Kanban und hat zahlreiche Artikel zu diesen Themen publiziert. Seine aktuellen Überlegungen veröffentlicht er in seinem Blog www.software-kanban.de
Henning Wolf ist Geschäftsführer der it-agile GmbH in Hamburg. Er verfügt über langjährige Erfahrung aus agilen Softwareprojekten (eXtreme Programming, Scrum, FDD) als Entwickler, Projektleiter und Berater.
David J. Anderson
Kanban
Evolutionäres Change Management fürIT-Organisationen
Übersetzt aus dem Amerikanischenvon Arne Roock und Henning Wolf
Übersetzung:
Arne Roock ([email protected])
Henning Wolf ([email protected])
Lektorat:
Christa Preisendanz
Copy-Editing:
Ursula Zimpfer, Herrenberg
Herstellung:
Birgit Bäuerlein
Umschlaggestaltung:
Helmut Kraus, www.exclam.de
Druck und Bindung:
Media-Print Informationstechnologie, Paderborn
Fotos auf S. 13/14 mit freundlicher Genehmigung von Thomas Blomseth
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-89864-730-4
PDF 978-3-86491-027-2
ePub 978-3-86491-028-9
Deutsche Ausgabe der 1. amerikanischen Auflage 2011
Translation Copyright für die deutschsprachige Ausgabe © 2011 dpunkt.verlag GmbH
Ringstraße 19 B
69115 Heidelberg
Copyright der amerikanischen Originalausgabe © 2010 by David J. Anderson
Title of American original: Kanban: Successful Evolutionary Change for Your Technology Business
Blue Hole Press · 72 Buckhorn Road · Sequim, WA 98382 · www.blueholepress.com
ISBN 978-0-9845214-0-1 (paperback)
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 Nicola und Natalie
Vorwort zur deutschen Ausgabe
Als wir David im Frühjahr 2009 kennenlernten und die erste Schulung mit ihm durchführten, war Software-Kanban weitgehend unbekannt. In Deutschland hatte höchstens eine Handvoll Leute jemals davon gehört, und auch international gab es nur eine kleine Kanban-Community. Damals war es ohne Weiteres möglich, alle Artikel, Blogs, Tweets und Nachrichten auf der Mailingliste zu lesen – und oft wünschten wir uns, es hätte mehr Informationen gegeben.
Heute, gerade mal zwei Jahre später, hat sich die Situation komplett geändert: Kanban ist in aller Munde! Inzwischen haben sich auch die größeren deutschen Softwarekonferenzen des Themas angenommen, und in den einschlägigen deutschsprachigen Zeitschriften sind schon etliche Artikel erschienen. Heute kann kaum noch jemand alle Blog-Posts, Tweets oder Mails zum Thema Kanban lesen, denn es sind einfach zu viele – und täglich werden es mehr. Dass Kanban in so kurzer Zeit so populär geworden ist, liegt natürlich zum großen Teil an der Eleganz und Einfachheit, mit der bei Kanban zu Werke gegangen wird. Es liegt aber auch an dem unermüdlichen Einsatz von David, der ein unglaubliches Reisepensum absolviert, um Kanban auf der ganzen Welt bekannt zu machen und seinen Enthusiasmus an andere weiterzugeben!
Wo viel Licht ist, da ist bekanntlich auch viel Schatten, und mit der wachsenden Popularität von Kanban bleibt es nicht aus, dass inzwischen auch viel Unsinn über dieses Thema verbreitet wird. Ein Gerücht, das nicht tot zu kriegen ist, besagt, Software-Kanban stelle den Versuch dar, Techniken aus der Automobilproduktion auf die Softwareentwicklung zu übertragen, und sei deshalb von vornherein zum Scheitern verurteilt. Natürlich ist Softwareentwicklung (und -wartung) etwas anderes als Fertigung, und niemand, der jemals in einem Softwareprojekt gearbeitet hat, wird dies ernsthaft bestreiten. Aber wie zahlreiche Erfahrungsberichte inzwischen zeigen, lassen sich viele grundlegende Prinzipien der Lean Production sehr wohl gewinnbringend auf die Softwareentwicklung übertragen. Pull gehört ebenso zu diesen Prinzipien wie die Begrenzung paralleler Arbeit (Work in Progress) und eine kontinuierliche Verbesserung (Kaizen).
Ein weiterer Streit, der an der eigentlichen Diskussion vorbeigeht, entzündet sich an den regelmäßig wiederkehrenden Debatten, ob Kanban besser oder schlechter als Scrum sei. Wie Henrik Kniberg es einmal ausgedrückt hat, könnte man genauso gut fragen: »Was ist besser: Messer oder Gabel?« Manchmal braucht man ein Messer, manchmal eine Gabel, manchmal beides und manchmal keins von beiden! Scrum und Kanban sind keine Widersprüche, denn Scrum ist ein Management-Framework, und Kanban ist ein Vorgehen, um evolutionäre Veränderungen herbeizuführen. Diese Veränderungen können Scrum genauso betreffen wie das Wasserfallmodell oder »Entwicklung-auf-Zuruf«.
Davids Buch kommt genau zur rechten Zeit, um Klarheit in diese und viele andere Fragen rund um Kanban zu bringen. Dabei merkt man von der ersten Seite an, dass David über ein unglaubliches Wissen zu Themen wie Lean Management, agile Softwareentwicklung und der Engpasstheorie verfügt, dass er aber alles andere als ein Theoretiker ist. Sämtliche Konzepte, die er in diesem Buch vorstellt, sind in realen Projekten entstanden und haben sich inzwischen auch anderswo bewährt.
Ganz besonders freuen wir uns, dass Markus Andrezak für die deutsche Ausgabe dieses Buches einen Erfahrungsbericht von mobile.international beigesteuert hat. Markus saß im April 2009 gemeinsam mit uns in der ersten deutschen Kanban-Schulung bei David und war sofort Feuer und Flamme für die Ideen, die uns dort präsentiert wurden. Schon kurze Zeit später ist er ins kalte Wasser gesprungen und hat die Konzepte bei mobile.international umgesetzt – mit beachtlichen Resultaten! Seitdem gibt es einen regen und fruchtbaren Austausch zwischen uns, durch den wir gegenseitig aus unseren Erfahrungen mit Kanban lernen. Markus hat darüber hinaus vorab große Teile der deutschen Ausgabe gelesen und war uns mit seinem Feedback eine große Hilfe, auch dafür danken wir ihm!
Wir wünschen Ihnen viel Spaß beim Lesen und viel Erfolg bei der Einführung von Kanban!
Und wir würden uns sehr freuen, wenn Sie uns Feedback zu Ihren eigenen Erfahrungen mit Kanban geben würden.
Hamburg, November 2010
Geleitwort
Ich habe stets ein Auge auf die Arbeit von David Anderson. Mein erster Kontakt zu ihm kam zustande, als er mir im Oktober 2003 sein Buch Agile Management for Software Engineering: Applying Theory of Constraints for Business Results zuschickte. Wie sich schon am Titel zeigt, ist dieses Buch stark durch Eli Goldratts Theory of Constraints (TOC) beeinflusst. Später, im März 2005, besuchte ich ihn bei Microsoft, wo er eine beeindruckende Arbeit mit Cumulative Flow Diagrams leistete. Noch später, im April 2007, hatte ich die Möglichkeit, mir das unglaubliche Kanban-System anzusehen, das er bei Corbis eingeführt hatte.
Ich beschreibe diese Chronologie, um Ihnen einen Eindruck davon zu vermitteln, mit welch unerbittlicher Geschwindigkeit sich Davids Managementdenken weiterentwickelt hat. Er verrennt sich nicht in eine einzelne Idee, um zu versuchen, die Welt dann für diese Idee zurechtzustutzen. Stattdessen konzentriert er sich auf das grundlegende Problem, das er zu lösen versucht, bleibt offen für verschiedene mögliche Lösungen, testet sie in der Praxis und reflektiert, warum sie funktionieren. Die Ergebnisse seines Ansatzes sehen Sie in diesem Buch.
Geschwindigkeit ist natürlich dann am nützlichsten, wenn sie in die richtige Richtung zielt. Ich bin sicher, dass David die korrekte Richtung eingeschlagen hat. Ich bin besonders begeistert von seinen neueren Arbeiten mit Kanban-Systemen. Für die Produktentwicklung hatte ich die Ideen der Lean Production immer nützlicher gefunden als die TOC. 2003 schrieb ich an David: »Eine der großen Schwächen der TOC ist, dass sie die Bedeutung von Losgrößen unterschätzt. Wenn die oberste Priorität darin besteht, den Engpass aufzuspüren und zu beseitigen, dann löst man oft das falsche Problem.« Davon bin ich noch immer überzeugt.
Bei unserem Treffen 2005 schlug ich David noch einmal vor, den Fokus nicht mehr so sehr auf Engpässe zu legen, wie es die TOC tut. Ich erklärte ihm, dass der herausragende Erfolg des Toyota-Produktionssystems (TPS) nichts mit dem Aufspüren und Erweitern von Engpässen zu tun hatte. Die Verbesserungen bei Toyota resultierten aus der Reduzierung der Losgrößen sowie der Verringerung der Variabilität, um den Work in Progress (WIP) zu reduzieren. Die ökonomischen Vorteile sind durch die Reduzierung der Lagerbestände gekommen, und es waren Systeme wie Kanban, die dies möglich machten, weil sie den Work in Progress begrenzten.
Als ich 2007 Corbis besuchte, konnte ich eine beeindruckende Kanban-Implementierung beobachten. Ich erklärte David, dass er viel weiter gegangen war als der Kanban-Ansatz, wie er bei Toyota verwendet wurde. Was meinte ich damit? Das Toyota-Produktionssystem ist auf geschickte Weise optimiert, um mit wiederkehrenden und vorhersagbaren Aufgaben umzugehen – Aufgaben mit gleicher Dauer und gleichen Verzugskosten. Unter diesen Bedingungen ist es angemessen, Ansätze wie die Priorisierung nach dem Schema first-in-first-out (FIFO) einzusetzen. Ebenso angemessen ist es, die Eingabe neuer Aufgaben zu blockieren, wenn das WIP-Limit erreicht ist. Diese Ansätze sind allerdings nicht optimal, wenn wir mit nicht wiederkehrenden Aufgaben umgehen müssen, die unterschiedlich lange dauern und ungleiche Verzugskosten aufweisen. Und genau damit haben wir es in der Produktentwicklung zu tun. Dafür brauchen wir weiterführende Systeme. Und dieses Buch ist das erste, das solche Systeme in der Praxis beschreibt.
Ich möchte den Leser kurz warnen. Erstens: Wenn Sie bereits zu wissen glauben, wie Kanban-Systeme funktionieren, dann denken Sie vermutlich an die Kanban-Systeme aus dem Lean Manufacturing. Die Ideen in diesem Buch gehen viel weiter als statische WIP-Limits, FIFO-Priorisierung und eine einzige Serviceklasse. Achten Sie genau auf diese Unterschiede!
Zweitens sollten Sie diesen Ansatz nicht einfach als ein System zur visuellen Kontrolle betrachten. Zwar ist die Art, wie Kanban-Boards den Work in Progress sichtbar machen, zweifellos überwältigend. Aber das ist nur ein kleiner Aspekt des gesamten Ansatzes. Wenn Sie dieses Buch genau lesen, werden Sie feststellen, dass viel mehr dahinter steckt. Die wahren Erkenntnisse liegen in Aspekten wie dem Design von Prozessein- und -ausgängen, dem Umgang mit nicht veränderbaren Prozessen und dem Gebrauch verschiedener Serviceklassen. Lassen Sie sich vom visuellen Aspekt nicht allzu sehr ablenken, damit Sie die Feinheiten nicht verpassen.
Drittens: Verurteilen Sie die hier vorgestellte Methode nicht, weil sie so einfach einzusetzen ist. Diese Einfachheit ist ein direktes Resultat aus Davids Erkenntnissen, welche Prozesse den größten Nutzen bei minimalen Kosten bringen. Er weiß sehr genau, was Praktiker wirklich brauchen, und er hat sich darauf konzentriert, was tatsächlich funktioniert.
Dies ist ein aufregendes und ein wichtiges Buch, das es verdient, aufmerksam gelesen zu werden. Wie viel Sie aus diesem Buch mitnehmen, hängt davon ab, wie genau Sie es lesen. Kein anderes Buch wird Ihnen einen besseren Überblick über diese fortgeschrittenen Ideen verschaffen. Ich hoffe, Sie werden das Buch genauso genießen, wie ich es getan habe.
Don Reinertsen
Autor des Buches The Principles of Product Development Flow
7. Februar 2010, Redondo Beach, California
Inhalt
Teil I
Einführung
1
Das Dilemma eines agilen Managers
1.1
Meine Suche nach dem nachhaltigen Arbeitstempo
1.2
Meine Suche nach erfolgreichem Change Management
1.3
Vom Drum-Buffer-Rope zu Kanban
1.4
Die Entstehung der von KANBAN-Methode
1.5
Anpassungen durch die KANBAN-Community
1.6
Der Nutzen von KANBAN ist kontraintuitiv
2
Was ist Kanban?
2.1
Was ist ein Kanban-System?
2.2
Kanban in der Softwareentwicklung
2.3
Wozu ein Kanban-System?
2.4
Kanban in Aktion
2.5
Kanban als ein komplexes, adaptives System für Lean
2.6
Resultierende Verhaltensweisen
2.7
Kanban als Erlaubnis
Teil II
Vorteile von Kanban
3
Ein Erfolgsrezept
3.1
Wie man das Rezept umsetzt
3.1.1 Fokussiere auf Qualität
3.1.2 Den Work in Progress reduzieren und häufig ausliefern
3.1.3 Sorge für ein Gleichgewicht zwischen Nachfragen und Durchsatz
3.1.4 Priorisiere
3.1.5 Nimm die Quellen von Variabilität ins Visier, um die Vorhersagbarkeit zu erhöhen
3.2
Das Erfolgsrezept und Kanban
4
Extreme Verbesserungen in fünf Quartalen
4.1
Das Problem
4.2
Die Visualisierung des Workflows
4.3
Faktoren, die die Leistungsfähigkeit beeinflussten
4.4
Prozessregeln explizit machen
4.5
Schätzungen stellten Verschwendung dar
4.6
Den Work in Progress begrenzen
4.7
Einen Rhythmus für den Input etablieren
4.8
Der Vorschlag für eine neue Abmachung
4.9
Veränderungen einführen
4.10
Regeln anpassen
4.11
Ausschau nach weiteren Verbesserungen
4.12
Ergebnis
5
Eine Kultur der kontinuierlichen Verbesserung
5.1
Kaizen-Kultur
5.2
Kanban beschleunigt organisatorische Reife und Potenzial
5.3
Soziologische Veränderung
5.4
Kulturelle Veränderung ist der vielleicht größte Vorteil von KANBAN
Teil III
Kanban einführen
6
Die Wertschöpfungskette visualisieren
6.1
Einen Start- und einen Endpunkt definieren
6.2
Aufgabentypen
6.3
Ein Kanban-Board zeichnen
6.4
Bedarfsanalyse
6.5
Kapazität gemäß Bedarf verteilen
6.6
Der Aufbau eines Tickets
6.7
Elektronisches Tracking
6.8
Ein- und Ausgangsgrenzen setzen
6.9
Umgang mit Nebenläufigkeit
6.10
Umgang mit Aktivitäten ohne feste Reihenfolge
7
Koordinierung durch Kanban
7.1
Visuelle Kontrolle und Pull
7.2
Elektronisches Tracking
7.3
Tägliche Standup-Meetings
7.4
Anschlussmeetings
7.5
Nachschubmeetings
7.6
Das Release-Planungsmeeting
7.7
Triage
7.8
Das Review der Problemliste und die Eskalierung
7.9
Sticky Buddies
7.10
Synchronisierung über geografische Grenzen hinweg
8
Einen Lieferrhythmus etablieren
8.1
Koordinierungskosten der Auslieferung
8.2
Transaktionskosten der Auslieferung
8.3
Effizienz der Auslieferung
8.4
Einen Lieferrhythmus vereinbaren
8.5
Die Effizienz steigern, um den Lieferrhythmus zu verkürzen
8.6
Auslieferungen bei Bedarf oder spontan durchführen
9
Einen Rhythmus für den Input festlegen
9.1
Die Koordinierungskosten der Priorisierung
9.2
Einigung auf einen Priorisierungsrhythmus
9.3
Effiziente Priorisierung
9.4
Die Transaktionskosten der Priorisierung
9.5
Häufigere Priorisierung durch verbesserte Effizienz
9.6
Priorisierungen spontan oder bei Bedarf durchführen
10
WIP-Limits setzen
10.1
Limits für Aufgaben
10.2
Limits für Queues
10.3
Engpässe puffern
10.4
Die Größe der Input Queue
10.5
Unbeschränkte Abschnitte im Workflow
10.6
Die Organisation nicht unter Druck setzen
10.7
Es ist ein Fehler, keine WIP-Limits zu setzen
10.8
Zuweisen von Kapazitäten
11
Service Level Agreements vereinbaren
11.1
Typische Definitionen von Serviceklassen
11.1.1 Beschleunigt
11.1.2 Fester Liefertermin
11.1.3 Die Standardklasse
11.1.4 Unbestimmbare Kosten
11.2
Regeln für Serviceklassen
11.2.1 Regeln für die Serviceklasse »beschleunigt«
11.2.2 Regeln für die Serviceklasse »fester Liefertermin«
11.2.3 Regeln für die Standardklasse
11.2.4 Regeln für die Serviceklasse »unbestimmbare Kosten«
11.3
Zieltermine für die Auslieferung festlegen
11.4
Die Zuordnung von Serviceklassen
11.5
Serviceklassen anwenden
11.6
Den Serviceklassen Kapazitäten zuordnen
12
Metriken und Managementberichte
12.1
WIP-Tracking
12.2
Durchlaufzeit
12.3
Termintreue
12.4
Durchsatz
12.5
Probleme und blockierte Aufgaben
12.6
Flusseffizienz
12.7
Initiale Qualität
12.8
Bruchlast
13
Kanban skalieren
13.1
Hierarchisch strukturierte Anforderungen
13.2
Die Auslieferung von Wert von der Variabilität der Aufgaben entkoppeln
13.3
Zweistufige Kanban-Boards
13.4
Swimlanes einführen
13.5
Alternativer Umgang mit Größen-Variabilität
13.6
Serviceklassen integrieren
13.7
Systemintegration
13.8
Der Umgang mit geteilten Ressourcen
14
Operations Reviews
14.1
Vor dem Meeting
14.2
Im Geschäftston von Anfang an
14.3
Gäste einladen erweitert das Publikum und schafft Mehrwert
14.4
Hauptpunkte der Tagesordnung
14.5
Der Grundpfeiler jeder Transition zu Lean
14.6
Angemessener Rhythmus
14.7
Den Wert von Managern nachweisen
14.8
Fokus auf die Organisation fördert Kaizen
14.9
Ein früheres Beispiel
15
Eine Veränderungsinitiative mit Kanban durchführen
15.1
Kulturwandel statt einer vorgeschriebenen Änderungsinitiative
15.2
Das Hauptziel unseres Kanban-Systems
15.3
Untergeordnete Ziele unseres Kanban-Systems
15.4
Das Ziel kennen und die Vorteile benennen
15.5
Die ersten Schritte
15.6
In Kanban gelten andere Abmachungen
15.7
Die Kanban-Verhandlungen
15.7.1 WIP-Limits
15.7.2 Priorisierung
15.7.3 Auslieferung/Releases
15.7.4 Durchlaufzeit und Serviceklassen
Teil VI
Verbesserungen durchführen
16
Drei Arten von Verbesserungsmöglichkeiten
16.1
Engpässe, Verschwendung eliminieren und die Reduktion von Variabilität
16.1.1 Engpasstheorie
16.1.2 Lean, TPS und die Verringerung von Verschwendung
16.1.3 Deming und Six Sigma
16.2
Kanban in Ihrer Unternehmenskultur
17
Engpässe und ungleichmäßige Verfügbarkeit
17.1
Ressourcen mit begrenzter Kapazität
17.1.1 Erweiterungsmaßnahmen
17.1.2 Ausnutzen und Schützen
17.1.3 Andere Dinge unterordnen
17.2
Ungleichmäßig verfügbare Ressourcen
17.2.1 Ausnutzen und schützen
17.2.2 Andere Dinge unterordnen
17.2.3 Erweiterungsmaßnahmen
18
Ein ökonomisches Modell für Lean
18.1
»Verschwendung« neu definieren
18.2
Transaktionskosten
18.3
Koordinierungskosten
18.4
Woher weiß man, ob eine Tätigkeit nur Kosten bedeutet?
18.5
Bruchlast
19
Quellen von Variabilität
19.1
Interne Quellen von Variabilität
19.1.1 Die Größe von Aufgaben
19.1.2 Unterschiedliche Aufgabentypen
19.1.3 Unterschiedliche Serviceklassen
19.1.4 Ungleichmäßiger Fluss
19.1.5 Nacharbeiten
19.2
Externe Quellen von Variabilität
19.2.1 Unklare Anforderungen
19.2.2 Beschleunigte Anforderungen
19.2.3 Ungleichmäßiger Fluss
19.2.4 Verfügbarkeit von Umgebungen
19.2.5 Marktfaktoren
19.2.6 Schwierigkeiten bei der Koordinierung
20
Problemmanagement und Eskalationsregeln
20.1
Problemmanagement
20.2
Probleme eskalieren
20.3
Probleme nachverfolgen und Problemberichte
21
Feeding the Kanban – Portfoliomanagement bei mobile.international GmbH
21.1
Geschichte
21.2
Portfolio
21.3
Die Verfahren verbessern
21.4
Lösungssuche und Transfer
21.5
Lösung über Kanban
21.6
Implementierung
21.7
Ist das wirklich Kanban?
21.8
Projektlevel
Anhang
Danksagung
Abkürzungsverzeichnis
Literatur
Index
Teil I
Einführung
1 Das Dilemma eines agilen Managers
2002 arbeitete ich als hoch motivierter Entwicklungsleiter an einem Standort der Motorola PCS-Mobiltelefon-Sparte in Seattle, Washington. Meine Abteilung war Teil eines Start-up-Unternehmens, das ein Jahr zuvor von Motorola gekauft worden war. Wir entwickelten Software für Netzwerkserver, um Services wie Over-the-Air-Download und Over-the-Air-Device-Management zu ermöglichen. Diese Serveranwendungen waren Teil eines integrierten Systems, das Hand in Hand sowohl mit der Software der Mobiltelefone als auch mit anderen Elementen innerhalb der Netzinfrastruktur und der Back-Office-Infrastruktur (etwa der Abrechnung) zusammenarbeitete. Unsere Deadlines wurden von Managern festgesetzt, ohne dass sie sich dabei um die Komplexität des Systems, die Risiken oder die Projektgröße scherten. Unsere Codebasis stammte aus dem ursprünglichen Start-up-Unternehmen und war verbesserungswürdig. Ein Senior-Entwickler beharrte darauf, dass unser Produkt nichts weiter als ein »Prototyp« sei. Um die Geschäftsziele zu erreichen, mussten wir um jeden Preis unsere Produktivität erhöhen und die Qualität verbessern.
Bei meiner damaligen Arbeit aus dem Jahr 2002 sowie durch die Erkenntnisse aus meinem ersten Buch [Anderson 2003] stand ich zwei großen Herausforderungen gegenüber. Erstens: Wie kann ich mein Team vor den steigenden Ansprüchen des Managements schützen, und wie können wir das erreichen, was die Agile Community heute »nachhaltiges Arbeitstempo« (sustainable pace) nennt? Und zweitens: Wie kann ich agile Ansätze erfolgreich auf ein ganzes Unternehmen hochskalieren, ohne dabei mit den unausweichlichen Widerständen gegen Veränderungen kämpfen zu müssen?
1.1 Meine Suche nach dem nachhaltigen Arbeitstempo
Im Jahr 2002 hatte die Agile Community mit nachhaltigem Arbeitstempo einfach die 40-Stunden-Woche [Beck 2000] gemeint. Die Prinzipien hinter dem Agilen Manifest [Beck et al. 2001] erklären uns: »Agile Methoden unterstützen nachhaltige Entwicklung. Die Sponsoren, Entwickler und Anwender sollen in der Lage sein, unbegrenzt in einem konstanten Arbeitstempo zu arbeiten.« Zwei Jahre zuvor hörte ich von meinem Team bei PCS: »Softwareentwicklung im Großen ist kein Sprint, sondern ein Marathon.« Wenn Teammitglieder ihr Arbeitstempo für die Langstrecke von 18 Monaten aufrechterhalten sollen, dürfen sie nicht nach ein oder zwei Monaten ausgebrannt sein. Unser Projekt musste so geplant, budgetiert, terminiert und geschätzt werden, dass die Teammitglieder täglich nur eine verantwortbare Anzahl an Stunden arbeiteten, ohne dadurch allzu sehr zu ermüden. Die Herausforderung für mich als Manager bestand also darin, dieses Ziel zu erreichen und gleichzeitig die Geschäftsziele zu erfüllen.
Als ich 1991 zum ersten Mal als Manager arbeitete – damals in einem fünf Jahre alten Start-up, das Video-Capture-Karten für PCs und andere kleinere Computer herstellte –, bekam ich vom Geschäftsführer das Feedback, dass mich das Management als »sehr negativ« empfand. Ich sagte nämlich immer »Nein«, wenn sie noch mehr Features oder weitere Produkte verlangten, obwohl unsere Entwicklungskapazität bereits voll ausgelastet war. Im Jahr 2002 zeichnete sich also ein deutliches Muster ab: Ich hatte mehr als zehn Jahre damit verbracht, »Nein« zu sagen und die ständig wechselnden Forderungen des Fachbereichs zurückzuweisen.
Für gewöhnlich schienen Entwicklungsteams und IT-Abteilungen von anderen Gruppen abhängig zu sein, die mit ihnen jeden Plan verhandelten, auf sie einredeten, sie einschüchterten und überstimmten, ganz egal wie sinnvoll und logisch hergeleitet dieser Plan auch war. Sogar solche Pläne wurden angegriffen, die durch sorgfältige Analysen und statistische Daten aus mehreren Jahren gestützt wurden. Die meisten Teams, die weder solche sorgfältigen Analysen noch statistische Daten aufweisen konnten, waren vollkommen anderen ausgeliefert, die sie immer wieder dazu brachten, sich auf unbekannte (und oft vollkommen unvernünftige) Teillieferungen einzulassen.
Inzwischen haben sich Angestellte daran gewöhnt, verrückte Zeitpläne und absurde Verpflichtungen als normal anzusehen. Softwareentwickler dürfen offenbar kein soziales oder familiäres Leben haben. Wenn sich das wie eine Beleidigung anhört, dann deswegen, weil es genau das ist! Ich kenne viele Menschen, deren Engagement für die Arbeit ihre Beziehung zu ihren Kindern und Familien schwer belastet hat. Dabei ist es nicht einfach, Mitleid mit dem typischen Entwicklungsexperten zu haben. Denn in meiner Heimat Washington stehen Softwareentwickler auf Platz zwei beim jährlichen Einkommen, übertroffen nur noch von Zahnärzten. Ähnlich war es bei den Fließbandarbeitern bei Ford zu Beginn des 20. Jahrhunderts. Weil sie durchschnittlich fünfmal so viel verdienten wie der Rest der Amerikaner, kümmerte sich keiner darum, wie monoton diese Arbeit war und wie sich die Arbeiter dabei fühlten. Die Entstehung gewerkschaftlicher Strukturen im Bereich der Wissensarbeit, und somit auch der Softwareentwicklung, ist kaum denkbar. Hauptsächlich deshalb, weil man sich schwer vorstellen kann, dass sich jemand um die wirklichen Ursachen kümmert, die für physische und psychische Krankheiten verantwortlich sind, unter denen die gut betuchten Entwickler häufig leiden. Arbeitgeber neigen dazu, therapeutische Maßnahmen wie Massage und Physiotherapie anzubieten und hin und wieder »Krankheitstage« zu akzeptieren, anstatt den wirklichen Ursachen dieser Probleme auf den Grund zu gehen. Ein technischer Redakteur eines bekannten Softwareunternehmens sagte einmal zu mir: »Es ist keine Schande, Antidepressiva zu nehmen, das macht schließlich jeder!« Als Reaktion auf diesen Missbrauch neigen Entwickler dazu, jeder Forderung zuzustimmen, ihre hohen Gehälter einzustreichen und die Konsequenzen einfach runterzuschlucken.
Ich wollte diese Verkrustungen aufbrechen. Ich wollte eine Win-win-Situation schaffen, die es mir erlaubte, »Ja« zu sagen, aber dennoch das Team zu schützen und ein nachhaltiges Arbeitstempo zu gewährleisten. Ich wollte den Mitgliedern meines Teams ihr soziales und familiäres Leben zurückgeben und die Bedingungen verbessern, die dazu führten, dass bereits unter 30-jährige Entwickler an stressbedingten Krankheiten litten. Also nahm ich die Herausforderung an und versuchte, eine Lösung für diese Probleme zu finden.
1.2 Meine Suche nach erfolgreichem Change Management
Die zweite Herausforderung, die ich anging, bestand darin, in großen Organisationen wirkliche Veränderungen zu erreichen. Ich war Entwicklungsleiter bei Sprint PCS und später bei Motorola gewesen. In beiden Firmen war es notwendig, agiler zu werden. Aber in beiden Fällen hatte ich große Schwierigkeiten, agile Methoden über die Grenzen von ein oder zwei Teams hinaus auszuweiten. In beiden Fällen war ich nicht in der entsprechenden Position, um Veränderungen für alle Teams einfach von oben durchzusetzen. Ich versuchte zwar, Neuerungen auf Wunsch des oberen Managements zu erwirken, aber ich besaß keine formale Macht. Ich sollte andere Entwicklungsleiter dazu bringen, ähnliche Veränderungen in ihren Teams durchzuführen, wie ich es in meinem Team getan hatte. Aber diese Teams weigerten sich, die Praktiken bei sich einzuführen, die in meinem Team ganz offensichtlich zu besseren Resultaten führten. Diese Weigerung hatte sicherlich viele Gründe, aber die häufigste Ursache war, dass sich jedes Team in einer ganz eigenen Situation befand; die Praktiken aus meinem Team hätten modifiziert und auf die Bedürfnisse der anderen zugeschnitten werden müssen. Mitte 2002 war ich zu der Erkenntnis gelangt, dass es nicht funktioniert, einem Team vorzuschreiben, wie es seinen Softwareentwicklungsprozess zu gestalten hat.
Der Prozess musste an die jeweilige Situation angepasst werden. Dazu wäre aktive Führung in jedem Team nötig gewesen. Selbst bei richtiger Führung zweifelte ich daran, dass wirkliche Veränderungen möglich wären ohne einen Rahmen und eine Anleitung zur Gestaltung dieses Prozesses, sodass er zu verschiedenen Situationen passt. Ohne diese Führung für den Leiter, Coach oder Prozessverantwortlichen würden die meisten Einführungen subjektiv auf Basis von Halbwissen vonstattengehen. Dies würde ebenso sehr für Einwände und Streit sorgen wie die Einführung eines unangemessenen Prozesses. Teilweise adressierte ich dieses Problem in dem Buch, an dem ich damals gerade arbeitete: Agile Management for Software Engineering. Darin stellte ich die Frage: »Warum erreicht man durch agile Softwareentwicklung bessere Ergebnisse als mit traditionellen Methoden?« Die Antwort suchte ich in der Engpasstheorie (Theory of Constraints) [Goldratt 1999].
Während der Arbeit an jenem Buch wurde mir klar, dass jede Situation einzigartig ist. Warum sollte sich der limitierende Faktor (Engpass) in jedem Team, in jedem Projekt und zu jeder Zeit an derselben Stelle befinden? Jedes Team zeichnet sich durch ein individuelles Bündel von Fähigkeiten, Möglichkeiten und Erfahrungen aus. Jedes Projekt ist unterschiedlich in Hinblick auf das Budget, den Zeitplan, den Umfang und das Risikoprofil. Und jede Organisation ist anders, wenn man bedenkt, dass sie eine bestimmte Wertschöpfungskette aufweist und in einem bestimmten Markt agiert, so wie es in Abbildung 1–1 dargestellt wird. Mir kam die Idee, dass hierin der Grund für die Weigerung gegenüber Veränderungen liegen könnte. Wenn die vorgeschlagenen Änderungen hinsichtlich der Arbeitspraktiken und Verhaltensweisen keine Vorteile bringen, dann lehnen die Menschen diese Veränderungen ab. Und wenn die Veränderungen nicht genau das adressieren, was die Teammitglieder als ihren Engpass ansehen, dann werden sie nicht akzeptiert. Um es einfach auszudrücken: Vorschläge für Veränderungen, die nicht zum jeweiligen Kontext passen, werden von den Menschen zurückgewiesen, die in diesem Projektkontext leben und ihn verstehen.
Teams haben unterschiedliche …
• Fähigkeiten
• Erfahrungen
• Leistungsvermögen
Projekte haben unterschiedliche …
• Budgets
• Zeitpläne
• Umfänge
• Risikoprofile
Organisationen haben unterschiedliche …
• Wertschöpfungsketten
• Zielmärkte
Abb. 1–1Warum Entwicklungsmethoden nach dem Motto »One size fits all« nicht funktionieren.
Es schien besser zu sein, einen neuen Prozess zu entwickeln, in dem man einen Engpass nach dem anderen beseitigt. Das ist der Kern der Engpasstheorie von Goldratt. Während mir klar wurde, dass ich noch eine Menge zu lernen hatte, wusste ich auch, dass mein bisheriges Material nützlich war, und so trieb ich mein ursprünglich geplantes Manuskript voran. Ich wusste sehr wohl, dass mein Buch keine Ratschläge enthielt, wie man diese Ideen im Großen umsetzt, denn es bot so gut wie keine Anleitungen zum Change Management.
Der Ansatz von Goldratt, der in Kapitel 16 beschrieben wird, bemüht sich, einen Engpass aufzuspüren und diesen so lange zu erweitern, bis er die Gesamtleistung des Systems nicht länger einschränkt. Sobald dies geschafft ist, entsteht ein neuer Engpass, und der Kreislauf beginnt von Neuem. Dies ist ein iterativer Ansatz, bei dem man die Leistung systematisch verbessert, indem Engpässe aufgespürt und beseitigt werden.
Ich hatte den Einfall, diese Praktik mit einigen Ideen aus Lean zu kombinieren. Indem ich die Arbeitsabläufe eines Softwareentwicklungszyklus als Wertstrom darstellte und ein Tracking- und Visualisierungssystem aufbaute, um mitzubekommen, wie sich die Zustände von Aufgaben änderten, während diese durch das System »flossen«, konnte ich Engpässe aufspüren. Diese Fähigkeit, Engpässe ausfindig zu machen, stellt den ersten Schritt dar, um die Engpasstheorie anzuwenden. Für Probleme, die den Fluss (Flow) betreffen, hatte Goldratt bereits eine Anwendung dieser Theorie entwickelt, die den umständlichen Namen »Drum-Buffer-Rope« trägt. Unabhängig von der schwerfälligen Bezeichnung wurde mir klar, dass sich ein einfacher Drum-Buffer-Rope-Ansatz für Softwareentwicklung einführen ließe.
Generell kann man sagen, dass Drum-Buffer-Rope ein Beispiel aus einer Reihe von Ansätzen darstellt, die als Pull-Systeme bekannt sind. Wie wir in Kapitel 2 sehen werden, ist ein Kanban-System ein weiteres Beispiel für ein Pull-System. Ein interessanter Nebeneffekt von Pull-Systemen liegt darin, dass sie den Work in Progress (WIP), also die Menge an begonnener Arbeit, auf ein vereinbartes Maß begrenzen und so die Angestellten vor Überlastung schützen. Außerdem sind nur diejenigen voll ausgelastet, die am Engpass arbeiten, während alle anderen immer wieder Leerlaufzeiten haben. Mir wurde klar, dass Pull-Systeme möglicherweise meine beiden Probleme lösen könnten. Ein Pull-System sollte mich in die Lage versetzen, inkrementelle Prozessveränderungen durchzuführen, wodurch sich (hoffentlich) die Widerstände reduzieren ließen. Und es sollte eine nachhaltige Entwicklungsgeschwindigkeit ermöglichen. Ich beschloss, bei nächster Gelegenheit ein Drum-Buffer-Rope-Pull-System einzusetzen. Ich wollte mit inkrementeller Prozessverbesserung experimentieren und sehen, ob dadurch nachhaltige Entwicklungsgeschwindigkeit ermöglicht würde und sich die Widerstände gegen Veränderungen reduzierten.
Diese Möglichkeit ergab sich im Herbst 2004 bei Microsoft. Hierzu gibt es eine komplette Fallstudie in Kapitel 4.
1.3 Vom Drum-Buffer-Rope zu Kanban
Der Einsatz des Drum-Buffer-Rope-Ansatzes bei Microsoft funktionierte gut. Wir hatten mit sehr geringen Widerständen zu kämpfen, während sich die Produktivität mehr als verdreifachte, die Durchlaufzeiten (lead times) um mehr als 90 Prozent sanken und die Vorhersagbarkeit sich um 98 Prozent verbesserte. Im Herbst 2005 berichtete ich über die Ergebnisse auf einer Konferenz in Barcelona [Anderson & Dumitriu 2005] und bei anderer Gelegenheit noch einmal im Winter 2006. Donald Reinertsen wurde auf meine Arbeit aufmerksam und machte sich auf den Weg zu meinem Büro in Redmond, Washington. Er wollte mich davon überzeugen, dass ich alle Teile beisammen hatte, um ein komplettes Kanban-System zu etablieren.
Kan-ban ist ein japanisches Wort, das wörtlich übersetzt »Signalkarte« bedeutet. In der Fertigung werden diese Karten als Signale verwendet, um einem vorgelagerten Prozessschritt mitzuteilen, dass er mehr Zwischenprodukte produzieren soll. Egal an welchem Prozessschritt ein Arbeiter sich gerade befindet: Er darf nur dann arbeiten, wenn ihm dies von einem nachgelagerten Prozessschritt signalisiert wird. Obwohl ich diesen Mechanismus kannte, war ich nicht überzeugt davon, dass dies eine nützliche und praktikable Technik war, um sie auf Wissensarbeit und insbesondere auf Softwareentwicklung anzuwenden. Mir war zwar klar, dass ein Kanban-System ein nachhaltiges Arbeitstempo ermöglichen würde, aber mir war nicht bewusst, welchen Ruf Kanban als Methode zur inkrementellen Prozessverbesserung genoss. Ich wusste nicht, dass Taiichi Ohno, einer der Schöpfer des Toyota-Produktionssystems, gesagt hatte: »Die zwei Säulen des Toyota-Produktionssystems sind just in time und Autonomatisierung, also Automatisierung mit menschlicher Note. Das Werkzeug, das dieses System antreibt, ist Kanban.« Mit anderen Worten: Kanban ist unabdingbar für den Kaizen-Prozess (kontinuierliche Verbesserung), der bei Toyota eingesetzt wird. Erst durch diesen Mechanismus funktioniert das Ganze. Durch meine Erfahrung der letzten Jahre wurde mir klar, dass dies absolut richtig war.
Zum Glück brachte Don ein überzeugendes Argument ein, das mich dazu bewegte, von der Drum-Buffer-Rope-Implementierung zu Kanban zu wechseln. Dabei handelte es sich um den feinen Unterschied, dass Kanban-Systeme sich auf ansprechendere Weise von einem Ausfall an einer Engpass-Station erholen. Als Leser müssen Sie diese Spitzfindigkeit nicht unbedingt begreifen, um dieses Buch zu verstehen.
Als ich mir noch einmal die endgültige Implementierung bei Microsoft ansah, wurde mir klar, dass das Ergebnis dasselbe gewesen wäre, wenn wir unser Vorgehen von Anfang an als ein Kanban-System konzipiert hätten. Ich fand es interessant, dass zwei unterschiedliche Ansätze zum selben Ergebnis führten. Wenn aber der resultierende Prozess beide Male derselbe war, so fühlte ich mich nicht gezwungen, ihn unbedingt als eine spezifische Drum-Buffer-Rope-Implementierung zu begreifen.
Ich entwickelte eine Vorliebe für den Terminus »Kanban« gegenüber Drum-Buffer-Rope. Kanban wird in der Lean Production (und dem Toyota-Produktionssystem) verwendet. Diese Wissensbestände genießen eine viel größere Verbreitung und Akzeptanz als die Engpasstheorie. Obwohl Kanban aus Japan stammt, ist es nicht so metaphorisch wie Drum-Buffer-Rope. Kanban ließ sich einfacher aussprechen, einfacher erklären, und es stellte sich heraus, dass es auch einfacher zu lehren und einzuführen war. Also setzte es sich durch.
1.4 Die Entstehung der von KANBAN-Methode
Im September 2006 verließ ich Microsoft, um die Leitung der Entwicklungsabteilung bei Corbis zu übernehmen. Corbis ist ein privates Unternehmen in der Innenstadt von Seattle, das Rechte an Fotografien und geistigem Eigentum verwaltet. Ermutigt durch die Ergebnisse bei Microsoft entschied ich mich, ein Kanban-Pull-System bei Corbis einzuführen. Wieder waren die Ergebnisse sehr ermutigend, und sie führten zur Entwicklung der meisten Ideen, die in diesem Buch vorgestellt werden. Ein erweitertes Set dieser Ideen – Visualisierung von Arbeitsabläufen, Rhythmen, Serviceklassen, spezifische Reports an das Management und Operations Reviews – macht Kanban als Methode aus.
Im weiteren Verlauf dieses Buches beschreibe ich KANBAN (in Kapitälchen) als eine Methode zum evolutionären Change Management, die ein Pull-System nach Kanban sowie Visualisierung und andere Werkzeuge verwendet, um so die Einführung von Ideen aus dem Lean-Umfeld in die Softwareentwicklung und den IT-Betrieb zu beschleunigen. Dieser Prozess ist evolutionär und inkrementell. KANBAN erlaubt Ihnen, eine kontextabhängige Optimierung Ihrer Prozesse bei minimalem Widerstand gegen diese Veränderungen vorzunehmen. Gleichzeitig wird für die beteiligten Personen ein nachhaltiges Arbeitstempo gewährleistet.
1.5 Anpassungen durch die KANBAN-Community
Im Mai 2007 stellten Rick Garber und ich die frühen Ergebnisse von Corbis auf der Konferenz »Lean New Product Development« in Chicago vor einem Publikum von 55 Teilnehmern vor. Später in diesem Sommer, auf der Konferenz »Agile 2007« in Washington, D.C., leitete ich eine Open-Space-Session zu Kanban, an der ungefähr 25 Personen teilnahmen. Zwei Tage später hielt Arlo Belshee, einer der Teilnehmer, einen Lightning Talk, in dem er seine Naked-Planning-Technik [Belshee 2008] vorstellte. Es wurde deutlich, dass neben mir auch andere Pull-Systeme eingeführt hatten. Wir gründeten eine Yahoo!-Diskussionsgruppe, die schnell auf 100 Mitglieder anwuchs. Während ich dies schreibe, hat diese Gruppe bereits über 1.000 Mitglieder.
Mehrere Teilnehmer der Open-Space-Session nahmen sich vor, KANBAN an ihrem Arbeitsplatz auszuprobieren – oft mit Teams, die Schwierigkeiten mit Scrum hatten. Von diesen frühen Kanban-Anwendern waren vor allem Karl Scotland, Aaron Sanders und Joe Arnold bemerkenswert. Sie alle arbeiteten bei Yahoo! und führten KANBAN schnell bei mehr als zehn Teams auf drei verschiedenen Kontinenten ein. Ein anderer hervorzuhebender Teilnehmer war Kenji Hiranabe, der Kanban-Lösungen in Japan entwickelte. Schon bald veröffentlichte er zwei Artikel auf InfoQ [Hiranabe 2007, Hiranabe 2008], die viel Interesse und Aufmerksamkeit weckten. Im Herbst 2007 besuchte Sanjiv Augustine, Autor von Managing Agile Projects [Augustine 2005] und Gründer des Agile Project Leadership Network (APLN), Corbis in Seattle und beschrieb unser Kanban-System als »die erste neue agile Methode, die ich in den letzten fünf Jahren gesehen habe«.
Im nächsten Jahr gab es auf der Konferenz »Agile 2008« in Toronto sechs Vorträge zum Einsatz von Kanban-Lösungen in unterschiedlichen Kontexten. In einem der Vorträge zeigte Joshua Kerievsky von Industrial Logic, einer Firma, die sich der Beratung und Schulung von Extreme Programming verschrieben hatte, wie er ähnliche Ideen entwickelt hatte, um Extreme Programming weiterzuentwickeln und an sein Geschäftsumfeld anzupassen. In diesem Jahr überreichte die Agile Alliance Arlo Belshee und Kenji Hiranabe den Gordon-Pask-Preis für ihre Verdienste um die Agile Community. Beide hatten entweder sichtbar zur Entstehung von KANBAN beigetragen oder bemerkenswert ähnliche Ideen zu diesem Thema hervorgebracht und verbreitet.
1.6 Der Nutzen von KANBAN ist kontraintuitiv
Wissensarbeit ist in vielerlei Hinsicht das Gegenteil von stereotypen Arbeitsabläufen in der Produktion. Softwareentwicklung ist ganz sicher anders als Fertigung. Beide Domänen weisen ganz unterschiedliche Eigenschaften auf. In der Fertigung gibt es weniger Variabilität, während der Großteil der Softwareentwicklung sehr variabel ist und man hier versucht, sich diese Variabilität zunutze zu machen, indem man das Design erneuert und so den Profit erhöht. Software ist von Natur aus »weich« und kann oft einfach und günstig verändert werden, während die Fertigung sich häufig auf »harte« Dinge bezieht, die schwierig zu verändern sind. Es ist ganz normal, dass Leute misstrauisch gegenüber dem Nutzen von Kanban sind, wenn es um Softwareentwicklung und andere Bereiche der IT geht. Vieles, was wir als Community in den letzten Jahren über KANBAN gelernt haben, ist kontraintuitiv. Niemand hatte die Auswirkung vorhergesehen, die Kanban auf die Firmenkultur oder die verbesserte Zusammenarbeit zwischen den Teams bei Corbis hatte (mehr dazu in Kap. 5). Ich hoffe, ich kann Ihnen in diesem Buch eines zeigen: »KANBAN kann!« Ich möchte Sie davon überzeugen, dass sich durch die Anwendung der einfachen Regeln von KANBAN die Produktivität erhöhen und die Vorhersagbarkeit verbessern lässt; dass die Lieferzeiten verkürzt und die Kundenzufriedenheit erhöht werden können. Und durch all dies wird sich Ihre Firmenkultur verändern, weil die zunehmende Zusammenarbeit hilfreich ist, um bessere Beziehungen innerhalb Ihrer Organisation zu etablieren.
Zusammenfassung
Die Kanban-Systeme gehören zur Familie der Pull-Systeme.
»Drum-Buffer-Rope« nach Eliyahu Goldratt, eine Ausprägung der Engpasstheorie, stellt eine alternative Variante eines Pull-Systems dar.
Die Motivation, einen Ansatz nach dem Pull-System anzustreben, bestand in zwei Dingen: Zum einen sollte ein systematischer Weg gefunden werden, um eine nachhaltige Arbeitsgeschwindigkeit zu erreichen. Zum anderen wollte ich einen Ansatz entwickeln, um Prozessveränderungen mit nur minimalem Widerstand einzuführen.
Kanban stellt einen Mechanismus dar, der dem Toyota-Produktionssystem und dessen Kaizen-Ansatz der kontinuierlichen Verbesserung zugrunde liegt.
Das erste virtuelle Kanban-System für Softwareentwicklung wurde Anfang 2004 bei Microsoft eingeführt.
Die Ergebnisse der frühen KANBAN-Einführungen waren ermutigend hinsichtlich der erreichten nachhaltigen Entwicklungsgeschwindigkeit, des Verringerns von Widerständen gegen Veränderungen durch einen inkrementellen und evolutionären Ansatz sowie des deutlichen ökonomischen Nutzens.
Nach der Konferenz »Agile 2007« in Washington D.C. begann sich KANBAN als ein Ansatz zum Change Management auszubreiten, weil die KANBAN-Community etliche Adaptionen vornahm.
In diesem Buch beziehe ich mich mit »Kanban« (in Normalschrift) auf Signalkarten und mit »Kanban-System« (auch in Normalschrift) auf eine Ausprägung des Pull-Systems mit (virtuellen) Signalkarten.
KANBAN (in Kapitälchen) meint eine Methode, mit der sich evolutionäre, inkrementelle Prozessverbesserungen durchführen lassen. Diese Methode entstand bei Corbis zwischen 2006 und 2008 und hat sich seitdem in der Community der Softwareentwicklung nach Lean-Prinzipien weiterentwickelt.
2 Was ist Kanban?
Im Frühjahr 2005 hatte ich das Glück, meinen Urlaub in Tokio zu verbringen – genau zu der Zeit, in der die Kirschbäume blühten. Um mir dieses Spektakel anzusehen, besuchte ich zum zweiten Mal in meinem Leben die Kaiserlichen Gärten in der Innenstadt. Hier hatte ich eine Offenbarung – Kanban ist nicht nur für die Fertigung geeignet. Am Samstag, den 9. April 2005 betrat ich den Park durch den nördlichen Eingang und überquerte die Brücke über den Graben nahe der Takebashi-U-Bahn-Station. Viele Tokioter nutzten die Gelegenheit, an einem sonnigen Samstagmorgen die Ruhe des Parks und die Schönheit der Sakura (Kirschblüten) zu genießen.
Der Brauch, ein Picknick zu machen, während die Blüten um einen herum herunterrieseln, wird als Hanami (Blumenfeier) bezeichnet. Dies ist eine uralte Tradition – eine Gelegenheit, über die Schönheit, Vergänglichkeit und Kürze des Lebens nachzudenken. Das kurze Leben der Kirschblüten steht als Metapher für unsere kurze, schöne und zerbrechliche Existenz inmitten der Weite des Universums.
Die Kirschblüten stellen einen Kontrast zu den grauen Gebäuden in der Innenstadt Tokios dar, zu seinem geschäftigen Treiben, den pulsierenden Mengen von beschäftigten Leuten und seinem Verkehrslärm. Die Gärten bilden eine Oase im Herzen dieses Betondschungels. Als ich mit meiner Familie die Brücke überquerte, kam ein älterer japanischer Herr mit einer Umhängetasche auf uns zu. Er nahm eine Handvoll Plastikkarten aus seiner Tasche und bot jedem von uns eine an. Dabei dachte er kurz darüber nach, ob meine 3 Monate alte Tochter, die ich in einem Tragetuch dabei hatte, auch eine Karte benötigte. Er entschied sich positiv und reichte mir zwei Karten. Dabei sagte er nichts, und meine Japanischkenntnisse reichten nicht, um von mir aus ein Gespräch zu beginnen. Wir gingen also weiter in die Gärten und suchten uns einen schönen Platz für unser Familienpicknick.
Zwei Stunden später – nach einem schönen Morgen im Sonnenschein – packten wir unsere Sachen zusammen und gingen Richtung Osttor am Otemachi. Als wir am Ausgang ankamen, stellten wir uns an der Schlange vor einem kleinen Kiosk an. Als wir weiter nach vorne kamen, bemerkte ich, wie Leute ihre Plastikkarten zurückgaben. Ich suchte in meinen Taschen und fand die Karten wieder. Am Kiosk angekommen, sah ich eine ordentlich uniformierte Japanerin darin sitzen. Zwischen uns befand sich eine Scheibe mit einem ausgeschnittenen Halbkreis – ähnlich einem Ticketschalter im Kino oder Vergnügungspark. Ich schob meine Plastikkarten über den Schalter durch das Loch im Glas. Die Japanerin nahm sie mit ihren weiß behandschuhten Händen und legte sie auf einen Stapel mit anderen Karten. Sie senkte ihren Kopf ein wenig und dankte mir mit einem freundlichen Lächeln. Kein Geld wechselte den Besitzer. Ich erhielt auch keine Erklärung, warum ich seit Eintritt in den Park stundenlang mit zwei weißen Plastikkarten herumlief.
Was hatte es mit diesen Eintrittskarten auf sich? Wozu ein Karte, wenn es gar keine Gebühr gibt? Meine erste Vermutung war, dass es etwas mit Sicherheitsrichtlinien zu tun haben könnte. Die Behörden könnten die zurückgegebenen Karten zählen und so sicherstellen, dass beim Schließen des Parks keine Besucher mehr im Park herumstreunen. Aber schnell fiel mir ein, dass dies ein ziemlich schlechtes Sicherheitssystem wäre. Wer bestimmte, dass ich zwei Karten statt nur einer zu nehmen hatte? Zählte mein Baby als »Gepäck« oder Besucher? Das System schien eine ziemliche Unbeständigkeit aufzuweisen und zu viele Fehlermöglichkeiten. Wenn es ein Sicherheitssystem wäre, würde es sicherlich täglich scheitern und zu viele falschpositive Rückmeldungen liefern. (Kurzer Hinweis am Rande: So ein System kann keine falsch-negativen Rückmeldungen liefern, weil dies die Produktion zusätzlicher Eintrittskarten voraussetzen würde. Dies ist generell eine nützliche Eigenschaft von Kanban-Systemen.) Unterdessen würden also jeden Abend Soldaten durch die Büsche huschen und nach verlorenen Touristen suchen. Nein, es musste etwas anderes sein. Ich stellte schließlich fest, dass der Kaiserliche Garten ein Kanban-System nutzte!
Diese Erleuchtung bewirkte bei mir, dass ich über Kanban-Systeme außerhalb der Fertigung nachdachte. Kanban-Karten schienen in allen Managementsituationen nützlich zu sein.
2.1 Was ist ein Kanban-System?
In einem Kanban-System wird eine vereinbarte Anzahl an Kanban-Karten in Umlauf gebracht, wobei die Menge der Karten nach oben durch die maximale Kapazität des Systems beschränkt ist. Eine Karte steht für eine Arbeitseinheit. Jede Karte stellt einen Signalmechanismus dar, und eine neue Arbeitseinheit darf nur angefangen werden, wenn auch eine Karte verfügbar ist. Diese freie Karte wird einer Arbeitseinheit zugeordnet und folgt ihr im Fluss durch das System. Wenn es keine freien Karten mehr gibt, kann keine weitere Arbeit begonnen werden. Jede neue Aufgabe muss in einer Queue (Warteschlange) warten, bis wieder eine Karte verfügbar ist. Wenn eine Aufgabe erledigt ist, wird die zugehörige Karte frei und kann wiederverwendet werden. Mit einer jetzt freien Karte darf eine neue Arbeitseinheit aus der Warteschlange gestartet werden.
Diesen Mechanismus nennt man ein Pull-System: Neue Aufgaben werden nur dann ins System gezogen (pull), wenn das System die Kapazität dafür bereitstellen kann, die Aufgabe auch abzuarbeiten. Die Aufgaben werden nicht nach Bedarf ins System gedrückt (push). Ein Pull-System kann nicht überlastet werden, wenn man die Kapazität durch die richtige Anzahl von Kanban-Karten adäquat festgelegt hat.
In den Kaiserlichen Gärten bildet der Garten selbst das System: Die Besucher stellen die unfertigen Aufgaben (Work in Progress, kurz WIP) dar; die Kapazität ist durch die Anzahl der Eintrittskarten, die sich im Umlauf befinden, limitiert. Neu ankommenden Besuchern wird nur Einlass gewährt, wenn weitere Eintrittskarten zur Verfügung stehen. Das stellt an normalen Tagen nie ein Problem dar. Aber an lebhaften Tagen wie Feiertagen oder Samstagen in der Kirschblütenzeit ist der Park sehr beliebt. Wenn dann alle Eintrittskarten ausgegeben wurden, müssen neue Besucher sich an der Brücke anstellen und darauf warten, dass Besucher den Park wieder verlassen und ihre Karten zurückgeben. Dieses Kanban-System stellt eine einfache, günstige und leicht einsetzbare Methode dar, um das Gedränge zu regulieren, indem die Anzahl an Personen im Park begrenzt wird. So kann die Parkverwaltung die Gärten in gutem Zustand halten und Schäden durch Überfüllung und zu viel Fußgängerverkehr vermeiden.
2.2 Kanban in der Softwareentwicklung
In der Softwareentwicklung verwenden wir ein virtuelles Kanban-System, um die begonnene Arbeit zu begrenzen. Auch wenn »Kanban« übersetzt »Signalkarte« bedeutet und in den meisten KANBAN-Implementierungen in der Softwareentwicklung Karten verwendet werden, fungieren diese Karten tatsächlich nicht als Signal, um neue Arbeit zu ziehen. Stattdessen repräsentieren sie Aufgaben. Weil es hier keine physikalischen Signalkarten gibt, sprechen wir von einem »virtuellen« Kanban-System. Das Signal zum Ziehen neuer Aufgaben folgt aus der sichtbaren Menge der begonnenen Arbeit, die von einem Indikator für das Limit (die Kapazität) für begonnene Arbeit abgezogen wird. Einige Praktiker haben mit Techniken wie Metallklammern oder einer begrenzten Anzahl von Feldern an einer Tafel ein physikalisches Kanban implementiert. Kapitel 6 zeigt Beispiele für die Mechanismen von Kanban-Systemen in der IT.
Karten an Wänden aufzuhängen, hat sich zu einem populären visuellen Kontrollmechanismus für agile Softwareentwicklung entwickelt. Ein Beispiel findet sich in Abbildung 2–2. Es ist eine Selbstverständlichkeit geworden, begonnene Aufgaben entweder auf Pinnwänden mit Karteikarten oder auf Whiteboards mit Haftnotizen darzustellen. Wir sollten aber bedenken, dass bis auf wenige Ausnahmen in der Agile Community Einigkeit darüber besteht, dass diese Kartensysteme nicht grundsätzlich Kanban-Systeme darstellen, sondern lediglich visuelle Kontrollsysteme. Sie erlauben es Teams, ihre Arbeitslast zu beobachten, sich selbst zu organisieren, sich neue Arbeit zu ziehen und Aufgaben vom Backlog bis zur Fertigstellung ohne Anweisung eines Projektleiters oder Vorgesetzten zu erledigen. Wenn es kein explizites Limit für begonnenen Arbeit und keinen Signalmechanismus gibt, um neue Aufgaben durch das System zu ziehen, dann haben wir es auch nicht mit einem Kanban-System zu tun. Dieser Punkt wird in Kapitel 7 weiter ausgeführt.
Abb. 2–1Ein Kanban-Board (mit freundlicher Genehmigung der SEP AG)
2.3 Wozu ein Kanban-System?
In den folgenden Kapiteln sollte klar werden, dass wir Kanban-Systeme verwenden, um den WIP (Menge an begonnener Arbeit) auf eine festgesetzte Kapazität zu beschränken und das Team nur in dem Maße zu belasten, in dem es in der Lage ist, auch Aufgaben abzuschließen – wir belasten das Team also entsprechend seinem Durchsatz (throughput). So können wir ein nachhaltiges Arbeitstempo erreichen, um allen Beteiligten eine gesunde Balance zwischen Arbeit und Freizeit zu ermöglichen. Wie Sie noch sehen werden, zeigt KANBAN schnell Schwachstellen in der Leistungsfähigkeit auf. Dabei ermuntert es Teams, sich auf das Beheben dieser Schwachstellen zu fokussieren, um einen stetigen Fluss der Aufgaben zu erreichen. Mit der Sichtbarkeit von Qualitäts- und Prozessproblemen wird klar, welche Auswirkungen Fehler, Engpässe, Variabilität und ökonomische Kosten auf diesen Fluss sowie und die Resultate der Arbeit haben. Eine so einfache Maßnahme wie die Begrenzung des WIP durch Kanban fördert höhere Qualität und bessere Leistungsfähigkeit. Die Kombination von verbessertem Fluss und besserer Qualität hilft dabei, die Durchlaufzeit zu verkürzen und Vorhersagbarkeit sowie Termintreue (due date performance) zu verbessern. Mit dem Einführen eines regelmäßigen Releaserhythmus und mit konsistenter Einhaltung dieses Rhythmus hilft KANBAN, Vertrauen zu den Kunden sowie entlang der Wertschöpfungskette zu anderen Abteilungen, Lieferanten und nachgelagerten Partnern im Prozess aufzubauen.
Mit all dem trägt KANBAN zu einer kulturellen Veränderung von Organisationen bei. Indem Probleme aufgedeckt werden, fokussiert sich die Organisation auf die Problemlösung und die Beseitigung negativer Auswirkungen in der Zukunft. Damit erleichtert KANBAN die Entstehung von Organisationen, die sich immer weiter verbessern und in denen die Mitarbeiter hochgradig kooperativ und überaus vertrauensvoll zusammenarbeiten und einen hohen Grad an Entscheidungskompetenz besitzen.
KANBAN hat gezeigt, dass die Kundenzufriedenheit erhöht werden kann, wenn man regelmäßig und zuverlässig hoch qualitative Software von hohem Wert ausliefert. Es hat auch gezeigt, dass sich so Produktivität, Qualität und Durchlaufzeiten verbessern lassen. Außerdem gibt es Belege dafür, dass Kanban ein zentraler Auslöser für die Entstehung einer agileren Organisation durch evolutionären Kulturwandel ist.
Im weiteren Verlauf dieses Buches möchte ich Ihnen nahebringen, wie Kanban-Systeme in der Softwareentwicklung verwendet werden und wie Sie so ein System implementieren können, um mit Ihrem Team in den Genuss der genannten Vorteile zu kommen.
2.4 Kanban in Aktion
Auf dem Cover der englischen Originalausgabe dieses Buches ist ein Cartoon zu sehen (vgl. Abb. 2–2). Dieser Cartoon, der speziell für dieses Buch in Auftrag gegeben wurde, zeigt, wie KANBAN in Aktion aussieht.
Auf dem Bild ist zu sehen, wie ein kleines Team von Wissensarbeitern ihr tägliches Meeting vor einem Whiteboard abhält. Das Board visualisiert ihren Arbeitsablauf sowie die momentane Menge an WIP. Deutlich zu erkennen ist, dass die Spalte mit den Tests (UAT) »verhungert«. Gleichzeitig scheint die Analyse mit unfertiger Arbeit überladen zu sein. Dieser Zustand spiegelt sich in der Kommunikation des Teams wider. Während ein Teammitglied nichts mehr zu tun hat (»I’m idle«), ist ein anderes überlastet (»I’m too busy«). Das dritte Teammitglied schließlich steckt fest und wartet darauf, dass die Blockade an einem Ticket aufgelöst wird (»I’m stuck«). Mit großer Sicherheit wird diese Unterhaltung durch ein WIP-Limit im Kanban-System gefördert. Wenn strikte WIP-Limits vorhanden sind, haben die Tester schon bald nichts mehr zu tun, wenn Aufgaben in der Entwicklung nicht schnell genug fertiggestellt werden.
Abb. 2–2Das Cover der englischen Originalausgabe dieses Buches
Ein viertes Teammitglied meldet sich zu Wort und übernimmt die Führung. Das Kanban-System macht ein Problem deutlich, die Teammitglieder diskutieren dieses Problem, und das vierte Teammitglied ermutigt die anderen dazu, etwas zu unternehmen (»Let’s do something about it!«).
Das Bild streicht viele Aspekte heraus, die KANBAN in der Praxis ausmachen. Der Arbeitsablauf des Teams ist visualisiert, und ein WIP-Limit für das Kanban-System wurde installiert. Dieses dient dazu, Probleme deutlich zu machen und Gespräche anzuregen. Zusammen mit dem Ausüben von Führung und einem Verständnis für häufig auftretende Probleme im Prozess führt dies dazu, dass das Team die Probleme offen miteinander besprechen und Verbesserungen vorschlagen kann.
Wie Sie in Kapitel 4 erfahren werden, kann das Team theoretische Modelle anwenden, um den Problemen in seinem Prozess auf den Grund zu gehen und Verbesserungsvorschläge zu unterbreiten. Dies stellt den Einsatz eines wissenschaftlichen Ansatzes dar. Modelle versetzen das Team in die Lage, die Ergebnisse jeder einzelnen Veränderung, die sie einführen, zu antizipieren. Die Ergebnisse können dann während der folgenden Tage beobachtet und mit den Erwartungen verglichen werden.
Was wir auf dem Bild sehen, ist wahrscheinlich ein Engpass in der Entwicklung. Dies wird daran deutlich, dass beim Testen kaum noch etwas zu tun ist, während sich die Arbeit bei der Analyse immer weiter aufstaut. Wir könnten es hier auch mit ungleichmäßiger Verfügbarkeit von Fachexperten zu tun haben, die dazu führt, dass Aufgaben bei der Analyse blockiert sind. Dadurch bedingt wird der Analyst wahrscheinlich immer weitere Aufgaben beginnen, was dazu beiträgt, dass der Stau bei der Analyse sich stetig vergrößert. (Sowohl Engpässe als auch Probleme, die mit ungleichmäßiger Verfügbarkeit von Teammitgliedern zu tun haben, werden in Kap. 17 behandelt.)
In Teil 4 dieses Buches werden verschiedene Modelle besprochen, die aus Lean, der Engpasstheorie oder Demings System of Profound Knowledge stammen. Wenn dem Team diese Modelle bekannt sind und zusätzlich Dinge deutlich visualisiert werden, dann können konstruktive Gespräche geführt werden. Das Team wird dadurch in die Lage versetzt, sich auf Änderungen im Prozess zu verständigen und sich darauf zu einigen, was getan werden sollte.
Alles in allem stellt Abbildung 2–2 also die Essenz von KANBAN dar. Gezeigt wird eine Kaizen-Kultur – also eine Organisation, die darauf ausgerichtet ist, sich kontinuierlich zu verbessern und deren Mitarbeiter gemeinsam an einem Strang ziehen, um ihre Leistung und ihre Fähigkeiten zu verbessern.
2.5 Kanban als ein komplexes, adaptives System für Lean
Mit KANBAN führt man ein komplexes, adaptives System ein, das dafür gedacht ist, Organisationen in Richtung Lean zu entwickeln. Solche komplexen, adaptiven Systeme zeichnen sich durch bestimmte Anfangsbedingungen und einfache Regeln aus, die nötig sind, damit sich auch die passenden Verhaltensweisen entwickeln können. In unserem Fall besteht das erwünschte Ergebnis in einer Kaizen-Kultur – also einer Organisation, die an kontinuierlicher Verbesserung ausgerichtet ist, sodass bessere ökonomische Resultate auf Geschäftsebene erzielt werden und bessere soziale Resultate für die Angestellten. KANBAN ist durch drei Grundprinzipien und fünf Kerneigenschaften gekennzeichnet, die dazu beitragen, Lean-Verhalten in Organisationen hervorzurufen. Die drei Grundprinzipien lauten:
1. Beginne dort, wo du dich im Moment befindest.
2. Komme mit den anderen überein, dass inkrementelle, evolutionäre Veränderungen angestrebt werden.
3. Respektiere den bestehenden Prozess sowie die existierenden Rollen, Verantwortlichkeiten und Berufsbezeichnungen.
In Organisationen, die eine Kultur der kontinuierlichen Verbesserung anstreben, habe ich alle fünf Kerneigenschaften beobachtet:
1. Visualisiere den Fluss der Arbeit (Workflow).
2. Begrenze den Work in Progress (Menge an begonnener Arbeit).
3. Führe Messungen zum Fluss durch und kontrolliere ihn.
4. Mache die Regeln für den Prozess explizit.
5. Verwende Modelle1, um Chancen für Verbesserungen zu erkennen.
2.6 Resultierende Verhaltensweisen
Es gibt eine wachsende Liste an Verhaltensweisen, die durch die Einführung von KANBAN entstehen und inzwischen als typisch für KANBAN angesehen werden können. Ein Großteil oder sogar alle diese Verhaltensweisen konnte in den meisten der bisherigen KANBAN-Implementierungen beobachtet werden – und alle haben sich 2007 bei Corbis herausgebildet. Man kann davon ausgehen, dass diese Liste noch länger wird, während wir mehr und mehr darüber lernen, welche Auswirkungen KANBAN auf Organisationen hat.
1. Für jedes Projekt bzw. jede Wertschöpfungskette wird der Prozess individuell zugeschnitten.
2. Die Rhythmen werden voneinander entkoppelt (Entwicklung ohne Iterationen).
3. Die Reihenfolge der Aufgaben richtet sich nach den Verzugskosten (bzw. Verzugs-Opportunitätskosten).
4. Der ausgelieferte Wert wird durch den Einsatz von Serviceklassen optimiert.
5. Durch die Zuordnung von Kapazitäten wird Risikomanagement betrieben.
6. Es ist erlaubt, mit dem Prozess zu experimentieren.
7. Quantitatives Management wird angewendet.
8. KANBAN verbreitet sich wie ein Virus über die gesamte Organisation.
