Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Carl Hanser Verlag GmbH & Co. KG
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2018
Die Kanban-Mechanik anzuwenden, ist nicht schwer. Damit eine Kultur kontinuierlicher Verbesserung anzustoßen, schon.
Wie das geht, zeigt dieses Buch. Hier erfahren Sie, wie Sie Kanban bestmöglich mit Change und Leadership-Know-how kombinieren. Und lernen an konkreten Praxisbeispielen, mit welchen Werkzeugen Sie Kanban erfolgreich in Ihr Unternehmen einführen können.
- Erfahren Sie, wie Sie mit Kanban nachhaltige Verbesserungsprozesse gestalten können
- Egal, ob es um Entwicklung, Wartung oder Betrieb geht: Kanban kann überall eingesetzt werden.
- Nutzen Sie die konkreten Empfehlungen und Tipps aus der Praxis der Autoren
Teil I – Wie funktioniert Kanban? Prinzipien und Kernpraktiken von Kanban // Visualisierung // WiP-Limits // Serviceklassen // Betrieb und Koordinierung // Metriken und Verbesserungen
Teil II – Change und Management: Kräfte der Veränderung // Umwelten und Systeme // Organisatorische und persönliche Veränderung // Emotionen in Veränderungsprozessen // Unternehmenskultur und Politik // Schlussfolgerungen für Kanban Change Management
Teil III – Kanban im Einsatz: Von der Idee zur Initiative // Allgemeine Klärung // Vertiefte Problemanalyse // Systemdesign // Betrieb
Extra: E-Book inside
Systemvoraussetzungen für E-Book inside: Internet-Verbindung und Adobe-Reader oder Ebook-Reader bzw. Adobe Digital Editions.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 565
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Klaus Leopold Siegfried Kaltenecker
Kanban in der IT
Eine Kultur der kontinuierlichen Verbesserung schaffen
3., überarbeitete Auflage
Die Autoren:
Dr. Klaus Leopold, WienDr. Siegfried Kaltenecker, Wien
Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autoren und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht.
Ebenso übernehmen Autoren und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen und MarkenschutzGesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
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.
Dieses Werk ist urheberrechtlich geschützt. Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.
© 2018 Carl Hanser Verlag Münchenwww.hanser-fachbuch.de
Lektorat: Brigitte Bauer-Schiewek Copyediting: Petra Kienle, Fürstenfeldbruck Umschlagdesign: Marc Müller-Bremer, München, www.rebranding.de Umschlagrealisation: Stephan Rönigk
Print-ISBN 978-3-446-45360-9 E-Book-ISBN 978-3-446-45371-5
Verwendete Schriften: SourceSansPro und SourceCodePro (Lizenz) CSS-Version: 1.0
Inhalt
Titelei
Impressum
Inhalt
Geleitwort von Holger Rieth
Vorwort zur 3. Auflage
Die Autoren
Danksagung
Teil I: Wie funktioniert Kanban?
1 Einleitung
2 Prinzipien und Kernpraktiken von Kanban
2.1 Auf der Suche nach der Produktivität
2.2 kanban und Kanban
2.3 Evolutionäres Change Management
2.4 Die Kernpraktiken von Kanban
2.5 Exkurs: Kanban Flight Levels – die Verbesserungsebenen der Organisation
2.5.1 Flight Level 1: Operative Ebene
2.5.2 Flight Level 2: Koordination
2.5.3 Flight Level 3: Strategisches Portfoliomanagement
3 Visualisierung
3.1 Erster Schritt: Abstecken der Grenzen
3.2 Zweiter Schritt: Visualisierung des Prozesses
3.2.1 Wie werden Aufgaben visualisiert?
3.2.2 Darstellung von Nebenläufigkeiten
3.2.3 Darstellung von Aktivitäten ohne feste Reihenfolge
3.3 Festlegen von Aufgabentypen
4 WiP-Limits
4.1 Die Vorteile von WiP-Limits
4.1.1 Probleme sichtbar machen
4.1.2 Engpässe sichtbar machen
4.2 Setzen von WiP-Limits
4.2.1 Größe der Input Queue
4.2.2 WiP-Limits für verschiedene Aufgabentypen
4.2.3 Auswirkungen unterschiedlicher WiP-Limits
5 Serviceklassen
5.1 Cost of Delay und Regeln
5.1.1 Serviceklasse „Beschleunigt“
5.1.2 Serviceklasse „Fester Liefertermin“
5.1.3 Serviceklasse „Standard“
5.1.4 Serviceklasse „Unbestimmbare Kosten“
5.2 Kapazitäten von Serviceklassen
5.3 Service Level Agreements
6 Betrieb und Koordinierung
6.1 Daily Standup Meeting
6.2 Queue Replenishment Meeting
6.3 Release-Planungsmeeting
6.4 Teamretrospektiven
6.5 Operations Reviews
7 Metriken und Verbesserungen
7.1 Metriken in Kanban
7.2 Cumulative Flow Diagram
7.3 Messungen der Durchlaufzeit
7.4 Failure Load und Blockaden
7.5 Verbesserungen
7.5.1 Engpasstheorie
7.5.2 Waste reduzieren
7.5.3 Variabilität reduzieren
Teil II: Change und Management
8 Kräfte der Veränderung
8.1 Turbulente Zeiten
8.2 Turbulente Veränderung
9 Umwelten und Systeme
9.1 Organisationen in Nahaufnahme
9.2 Eine Landkarte der Veränderung
10 Organisatorische und persönliche Veränderung
10.1 Der Eisberg der Veränderung
10.2 Die Veränderungskurve
10.2.1 Angst und Abwehr
10.2.2 Rationale Einsicht und emotionale Akzeptanz
10.2.3 Training des Neuen
10.2.4 Lernen und Integrieren
11 Emotionen in Veränderungsprozessen
11.1 Unsicherheit, Sorge, Angst
11.2 Ärger und Aggression
11.3 Trauer und Enttäuschung
11.4 Aufbruchstimmung, Freude, Mut
12 Unternehmenskultur und Politik
12.1 Die Macht der Unternehmenskultur
12.2 Unternehmenskultur und Mikropolitik
13 Schlussfolgerungen für Kanban Change Management
13.1 Wahrnehmung
13.1.1 Ein neues Paradigma für Management und Führung
13.2 Kommunikation
13.2.1 Die Bedeutung gemeinsamer Reflexion
13.2.2 Die Kraft des Dialogs
13.3 Prozessgestaltung
Teil III: Kanban im Einsatz
14 Von der Idee zur Initiative
15 Allgemeine Klärung
15.1 Inhaltliche Klärung
15.2 Organisatorische Klärung
16 Vertiefte Problemanalyse
16.1 Die persönliche Retrospektive
16.2 Die Teamaufstellung
16.3 Der Veränderungsdialog
16.3.1 Einfühlen
16.3.2 Abgrenzen
16.3.3 Versachlichen
16.4 Das Teamgespräch
16.5 Die Teamretrospektive
16.6 Eine Landkarte unserer Stakeholder
16.7 Das Stakeholder-Interview
16.8 Stakeholder-Workshop
16.8.1 Feedback durch Kanban-Initiatorin
16.8.2 Feedback durch Stakeholder
16.9 Einzelarbeit, Dialog, Coaching oder Training?
17 Systemdesign-Workshop
17.1 Arbeitstypen identifizieren
17.1.1 Die Stakeholder-Landkarte mit Arbeitstypen füllen
17.1.2 Entscheidungskriterien beim Clustern
17.1.3 White Noise – die Stimmen aus dem Hintergrund
17.2 Prozesse identifizieren
17.2.1 Arbeitsschritte pro Arbeitstyp finden
17.2.2 Simulation und Ticketdesign
17.3 WiP-Limits bestimmen
17.3.1 Schritt 1: Kapazitäten finden
17.3.2 Schritt 2: Übersetzen in WiP-Limits
17.3.3 Verteilen der WiP-Limits bei einem Support- oder Testteam
17.4 Serviceklassen bestimmen
17.4.1 Klarheit zwischen Arbeitstypen und Serviceklassen schaffen
17.4.2 Regeln definieren
17.4.3 Kapazitäten von Serviceklassen festlegen
17.5 Messungen definieren
17.6 Meetings bestimmen
17.6.1 Daily Standup Meeting
17.6.2 Teamretrospektiven
17.6.3 Queue Replenishment Meeting
17.6.4 Release-Planungsmeeting
17.7 Abschluss des Systemdesign-Workshops
18 Betrieb
18.1 Von der Fehlerkultur zur Lernkultur
18.2 Moderation
18.3 Konflikte im Betrieb
18.3.1 Ein wichtiger Stakeholder bricht Vereinbarungen
18.3.2 Das Team fällt in alte Gewohnheiten zurück
18.3.3 Die Zusammenarbeit ist von dysfunktionalen Verhaltensformen geprägt
18.4 Das Kanban-Feuer weitertragen
19 Fallstudien
19.1 Computest: Die Geschichte einer agilen Transformation
19.1.1 Die Ausgangssituation
19.1.2 Hilfe von außen – klarer sehen
19.1.3 Fokus auf Wertströme
19.1.4 Rollen und Verantwortlichkeiten
19.1.5 Visuelles Arbeitsmanagement
19.1.6 Lehren und Ausblick
19.2 Bosch Automotive Electronics: die lernende Organisation
19.2.1 Effizienz alleine reicht nicht
19.2.2 Den Wandel anführen: die Guiding Coalition und das Efficiency Team
19.2.3 Kommunizieren ist alles
19.2.4 Verbesserung als Kernpraktik: Kanban als Instrument des Wandels
19.2.5 Eigendynamik – der internationale Pull beginnt
19.2.6 Die Zukunft: Fokus auf den Wertstrom
Literatur
Nicht nur in der IT stellt man sich als Führungskraft immer wieder die Frage: „Wie organisiere ich mein Team/meinen Bereich/mein Unternehmen, um die Arbeit effizienter zu gestalten?“ In den Zeiten der kurzen Zyklen und angesichts stets steigender Erwartungshaltungen seitens der Märkte sind Agilität und kontinuierliche Verbesserung gefragt. In der IT-Abteilung von STUTE Logistics hatten wir ITIL eingeführt, Prozesse definiert, KPIs aufgebaut und Regelmeetings definiert, aber der erhoffte Schub an Motivation, Effizienz und Agilität ist damals ausgeblieben.
Auf der Suche nach einer effizienteren Arbeits- und Organisationsmethodik bin ich auf Kanban gestoßen und damit auch sehr schnell auf dieses Buch. Voller Spannung habe ich es gelesen und festgestellt, dass ich viele meiner Probleme und Fragestellungen mit den beschriebenen Methoden lösen konnte. Agilität, KVP, Organisation, Führung, Change Management – alles Themen, die auf jeder Unternehmensagenda stehen. Die vielen Beispiele konnte ich für meine Situation einfach und erfolgreich adaptieren. Wie wir das gemacht haben, können Sie übrigens im zweiten Buch von Klaus Leopold, „Kanban in der Praxis“, nachlesen (und unter diesem Link herunterladen http://bit.ly/2xpBnVu).
Während der Einführung und Umsetzung von Kanban, aber auch heute noch ist dieses Buch immer ein sehr wichtiger Rat- und Ideengeber. Kanban basiert auf wenigen einfachen wie genialen Grundregeln und Prinzipien, die bei konsequenter Anwendung zum gewünschten Erfolg führen. Erfolg heißt, die Kultur in einem Unternehmen nachhaltig in eine Kultur der Verbesserung zu verwandeln. Das Beste daran ist, dass ich jederzeit mit Kanban im Unternehmen starten kann, ohne das Unternehmen revolutionär umzukrempeln. Heute ist Kanban in der IT-Abteilung von STUTE Logistics eine Selbstverständlichkeit und nicht mehr wegzudenken.
Die notwendigen Werkzeuge genauso wie die praktische Anwendung der Methodik sind in diesem Buch auf sehr unterhaltende Weise beschrieben. Es ist keine trockene wissenschaftliche Abhandlung über eine Organisationstheorie, sondern ein Handbuch für den Praktiker, der für sich festgestellt hat, dass eine Organisation mit althergebrachten Methoden kein Zukunftsmodell ist. Organisationen müssen agiler werden und lernen, um in Zukunft zu bestehen.
Wir haben sehr schnell festgestellt, dass Kanban nicht nur für die IT passt, sondern auch für andere Unternehmensbereiche interessant ist. So wurde Kanban rasch auf den Bereich HR ausgerollt, weitere Bereiche sind inzwischen gefolgt. Agilität ist nicht nur etwas für die IT, sondern ein Muss für das gesamte Unternehmen. In diesem Buch finden Sie den Bauplan dafür!
Holger Rieth, IT-Leiter STUTE Logistics (AG & Co.) KG
Jetzt geht unser Buch also schon in die dritte Runde. Vieles hat sich verändert, seit Kanban in der IT 2012 erstmals publiziert wurde. Die Welt scheint sich noch schneller zu drehen – sei es im Business, in der Gesellschaft oder in den diversen agilen Communities. Volatilität, Unsicherheit, Komplexität und Ambiguität haben uns fest im Griff und haben sich mittlerweile sogar zu einer eigenen Formel vereinigt. Um die mit der VUCA-Welt verbundenen Herausforderungen zu meistern, haben in den letzten Jahren immer mehr Unternehmen auf evolutionären Change gesetzt. Kanban hat abseits der IT in anderen Unternehmensbereichen erfolgreich Fuß gefasst.
Im Zuge der damit verbundenen Kundenaufträge und inhaltlichen Diskussionen hat auch unser persönliches Denken und Handeln einen tiefgreifenden Wandel erfahren. Salopp gesprochen haben wir das Gefühl, wieder ein wenig schlauer geworden zu sein, was sich in einigen grundlegend neuen Konzepten niederschlägt: etwa dem sogenannten Flugebenen-Modell, dem Fokus auf Lean Business Agility, der Betonung von Selbstorganisation oder der Renaissance systemischer Zugänge. Zwei neue Bücher, die wir in der Zwischenzeit veröffentlicht haben, sprechen diesbezüglich im wahrsten Sinne des Wortes Bände: Kanban in der Praxis. Vom Teamfokus zur Wertschöpfung (Leopold 2016) sowie Selbstorganisierte Unternehmen. Management und Coaching in der agilen Welt (Kaltenecker 2017) stecken neue Horizonte ab.
In dieser Hinsicht steht die vorliegende dritte Auflage ganz im Zeichen der Spannung. Zum einen spiegelt sich unsere eigene Horizonterweiterung in den beiden aktuellen Fallstudien wider, die Sie am Ende des Buchs finden. Zum anderen haben wir den Hauptteil zwar aktualisiert, die Eckpfeiler jedoch unberührt gelassen. Obwohl wir uns selbst inzwischen kaum noch mit Teams beschäftigen, erscheinen uns die in diesem Buch vorgestellten Landkarten und Werkzeuge nach wie vor nützlich.
Bleibt uns also zu hoffen, dass auch Sie, wie all die Leserinnen und Leser der ersten beiden Auflagen zuvor, wertvolle Orientierungspunkte entdecken. Mögen Sie an unserer Melange Gefallen finden und damit für spannende Zeiten sorgen!
Mit herzlichen Grüßen aus Wien und aus der Welt
Klaus Leopold und Sigi Kaltenecker
Herbst 2017
Klaus Leopold, Informatiker und Kanban-Pionier, hat langjährige Erfahrung als Lean- und Kanban-Berater sowie als Trainer mit ungefähr 1000 Workshop- und Trainings-TeilnehmerInnen pro Jahr. Er berät weltweit tätige Unternehmen bei der Einführung von Lean und Kanban, den damit verbundenen Change-Prozessen und in der Optimierung ihrer Wertschöpfung. Klaus spricht regelmäßig auf renommierten internationalen Konferenzen und wurde 2014 in San Francisco mit dem Brickell Key Award für „outstanding achievement and leadership“ ausgezeichnet. Er veröffentlicht seine aktuellen Gedanken und Erlebnisse in der Welt von Lean, Kanban und Management auf seinem Blog www.LEANability.com und man kann ihm unter @klausleopold auf Twitter folgen.
Siegfried Kaltenecker ist geschäftsführender Gesellschafter der Wiener Unternehmensberatung Loop, die auf agile Veränderung spezialisiert ist. Seit über 20 Jahren ist er für die unterschiedlichsten Unternehmen als systemischer Berater, LeanAgile Trainer und Managementcoach tätig. Zudem ist er Verfasser zahlreicher Fachartikel sowie Autor der Bücher "Selbstorganisierte Teams führen" und "Selbstorganisierte Unternehmen".
Danksagung
Und auch dieses Mal wollen wir wieder jenen Menschen danken, die uns seit der ersten Auflage unterstützt haben bzw. Neues zur 3. Auflage von „Kanban in der IT“ beigetragen haben.
Die ursprüngliche Idee zu diesem Buch stammt von Katrin Dietze, die unermüdlich darauf beharrte, unsere gesammelten Erfahrungen schriftlich zu kanalisieren. Sie ist die Initiatorin und mit ihrem Talent wesentlich dafür verantwortlich, dass dieses Buch viel positives Feedback von den Leserinnen und Lesern bekommen hat. Sie übersetzt unsere wilden Kritzeleien in schöne Illustrationen und macht die Inhalte dadurch leichter fassbar.
Zwischendurch haben wir immer wieder Feedback dazu benötigt, ob wir auf dem richtigen Weg sind. Dieses Feedback haben wir von unseren Reviewern Arne Roock, Elisabeth Blum, Jens Meydam, Katrin Dietze, Markus Andrezak, Sabine Eybl und Holger Rieth bekommen, die uns darüber hinaus für spannende Diskussionen zur Verfügung standen. Außerdem: Danke, Holger, für das Geleitwort!
Ein spezieller Dank geht an Tanja Marongiu und Andreas Haugeneder von Bosch Automotive Electronics sowie Hartger Ruijs und Clemens Riedl von Computest, die sich bereit erklärt haben, unsere gemeinsame praktische Erfahrung in Form von Fallbeispielen für diese Auflage zur Verfügung zu stellen.
Wir möchten uns auch bei David J. Anderson und Barbara Heitger bedanken, deren Know-how eine produktive Steilvorlage bot.
Dolores Omann hilft uns seit der ersten Auflage, unsere Gedanken so klar wie möglich aufs Papier zu bringen und die Texte les- und lieferbar zu machen. Danke!
Natürlich könnten Sie dieses Buch jetzt nicht in Händen halten, wäre da nicht der Carl Hanser Verlag. Herzlichen Dank an Brigitte Bauer-Schiewek für das Engagement in allem, was den Vertrieb unseres Buchs betrifft, und Irene Weilhart für die Hilfestellung in technischen Notfällen.
„Was soll ich tun?“, fragt der Zen-Schüler seinen Meister, als er vor einer hohen Leiter steht.
„Du kannst Sprosse für Sprosse nach oben klettern.“
„Wie viele Sprossen hat die Leiter?“, fragt der Schüler.
„18“, antwortet der Zen-Meister.
„Und was mache ich, wenn ich oben bin?“, will der Schüler noch wissen, während er seinen Fuß bereits auf die erste Sprosse setzt.
„Dann kannst du stehenbleiben“, erklärt der Meister freundlich. „Du kannst die Aussicht genießen. Du kannst wieder heruntersteigen. Oder du kannst ohne Sprossen weiterklettern.“
Dieses Buch ist geschrieben, um Ihnen Mut zum Weiterklettern zu machen. Es berichtet von mehr oder weniger hohen Leitern, von unternehmungslustigen Kletterern und von spektakulären Aufstiegen. Allen Aufstiegen ist gemeinsam, dass sie mit einer ersten Sprosse beginnen und dann Schritt für Schritt weiterführen. Jeder dieser Schritte bedeutet eine kleine Veränderung, durch die Sie neue Erfahrung sammeln und Ihren Überblick verbessern können.
Wir denken, dass die Zen-Geschichte eine würdige Einleitung für ein Buch über Kanban ist. Schließlich geht es auch bei Kanban um eine schrittweise Veränderung. Durch klare Strukturen wird eine sukzessive Verbesserungsarbeit auf den Weg gebracht. Dieser Weg erscheint relativ leicht, viele Hilfsmittel von Kanban erinnern an einfache Leitern. Das sorgt zunehmend für Aufsehen und macht Kanban in der Softwareentwicklung immer populärer.
„Kanban rocks“, wie das einer unserer IT-Kunden begeistert auf den Punkt gebracht hat. Wie viele andere Kanban-Fans hat er dafür triftige Gründe. Kanban
folgt einfachen Regeln,
stützt sich auf leicht nachvollziehbare Mechaniken,
ist mit relativ wenig Aufwand zu implementieren,
kann in kurzer Zeit zu markanten Verbesserungen führen.
Das ist gut und soll auch so bleiben. Trotzdem ist dieses Buch nicht nur für die Kanban-Fankurve geschrieben. Es will auch kritische Aspekte und einige Fallen verdeutlichen, in die Praktiker immer wieder tappen. Um diesen Fallen zu entgehen, möchten wir ein möglichst umfassendes Bild von Kanban Change Management zeichnen. Dazu werden wir verschiedene Ausgangssituationen erkunden, relevante System- und Umweltfaktoren beleuchten und auch die persönlichen Herausforderungen für eine kontinuierliche Verbesserungsarbeit identifizieren. Schließlich geht es mit Kanban stets ums Ganze. Denn Kanban
setzt zwar beim Team an, hat aber die gesamte Organisation im Auge,
konzentriert sich auf technische Entwicklung und ist dabei immer auf wirtschaftliche Wertschöpfung ausgerichtet,
will Softwareentwicklungsprozesse verbessern, braucht dafür aber die Veränderungsbereitschaft von allen, die von diesen Prozessen betroffen sind,
ist rasch einzusetzen, erfordert jedoch tiefergehende Einsichten, damit das vorhandene Potenzial konsequent entfaltet werden kann.
Es ist relativ einfach, in Ihrem Arbeitsbereich eine Kanban-Initiative zu starten. Es ist jedoch durchaus anspruchsvoll, Ihre Initiative so fortzusetzen, dass Sie eine Kultur der kontinuierlichen Verbesserung schaffen. Wie die Praxis zeigt, sorgt eine quick-fix-orientierte Kanbanisierung eines Arbeitsbereichs selten für einen nachhaltigen Kulturwandel. Um einen solchen zu bewirken, brauchen Sie professionelles Change Management.
Was uns wichtig ist
„Kanban in der IT“ möchte Ihnen alle wesentlichen Aspekte vermitteln, damit Sie das Veränderungsmanagement mit Kanban richtig verstehen und optimal einsetzen können. Dafür bieten wir Ihnen jede Menge Landkarten, Werkzeuge und vor allem Praxisfälle. Einerseits greifen wir auf unsere eigenen Erfahrungen als Kanban-Coaches und Change-Berater zurück, um Ihnen ein Lernen durch konkrete Fallbeispiele zu ermöglichen. Andererseits setzen wir diese Beispiele mit systemisch infiziertem Interesse ein. Das heißt, wir versuchen Wissenswertes über Organisationen, Kulturen, Strategien oder Emotionen aus der Systemtheorie einzuschmuggeln, ohne Ihnen dadurch den Blick auf die Praxis zu versperren. Denn was hilft die beste Theorie, wenn man hinterher unfähig ist, angemessen zu handeln?
Apropos angemessenes Handeln: Eine von Kimberley-Clark durchgeführte Studie wollte wissen, was die Leute auf eine einsame Insel mitnehmen würden. Über 50 Prozent der 1000 Befragten hielten es für besonders wichtig, Toilettenpapier mitzunehmen. Was lässt sich daraus folgern? Mit dem deutschen Betriebswirtschaftler Günter Ortmann meinen wir: „Die Leute denken praktisch.“ (Ortmann 2011, S. 133)
Auch im Veränderungsmanagement des 21. Jahrhunderts ist praktisches Denken gefragt. In diesem Buch orientiert sich das Denken an acht Grundprinzipien. Das sind einmal die von David J. Anderson propagierten Prinzipien (vgl. Anderson 2010):
Kanban beginnt dort, wo sich ein System gerade befindet. Es braucht keine großen Umstellungen, aufwendige Trainingsprogramme oder Prozessrevolutionen. Sie machen mit einfachen Mitteln Ihre derzeitigen Arbeitsprozesse sichtbar und sind schon zumindest eine Sprosse auf der Zen-Leiter aufgestiegen.
Kanban respektiert die bestehende Ordnung. Weder werden die bestehenden Prozesse per se in Frage gestellt noch die existierenden Funktionen. Respekt heißt in diesem Zusammenhang, dem Bestehenden einen Sinn zuzugestehen – und diesen Sinn gemeinsam mit allen Wertschöpfungspartnern sukzessive zu vermehren.
Kanban strebt inkrementelle, evolutionäre Veränderungen an. Es geht um ein Schritt für Schritt und nicht um den großen Wurf. Und es geht um eine Übereinkunft mit all jenen, die von dieser Veränderungsbewegung essenziell berührt werden. Anders gesagt: Kanban braucht ein gemeinsames Arbeits- und Verbesserungsverständnis zwischen allen Stakeholdern eines bestimmten Wertschöpfungsprozesses, egal ob es sich nun um operative Teams, um Kunden, um Lieferanten, um Eigentümer oder um das Senior Management handelt.
Kanban benötigt Leadership auf allen Ebenen in der Organisation. Damit kontinuierliche Verbesserung funktionieren kann, müssen alle Beteiligten ihre Verbesserungsideen einbringen und auch umsetzen können. Die operativ tätigen Mitarbeiter wissen am besten, was sich in ihrer täglichen Arbeit verbessern soll – fördern wir sie, ihre Sicht mit der vom Management abzugleichen und gemeinsam den nächsten Verbesserungsschritt zu gehen.
Wir denken, dass es über diese Prinzipien hinaus ein profundes Grundverständnis braucht, wie eine Kultur kontinuierlicher Verbesserung geschaffen werden kann. Hierfür sind unserer Ansicht nach folgende Wegweiser maßgeblich:
Kanban ist eine Veränderungsinitiative. Es geht um systemische Verbesserungen, für die nicht Einzelleistungen, sondern die Interaktionen wesentlich sind. Wertschöpfung und Arbeitsqualität steigen durch bessere Strukturen und klarere Spielregeln mit allen relevanten Kooperationspartnern.
Kanban geht es um die gesamte Arbeitskultur. Die Verbesserung dieser Kultur erfordert eine kritische Reflexion der eigenen Grundhaltungen, die sich in einem bestimmten Leistungs- und Kooperationsverhalten ausdrücken. Das erfordert wiederum die Bereitschaft zu einer kontinuierlichen Arbeit an der eigenen Entwicklung.
Kanban dreht sich um Menschen und nicht um Mechaniken. Es sind die Menschen, die eine nachhaltige Verbesserungsarbeit vorantreiben – und sie tun dies ganz wesentlich durch Emotionen: Freude, Mut, Begeisterung, aber ebenso Ärger, Enttäuschung oder Trauer. Wir empfehlen dringend, diese Emotionen zu respektieren und zu nützen – schließlich dürfen sie als Motor von Veränderung betrachtet werden.
Kanban ist Teamsport. Um eine Kultur kontinuierlicher Verbesserung zu schaffen, brauchen Sie Verbündete. Sie brauchen Partnerinnen und Partner, die mit Ihnen neue Werte ins Leben rufen und am Leben erhalten. Sie brauchen die Unterstützung Ihres Managements, da Sie systemische Probleme sichtbar machen und auch lösen wollen. Und Sie müssen Ihre Stakeholder im Boot haben, da Sie ohne deren aktive Kooperation nicht den gewünschten Mehrwert schaffen können.
Diese Wegweiser unterstreichen die Komplexität des Veränderungsfelds, das mit Kanban gestaltet wird. Das erfordert ein Vorgehen, das dieser Komplexität gewachsen ist, und erklärt, warum es sich in der Regel nicht empfiehlt, einfach mal mit Kanban loszulegen. Damit riskieren Sie, dass es bei kurzfristigen Veränderungsschritten bleibt und das langfristige Verbesserungspotenzial nicht genutzt wird. Mit der Einleitungsgeschichte gesprochen: dass Sie spätestens nach zehn Sprossen wieder absteigen und gar nicht zum Weiterklettern kommen.
„Drum prüfe, wer sich ewig bindet“, meinte eine Kollegin einmal, als es um die Unendlichkeit dieses Weiterkletterns ging. Prüfen Sie also sorgsam, bevor Sie sich auf eine solche Bindung einlassen. Klären Sie mithilfe unserer Leitfäden Ihre Ausgangssituation, bevor Sie Ihr Kanban-Abenteuer starten. Versuchen Sie herauszufinden, auf welcher Unternehmenskultur Sie aufsetzen. Und stellen Sie sich ein für Ihre persönliche Arbeitssituation maßgeschneidertes Trainingsprogramm aus den von uns angebotenen Übungen zusammen.
Für wen dieses Buch geschrieben ist
Wir möchten „Kanban in der IT“ vor allem drei Zielgruppen an Herz und Hirn legen:
Allen, die sich grundsätzlich für Kanban interessieren: „Hey, das ist ein cooles Ding! Was genau ist das eigentlich? Und was ist Kaizen?“
Allen, die mit dem Management von Veränderungen in der IT beschäftigt sind: „Welche Ansätze gibt es? Was sind die Besonderheiten kontinuierlicher Verbesserungsarbeit? Was könnte ich mir vom Kanban Change Management abschauen?“
Allen, die eine Kanban-Initiative ins Auge fassen oder bereits vorantreiben: „Was gilt es zu beachten? Wie machen das andere? Was könnte ich selbst auch einmal ausprobieren?“
Unseren drei Zielgruppen entspricht die Dreiteilung des Buchs.
Im ersten Teil geht es um die Grundlagen von Kanban: Von welchen Annahmen wird ausgegangen? Wie wird das Bestehende visualisiert? Wozu dienen WIP-Limits? Was sind Serviceklassen? Wie können Sie Metriken einsetzen? Und vieles mehr. Teil 1 möchte also die prozesstechnische Basis von Kanban festigen und erläutert die dafür notwendigen Mechaniken.
Im zweiten Teil holen wir ein wenig aus, um den Kontext von Kanban Change Management zu erhellen: Welche Veränderungsoptionen gibt es überhaupt? Was wird dabei alles in Bewegung gesetzt? Welche Folgen hat das für ein Unternehmen? Und welche besonderen Chancen bietet eine von Kanban inspirierte Veränderungsarbeit? Abseits von mechanistischen Formeln und Verbesserungsautomatismen wollen wir Ihnen in Teil 2 ein zeitgemäßes Verständnis professioneller Veränderungsarbeit vermitteln. Change mag zwar in aller Munde sein – wir sind jedoch davon überzeugt, dass das Thema nachhaltige Verbesserung weder gegessen noch verdaut ist.
Im dritten Teil verbinden wir das technische System Kanban mit dem sozialen System Unternehmen und zeigen anhand ausgewählter Fallbeispiele, wie Sie eine Kultur kontinuierlicher Verbesserung aufbauen können. Wie können Sie Ihre Initiative starten? Wie erkunden Sie Ihre spezifische Ausgangssituation? Wie gestalten Sie ein für Ihren Arbeitsbereich maßgeschneidertes Kanban-System? Worauf achten Sie im Betrieb? Teil 3 bietet Ihnen eine Fülle von Erfahrungswerten, wie Kanban in unterschiedlichen Situationen eingesetzt wird.
„Ob es besser wird, wenn es anders wird, weiß ich nicht“, meinte der deutsche Philosoph Lichtenberg einmal. „Dass es aber anders werden muss, wenn es besser werden soll, weiß ich.“ In diesem Sinne wünschen wir Ihnen eine möglichst erkenntnisreiche Lektüre. Und viel Erfolg bei der Umsetzung: Möge die Übung gelingen!
Kennen Sie „Modern Times“ von Charlie Chaplin? Es gibt darin eine berühmte Szene: Der Vorsitzende des Unternehmens lässt ohne Vorwarnung ständig die Geschwindigkeit der Fließbänder erhöhen: „Fließband fünf läuft zu langsam. Tempo verdoppeln!“ Charlie müht sich nach Kräften ab und schraubt pausenlos fest, was an den vorbeilaufenden Produkten festgeschraubt werden muss. Doch er gerät immer wieder in Rückstand. Bei dieser Geschwindigkeit genügt ein kurzes Niesen, um ihn immer wieder aufs Neue aus dem Takt zu bringen. So kommt Charlie dauernd dem nächsten, hämmernden Fließbandarbeiter in die Quere und bringt den Ablauf durcheinander. Kollegen und Aufseher bugsieren ihn an seinen angestammten Platz, aber es nützt nichts. Er kann mit dem Tempo einfach nicht Schritt halten. Und dann passiert es: Im wilden Schraubeifer kann ihn plötzlich niemand mehr stoppen, er wird über das Fließband gezogen und von der Maschine verschluckt, die die Fließbänder antreibt. Elegant gleitet er zwischen den gigantischen Zahnrädern hindurch, wird dann aber von der Maschine im Retourgang wieder ausgespuckt. Sein Arbeitsunfall hat Spuren hinterlassen: Plötzlich will er alles festschrauben, was im Entferntesten an eine Schraube erinnert. Die Brustwarzen seines Kollegen genauso wie die Rockknöpfe einer Sekretärin.
Chaplins Film war 1936 eine harsche Kritik an den herrschenden Zuständen in der Fertigungsindustrie. Im Vorspann steht zu lesen:
Modern Times. A story of industry, of individual enterprise – humanity crusading in the pursuit of happiness.
(Moderne Zeiten. Eine Geschichte der Industrie, des individuellen Unternehmertums – der Menschheit auf einem Kreuzzug im Streben nach dem Glück. Übersetzung der Autoren)
Wie würde Chaplin diesen Film heute wohl inszenieren? Heute sind meistens Schreibtische und Computer unsere Fließbänder, wir werden besser bezahlt und von den heutigen Sozialleistungen konnten Arbeiter in den 1930er-Jahren nur träumen. Aber auch in unserer von der Wissensarbeit geprägten Gegenwart ruft immer wieder jemand: „Tempo verdoppeln!“ Es scheint, als würde sich die Geschichte wiederholen: Auch heute müssen die Wissensarbeiter wieder für gute Arbeitsverhältnisse kämpfen. Anders als im Zeitalter der Industrialisierung geht es aber nicht mehr um die Mindestanforderungen menschenwürdigen Arbeitens wie Licht, Pausen und Sicherheit. Heute geht es hauptsächlich um den Faktor Zeit und um das Recht, nicht rund um die Uhr für die Firma erreichbar und verfügbar sein zu müssen. Kurzum: Es geht um die Möglichkeit, die anstehende Arbeit auch in der dafür vorgesehenen Arbeitszeit erledigen zu können. Natürlich gibt es aber auch noch die andere Seite der Medaille. Der globale Wettbewerb schafft heute oft unerträglichen Druck und zwingt Unternehmen dazu, zwei Faktoren auf einen Nenner zu bringen: Qualität und Geschwindigkeit. Lässt sich das überhaupt mit den Ansprüchen an eine sozialverträgliche Arbeitswelt vereinbaren? Geht das denn, entspannter zu arbeiten und gleichzeitig produktiver zu sein? Wir sagen: Ja, es geht. Indem man adaptive Systeme schafft, in denen Menschen selbstständig ihre eigenen Wege der Verbesserung finden können.
In der industriellen Fertigung geht es nach dem ökonomischen Prinzip darum, das Verhältnis von eingesetzter Menge (Input) zur ausgebrachten Menge (Output) zu optimieren. „Handle so, dass die angestrebten Leistungen mit einem Minimum an Mitteln erreicht werden (Minimumprinzip) bzw. dass die Leistungen bei gegebenem Mitteleinsatz möglichst groß werden (Maximumprinzip).“ (Zäpfel 1996, S. 37) Man ist also auf der Suche nach der größtmöglichen Produktivität.
Die Idee des Optimierens wird gerne falsch interpretiert, und dann heißt es plötzlich: „Mit möglichst wenig Mitteln soll das Maximum erreicht werden.“ Ironischerweise ist es aber gerade diese Sichtweise, die uns in der Praxis der Wissensarbeit häufig begegnet: In ein System wird bei gleichbleibenden Prozessen, Strukturen und Ressourcen möglichst viel an Input – sprich Aufträgen – hineingestopft. In der Hoffnung, dass am Ende auch möglichst viel wertvoller Output herauskommt.
Peter F. Drucker, einer der Pioniere der modernen Managementlehre, hat dieses Problem bereits vor 30 Jahren vorhergesehen. In seinem Artikel „The New Productivity Challenge“ zeigte er 1991 auf, wie die Produktivität in „making and moving things“ seit Beginn der industriellen Revolution ständig gestiegen ist und damit den Wohlstand vor allem der westlichen Gesellschaft aufgebaut und kontinuierlich genährt hat. Auch in unserer heutigen Zeit steige die Produktivität noch ständig an, aber die großen Revolutionen seien in diesen Sektoren – Produktion, Bergbau, Bauwesen und Transport – vorbei, sagte Drucker damals. Die Arbeitskraft habe sich nämlich aus den klassischen Produktionsbereichen in die Wissensarbeit und Dienstleistung verlagert. Daher stellte Drucker gleich zu Beginn seines Artikels fest, dass die größte Herausforderung für Manager in den nächsten Dekaden darin bestehe, die Produktivität von Wissensarbeitern zu steigern. Diese Herausforderung würde entscheidend für die Wettbewerbsfähigkeit von Unternehmen sein und noch wichtiger: Sie werde das gesellschaftliche Gefüge und die Lebensqualität in jeder Industrienation bestimmen. „The single greatest challenge facing managers in the developed countries of the world is to raise the productivity of knowledge and service workers. This challenge, which will dominate the management agenda for the next several decades, will ultimately determine the competitive performance of companies. Even more important, it will determine the very fabric of society and the quality of life in every industrialized nation.“ (Drucker 1991)
Heute wissen wir, wie recht Drucker damals hatte. Genauso lange ringen wissensintensive Branchen auch darum, den Knopf und die Schrauben zu finden, mit denen sich die Produktivität der Wissensarbeiter erhöhen lässt. Interessanterweise gibt es sehr offensichtliche Parallelen zwischen Optimierungsfragen in der industriellen Produktion und in der Wissensarbeit – wir werden das noch in den einzelnen Schritten von Kanban sehen. Genauso gibt es aber sehr konträre Voraussetzungen zwischen diesen beiden Sektoren. Wie ist Wissensarbeit überhaupt definiert?
Wissensarbeit
Der deutsche Systemtheoretiker Helmut Willke beschreibt Wissensarbeit folgendermaßen:
„Nahezu jede menschliche Tätigkeit ist wissensbasiert in dem Sinne, dass Erfahrung und Wissen eine Rolle spielen. Praktisch jede Facharbeit, vor allem die klassische professionelle Tätigkeit (der Ärzte, Juristen, Lehrer, Wissenschaftler) ist wissensbasierte Arbeit, gründet auf spezialisierter Expertise, die sich die Professionellen in langwierigen Ausbildungsprozessen aneignen müssen.
Der Begriff Wissensarbeit meint etwas anderes. Er kennzeichnet Tätigkeiten (Kommunikationen, Transaktionen, Interaktionen), bei denen das erforderliche Wissen nicht etwa einmal im Leben durch Erfahrung, Initiation, Lehre, Fachausbildung oder Professionalisierung erworben und dann angewendet wird. Vielmehr erfordert Wissensarbeit im hier gemeinten Sinn, dass das relevante Wissen
kontinuierlich revidiert,
permanent als verbesserungsfähig angesehen,
prinzipiell nicht als Wahrheit, sondern als Ressource betrachtet wird und
untrennbar mit Nichtwissen gekoppelt ist, sodass mit Wissensarbeit spezifische Risiken verbunden sind.“ (Willke 1998, S. 20)
Handwerkliche Arbeit unterscheidet sich von der Wissensarbeit also dadurch, dass das Nichtwissen und die nötige Reflexion bei der Wissensarbeit eine schwer beeinflussbare Größe darstellen. Auch die Ausgangsprobleme – also die Aufgaben und Aufträge – sind in Branchen wie der Softwareentwicklung wesentlich facettenreicher als bei der Fertigung von im wahrsten Sinne des Wortes be-greifbaren Produkten. Viel öfter geht es darum, etwas völlig Neues zu erfinden oder etwas Bestehendes weiterzuentwickeln, als einfach etwas Bekanntes zu reproduzieren. Vereinfacht gesagt, lassen sich Denken und Problemlösen nicht einfach standardisieren.
So wie es diesen großen Unterschied gibt, gibt es aber auch eine große Gemeinsamkeit. Egal, ob man Software schreibt oder ein Auto zusammenbaut: Bei beiden Aufgaben muss der oder die Ausführende die Möglichkeit haben, Schritte sinnvoll abzuschließen, bevor etwas Neues begonnen wird, wie auch immer der Prozess in seiner Gesamtheit aussieht.
Wir müssen uns dazu nur einmal vor Augen führen, wie wir praktische Arbeiten in unserem täglichen Leben durchführen. Wenn wir zum Beispiel ein Regal zusammenbauen, ist uns vollkommen klar, dass wir einen Handgriff nach dem anderen machen müssen. Nur die wenigsten werden es wahrscheinlich schaffen, gleichzeitig zu hämmern und zu schrauben. Wir erledigen diese Schritte nacheinander und konzentrieren uns auf eine Aufgabe.
Seltsamerweise verschwindet diese logische Sichtweise auf das Erledigen von Aufgaben, wenn es sich um Wissensarbeit handelt. Hier wird oft davon ausgegangen, dass mehrere Aufgaben von denselben Menschen parallel ausgeführt werden können. Vor allem wandern ständig Aufgaben (z. B. überbordende Administration) in die „Produktionsbereiche“ von Wissensarbeit, die mit dem eigentlichen Kern nichts zu tun haben. Anders als in Produktionsbetrieben bringt es dann auch keinen wesentlichen Produktivitätszuwachs, mehr Geld oder mehr Technologie in den Prozess zu pumpen. Die einzige Möglichkeit in der Wissensarbeit – so sah es 1991 auch Peter F. Drucker – ist es, einfach „smarter“ zu arbeiten, indem man sich auf das wirklich Wesentliche konzentriert. Die Grundlage für eine smarte Arbeitsweise lag für ihn in der Antwort auf die Fragen: „Was ist die Aufgabe? Was versuchen wir zu erreichen? Warum müssen wir es überhaupt machen?“ Der größte Zugewinn an Produktivität in der Wissensarbeit entsteht, wenn wir Aufgabe und Ziel klar definieren und alles das nicht machen, was nicht unbedingt getan werden muss.
Kanban praktisch
Das Seminar in Zürich mit David J. Anderson hatte gerade begonnen. Alle waren sie da, um zu erfahren, wie Kanban funktioniert, und natürlich hatten wir jede Menge Trainingsbeispiele im Ärmel – für die praktische Erfahrung. Und dann schrillte plötzlich der Feueralarm. Keine Übung, es brannte tatsächlich irgendwo im Haus. Also trat die gesamte Truppe die geordnete Flucht in den nächstgelegenen Coffee Shop an. Nach einer kurzen Schrecksekunde ob des plötzlichen Ansturms einer Horde heimatloser Seminarteilnehmer taten die Baristas aber das einzig Logische. „Kaffee?“, rief einer der Angestellten in die Menge und so bildete sich ein Grüppchen der Kaffeedurstigen aus der ungeordneten Masse. Die Hungrigen wurden in eine andere Schlange gereiht und wer gar nichts wollte, setzte sich einfach schon mal hin. Logisch, einfach, effizient – und ziemlich smart. Warum reagierten die Baristas so schnell und effizient? Nun, weil sie einfach wussten, wo in ihren Abläufen der Engpass lag, und das war ganz eindeutig die Kaffeemaschine. Mit diesem Wissen konnten sie ihre Vorgehensweise blitzschnell anpassen. Einen besseren Einstieg – vom Feuer abgesehen – hätten wir uns für das Seminar gar nicht wünschen können.
Ein weiteres Kuriosum im Umgang mit Wissensarbeit ist, dass der Mensch von vielen als jener Faktor gesehen wird, der optimiert werden muss. Unternehmen starten dazu teure Weiterbildungsprogramme und investieren kräftig in den aktuellsten Wissensstand ihrer Mitarbeiter. Grundsätzlich ist das lobenswert, nur bleibt eines dabei unberücksichtigt: Auch wenn ein Mitarbeiter alles weiß, was es in seinem Bereich zu wissen gibt, macht das weder ihn noch das Team zwangsläufig schneller. Trotz allem kann ein Mensch in einem bestimmten Zeitraum nur eine bestimmte Menge an Arbeit bewältigen. Wenn man immer nur den einzelnen Menschen optimieren will, rückt die Tatsache in den Hintergrund, die William Edwards Deming auf den Punkt gebracht hat: 94 Prozent der Leistung in einem Unternehmen hängen von den Bedingungen des Systems ab und nur sechs Prozent von den Mitarbeitern (Deming 2000). Jede wesentliche Verbesserung in Qualität und Produktivität entsteht nach Demings Ansicht durch Maßnahmen, die das System betreffen. So wie auch Peter F. Drucker sagt Deming, dass man Mitarbeitern dabei helfen muss, smarter und nicht härter zu arbeiten.
Das Toyota Production System (TPS) ist das berühmteste Beispiel für permanente Veränderungen und Verbesserungen an einem System. Der Grund, warum Taiichi Ohno und Kiichiro Toyoda so intensiv an der Verbesserung ihres Produktionssystems gearbeitet haben, war ein ähnlicher wie heute in der Softwareentwicklung, die von der Einzelfertigung geprägt ist: Der Markt forderte viele unterschiedliche Modelle in kleinen Stückzahlen. Eine Vielfalt in diesem Ausmaß war mit dem Produktionsmodell, wie es Henry Ford perfektioniert hatte, nicht mehr zu bewältigen. Ford hatte mit der hochgradigen Arbeitsteilung zwar Kosteneffizienz geschaffen, aber es gab keine Möglichkeiten, den für die damalige Zeit revolutionären Verkaufsschlager „Tin Lizzy“ an spezielle Wünsche zu adaptieren. Ohno und Toyoda gelangten zu der Erkenntnis, dass sich das Problem der Variantenfertigung nicht dadurch lösen ließ, Mitarbeiter mit einer noch strikteren – und dadurch noch monotoneren – Arbeitsteilung zu belasten. Und sie hatten noch einen zusätzlichen Anspruch: Sie wollten beste Qualität zu niedrigen Kosten und in der kürzest möglichen Durchlaufzeit liefern.
Also nahmen sie einen neuen Blickwinkel ein und konzentrierten sich auf den Fluss des Produkts durch den gesamten Produktionsprozess. Die ständige Frage nach der Produktivitätssteigerung beantworteten sie mit dem Prinzip, dass nur gemacht werden sollte, was wirklich gebraucht wird – und zwar zu dem Zeitpunkt, zu dem es gebraucht wird, und in der Menge, in der es gebraucht wird (Just-in-Time). Damit hängt auch das Vermeiden von Verschwendung zusammen, wobei Toyota drei Arten von Verschwendung definiert (Ohno, Bodek 1988):
Aufgaben, die Ressourcen verbrauchen, aber keinen zusätzlichen Wert liefern (Muda),
Unregelmäßigkeiten (oder zu hohe Variabilität) im Produktionsprozess (Mura),
Überlastung (Muri).
Das Ziel der „Built-in-Quality“ wird durch „Jidoka“, das sofortige Aufzeigen von Fehlern und Problemen, erreicht. Die Produktion wird sofort gestoppt, sobald ein Fehler auftritt. Denn die Erfahrung zeigt, dass nicht behobene Fehler an anderen Stellen wieder auftreten. Kernelement der Produktionsablaufsteuerung des Toyota Production Systems sind die kanban. „kan“ ist das japanische Wort für Signal, „ban“ bedeutet Karte. Mit diesen Signalkarten zeigen nachgelagerte Produktionsstufen an, dass eine Aufgabe fertiggestellt wurde und Nachschub an Fertigungskomponenten oder Materialien benötigt wird, um weiterarbeiten zu können. Durch dieses Holprinzip (Pull-System) werden Lagerbestände auf ein Minimum reduziert. Gleichzeitig werden sofort Probleme im Produktionsablauf sichtbar, wenn sich in vorgelagerten Produktionsstufen plötzlich die Fertigprodukte stauen. Der Trick dahinter ist nämlich, dass die Zahl der kanban limitiert ist. Es kann also nur so viel Arbeit in das System eingelastet werden, wie Signalkarten zur Verfügung stehen.
David J. Anderson, der Entwickler von Kanban in der IT, fand auf seiner Suche nach Verbesserungsmöglichkeiten in der Softwareentwicklung erst auf Umwegen zum Toyota Production System. Bei seinen ersten Überlegungen ging er hauptsächlich vom Konzept der Drum-Buffer-Ropes in der Theory of Constraints von Eliyahu M. Goldratt aus, die kurz gesagt feststellt, dass jedes System spezifische Engpässe hat, die die Möglichkeiten der Wertschöpfung beschränken. Denn der Engpass bestimmt den Durchsatz (wir werden darauf noch in den Kapiteln 4 und 7 näher zu sprechen kommen). Das hatten auch die Denker von Toyota schon vor Jahrzehnten erkannt und sie sahen den sinnvollsten Weg der Flussoptimierung darin, dass der Engpass selbst bestimmt, wie viel er gerade verarbeiten kann. Kanban in der IT vereint das Beste aus den unterschiedlichsten Denkansätzen, von Anfang an aber gepaart und weiterentwickelt mit und durch Erfahrungen aus der Praxis wie etwa dem Ansatz der evolutionären Veränderung, dem Explizitmachen von Regeln oder den Serviceklassen. Darauf werden wir in den nächsten Kapiteln eingehen. Kanban in der IT ist also keine Übertragung eines einzelnen Konzepts aus der industriellen Fertigung auf die Wissensarbeit, sondern ein Hybrid. Dass sich die Bezeichnung Kanban durchgesetzt hat, ist leicht erklärt: Sie spiegelt die wichtigsten Kernpunkte wider, ist außerdem eingängig und weltweit leicht auszusprechen.
So verwenden wir die Begriffe in diesem Buch
kanban und Kanban
kanban: Ein kanban ist im Wortsinn ein „Anhängeschild“, um die Just-in-Time-Produktion zu ermöglichen und zu sichern. Insgesamt gesehen ist es ein Zeitplanungssystem in Produktionsbetrieben, das bei der Entscheidung hilft, was, wann und in welchen Mengen produziert werden muss. Für die Unterscheidung zu Kanban in der IT verwenden wir in diesem Buch die Kleinschreibung, wenn wir kanban im Sinne des Toyota Production Systems meinen.
Kanban: Das von David J. Anderson entwickelte adaptive System für die Softwareentwicklung. Es unterstützt Veränderung evolutionär, indem bestehende Prozesse sukzessive optimiert werden.
Was verstehen wir unter einem „System“?
System meint im altgriechischen Sinne „das Gebilde, Zusammengestellte, Verbundene“. In der modernen Soziologie bezeichnet es eine sinnvolle Einheit von Elementen, die sich von der sie umgebenden Umwelt unterscheidet. „Ein System ist organisierte Komplexität“, definiert der Vater der soziologischen Systemtheorie Niklas Luhmann (Luhmann 1984, S. 46).
Soziale Systeme sind komplexe Gebilde, die durch Kommunikation produziert und reproduziert werden. Die Gesellschaft sowie all ihre Organisationen und Interaktionen sind gemäß Luhmann „Netzwerk(e) von Kommunikation“. Das macht sie lebendig, aber auch unberechenbar.
Psychische Systeme operieren in Form von Bewusstseinsprozessen, die als eine sinnstiftende Einheit von Wahrnehmen, Denken, Fühlen und Wollen beschrieben werden können. Sie sind untrennbar mit sozialen Systemen verbunden, jedoch kein Teil davon.
Technische Systeme verbinden Elemente, deren Zusammenspiel ebenfalls eine Einheit ergibt. Diese Einheit ist jedoch nicht sinn-, sondern funktionsgetrieben, hochgradig strukturiert und mathematisch berechenbar wie zum Beispiel ein Computer- oder ein Betriebssystem.
Kanban-Systeme bezeichnen die komplexe Wechselwirkung von sozialen, psychischen und technischen Elementen, die auf kontinuierliche Verbesserung ausgerichtet ist. Kaizen, so die japanische Bezeichnung für „Veränderung zum Besseren“, verlangt eine zielorientierte Verbindung von Unternehmen, Mitarbeitern und Arbeitsprozessen.
Als technisches Kanban-System im engeren Sinn verstehen wir die Form der Visualisierung des Arbeitsprozesses (z. B. durch ein Board) und die einzelnen Instrumente (z. B. Tickets, Meetings), mit deren Hilfe man Einblicke in die eigenen Abläufe bekommt. Die Visualisierung symbolisiert gleichzeitig den Ausschnitt aus der Wertschöpfungskette, auf dessen Optimierung wir Einfluss haben. Wichtigstes Kennzeichen eines technischen Kanban-Systems ist, dass es den Work in Progress mengenmäßig limitiert.
Kanban-Team, Team oder Kanban-Gruppe: Damit meinen wir all jene Menschen, die mit einem Kanban-System arbeiten und aktiv die Praktiken von Kanban umsetzen. Eine solche Gruppe ist keine statische Größe, sondern verändert sich auch selbst mit dem Fortschritt von Kanban im Einsatz, wird also größer oder kleiner und kann aus Menschen aus den verschiedensten Bereichen, Abteilungen oder Teams eines Unternehmens bestehen.
Was verstehen wir unter „Stakeholder“?
Der Begriff Stakeholder hat zwei Bestandteile: stake meint im Englischen „Einsatz“, „Anteil“ oder „Anspruch“, holder weist auf eine Person oder Gruppe, die einen Anteil besitzt oder einen Anspruch erhebt.
Im deutschen Sprachgebrauch wird der Begriff Stakeholder meistens im Sinne von „Interessengruppe“ verwendet. Im unternehmerischen Zusammenhang bezeichnet er all jene, die einen bestimmten Einsatz im Organisationsspiel haben. Das erweitert die betriebswirtschaftliche Definition des rein ökonomischen Shareholders (des Eigentümers oder Aktionärs) bewusst um soziale, kulturelle oder ökologische Interessen.
Im systemischen Sinne unterscheidet man zwischen internen und externen Stakeholdern. Streng genommen stehen die Interessengruppen der Mitarbeiter, Manager oder Eigentümer ebenso außerhalb des Unternehmenssystems wie Kunden, Lieferanten, Geschäftspartner, Gläubiger, der Staat oder Nichtregierungsorganisationen.
In diesem Buch meinen wir mit den Stakeholdern eines Wertschöpfungsprozesses demnach immer alle, die an diesem Prozess unmittelbar beteiligt oder von Auswirkungen spürbar betroffen sind. Die Identifikation, Adressierung und Mobilisierung der Stakeholder bildet eines der zentralen Fundamente des von uns entworfenen Kanban Change Managements.
Wenn wir in diesem Buch von Kunden sprechen, bezeichnen wir damit ausschließlich interne Kunden bzw. die internen Vertreter externer Kunden.
Unternehmen in und abseits der Softwareentwicklung versuchen heute, agil und lean zu sein, um im globalen Wettbewerb bestehen zu können. Aber kann man von einem Tag auf den anderen plötzlich agil und lean sein? Kommen wir noch einmal kurz auf das Toyota Production System (TPS) zu sprechen: Die wesentliche kulturelle Komponente des TPS ist der Gedanke der kontinuierlichen Verbesserung – Kaizen. Alle Maßnahmen im Produktionsprozess selbst sind Ausdruck dieses Gedankens bzw. dieser inneren Haltung. In den Fertigungshallen von Ford mussten die Menschen bloß immer schneller werden, indem sie sich ausschließlich auf einen Handgriff konzentrierten und womöglich so verstört endeten wie Charlie in „Modern Times“. Wenn immer nur die Schnelligkeit eines Handgriffs im Vordergrund steht, hat man keine Zeit mehr, sich über Verbesserungen Gedanken zu machen, denn man ist gefangen in der Monotonie. Die Kaizen-Kultur von Toyota hat den Mitarbeitern wieder die Zeit, Verantwortung und Möglichkeit zurückgegeben, Probleme zu erkennen und Verbesserungsvorschläge zu machen. Und damit sprechen wir einen wichtigen Punkt an:
Die Veränderung passiert durch die Menschen selbst.
Wir sehen Kanban nicht als agile Methode der Softwareentwicklung im herkömmlichen Sinn. Es geht nicht darum, Methoden einzuführen – Kanban, Scrum oder XP. Wir glauben, dass es die primäre Aufgabe eines Unternehmens ist, erfolgreich zu sein. Kanban ist ein möglicher Weg und kann dabei helfen, Unternehmen erfolgreich zu machen. Die Methode alleine hilft aber noch nicht, die Menschen müssen sie mit Leben füllen. Sie müssen erkennen, welche Probleme durch das Instrument Kanban sichtbar werden, und entsprechend handeln.
Kanban geht dabei den Weg der ständigen kleinen, evolutionären Schritte. Kanban ist keine Wunderpraktik, die einfach so erfolgreich macht. Es ist der Wandel im Denken und Handeln, der erfolgreich macht. Der wesentliche Unterschied zu vielen agilen Methoden ist die evolutionäre Veränderung. Systeme und Prozesse wurden aus einem bestimmten Grund so geschaffen oder haben sich aus bestimmten Gründen so entwickelt, wie sie zu einem bestimmten Moment aussehen. Die Entwicklung eines Unternehmens ist immer eng mit externen Faktoren verknüpft, die es nicht direkt beeinflussen kann – etwa durch Abhängigkeiten von gesetzlich vorgeschriebenen Entwicklungsstandards wie zum Beispiel in der Luftfahrtindustrie. Doch jedes Unternehmen kann und muss einen Weg finden, um trotz der Restriktionen die eigenen Prozesse laufend zu verbessern, um damit wettbewerbsfähig zu bleiben.
Im klassischen Veränderungsmanagement würden sich Prozessingenieure auf die Suche nach dem optimalen neuen System für ein Unternehmen machen. Sie würden zuerst ein „big picture“ entwerfen, ein Bild davon, wie die Abläufe gestaltet sein sollten, um als Optimum zu gelten und den unterschiedlichsten Anforderungen zu genügen. Meistens ist das ein langwieriger Prozess, der auf dem Wissensstand von heute einen Sollzustand in einer mehr oder weniger weit entfernten Zukunft definiert. Der zweite Schwachpunkt: Diese Überlegungen zum Sollzustand passieren meistens isoliert, abseits von jenen Menschen, die von der Veränderung betroffen sein werden und welche die Probleme in ihrer täglichen Arbeitsumgebung, die Schwächen der Prozesse sehr genau kennen. Die betroffenen Mitarbeiter können im besten Fall bis zu einem gewissen Grad ihre Meinungen und Sichtweisen einbringen, müssen dann aber mit den einmal getroffenen Entscheidungen leben und gezwungenermaßen „besser“ werden. Zu einem bestimmten Zeitpunkt wird das Veränderungskonzept der Organisation offiziell übergestülpt und alle hoffen, dass sich nun wie von magischer Hand alles zum Positiven wenden wird. In diesem Fall haben Organisationsveränderungen nur das Ergebnis im Blick, aber nicht das, was eigentlich schiefläuft. Dabei bleibt unberücksichtigt, dass es immer nur Zustände gibt, die momentan optimal sind. Sie sind aber nicht für alle Ewigkeit gültig. Unberücksichtigt bleibt dabei auch, dass Veränderungen immer Angst hervorrufen.
Nicht jede Veränderung ist gleichzeitig eine Verbesserung. Je größer die Veränderung, desto größer die Angst, die sich mit logischer Argumentation zum Zweck und Nutzen der Veränderung nicht entschärfen lässt. Damit steigt auch die Gefahr, dass anfangs erzielte Erfolge nur Strohfeuer bleiben und schlussendlich durch den aktiven oder passiven Widerstand der überrumpelten Mitarbeiter wieder verloren gehen. Kanban hat also nicht das Ziel, eine abstrakt definierte „optimale“ Arbeitsweise zu etablieren. Vielmehr geht es darum, immer auf der Suche danach zu bleiben, was verbessert werden kann. Das Ziel ist es, schrittweise eine Kaizen-Kultur zu entwickeln, die für das Unternehmen auf ökonomischer und für die in ihm arbeitenden Menschen auf sozialer Ebene bessere Resultate erzielt (vgl. Anderson 2011, S. 19).
Kanban geht davon aus, dass in den bestehenden Prozessen selbst die Kraft der Verbesserung und Weiterentwicklung liegt. Begonnen wird bei den Abläufen und Prozessen, die es zum aktuellen Zeitpunkt gibt. Es wird kein fern in der Zukunft liegender Sollzustand definiert, denn nicht alles in einem bestehenden System ist schlecht. Der gedankliche Kern ist es, Mechanismen im System zu installieren, die laufende Veränderung und Verbesserung möglich machen. Anders als im klassischen Veränderungsmanagement entsteht hier der Weg also im Gehen. Im Laufe des Prozesses sollen alle Beteiligten selbst erkennen, wo die Probleme liegen, was sie können, wie sie sich helfen können, wann und wie sie handeln müssen. Um Missverständnissen gleich vorzubeugen: Nur weil die aktuelle Situation der Ausgangspunkt ist, ist Kanban kein Vorwand, um den Status quo zu wahren. Veränderung muss ständig passieren. Auch wenn Kanban in seinen Instrumenten zunächst sehr einfach aussieht, liegt die Schwierigkeit genau darin, den Kaizen-Gedanken im Wertesystem der handelnden Menschen zu verankern.
Kanban …
… ist ein komplexes, adaptives System. Die Prinzipien lauten:
Starte mit dem, was du jetzt machst.
Verfolge inkrementelle, evolutionäre Veränderung.
Fördere Leadership auf allen Ebenen in der Organisation.
Kanban setzt in seiner Gesamtheit und in allen seinen Elementen darauf, nicht sofort unter größten Anstrengungen aus Zustand A in Zustand B zu gelangen (was oft genug auch nicht gelingt). In kleinen Schritten wird das System optimiert, um zunächst sicher A' zu erreichen. Ist A' erreicht, geht es weiter zu A'' usw. (Bild 2.1). Und genau das sollte eine Kanban-Gruppe zunächst auch messen: den ersten kleinen Schritt.
Bild 2.1Klassische Veränderungsprojekte vs. evolutionäre Veränderung
Es taucht immer wieder die Frage auf, ob denn eine evolutionäre Veränderung, wie sie Kanban vertritt, nicht sehr lange dauere. Die – vermutlich für manche unbefriedigende Antwort – lautet: Ja, kann sein. Es kann aber auch genau das Gegenteil eintreten. Wir haben Erfahrungen mit Teams in der Finanzbranche gemacht, die innerhalb von drei Monaten von wenigen Kanban-Beginnern zu einer Gruppe von 40 Personen angewachsen sind, die ihre Arbeit mit Kanban-Boards koordinieren. Plötzlich reden dort Menschen aktiv und direkt miteinander, die sich zuvor nur vom Namen her gekannt haben. Jetzt besprechen sie ihre Arbeit gemeinsam im Daily Standup, aber eben nicht, weil ihnen jemand gesagt hat, dass sie das tun sollen. Sie sind einfach selbst zu dem Schluss gekommen, dass diese Gespräche ihren Abläufen und den Ergebnissen gut täten.
Wissensarbeit – das Problem der Unsichtbarkeit
Wir haben zu Beginn dieses Kapitels darüber gesprochen, wie sich klassische Produktion und Wissensarbeit in manchen Punkten ähneln und in anderen Punkten unterscheiden. Einer – wenn man es so nennen will – der größten Schwachpunkte der Wissensarbeit ist, dass man im Produktionsprozess nicht sieht, was eigentlich passiert. Die Fertigungsstraße verläuft in den Köpfen der Mitarbeiter, und wie wir wissen, kann man zielführende Denkprozesse nicht standardisieren und nicht steuern. Daraus ergeben sich zwei Probleme:
Weil auch interne und externe Auftraggeber den geistigen Produktionsprozess nicht sehen können, entsteht der Anspruch, dass zum Beispiel Softwareentwickler doch mehrere Dinge gleichzeitig machen sollten.
Auch die Softwareentwickler selbst können nicht sehen, was sich in diesem Produktionsprozess so tut. Sie selbst tappen in die Falle und meinen, dass man mehrere Aufträge gleichzeitig erledigen kann, denn irgendwie geht es doch immer. Die Frage ist jedoch: Zu welchem persönlichen Preis und zu welchen betriebswirtschaftlichen Kosten? In den Fertigungsstraßen von Produktionsunternehmen kann man sehr schnell erkennen, wo der Engpass liegt: nämlich dort, wo sich Zwischenprodukte stauen. In der Wissensarbeit fehlt uns dieser plastische Blick auf die Arbeit, die wir leisten. Engpässe erkennen wir zwar an unseren eigenen panischen Reaktionen, aber es fehlt die Darstellung des gesamten Prozesses, um zu verstehen, an welchen Stellen wir ansetzen müssen, damit wir mit einer Veränderung auch eine Verbesserung bewirken.
Um Ansatzpunkte für Veränderungen und Verbesserungen zu finden, muss daher der Prozess der Wissensarbeit aus dem Schattendasein geholt und dargestellt werden. Erst das Sichtbarmachen der Arbeit schafft das Bewusstsein für die Begrenztheit und maximale Auslastungsmöglichkeit von Kapazitäten.
Womit wir bei den Kernpraktiken von Kanban angelangt wären – also jenen Punkten, die für das Funktionieren dieses adaptiven Systems unbedingt berücksichtigt werden sollten. Grundsätzlich macht Kanban sehr wenige Vorschriften, wie etwas gemacht werden soll. Kanban macht eher Vorschläge, dass etwas gemacht werden sollte. Vorschriften wären kontraproduktiv, da eben die in einem System arbeitenden Menschen selbst erkennen sollen, was in welcher Form verändert werden muss. Es sind sechs Kernpraktiken, die eine Kanban-Implementierung erfolgreich machen:
Mache Arbeit sichtbar
Limitiere den Work in Progress (WiP)
Manage Flow
Mache Prozessregeln explizit
Implementiere Feedback-Mechanismen
Führe Verbesserungen basierend auf Methoden und Modellen durch
1. Mache Arbeit sichtbar
Ziel von Kanban ist es, einen kontinuierlichen Arbeitsfluss zu etablieren, der am Ende einen Mehrwert beim Kunden generiert. Kanban hilft, die Abläufe der Wissensarbeit und dadurch Probleme sichtbar zu machen, die den Arbeitsfluss behindern. Durch die Einführung mengenmäßiger Beschränkungen (WiP-Limits) der Arbeit wird auch deutlich, was das System ins Stocken bringt und die Beteiligten daran hindert, Arbeiten abzuschließen. Genau das ist auch bei dem vorhin erwähnten Team passiert: Durch die Visualisierung des Arbeitsflusses wurde deutlich, dass bestimmte Personen im Unternehmen direkt miteinander kommunizieren mussten, um ihre Abläufe zu verbessern.
Der wesentliche Unterschied von Kanban zu gängigen Arbeitsweisen ist außerdem, dass Arbeit nicht in den nächsten Bearbeitungsschritt „weitergeschoben“ wird (Push-Prinzip), sobald ein Teammitglied damit fertig ist. Vielmehr holen sich die Teammitglieder der nachfolgenden Stufen aus dem vorgelagerten Arbeitsschritt die Arbeit, sobald sie dafür Kapazitäten zur Verfügung haben (Pull-Prinzip).
2. Limitiere den Work in Progress (WiP)
Aus dem traditionellen Produktionsmanagement wissen wir: Unfertige Produkte sind gebundenes Kapital. Daher ist jedes Produktionsunternehmen bestrebt, den Bestand an Halbfertigprodukten möglichst gering zu halten. Auch hier haben wir die Schwierigkeit, dass der Wert physisch greifbarer Produkte leichter zu beziffern ist als das, was sich in den Köpfen von Softwareentwicklern erst noch formieren muss. Allerdings gilt sowohl für die klassische Fertigung als auch für die Wissensarbeit: Je größer die Anzahl der aktiven Arbeiten im System ist, desto höher sind die Durchlaufzeiten. Machen wir es an der Verrechenbarkeit fest: Was fertig ist und ausgeliefert werden kann, kann fakturiert werden und bringt somit Geld ins Unternehmen. Ökonomisch gesehen ist es daher schlauer, eine Arbeit zu 100 Prozent abzuschließen als zehn Arbeiten zu lediglich 10 Prozent. Um die Durchlaufzeiten zu senken und einen kontinuierlichen Arbeitsfluss zu etablieren, ist es also sinnvoll, die Zahl der Arbeiten zu beschränken, die gleichzeitig in einem Arbeitsschritt ausgeführt werden. Wir sprechen dabei von einer Limitierung des „Work in Progress“ oder ganz einfach von den „WiP-Limits“. In Bild 2.2 wird der Zusammenhang zwischen der Zahl der parallelen Arbeiten und den Durchlaufzeiten deutlich.
Bild 2.2Sequenzielle vs. quasi-parallele Arbeit
Die Abbildung zeigt, wie sich drei Arbeiten sequenziell und quasi-parallel abarbeiten lassen. Quasi-parallel bedeutet, dass ständig zwischen den drei Aufgaben gewechselt wird, weil Menschen nicht in der Lage sind, mehrere aktive Aufgaben gleichzeitig durchzuführen. Man sieht, dass bei der sequenziellen Vorgehensweise (den drei großen Blöcken in der Abbildung) die Aufgaben in jeweils fünf Zeiteinheiten abgearbeitet werden – die Durchlaufzeit beträgt demnach fünf Zeiteinheiten pro Aufgabe. Bei quasi-paralleler Abarbeitung erhöhen sich die Durchlaufzeiten auf 16, 17 und 18 Zeiteinheiten. Der ständige Aufgabenwechsel fordert einen zusätzlichen Aufwand, da sich das Projektmitglied immer wieder aufs Neue in die Aufgaben einarbeiten muss – in einem klassischen Produktionsprozess wären das die Rüstzeiten für die Umjustierungen von Maschinen. Der Zusatzaufwand ist in diesem vereinfachten Beispiel mit einer Zeiteinheit pro Aufgabe quantifiziert.
Neben der Minimierung gebundenen Kapitals im Prozess und der Senkung der Durchlaufzeiten bringt eine Limitierung des Work in Progress noch einen Vorteil, der direkt mit dem Ziel der ständigen Verbesserung zusammenhängt. In einem WiP-limitierten Pull-System werden die Engpässe sichtbar: Der in den Engpass involvierte Mitarbeiter kann keine Arbeit vom Vorgänger abholen, weil er noch mit der aktuellen Aufgabe beschäftigt ist. Und da der Vorgänger durch ein WiP-Limit beschränkt ist, kann er sich auch keine Arbeit von seinem Vorgänger abholen. Als Konsequenz wird der Arbeitsfluss blockiert und Kollegen werden am Weiterarbeiten gehindert. WiP-Limits sind also im Grunde die Voraussetzung, um ein Pull-System – wie es die Prinzipien der Lean Production vorsehen – überhaupt entstehen zu lassen.
Einer der wohl wichtigsten Vorteile von WiP-Limits betrifft das Verhältnis zu den Kunden. Nicht eingehaltene Zusagen belasten nachhaltig die Kundenbeziehungen – sei es zu externen Kunden oder zu Kollegen im Unternehmen – und können dem Image auf lange Sicht schaden. Nicht nur in der Softwareentwicklung kommt es oft genug vor, dass Arbeiten parallel laufen und dadurch die Zeit zu knapp wird. Meistens wird dann versucht, Termine hinauszuschieben, oder es werden bewusst Abstriche in der Qualität hingenommen. Was dabei oft vergessen wird: All diese Abstriche in der Qualität kommen in der einen oder anderen Form wieder zurück. Entweder als Beschwerden, als Fehlermeldungen oder Änderungswünsche, die wiederum den aktuellen Arbeitsprozess stören, ins Stocken bringen und damit die Durchlaufzeiten aller anderen Aufgaben wieder erhöhen. In Kanban ist es das Ziel, nur solche Zusagen zu treffen, die man halten kann. Dazu gehört es auch, „nein“ zu sagen, wenn zusätzliche Aufgaben das WiP-Limit sprengen würden.
3. Manage Flow
In Kanban wird der Fokus auf den Arbeitsfluss gelegt. Das heißt, alles, was die Arbeit beim Fließen behindert, wie zum Beispiel Blockaden und Engpässe, bekommt besondere Aufmerksamkeit. Das Motto lautet: Arbeite zuerst an deinen Problemen, bevor du neue Arbeiten startest. Des Weiteren wollen wir mit unseren Partnern Vereinbarungen eingehen, die wir einhalten können, und damit das gegenseitige Vertrauen fördern. Um Zusagen und Vereinbarungen treffen zu können, muss man wissen, wozu man überhaupt fähig ist. Auch wenn wir etwas ändern, wollen wir sehen, ob sich die Änderungen bewährt haben. Dafür müssen wir messen, ob wir uns den definierten Zielen genähert haben. Das bedeutet aber nicht, dass wir die Leistung einzelner Mitarbeiter messen, sondern die Leistung unseres Kanban-Systems. Wir wollen also überprüfen, ob wir die Kapazitäten und Abläufe in unserem Ausschnitt der Wertschöpfungskette so gestaltet und aufgebaut haben, dass sie den an uns gestellten Aufgaben gerecht werden. Wenn es den Aufgaben nicht gerecht wird, muss man es weiter verändern – das ist die Grundlage einer Kaizen-Kultur.
Änderungen am Verhalten vs. Änderungen am System
Probleme im Arbeitsfluss können wir aus zwei Perspektiven betrachten. Treten zum Beispiel Qualitätsprobleme in der Programmierung auf, ist eine mögliche Reaktion darauf: „Programmiert besser!“ Damit wird nur auf die Skills der Mitarbeiter abgestellt. Es wird dabei aber nicht berücksichtigt, dass ein Mitarbeiter in seiner Leistung auch von seiner Umgebung abhängig ist, also von den Einflüssen und Störungen, die während seiner Arbeit auf das System einprasseln, in dem er sich bewegt.
Eine andere Herangehensweise im konkreten Beispiel wäre die Aussage: „Setzt Test Driven Development ein. Schreibt zuerst einen Testfall und programmiert danach.“ Oder man verkürzt die Feedbackschleifen zwischen Programmierung und Test. Hier handelt es sich um systemische Änderungen: Man baut die sozialen und technischen Systeme so um, dass gute Qualität geliefert werden kann.
Kanban zielt darauf ab, einen schnellen, vorhersehbaren und stetigen Arbeitsfluss zu etablieren. Für die Steuerung des Arbeitsflusses müssen wir zuerst identifizieren, welche Arbeitstypen ein Team überhaupt in der Regel erledigen muss. Um den Arbeitsfluss steuern zu können, müssen wir uns auch darüber im Klaren sein, dass nicht alle Aufgaben den gleichen Grad an Dringlichkeit haben. Daher führen wir in einem Kanban-System Serviceklassen ein. Ein Prinzip, das uns bei greifbaren Leistungen einleuchtet: Paketdienste bieten zum Beispiel unterschiedliche Behandlungen von Paketen an, je nachdem, ob sie schnell ihr Ziel erreichen müssen oder ob die Zustellung nicht so dringend ist. Dementsprechend werden auch die Routen der Fahrer geplant.
Arbeitstypen und Serviceklassen bilden die Grundlage für Service Level Agreements (SLAs). Damit gibt das Team die Garantie ab, Arbeiten einer gewissen Serviceklasse oder eines gewissen Arbeitstyps innerhalb eines definierten Zeitraums fertigzustellen. Das gibt den Stakeholdern eine hohe Planungssicherheit, da Teams meist eine SLA-Zuverlässigkeit von über 90 Prozent aufweisen.
Die gemeinsame Klammer aller Maßnahmen zur Steuerung und Messung des Arbeitsflusses ist die Kommunikation. Für Teams sind zum Beispiel sogenannte Daily-Standup-Meetings wichtig, in denen die Teammitglieder die Arbeiten am Board besprechen. Das Ziel der Meetings ist es, die Arbeiten zu koordinieren und den Arbeitsfluss aufrechtzuerhalten.
4. Mache Prozessregeln explizit
Die Arbeitsweise eines Kanban-Teams kann als eine Menge von Regeln betrachtet werden, die sich ein Team selbst auferlegt. Diese Regeln werden für alle Beteiligten transparent gemacht und müssen eingehalten werden. Das hat zwei Effekte:
Nur wenn Team und Stakeholder Regeln einhalten, können auch Fehler oder Aspekte in einer Regel erkannt werden, die (manchmal spontan) verändert werden müssen. Das Training, das wir ins Kaffeehaus auslagern mussten, ist dafür ein hervorragendes Beispiel. Die Baristas haben sofort erkannt, dass die Regel „Alle stellen sich in einer einzigen Reihe an, egal wer welche Bestellung aufgeben will“ nicht mehr zweckmäßig ist, wenn statt fünf Kunden plötzlich 25 den Tresen stürmen. Eine der ersten Regeln lautet: Sobald ein Problem auftritt, muss es gelöst werden. Die Regeln selbst sind davon nicht ausgenommen: Ist eine Regel nicht mehr sinnvoll, wird die Regel geändert. Sobald wir Regeln und Standards nicht mehr ändern, stoppen wir den Verbesserungsprozess.
Regeln nehmen einen großen Teil der Emotionen aus Diskussionen heraus. Man gelangt von subjektiven Schuldzuweisungen an Personen zu wesentlich objektiver geführten Diskussionen über Regeln. Damit steigt die Wahrscheinlichkeit, bei Streitthemen auch zu einem Konsens zu gelangen. Dieser Effekt tritt nicht immer sofort ein. Es kommt zu Beginn oft vor, dass den bisherigen Gewohnheiten entsprechend nach einem Schuldigen dafür gesucht wird, wenn eine Regel nicht eingehalten wurde. Deswegen ist in der Einführungsphase von Kanban eine professionelle Begleitung dieser Gespräche sinnvoll. Zumindest muss jemand die Verantwortung dafür übernehmen, die Diskussion auf die sachliche Ebene zu heben – auf die Ebene der Diskussion über die Regel und nicht über einzelne Menschen.
5. Implementiere Feedback-Mechanismen
Bei Kanban dreht sich alles um die kontinuierliche Verbesserung, dabei spielt Lernen eine entscheidende Rolle. Damit wir fähig sind, etwas zu lernen, benötigen wir Feedback, um zu sehen, was wir besser machen können. Viele Unternehmen setzen dabei zum Beispiel auf Daily-Standup-Meetings, bei denen einmal am Tag Feedback über die aktuelle Arbeitssituation ausgetauscht wird. Wir empfehlen, dass diese Treffen nicht nur auf Teamebene stattfinden, sondern übergreifend über die gesamte Wertschöpfungskette. Um die Anzahl der Teilnehmer und Teilnehmerinnen gering zu halten, werden dabei meist Delegierte aus den einzelnen Teams gesendet, die sich mit den anderen Teams vor dem Board koordinieren. Ein weiterer wichtiger Feedbackmechanismus sind Retrospektiven, also gezielte Verbesserungsmeetings. Auch hier gilt: Je breiter das Teilnehmerspektrum, desto besser das Feedback. Operations Reviews werden häufig für das unternehmensweite Lernen von Metriken verwendet. Was auch immer dabei hilft, qualitativ hochwertiges Feedback über die wirklichen Arbeitsabläufe zu erhalten, sollte in den Arbeitsalltag integriert werden, um zu lernen und um besser zu werden.
6. Führe Verbesserungen basierend auf Methoden und Modellen durch
Verbesserung bedeutet nicht, dass man das Rad ständig neu erfinden muss. Bei einer Vielzahl von Problemen kann man auf Ansätze und Modelle zurückgreifen, die Problematiken beleuchten, die in sämtlichen Systemen immer wieder auftreten und sich daher in der Praxis bereits bewährt haben. So ist Kanban selbst eine Adaptierung vorhandener Praktiken und Ideen – zum Beispiel aus der Automobilindustrie – für die Zwecke der Softwareentwicklung im Speziellen und Wissensarbeit im Allgemeinen. Für die Basisüberlegungen zu Kanban hat David J. Anderson einige passende und erprobte Theorien gefunden wie die bereits erwähnte Engpasstheorie von Eliyahu M. Goldratt, das ökonomische Wissen über Verschwendung zum Beispiel in Form von Transaktions- und Koordinationskosten oder über die Einflüsse von Variabilität auf ein System.
Trotzdem schreibt Kanban nicht vor, welche Modelle und Methoden angewendet werden müssen, weil Anforderungen und Situationen in jedem Unternehmen anders sind. Kanban schreibt auch nicht vor, wie Modelle und Methoden angewendet werden sollen. Es gibt keine Aussagen zu richtig oder falsch. Alleine in der Art und Weise der Visualisierung gibt es so viele Möglichkeiten, wie es Unternehmen auf der Welt gibt, die Kanban einsetzen.
Umsetzung der Kernpraktiken im Unternehmen
Der „Mangel“ an Vorschriften ist einerseits die große Freiheit, die Kanban in den einzelnen Anwendungsfällen lässt, weil die Grundlage für die Veränderung hin zur Verbesserung die bestehenden Prozesse in einem System sind. Strikte Vorschriften wären auch widersinnig, weil die Situationen in Unternehmen zu vielfältig sind: Die Softwareentwicklung eines Webshops funktioniert nach anderen Gesetzen als etwa die Entwicklung einer Signalsteuerung im Zugverkehr. Andererseits ist es natürlich auch die Schwäche von Kanban aus Sicht jener, die auf der Suche nach Patentrezepten und Best Practices sind. Aber dadurch wird der Kern von Kanban definiert:
Kanban anzuwenden bedeutet nicht, vorgegebene Regeln zu befolgen. Kanban hilft, die eigenen Arbeitszusammenhänge zu verstehen, und fördert auf dieser Basis das kontextspezifische Lernen. Nachdenken ist dabei ausdrücklich erlaubt!
