Kanban E-Book

David J. Anderson

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Serie: Better with Kanban
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Seitenzahl: 502

Beschreibung

Know-how und Must-have für die Kanban-Praxis - Know-how und Must-have für die Kansan-Praxis - Inspirierend geschrieben und direkt anwendbar - Band 1 der umfassenden und maßgebenden Buchreihe »Better with Kanban« David J Anderson beschreibt in diesem Buch die Ursprünge und den Grundgedanken der Kanban-Methode und wie die Konzepte aus der physischen Industrie für die moderne Wissensarbeit des 21. Jahrhunderts angepasst und übernommen wurden. Darüber hinaus werden die Praktiken, Prinzipien und Werte der Kanban-Methode anhand realer Fallstudien von Microsoft und zwei weiteren Technologieunternehmen aus Seattle und San Francisco erläutert, die kritischen Elemente eines erfolgreichen organisatorischen Wandels aufgezeigt und das Kanban-Reifegradmodell vorgestellt. Die präsentierten Konzepte bilden die Grundlage für die gesamte Kanban-Methode und die neue Buchreihe »Better with Kanban«. Das Buch ist ein Muss für alle Führungskräfte und Projektverantwortlichen in der Wissensarbeit – ganz gleich, ob Sie ein erfahrener Kanban-Praktiker sind, ob Sie bereits nach der Kanban-Methode zertifiziert sind und nach weiteren Anleitungen suchen oder ob Sie ein Neueinsteiger sind, der sich ein solides Verständnis der Kanban-Methode aneignen möchte.

Leseprobe

David J Anderson ist ein Innovator von Managementkonzepten für Unternehmen des 21. Jahrhunderts. Er ist Autor und Pionier der Kanban-Methode und verfügt über mehr als 30 Jahre Erfahrung in der Hightech-Branche. David J Anderson arbeitete früher bei IBM, Sprint, Motorola und Microsoft, wo er die Kanban-Methode entwickelte, um die Geschäftsergebnisse auf Unternehmensebene signifikant zu verbessern.

Er ist der Begründer der Kanban-Methode und Mitentwickler des Kanban Maturity Model, des Fit-for-Purpose-Frameworks und Enterprise Services Planning und einer der weltweit führenden Anbieter von Managementschulungen und Führungskräfteentwicklung in den Bereichen professionelle Dienstleistungen und immaterielle Güter.

Er ist Autor von sieben Referenzwerken für moderne Unternehmen; das bekannteste, Kanban: Successful Evolutionary Change for Your Technology Business, wurde 2010 veröffentlicht und gehört zu den fünf meistverkauften Büchern zu Agilität aller Zeiten.

David J Anderson gründete außerdem die Kanban University, zu der über 400 akkreditierte Trainer und Berater gehören. Darüber hinaus hat er mehrere globale Kanban-Konferenzen organisiert und ist Vorsitzender der David J Anderson School of Management, die Schulungen zu Geschäftspraktiken des 21. Jahrhunderts für Business-Agilität, Unternehmensresilienz und organisatorische Reife anbietet.

Die von David gegründete Unternehmensgruppe ist Teil der Mauvius Group Inc. Diese Unternehmensgruppe konzentriert sich auf die Verbesserung der Qualität von Management, Führung und Entscheidungsfindung für Unternehmen des 21. Jahrhunderts.

Die Übersetzer:

Sven Günther ist akkreditierter Kanban-Trainer und akkreditierter Kanban-Consultant bei der it-agile GmbH in Hamburg. Er unterstützt Unternehmen dabei, ihre Services mithilfe von Kanban so zu gestalten, dass diese die Erwartungen der Kunden erfüllen.

Seine berufliche Laufbahn begann er mit der Entwicklung und Reparatur elektronischer Baugruppen. Er studierte an der Fachhochschule Brandenburg Informatik mit den Schwerpunkten Softwareentwicklung und Mikroprozessortechnik. Seit 1997 entwickelt Sven Software in den Sprachen Java und C sowohl im Enterprise-Umfeld als auch für mobile Geräte. Agile Entwicklungsmethoden hat er 2007 für sich entdeckt und ist seitdem begeistert von ihnen.

Nach einem anstrengenden Arbeitstag entspannt er sich gerne bei seiner Familie. Sven schaltet am liebsten beim Klavierspielen ab und lässt so den Stress des Tages hinter sich. Den Rest seiner Zeit widmet er seiner Frau und seinen zwei Hunden.

Wolfgang Wiedenroth ist akkreditierter Kanban-Trainer und akkreditierter Kanban-Consultant bei der it-agile GmbH in Hamburg. Er packt bei Kunden mit an, wenn es darum geht, den Arbeitsfluss zu optimieren. Die Kanban-Methode und Lean-Prinzipien unterstützen und leiten ihn dabei. Erfolg bedeutet für ihn, wenn Veränderungen eine positive Wirkung für Kunden, Mitarbeiter und Organisation erzielen.

Wolfgang ist regelmäßiger Sprecher auf Konferenzen und bei User Groups sowie Autor zahlreicher Artikel zu Kanban und Flight Levels. Als Co-Übersetzer hat er mehrere Bücher zum Thema Kanban und Leadership übersetzt.

In seiner Freizeit verbringt er am liebsten Zeit mit seinen zwei Söhnen und seiner Frau. Neigt der Tag sich dem Ende zu, entspannt er sich gerne mit einem Glas Single Malt Whisky auf dem Sofa und schaut dabei American Football.

David J Anderson

Kanban

Der evolutionäre Weg zu agilen Organisationen

Aus dem Englischen von Sven Günther und Wolfgang Wiedenroth

David J Anderson · [email protected]

Lektorat: Christa Preisendanz

Übersetzung: Sven Günther · [email protected]

Wolfgang Wiedenroth · [email protected]

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz & Layout: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Eva Hepper, Silke Braun

Original Coverdesign: Nastya Kondratova

Fotos auf S. 2/3 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:

Print

978-3-86490-986-3

PDF

978-3-98890-105-7

ePub

978-3-98890-106-4

1. Auflage 2024

Translation Copyright für die deutschsprachige Ausgabe © 2024

dpunkt.verlag GmbH

Wieblinger Weg 17 · 69123 Heidelberg

Copyright © 2023 Kanban University Press

Title of the English Original: Discovering Kanban: The Evolutionary Path to Enterprise Agility

(Book One in the Better with Kanban series), ISBN 978-1-960442-08-6

Translation Copyright © 2024 by dpunkt.verlag. All rights reserved.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben,

lassen Sie es uns wissen: [email protected].

CMMI und Capability Maturity Model sind eingetragene Warenzeichen

im US Patent and Trademark Office by ISACA®.

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 noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

Copyright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Für Nicola, Natalie & Nastya

In Erinnerung an Mikiko

Geleitwort zu Kanban1

Ich habe die Arbeit von David Anderson immer im Auge behalten. 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 der Titel schon vermuten lässt, 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 bahnbrechende 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 dann zu versuchen, die Welt 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 mir sicher, dass David die richtige Richtung eingeschlagen hat. Besonders begeistert bin ich von seinen neueren Arbeiten mit Kanban-Systemen. Für die Produktentwicklung hatte ich die Ideen der Lean Production immer hilfreicher 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 nach wie vor überzeugt.

Bei unserem Treffen 2005 bestärkte ich David darin, 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 Leistungssteigerung bei Toyota resultierte 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, indem sie den Work in Progress begrenzten.

Als ich 2007 Corbis besuchte, sah ich eine beeindruckende Implementierung eines Kanban-Systems. Ich machte David darauf aufmerksam, dass er weit über den bei Toyota genutzten Kanban-Ansatz hinausgegangen war. Was meinte ich damit? Das Toyota-Produktionssystem ist daraufhin optimiert, mit sich wiederholenden und vorhersagbaren Aufgaben umzugehen – Aufgaben von gleichbleibender Dauer und mit gleichmäßigen Verzögerungskosten. Unter diesen Bedingungen ist es richtig, Ansätze wie die Priorisierung nach dem Schema first-in-first-out (FIFO) einzusetzen. Es ist auch richtig, die Eingabe neuer Aufgaben zu blockieren, wenn das WIP-Limit erreicht ist. Diese Ansätze sind allerdings nicht optimal, wenn wir es mit sich nicht wiederholenden Aufgaben zu tun haben, die zu unterschiedlichen Verzögerungskosten führen und deren Umsetzung unterschiedlich lange dauert. Und genau damit haben wir es in der Produktentwicklung zu tun. Dafür brauchen wir fortschrittlichere Systeme und dieses Buch ist das erste, das solche Systeme in der Praxis beschreibt.

Ich möchte den Leserinnen und Lesern einige kurze Hinweise geben. Erstens: Wenn Sie glauben, bereits zu wissen, wie Kanban-Systeme funktionieren, denken Sie vermutlich an die Kanban-Systeme, die in der Produktion verwendet werden. Die in diesem Buch vorgestellten Ideen gehen weit über solche einfachen Systeme hinaus, die statische WIP-Limits, FIFO-Priorisierung und nur eine Serviceklasse nutzen. Achten Sie auf diese Unterschiede!

Zweitens sollten Sie diesen Ansatz nicht nur als ein einfaches visuelles Steuerungsinstrument betrachten. Die Art und Weise, wie Kanban-Boards den Work in Progress sichtbar machen, ist zweifellos beeindruckend, aber das ist nur ein kleiner Aspekt des gesamten Ansatzes. Wenn Sie dieses Buch sorgfältig lesen, werden Sie herausfinden, dass noch sehr viel mehr dahinter steckt. Die wirklichen Erkenntnisse liegen in Aspekten wie dem Design von Prozessein- und -ausgängen, dem Umgang mit nicht veränderlichen Ressourcen und der Nutzung von Serviceklassen. Lassen Sie sich vom visuellen Aspekt nicht allzu sehr ablenken, damit Sie die Feinheiten nicht verpassen.

Drittens: Verurteilen Sie diese Methoden nicht, nur weil sie scheinbar einfach anzuwenden sind. Diese Einfachheit resultiert direkt 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 auf das konzentriert, was tatsächlich funktioniert. Einfache Methoden verursachen die wenigsten Störungen und bringen fast immer den größten nachhaltigen Nutzen.

Dies ist ein aufregendes und bedeutendes 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 fortschrittlichen Ideen verschaffen. Ich hoffe, es wird Ihnen ebenso gefallen wie mir.

Don Reinertsen

Autor des Buches The Principles of Product Development

7. Februar 2010, Redondo Beach, California

Frage:

Wie viele Psychologen benötigt man, um eine Glühlampe zu wechseln?

Antwort:

Nur einen, aber die Glühlampe muss wirklich wollen!

Geleitwort

Seitdem John Krafcik im Jahr 1988 den Begriff »Lean Manufacturing – Schlanke Produktion« geprägt hat, haben viele Menschen eine Menge Aufwand betrieben, diese Prinzipien auch auf andere Aktivitäten anzuwenden. Die Kanban-Methode ist dabei die einzige, die einen weitreichenden Erfolg erzielen konnte. Warum ist das so? Wie Don Reinertsen in seinem Geleitwort zu »Kanban: Evolutionäres Change-Management für IT-Organisationen« schreibt, ist Lean Manufacturing »daraufhin optimiert, mit sich wiederholenden und vorhersagbaren Aufgaben umzugehen«. Wissensarbeit unterscheidet sich aber sehr davon. Kanban war erfolgreich, weil es nicht versucht hat, Praktiken aus der Produktionsarbeit auf Bereiche zu übertragen, in denen sie nicht angemessen sind. Stattdessen stellt Kanban eine Evolution dar, die von den tiefergehenden Grundprinzipien ausgeht, die dem Toyota-Produktionssystem zugrunde liegen. Wie sich herausstellte, sind es die gleichen Prinzipien, die auch in der asiatischen Philosophie, den Kampfkünsten und der modernen Kriegsführung zu finden sind.

Hinweise auf diese Grundlage finden sich im ersten Kapitel. David Anderson beschreibt, wie er eine plötzliche Eingebung hatte, als er einen Beamten dabei beobachtete, wie er kleine Plastikkarten wieder einsammelte. Diese Ereignisse der »blitzartigen Erkenntnisse« sind ein weitverbreitetes Phänomen im Zen, aber eher selten in der heutigen Managementlehre.

Meine eigene Begegnung mit Satori, der Erkenntnis, war sehr viel banaler. Es war 1987. Wie jedes Jahr schloss Lockheed unser Werk über Weihnachten für drei Wochen. Ich stöberte in unserer öffentlichen Bibliothek in einem Vorort von Atlanta, als mir der hellrote Einband von »Thriving on Chaos« [Peters 1991] auffiel. Dies war mein eigenes Erwachen: Tom Peters vollzog einen klaren Bruch mit den Rezepten aus »In Search of Excellence« und propagierte Führungskonzepte, die von militärischen Führungskräften und Strategen bis heute heiß diskutiert werden.

Ich war mit einigen dieser Ideen vertraut, da ich einige Jahre zuvor als junger Mitarbeiter im Büro des Verteidigungsministers im Pentagon für das Kampfflugzeug F15 und ein Technologie-Demonstrationsprogramm namens »Lightweight Fighter Prototype« zuständig war, das später zur Entwicklung der F16 und der F18 führte. Der philosophische Wegbereiter dieser Programme war ein Colonel der Air Force namens John Boyd, der ebenfalls im Pentagon stationiert war. In den späten 1960er-Jahren entwickelte Boyd eine mathematische Methodik für den Vergleich der Kampffähigkeiten verschiedener Düsenjäger, die übrigens noch heute Verwendung findet. Diese Methodik prägte das Design der drei Flugzeuge.

Einige Jahre später ging Boyd in den Ruhestand und begann, sich mit Konflikten im Allgemeinen zu beschäftigen, mit anderen Worten mit dem Krieg. Er war von dem Phänomen fasziniert, dass in den meisten Fällen die kleinere oder die technisch weniger fortschrittliche Seite gewann. Boyd verbrachte die folgende Dekade damit, die Gründe dafür zu untersuchen, angefangen bei den Schriften von Sun Tzu (um 400 v. Chr.) bis hin zur Gegenwart. Er fasste seine Erkenntnisse in einer 185 Seiten starken Präsentation zusammen, die er Hunderte Male vor Mitgliedern des Kongresses, hochrangigen Militär- und Verteidigungsbeamten und Führungskräften aus der Industrie hielt.

Nun, worauf kommt es also an?

Boyd kam zu dem Schluss, dass die kleinere Armee, wenn sie siegte, eine Reihe von Mitteln einsetzte, um die Gegner in die Irre zu führen und zu verwirren, und dann diese Verwirrung zu ihrem Vorteil ausnutzte, bevor der Gegner herausfand, was tatsächlich vor sich ging. Das Ergebnis war Überraschung, Schock, verzögerte Reaktionsfähigkeit, Fallen und Hinterhalte und die Zerstörung des inneren Zusammenhalts. Mit anderen Worten: Die größere Streitmacht war nicht in der Lage, von ihrer zahlenmäßigen Überlegenheit und Feuerkraft zu profitieren.

Auf welche Arten von Organisationen trifft das zu? Der Schlüssel zum Erfolg war ein Klima in der Organisation, das Einheiten hervorbrachte, die in der Lage waren, gute Gelegenheiten zu schaffen und zu erkennen, und diese dann nutzen konnten, solange sie noch Gelegenheiten waren. Chaos zu erzeugen und es dann anwachsen zu lassen, ist Talebs Vorstellung von Antifragilität sehr ähnlich.

Boyd beschrieb dieses Klima als:

Gegenseitiges Vertrauen und Zusammenhalt, insbesondere ähnliche Einstellungen unter den Mitgliedern

Eine genauere Orientierung beibehalten als der Gegner

Die auf Erfahrung basierende Fähigkeit, die meisten Entscheidungen intuitiv zu treffen und implizit zu kommunizieren

»Auftragstaktik«, bei der erfahrene Führungskräfte festlegen, was erreicht werden soll (ihre übergeordnete Zielvorstellung), es aber ihren Untergebenen überlassen, wie sie es erreichen wollen.

Es war leicht, die gleichen Prinzipien in den Schriften von Sun Tzu, in »Thriving on Chaos« oder im Produktions- und Entwicklungssystem von Toyota und, wie ich entdeckte, auch in Kanban zu finden. Sie sind ebenso von zentraler Bedeutung in der Doktrin der Manöverkriegsführung des US Marine Corps, die sich auf Boyds Arbeit stützt und kurz nach Peters’ Buch veröffentlicht wurde. Weil Antifragilität der rote Faden ist, ist es nicht verwunderlich, dass sie alle von Boyds Geist angetrieben sind.

Was Sie in diesem Buch finden werden, ist eine neue Ausprägung dieser alten Ideen. Aufgrund seiner breiteren Anwendung wird Kanban die Welt jedoch tiefgreifender verändern als alle seine Vorgänger.

Chet Richards

Autor des Buches »Certain to Win«

9. März 2023, Hilton Head, California

Vorwort zur deutschen Ausgabe

Konnte man sich in Deutschland anfangs nur online über Twitter oder das kanbandev Yahoo Messageboard über Kanban informieren und austauschen, wurde Kanban im Januar 2011 durch die deutsche Übersetzung des ersten Kanban-Buches (das Blue Book) von David J Anderson endlich auch für eine breitere Zielgruppe zugänglich. Spätestens ab diesem Zeitpunkt wurde Kanban auch in deutschen agilen User Groups immer häufiger zum Thema. Die Zahl derer, die sich für diese neue Methode, die eigentlich gar nicht so neu war, interessierten, wuchs stetig und schon kurze Zeit später traf man sich in lokalen Gruppen und Meetups und lernte voneinander.

Für uns war es eine besondere Zeit, in der wir sehr viel Neues gelernt haben. Wir haben nicht nur die Kanban-Methode besser verstanden, sondern auch viele andere Modelle, Methoden und Ansätze kennengelernt. Viele davon haben ihren Weg erst in die agile Community gefunden, nachdem sie in der Kanban-Welt bereits Standard waren oder sogar weiterentwickelt wurden. Dieser Blick über den Tellerrand war und ist auch heute noch eines der besonderen Merkmale der Kanban Community. Auch wir lernen ständig von der Kanban Community.

Kanban besteht aus nur wenigen Prinzipien und Praktiken. Die Praktiken sind zudem sehr allgemein gehalten. Sie geben den Anwenderinnen und Anwendern wenig Anleitung und müssen auch nicht alle gleichzeitig umgesetzt werden. Diese Einfachheit führt leider allzu oft dazu, dass Kanban nur als eine schlanke Alternative zu anderen Methoden gesehen wird. Das Ergebnis beschränkt sich dann häufig auf »Zettel an der Wand« und enttäuschte Erwartungen. Aber wie so oft liegt in der Einfachheit auch eine Stärke.

Denn Einfachheit bedeutet oft auch ein hohes Maß an Freiheit. Die Vielfalt der Ideen und der angewandten Modelle in der Kanban-Methode und ihrer Community ist kein Zufall, sondern ein Produkt dieser Freiheit. Modelle sind so wichtig für die erfolgreiche Anwendung von Kanban, dass die sechste Kanban-Praktik explizit zur Verwendung von Modellen auffordert. Es sind die Ideen der Menschen, die die Kanban-Praktiken mit Leben füllen. Modelle können diese Ideen lenken.

Seit der Veröffentlichung des ersten Kanban-Buches sind viele Ideen entstanden. Unser Verständnis davon, was die Kanban-Methode ist und wie sie Menschen und Organisationen helfen kann, Wissensarbeit zu managen, um den Service für Kunden zu optimieren, ist gereift. Die Werte von Kanban, die Kanban Lens, die drei Agenden von Kanban und das Fit-for-Purpose-Framework sind nur einige der vielen Dinge, die uns dabei helfen. Nicht zu vergessen ist natürlich das Kanban Maturity Model, das einen Großteil der gesammelten Erfahrungen bündelt und Führungskräften und Coaches hilft, Dienstleistungen und Organisationen evolutionär und menschengerecht zu verbessern.

Als David uns und viele andere Kanban Coaches und Trainer im Sommer 2022 während des Kanban Leadership Retreat in Mayrhofen fragte, wie er der Kanban Community mit seiner Zeit am besten dienen könne, wünschte sich die überwiegende Mehrheit eine aktualisierte Auflage des ersten Kanban-Buches. David hatte schon länger eine Neuauflage geplant und sah sich in seinem Vorhaben bestätigt. Das Ergebnis liegt nun vor.

Was als zweite Auflage des ersten Buches geplant war, ist eher eine Fortsetzung. Sie erweitert die Erkenntnisse des ersten Buches um die Motivation der Kanban-Methode, ihre Anwendung als Managementmethode für Wissensarbeit und überführt damit die Managementansätze von Walter E. Deming ins 21. Jahrhundert.

Das ist für uns nicht weiter verwunderlich, denn der Kern der Kanban-Methode, also ihre Prinzipien und Praktiken, hat sich über all die Jahre bis auf kleine Feinheiten nicht verändert. Eine bessere Bestätigung für die Kanban-Methode kann es unserer Meinung nach kaum geben.

Sven Günther und Wolfgang Wiedenroth

Hamburg, November 2023

Inhaltsübersicht

1Das Dilemma eines gewissenhaften Managers

Meine Motivation für die Einführung virtueller Kanban-Systeme

2Ein ehemaliger Athlet und seine neue Herausforderung

Die Motivation für Kanban bei Microsoft im Jahr 2005

3»Glaubst du, sie werden sich darauf einlassen?«

Entwurf und Einführung von Kanban bei Microsoft XIT

4Nieder mit der Demokratie!

Kanban-Magie: Emergente, evolutionäre, soziale, kulturelle und prozessuale Veränderungen

5Umwege!

Mehr Kanban-Magie: Operations-Review

6Geschichten zu Scrumban

Der Aufstieg und Fall von Scrum bei Posit Science

7Proto-Kanban

Erste Schritte mit Kanban in einer Organisation mit niedrigem Reifegrad

8Sei geduldig

Widerstände beseitigen, um Veränderung zu ermöglichen

9Ein Flow-System

Entwurf und Einführung von Kanban bei Posit Science

10Mittagessen in Hibiya, Abendessen bei Anthony’s

Die Rolle des Service Delivery Manager

11Sei wie Wasser

Die Philosophie hinter der Kanban-Methode

12Kodifizierung der Methode

Eine kurze Definition von Kanban

13Kanban Maturity Model

Kanban-Implementierungsmuster den Reifegraden einer Organisation zuordnen

14Das Erfolgsrezept

Ein Leadership-Fahrplan zur Steigerung der Organisationsreife

15Die Tyrannei der immer kleiner werdenden Timebox

Warum Flow-Systeme für die unternehmensweite Agilität unverzichtbar sind

16Eingebung auf fünf Meilen

Autonomes, agiles Abhängigkeitsmanagement

17Mit Führung raus aus der Krise

Um zu erfahren, wie man skaliert, fragen Sie einen Unternehmer

Anhang

ADie ursprünglichen Kanban-Werte

BDemings 14 Punkte

Zerlegt und neu interpretiert für das 21. Jahrhundert

Literaturverzeichnis

Index

Inhaltsverzeichnis

1Das Dilemma eines gewissenhaften Managers

Meine Motivation für die Einführung virtueller Kanban-Systeme

1.1Die Eingebung in den Gärten des Kaiserpalastes

1.2Managen bei Motorola

1.3Meine Suche nach nachhaltiger Geschwindigkeit

1.4Meine Suche nach erfolgreichem Veränderungsmanagement

1.5Die drei Herausforderungen der agilen Skalierung

1.6Von Drum-Buffer-Rope zu Kanban-Systemen

Zusammenfassung

2Ein ehemaliger Athlet und seine neue Herausforderung

Die Motivation für Kanban bei Microsoft im Jahr 2005

2.1Das XIT-Wartungsteam

2.2Das Problem

2.3Aktuelle Leistungsfähigkeit

2.4Rahmenbedingungen

2.5Visualisieren

2.6Analyse des Bedarfs und der Leistungsfähigkeit

2.7Analyse der bisherigen Arbeit

2.8Flusseffizienz

2.9Ein zusätzlicher Arbeitstyp

2.10Vom Verständnis eines Problems zum Entwurf einer Lösung

Zusammenfassung

3»Glaubst du, sie werden sich darauf einlassen?«

Entwurf und Einführung von Kanban bei Microsoft XIT

3.1Wie sich Regeln und Vereinbarungen auf die Leistungsfähigkeit auswirkten

3.2Keine Aufwandsschätzungen

3.3Begrenzung der parallelen Arbeit (Work in Progress – WIP)

3.4Keine Planungsmeetings

3.5Wer könnte dagegen sein und warum?

3.6Würden sie sich auf ein Kanban-System einlassen?

3.7Pendel-Diplomatie

3.8Umsetzung der Änderungen

3.9Evolutionäre Relikte

3.10Priorisierung: Das evolutionäre Relikt beim XIT-Wartungsteam

3.11Die Wegwerf-Guillotine

3.12Keine Aufwandsschätzungen: Ein weiteres Hindernis für die Einführung

3.13Wie ging es weiter?

3.14Die Suche nach weiteren Verbesserungsmöglichkeiten

3.15Ergebnisse

Zusammenfassung

4Nieder mit der Demokratie!

Kanban-Magie: Emergente, evolutionäre, soziale, kulturelle und prozessuale Veränderungen

4.1Kaizen-Kultur

4.2Kanban beschleunigt die Reife der Organisation und deren Leistungsfähigkeit

Corbis:Das nicht so schnelle, nicht reaktionsfähige Team, das es nicht gab

Hintergrund und Kultur

Der Bedarf für eine Softwarewartungsabteilung

Kleine Projekte für Wartungen funktionierten nicht

Umsetzung der Veränderungen

4.3Primäre Auswirkungen der Veränderungen

Corbis:Unzureichende Ergebnisse führen zu einem sich abzeichnenden kulturellen Wandel

Unerwartete Auswirkungen der Kanban-Einführung

4.4Soziologische Veränderungen

Virale Verbreitung von Zusammenarbeit

Corbis:Virale Verbreitung von kulturellen Veränderungen

Verhandlungen

Demokratie

Nieder mit der Demokratie

Zusammenarbeit

4.5Der kulturelle Wandel ist vielleicht der größte Vorteil von Kanban

Zusammenfassung

5Umwege!

Mehr Kanban-Magie: Operations-Review

Corbis:Die Vorbereitung des ersten Operations-Reviews

Die Entwicklung von Führungskräften

Der Wert manueller Datenerfassung

5.1In welchem Geschäftsbereich bist du tätig?

5.2Wir machen Kunst! Die kann man nicht messen!

Corbis:Operations-Review, 9. März 2007

Vor dem Meeting

Setzen Sie von Anfang an einen geschäftlichen Akzent

Das Einladen von Gästen erweitert das Publikum und schafft einen Mehrwert

Hauptpunkte der Tagesordnung

5.3Respekt für Führungskräfte und ihr Handeln

5.4Vertrauen ist keine Einbahnstraße

5.5Operations-Review: Pfeiler einer Kaizen-Kultur

Zusammenfassung

6Geschichten zu Scrumban

Der Aufstieg und Fall von Scrum bei Posit Science

Posit Science:Hintergrund – das Unternehmen für Gehirnjogging

Posit Science:Der Aufstieg und Fall von Scrum (Teil 1)

Zusammenfassung

7Proto-Kanban

Erste Schritte mit Kanban in einer Organisation mit niedrigem Reifegrad

Posit Science:Der Aufstieg und Fall von Scrum (Teil 2)

Posit Science:Kanban wird abgelehnt

7.1Die Namensgebung von Proto-Kanban

Zusammenfassung

8Sei geduldig

Widerstände beseitigen, um Veränderung zu ermöglichen

Posit Science:Dinge spitzen sich zu und motivieren zu weiteren Veränderungen

Posit Science:Neue Erkenntnisse in Bezug auf Priorität, Dringlichkeit und Auswirkung

Zusammenfassung

9Ein Flow-System

Entwurf und Einführung von Kanban bei Posit Science

Posit Science:Das Kanban-System

Posit Science:Postskriptum

Zusammenfassung

10Mittagessen in Hibiya, Abendessen bei Anthony’s

Die Rolle des Service Delivery Manager

10.1»Ich will mein Sushi!«

10.2Selbstorganisierend

10.3Service Delivery Manager

Zusammenfassung

11Sei wie Wasser

Die Philosophie hinter der Kanban-Methode

11.1Chinesische Kampfkünste

11.2Umgehe den Felsen

Zusammenfassung

12Kodifizierung der Methode

Eine kurze Definition von Kanban

12.1Die Bedeutung von »Kanban«

12.2Was ist ein Kanban-System?

12.3Was ist die Kanban-Methode?

Nachhaltigkeit

Serviceorientierung

Überlebensfähigkeit

12.4Veränderungen, die menschlich sind

Kanban-Systeme sind der Kern für evolutionäre Veränderungen

12.5Anwendung von Kanban auf professionelle Services

12.6Vorteile von Kanban

Vermeidung von Überlastung

Aufgeschobene Zusage

Sichtbarkeit von Problemen

Kulturelle Entwicklung

Verbesserte Kundenzufriedenheit

Kontinuierliche Verbesserung

12.7Die sechs allgemeinen Praktiken von Kanban

12.8Operative Praktiken versus Managementpraktiken

12.9Kanban-Prinzipien

Die Flow-Prinzipien

Die Service-Delivery-Prinzipien

Die Veränderungsprinzipien

12.10Die Essenz der effektiven Führung von Veränderungen

12.11Die Kanban-Werte

12.12Leadership ist die geheime Zutat

Zusammenfassung

13Kanban Maturity Model

Kanban-Implementierungsmuster den Reifegraden einer Organisation zuordnen

13.1Die drei Säulen des Kanban Maturity Model (KMM)

13.2Das Modell der organisatorischen Reife

Reifegrad 0 – Unbewusst

Reifegrad 1 – Teamfokussiert

Reifegrad 2 – Kundenfokussiert

Reifegrad 3 – Fit for Purpose

Reifegrad 4 – Risikoabgesichert

Reifegrad 5 – Marktführer

Reifegrad 6 – Überlebensfähig

13.3Die Architektur des Kanban Maturity Model

13.4Spezifische Praktiken

13.5Übergangs- und Festigungspraktiken

13.6Die zwei bekannten Fehlersymptome von Kanban vermeiden

False Summit Plateau

Overreaching

Zusammenfassung

14Das Erfolgsrezept

Ein Leadership-Fahrplan zur Steigerung der Organisationsreife

14.1Verantwortlichkeit – die magische Zutat

14.2Eine reifende Organisation führen

Führen Sie mit Zielsetzungen

Erstellen Sie kundenzentrierte Metriken

Implementieren Sie Feedbackschleifen

Nehmen Sie die Mitarbeiter in die Verantwortung

14.3Managementmaßnahmen, um Ihre Organisation reifen zu lassen

14.4Das Originalrezept einführen

14.5Das Rezept von 2010 in der Retrospektive

14.6Das neue Erfolgsrezept

Zusammenfassung

15Die Tyrannei der immer kleiner werdenden Timebox

Warum Flow-Systeme für die unternehmensweite Agilität unverzichtbar sind

15.1Timeboxen

15.2Losgrößen

15.3Zwei Möglichkeiten, kleine Losgrößen zu erhalten: Timeboxen oder WIP-Limits

15.4Der Druck zu kürzeren Timeboxen

15.5Die Herausforderungen kürzerer Timeboxen

15.6Anforderungsanalyse

15.7Aufwandsschätzung

15.8Abhängigkeiten

15.9Skalierung, Business-Agilität und Timeboxen

15.10Die Angst vor dem Abhängigkeitsmanagement wurzelt in der Sprint-Beschränkung

15.11Scrum hinter sich lassen: Der erste Schritt auf dem Weg zu unternehmensweiter Business-Agilität

15.12Befreiung von der Tyrannei der Timebox

Vermeiden Sie die Frage: Wird es in die Timebox passen?

Vermeiden Sie die Frage: Wird es durch eine Abhängigkeit verzögert werden?

15.13Eine allgemeine Lösung für das Abhängigkeitsmanagement

Zusammenfassung

16Eingebung auf fünf Meilen

Autonomes, agiles Abhängigkeitsmanagement

16.1Wie man Kanban skaliert: Mach mehr davon!

16.2Skalierungsframeworks – organisatorischer Wahnsinn?

16.3Bestehende Praktiken des Abhängigkeitsmanagements in Kanban

16.4Erste Eingebung: Reservierungssysteme

16.5Dynamische Reservierungssysteme

16.6Reservierungsklassen

16.7Return on Investment entspricht nicht den Verzögerungskosten

16.8Zweite Eingebung: Verzögerung ist gleich Replenishment-Kadenz

16.9Die Entdeckung der mathematischen Beweise für empirisch abgeleitete Verzögerungskostenfunktionen

16.10Dritte Eingebung: Abhängigkeitsmanagementklassen

16.11Die Annahme eines kurzen Verlaufs

Zusammenfassung

17Mit Führung raus aus der Krise

Um zu erfahren, wie man skaliert, fragen Sie einen Unternehmer

17.1Home & Garden Television

17.2Qualität im Fokus

17.3Steigerung der Widerstandsfähigkeit

17.4Sich selbst entbehrlich machen

17.5Robustheit schaffen

17.6Erwachen

17.7Finden Sie Ihre Führungspersönlichkeiten und befähigen Sie sie

17.8Zum Schluss

Zusammenfassung

Anhang

ADie ursprünglichen Kanban-Werte

Kollaboration

Transparenz

Arbeitsfluss

Respekt

Verständnis (internes)

Vereinbarung

Balance

Kundenservice

Leadership auf allen Ebenen

BDemings 14 Punkte

Zerlegt und neu interpretiert für das 21. Jahrhundert

Schaffe ein unverrückbares Unternehmensziel.

Übernimm Führung für Veränderung.

Beende die Abhängigkeit von Kontrollen, um Qualität zu erreichen.

Beende die Praxis, Geschäfte auf Basis des niedrigsten Preises zu machen.

Verbessere das Produktions- und Servicesystem regelmäßig und dauerhaft.

Festige die Ausbildung am Arbeitsplatz.

Institutionalisiere Führung.

Vertreibe die Angst.

Baue Barrieren ab.

Beseitige Slogans, Ermahnungen und Zielvorgaben.

Eliminiere Management by Objectives: Ersetze es mit Führung.

Beseitige alle Hindernisse, die verhindern, dass Mitarbeiter stolz auf ihre Arbeit sein können: Ersetze es mit Führung.

Führe ein robustes Programm zur Weiterbildung und Self-Improvement (persönliche Entwicklung) ein.

Die Transformation ist die Aufgabe aller.

Literaturverzeichnis

Index

1Das Dilemma eines gewissenhaften Managers

Meine Motivation für die Einführung virtueller Kanban-Systeme

In den ersten Tagen des April 2005 hatte ich das Glück, zusammen mit meiner Frau und unseren kleinen Kindern den Urlaub während der Zeit der Kirschblüte in der japanischen Hauptstadt Tokio zu verbringen. Um dieses Naturschauspiel zu genießen, besuchte ich zum zweiten Mal in meinem Leben die östlichen Gärten des Kaiserpalastes im Zentrum von Tokio. Es war genau hier, wo ich die Eingebung hatte, dass Kanban nicht allein der Produktion vorbehalten war.

1.1Die Eingebung in den Gärten des Kaiserpalastes

Am Samstag, den 9. April 2005 betrat ich den Park durch den Nordeingang, indem ich die Brücke über den Graben in der Nähe der U-Bahn-Station Takebashi überquerte. Meine zweite Tochter, gerade 3 Monate alt geworden, trug ich in einer Babytrage, ihre ältere Schwester saß in einem Kinderwagen, der abwechselnd von ihrer Mutter oder ihrer Tante geschoben wurde, die beide aus Tokio stammen.

Die östlichen Gärten des Kaiserpalastes liegen hinter den alten Mauern der historischen Burg von Edo, der traditionellen Residenz des herrschenden japanischen Kriegsherrn, bekannt als der Shogun. Nach der Meiji-Restauration von 1868 und dem Ende des Tokugawa-Shogunats mit der Kapitulation des Shoguns Tokugawa Yoshinobu verlegte der Kaiser von Japan seine Residenz von Kyoto nach Tokio und besetzte die Burg. Von diesem Zeitpunkt an war sie als Kaiserlicher Palast bekannt. An der Stelle, an der sich die Gärten heute befinden, war früher der Innenhof des Schlosses, wo sich die Arbeitsplätze und Unterkünfte der Bediensteten des königlichen Hofes befanden. Nach der Meiji-Restauration wurden die mittelalterlichen und nun nicht mehr benötigten Innenhöfe abgerissen und im späten 19. Jahrhundert die Gärten angelegt. Heute sind sie öffentlich zugänglich und gehören zu den schönsten und einzigartigsten Parkanlagen im Großraum Tokio.

An diesem sonnigen Samstagmorgen nutzten bereits viele Tokioter die Gelegenheit, sich an der Ruhe im Park und der Schönheit der Sakura (der Kirschblüten) zu erfreuen. Der Brauch, unter den Kirschbäumen ein Picknick zu machen, während um einen herum die Blüten herunterfallen, ist als Hanami (Kirschblütenfest) bekannt. Es ist eine alte Tradition in Japan und eine Möglichkeit, über die Schönheit, Zerbrechlichkeit und die Vergänglichkeit des Lebens nachzudenken. Die kurze Lebensdauer der Kirschblüte ist eine Metapher für das eigene Leben und unsere kurze, schöne und fragile Existenz inmitten der Weite des Universums.

Die Kirschblüten bildeten einen willkommenen Kontrast zu den grauen Gebäuden der Tokioter Innenstadt, dem geschäftigen Treiben, den pulsierenden Menschenmassen und dem Verkehrslärm. Die Gärten waren eine Oase im Herzen des Betondschungels. Als ich mit meiner Familie die Brücke überquerte, kam ein älterer japanischer Herr mit einem Tornister auf seinem Rücken auf uns zu. Er entnahm seiner Tasche eine Handvoll Plastikkarten. Er reichte jedem von uns eine und hielt kurz inne, um zu überlegen, ob meine drei Monate alte Tochter in ihrer Babytrage auch eine benötigte. Er entschied, dass sie auch eine bekommen sollte, und überreichte mir zwei Karten. Er sagte nichts und da mein Japanisch nicht so gut war, verzichtete ich auf ein Gespräch. Wir gingen in den Garten, um uns ein Plätzchen für unser Picknick zu suchen.

Zwei Stunden später, nach einem herrlichen Vormittag im Sonnenschein, packten wir unsere Sachen zusammen und machten uns auf den Weg zum Ausgang am Osttor in Otemachi. Als wir uns dem Ausgang näherten, reihten wir uns in eine Schlange vor einem kleinen Kiosk ein. Während sich die Schlange vorwärtsbewegte, beobachtete ich, wie Menschen ihre Plastikeintrittskarten zurückgaben. Ich suchte in meinen Taschen und fand die Karten, die ich erhalten hatte. Als ich mich dem Kiosk näherte, sah ich darin eine elegant gekleidete japanische Dame. Zwischen uns befand sich eine Glasscheibe mit einem halbkreisförmigen Loch auf Höhe der Theke, ähnlich wie beim Eintrittskartenverkauf in einem Kino oder einem Vergnügungspark. Ich schob meine Plastikkarten durch das Loch in der Scheibe über die Theke. Die Dame nahm sie in ihren weißen Handschuhen entgegen und stapelte sie in einem Regal zusammen mit anderen. Sie neigte leicht den Kopf und bedankte sich mit einem Lächeln. Kein Geld wechselte den Besitzer. Es gab keine Erklärung dafür, warum ich seit dem Betreten des Parks vor zwei Stunden zwei Plastikeintrittskarten mit mir herumgetragen hatte.

Was hatte es mit diesen Eintrittskarten auf sich? Warum sollte man ein Ticket aushändigen, wenn dafür keine Gebühr erhoben wird? Mein erster Gedanke war, dass es sich um ein Sicherheitssystem handeln musste. Indem man alle zurückgegebenen Karten zählt, konnten die Betreiber sicherstellen, dass keine herumstreunenden Besucher auf dem Gelände zurückgeblieben waren, wenn das Gelände zum Abend hin geschlossen wurde. Nach kurzem Nachdenken stellte ich fest, dass es ein schlechtes Sicherheitssystem sein würde. Wer könnte sagen, ob ich zwei Karten erhalten hatte oder nur eine? Zählte meine drei Monate alte Tochter als Besucher oder als Gepäck? Es schien zu viele Unregelmäßigkeiten in diesem System zu geben, zu viele Fehlermöglichkeiten! Wenn es sich um ein Sicherheitssystem handeln würde, dann würde es zu viele Fehler produzieren und jeden Tag eine Menge falsch positiver Ergebnisse erzeugen. (Nebenbei bemerkt, kann ein solches System keine falsch negativen Ergebnisse erzeugen, da dies das Herstellen zusätzlicher Eintrittskarten erfordern würde. Dies ist eine nützliche Eigenschaft von physischen Kanban-Systemen.) In der Zwischenzeit würden die Beschäftigten jeden Abend durch die Büsche streifen, um nach verlorenen Touristen zu suchen. Nein, es muss etwas anderes sein. Ich realisierte, dass die Gärten des Kaiserlichen Palastes ein Kanban-System benutzten. Die begrenzte Ausgabe von Tickets (oder Kanban-Karten) stellte sicher, dass der Park nicht überfüllt wurde – solange alle Tickets vergeben waren, könnte keiner mehr den Park betreten, bis jemand anderes den Park verließ und die Tickets zurückgab.

Diese äußerst aufschlussreiche Erkenntnis ermöglichte es mir, über den Einsatz von Kanban-Systemen in der Produktion hinauszudenken. Es schien mir sicher, dass Kanban-Token in allen möglichen Managementsituationen nützlich sein könnten. Wie ich seither gelernt habe, scheinen Kanban-Systeme in allen Branchen für professionelle Dienstleistungen, Arbeit mit immateriellen Gütern oder bei Wissensarbeit anwendbar zu sein. Ich habe gesehen, dass sie in Verkauf, Marketing, Finanzwesen, Personalwesen und Recruiting, in Webdesignagenturen, Werbeagenturen, Bauingenieurs- und Architekturbüros, Anwaltskanzleien, Film- und Fernsehproduktionen und -nachbearbeitung sowie in vielen gemeinsam genutzten Services in so unterschiedlichen Bereichen wie Ölförderung und -vertrieb, Pharmazie und Bankwesen eingesetzt werden.

1.2Managen bei Motorola

Drei Jahre zuvor, im Jahr 2002, war ich ein frustrierter Entwicklungsleiter in einer Außenstelle von PCS, der Mobilfunksparte von Motorola. Motorola mit Sitz in Chicago hatte das aus Seattle stammende Start-up 4thpass einige Monate zuvor übernommen. Wir entwickelten Software für die Netzwerkserver der drahtlosen Datendienste wie Over-the-Air-Updates und Over-the-Air-Geräteverwaltung. Diese Serveranwendungen waren Teil integrierter Systeme, die Hand in Hand mit dem Clientcode auf den Mobiltelefonen und auch mit anderen Teilen innerhalb des Netzwerks des Telefonanbieters und der Backoffice-Infrastruktur wie z.B. der Abrechnung arbeiteten. Unsere Termine wurden uns von Managern auferlegt, ohne Rücksicht auf die Komplexität der Entwicklung, die Risiken oder die Größe der Projekte. Kommt Ihnen das bekannt vor? Unsere Codebasis hatte sich aus dem Produkt des früheren Start-up-Unternehmens weiterentwickelt, bei dem in der Eile der Markteinführung an vielen Ecken gespart wurde. Ein erfahrener Entwickler bestand darauf, unsere Plattform als »Prototyp« zu bezeichnen. Sie war ausgesprochen schwierig zu warten und zu erweitern. Wir brauchten dringend eine höhere Produktivität und eine höhere Qualität, um den ständig steigenden Anforderungen des Unternehmens zu genügen.

Bei meiner täglichen Arbeit im Jahr 2002 und durch mein Schreiben an meinem früheren Buch [Anderson 2003] hatte ich zwei Herausforderungen zu meistern: Erstens, wie konnte ich meine Abteilung mit 30 Personen vor der steigenden Menge an Anforderungen aus dem Unternehmen schützen und das erreichen, was die Community der agilen Softwareentwicklung als »nachhaltige Geschwindigkeit« bezeichnet? Und zweitens, wie konnte ich erfolgreich die Anwendung von agilen Softwareentwicklungsmethoden in einer Geschäftseinheit mit rund 250 Personen skalieren und die unvermeidlichen Widerstände überwinden? Ich musste beides schaffen. Ich brauchte Menschen in einer effektiven, produktiven Abteilung, die nicht erschöpft waren durch konstante Überlastung und Termindruck, und ich benötigte die Produktivitätssteigerungen, von denen ich wusste, dass sie durch eine erfolgreiche Einführung agiler Softwareentwicklungsmethoden möglich waren.

1.3Meine Suche nach nachhaltiger Geschwindigkeit

In den Prinzipien hinter dem Agilen Manifest [Beck et al. 2001] heißt es: »Agile Prozesse fördern eine nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.« Für einen gewissenhaften Manager, der eine Abteilung mit sechs Projektleitern und 24 Entwicklern leitete, war dies eine überzeugende Botschaft, agile Softwareentwicklungsmethoden einzuführen. Zwei Jahre zuvor war mein Team bei Sprint PCS es gewohnt, mir zu sagen, dass »Softwareentwicklung im Großen ein Marathon ist, kein Sprint«. Dieses Wortspiel war eine bewusste Ermahnung. Wir »sprinten« bei Sprint nicht, wir laufen einen Marathon. Wenn wir wollen, dass die Teammitglieder das Tempo bei einem 18-monatigen Projekt auf Dauer durchhalten sollen, dann können wir es uns nicht leisten, sie nach einem oder zwei Monaten auszubrennen. Das Projekt musste so geplant, budgetiert, terminiert und geschätzt werden, dass alle Teammitglieder jeden Tag eine angemessene Arbeitszeit leisten konnten, ohne sich zu überanstrengen. Die Herausforderung für mich als Manager bestand darin, dieses Ziel zu erreichen und gleichzeitig alle Anforderungen aus dem Unternehmen zu erfüllen.

In meiner ersten Führungsposition 1991 bei einem fünf Jahre alten Start-up, das Video-Capture-Karten für PCs und andere kleinere Computer wie den Commodore Amiga herstellte, bekam ich das Feedback vom CEO, dass das Führungsteam mich als »sehr negativ« wahrnahm. Ich antwortete immer mit »Nein«, wenn sie mich nach mehr Produkten oder Features fragten, obwohl unsere Entwicklungskapazität bereits bis zum Äußersten ausgelastet war. Im Jahr 2002 zeichnete sich deutlich ein Muster ab: Ich verbrachte mehr als zehn Jahre damit, »Nein« zu sagen und mich gegen die ständigen launischen Anforderungen der Stakeholder aus dem Unternehmen zu wehren.

Im Allgemeinen kam es mir vor, als ob Softwareentwicklungsteams und IT-Abteilungen der Gnade anderer Gruppen ausgeliefert waren, die selbst die vertretbarsten und objektiv abgeleiteten Pläne aushandeln, überreden, einschüchtern und überstimmen wollten. Selbst Pläne, die auf einer eingehenden Analyse beruhten und durch jahrelang gesammelte historische Daten gestützt wurden, waren anfällig für unsinnige Anpassungen. Die meisten Projektteams, die weder über eine eingehende Analysemethode noch über irgendwelche historischen Daten verfügten, waren machtlos, wenn andere sie dazu drängten, völlig unangemessenen Fristen zuzustimmen.

Ich hatte das Gefühl, dass die Softwareentwicklungsbranche verrückte Zeitpläne und absurde Arbeitsvereinbarungen weitgehend als normal akzeptiert hatte. Es schien, als ob Softwareentwickler kein Sozial- und Familienleben haben sollten. Die Empfehlungen für das Management, wie es Anreize für die Beschäftigten schaffen konnte, länger zu arbeiten und ihr gesamtes Leben der Sache des neuesten Projekts zu widmen, waren legendär. Diese zweifelhafte Art der Führung kam aus dem Silicon Valley, der San Francisco Bay Area in Kalifornien. Ideen wie die, Köche eines Fünf-Sterne-Hotels Gourmet-Mahlzeiten zubereiten zu lassen und einen Wäsche- oder sogar Wellnessservice am Arbeitsplatz einzurichten, waren alle darauf ausgerichtet, die Menschen im Büro zu halten, damit sie länger und länger arbeiteten. Das plumpe Werkzeug des Managements in der Technologieentwicklung bestand darin, härter und länger zu arbeiten anstatt intelligenter. Mehr Intensität war offenbar unsere einzige Antwort auf die unstillbare Nachfrage nach mehr Funktionen und Features.

Ich kannte zu viele Menschen, deren Engagement für die Arbeit ihrem Sozialleben und ihrer mentalen Gesundheit unbestreitbar geschadet hatte. Es war üblich, dass sich Beziehungen zu Kindern und anderen Familienmitgliedern verschlechterten, viele davon für immer. Ein Programmmanager, den ich bei Microsoft kennenlernte, führte tatsächlich Buch und gab scherzhaft die »Scheidungsrate pro Release« als Metrik dafür an, wie verrückt die Zeiten geworden waren. Eine Abteilung, die an SQL-Server 2005 arbeitete, hatte angeblich eine Scheidungsrate von 30 Prozent. Wie bei jedem guten Witz, gab es eine dahinterliegende Wahrheit, die ihn besonders treffend machte.

Allerdings fällt es der breiten Öffentlichkeit schwer, Sympathie für den typischen Softwareentwickler aufzubringen. Im US-Bundesstaat Washington, wo ich fast 20 Jahre lang lebte, stehen Softwareentwickler beim durchschnittlichen Jahreseinkommen hinter Zahnärzten an zweiter Stelle. Man könnte sie mit den Fließbandarbeitern bei Ford hundert Jahre zuvor vergleichen. Es fiel schwer, mit ihnen wegen der Monotonie ihrer Arbeit und ihren eng gefassten Aufgaben oder ihres mentalen Wohlbefindens bei dieser sich wiederholenden Arbeit Mitleid zu haben, da sie das Fünffache des Durchschnittslohns in den USA bekamen. Es ist schwer vorstellbar, dass irgendjemand die wirklichen Ursachen für die physischen und psychischen Beschwerden, denen Entwickler ausgesetzt sind, in Betracht zieht. Wohlhabendere Arbeitgeber sind in der Lage, die Symptome zu bekämpfen, indem sie zusätzliche Gesundheitsleistungen wie Massagen und Psychotherapie anbieten und gelegentlich Krankheitstage für die »geistige Gesundheit« gestatten. Viele andere drücken einfach ein Auge zu, wenn Arbeitnehmer Krankheitstage aus psychischen Gründen in Anspruch nehmen, und die Abmachung ist für beide Seiten verständlich – der Arbeitgeber wird Sie ausbeuten und Sie haben das Recht, sich zu wehren, indem Sie Krankheitstage nehmen. Der Ansatz bestand immer darin, die Symptome zu lindern, anstatt die Ursachen der Probleme anzugehen. Ein technischer Redakteur, der mit mir 2005 bei Microsoft arbeitete, sagte einmal zu mir: »Es ist keine Schande, Antidepressiva zu nehmen, das macht schließlich jeder!« Als Reaktion auf diesen Missbrauch neigten Softwareentwickler dazu, den Forderungen nachzugeben, ihre schicken Gehälter zu kassieren und ein wohlhabendes Leben voller materieller Güter zu führen, während sie unter den Folgen litten, die nur schwer direkt auf den arbeitsbedingten Stress zurückgeführt werden konnten.

Einige Jahre später war ich wieder einmal mit meinen früheren Arbeitskollegen in einem Meeting bei Microsoft. Bevor das Meeting begann, unterhielten wir uns über persönliche Dinge. Ein Kollege erzählte mir, dass er sich mehr Zeit für sich selbst nehme und mit dem Snowboarden begonnen habe, um die Beziehung zu dem jüngsten seiner vier Kinder zu retten. Er erklärte weiter, dass »die anderen drei ihn bereits abgeschrieben hatten«. Er verbrachte die Zeit ihrer Kindheit auf der Arbeit und sie nahmen ihm das übel. Ich habe mich gefragt, wie viele andere Familienleben auch durch die Probleme der Überlastung, der Erwartung, immer präsent zu sein, und einer heroischen Arbeitsmoral oder durch den sozialen Druck, ein Teil eines Teams zu sein, ungeachtet der weiteren Konsequenzen, zerstört werden.

Als Manager wollte ich dieses Korsett aufbrechen. Ich wollte einen Ansatz finden, bei dem alle gewinnen konnten, der es mir erlaubte, zu neuen Anforderungen »Ja« zu sagen und gleichzeitig meine Teammitglieder zu schützen, indem ich ihnen ein nachhaltiges Arbeitstempo ermöglichte. Im Jahr 2002 wollte ich meiner Abteilung etwas zurückgeben – ihnen ein Sozial- und Familienleben zurückgeben – und die Bedingungen verbessern, die stressbedingte Gesundheitsprobleme wie Panikattacken bei unter 30-jährigen Entwicklern verursachten.

Kanban hat es mir ermöglicht, dieses Rätsel zu lösen, und deshalb habe ich für dieses Buch gedanklich mit dem Untertitel »Wie werde ich ein Ja-Sager« gespielt. Es klingt fast zu schön, um wahr zu sein!

1.4Meine Suche nach erfolgreichem Veränderungsmanagement

Ein weiterer Gedanke, der mich beschäftigte, war die Herausforderung, den Wandel in großen Organisationen zu gestalten. Ich war zuerst Entwicklungsleiter bei Sprint PCS und später bei Motorola. In beiden Unternehmen gab es den Bedarf nach größerer Agilität, also in der Arbeitsweise schneller und reaktionsfähiger zu sein. In beiden Fällen hatte ich aber Schwierigkeiten, agile Softwareentwicklungsmethoden über mehr als zwei Abteilungen oder ein kleines Projektportfolio hinaus zu skalieren. Während der Einsatz agiler Methoden in den letzten zehn Jahren ein heißes Thema war, bin ich, während ich dies im Jahr 2022 schreibe, schon 2002 zweimal gescheitert – 20 Jahre zuvor! Während ein Großteil der agilen Community zu dieser Zeit damit kämpfte, wie man Teams von sechs Personen motiviert, hatte ich bereits die Schwierigkeiten kennengelernt, die Einführung auf Hunderte von Personen auszuweiten.

Ich nahm an, dass ich eine höhere Position im Unternehmen haben müsste, um die Menschen dazu zu bringen, mir zu folgen. Ich glaubte, dass ich deswegen scheiterte, weil ich nicht in jedem Fall genügend Befugnisse besaß. Ich war nicht in der Lage, einer großen Gruppe von Menschen einfach Veränderungen aufzudrängen. In beiden Fällen versuchte ich, Veränderungen als Wunsch des Managements herbeizuführen, hatte aber auf die Mehrzahl der Personen keine Einflussmöglichkeiten. Ich war zwar Abteilungsleiter, wurde aber gebeten, Veränderungen in einer ganzen Geschäftseinheit zu bewirken. Ich musste meine Kollegen dazu bringen, in ihren Abteilungen ähnliche Veränderungen herbeizuführen, wie ich selbst in meiner Abteilung umgesetzt hatte. Diese Manager mit ins Boot zu holen war nicht schwer, sie wollten alle als Unterstützer gesehen werden und in den Augen unseres Vorgesetzten gut dastehen. Bei ihren Mitarbeitenden sah die Sache jedoch anders aus. Die anderen Abteilungen wehrten sich dagegen, Techniken einzuführen, die in meiner Abteilung eindeutig zu besseren Ergebnissen führten.

Es gab sicherlich mehrere Facetten dieses Widerstands, aber die häufigste Ursache war die, dass die Ausgangslage in jeder Abteilung eine andere war. Die Praktiken aus meiner Abteilung hätten angepasst und auf die besonderen Bedürfnisse der anderen zugeschnitten werden müssen. Mitte 2002 kam ich zu dem Schluss, dass die Durchsetzung einer vorgegebenen Softwareentwicklungsmethode oder eines definierten Prozesses im großen Maßstab, also in einem Unternehmensbereich mit 250–450 Personen, einfach nicht funktionierte. Es kam nicht darauf an, wie gut die vorgegebene Methode war, sie würde bei einer flächendeckenden Einführung auf den Widerstand eines Großteils der Belegschaft stoßen.

Als ich 2003 an meinem Buch »Agile Management for Software Engineering« [Anderson 2003] arbeitete, wurde mir bei der Recherche klar, dass jede Situation in gewisser Weise einzigartig ist. Die These des Buches war zu zeigen, dass agile Softwareentwicklungsmethoden mit der Hilfe der Engpasstheorie von Eli Goldratt [Goldratt 1999] zu besseren wirtschaftlichen Ergebnissen führen können. Ich glaubte zu dieser Zeit – zugegebenermaßen zu optimistisch – daran, dass die wirtschaftlichen Argumente die Unternehmensleitung davon überzeugen würden, die breite Einführung von agilen Methoden zu unterstützen. Die Engpasstheorie fordert uns auf, nach Engpässen zu suchen, diese zu managen und zu erweitern, um die wirtschaftliche Leistung des Unternehmens zu verbessern. Als ich während der Entwicklung des Manuskripts im Jahr 2002 ständig über dieses Konzept nachdachte, kam ich zu der Erkenntnis, dass jede Situation als einzigartig zu betrachten ist. Die Vorstellung, dass eine einzige vorgegebene Prozessbeschreibung auf alle Situationen passen könnte, war eindeutig unzutreffend. Warum sollte der begrenzende Faktor oder Engpass für alle Teams in jedem Projekt zu jeder Zeit an derselben Stelle sein? Jede Organisation ist anders, hat unterschiedliche Fertigkeiten, Fähigkeiten und Erfahrungen. Jedes Projekt ist anders: unterschiedliche Budgets, Zeitpläne, Umfang und Risikoprofile. Auch ist jedes Unternehmen anders: andere Workflows mit anderen Aktivitäten, die in anderen Marktnischen operieren oder eine andere Art von Kunden bedienen. Mir kam der Gedanke, dass uns dies einen Hinweis auf die Widerstände gegenüber Veränderungen geben könnte. Wenn die angedachten Änderungen der Arbeitsweisen und Verhaltensweisen keinen erkennbaren Nutzen hatten, würden die Menschen sich dagegen wehren. Wenn diese Veränderungen nicht das beeinflussen, was die Menschen als ihre Beschränkungen ansehen oder als ihren limitierenden Faktor, würden sie sich dagegen wehren. Einfach gesagt, Veränderungen, die aus dem Zusammenhang gerissen vorgeschlagen werden, würden von den Beschäftigten abgelehnt werden, die ihren eigenen Arbeitskontext kennen, die Arbeitsabläufe des von ihnen bereitgestellten Service verstehen und wissen, ob diese effektiv sind oder nicht.

Es schien sinnvoller zu sein, für einen verbesserten Arbeitsablauf zu sorgen, indem man einen Engpass nach dem anderen beseitigt. Dies ist die Kernidee hinter der Engpasstheorie von Goldratt. Ich war von ihr als Antwort auf meine Suche völlig überzeugt.

Goldratts Ansatz, der in Band 2, Implementing Kanban1, erläutert wird, zielt darauf ab, einen Engpass zu identifizieren und dann Wege zu finden, diesen zu erweitern, bis er die Leistungsfähigkeit nicht mehr einschränkt. Sobald dies passiert ist, wird ein neuer Engpass sichtbar und der Zyklus wiederholt sich. Das Finden und Beseitigen von Engpässen ist ein iterativer und evolutionärer Ansatz, um die Leistungsfähigkeit systematisch zu verbessern.

Ich erkannte, dass ich diese Technik mit einigen Ideen aus Lean Production Development zusammenführen konnte. Indem ich den Arbeitsfluss einer Softwareentwicklung modellierte und dann die Arbeit entlang einer Reihe von Aktivitäten visualisierte und beobachtete, konnte ich die Engpässe erkennen. Die Fähigkeit, einen Engpass zu erkennen, ist der erste Schritt im zugrunde liegenden Modell der Engpasstheorie. Goldratt hatte bereits eine Anwendung seiner Theorie für Flussprobleme entwickelt, die er ungeschickterweise »Drum-Buffer-Rope« nannte. Ungeachtet des Namens erkannte ich, dass eine vereinfachte Drum-Buffer-Rope-Lösung in der Softwareentwicklung eingesetzt werden konnte.

Die Kombination der Konzepte bot mir einen Mechanismus, der evolutionäre Veränderungen vorantreiben konnte. Eingebettet in eine Feedbackschleife, wie die fünf Fokussierungsschritte der Engpasstheorie, wird ein Drum-Buffer-Rope-System zu einem Wegbereiter für einen evolutionären Verbesserungsansatz. Goldratt nannte dies einen POOGI (a Process of ongoing Improvement – einen Prozess der ständigen Verbesserung). Er versprach eine Prozessverbesserung, die von der Situation des aktuellen Prozesses ausgeht, wie er tatsächlich umgesetzt wird – ein Veränderungsansatz, der »mit dem beginnt, was man gerade tut, und sich von dort aus weiterentwickelt«. Ich hoffte, dass dies die Antwort auf meine Suche nach einem erfolgreichen Veränderungsmanagement war. Und ich war zuversichtlich, dass der Ansatz der Engpasstheorie eine Lösung für einen erfolgreichen und verankerten Wandel lieferte, einen Wandel, der anhält!

1.5Die drei Herausforderungen der agilen Skalierung

Die individuelle Anpassung der Prozesse für jede spezifische Situation erforderte aktive Führungsarbeit in jedem Team. Daran mangelte es oft. Selbst mit der richtigen Leadership bezweifelte ich, dass signifikante Veränderungen möglich wären, ohne ein Framework für das Management zu haben und ohne Anleitung, wie Prozesse an verschiedene Situationen angepasst werden können. Ohne einen Leitfaden für Führungskräfte, Coaches oder Prozessingenieure würde jede Anpassung vermutlich subjektiv erfolgen. Ebenso war es wahrscheinlich, dass es zu Unmut, Einwänden oder unpassenden Prozessvorlagen führen würde. Ich bin nach wie vor der Meinung, dass das Fehlen von effektiven Führungskräften mit entsprechenden Fähigkeiten, Schulungen und Erfahrungen eines der drei Haupthindernisse ist, um die Einführung von agiler Softwareentwicklung zu skalieren.

Der zweite Grund war der Mangel an Reife in der Organisation, das Fehlen eines passenden Wertesystems, eines Credos. Fehlt dieses, ist man nicht in der Lage, Risiken zu managen und schwierige Entscheidungen mit langfristigem Nutzen zu treffen; man konzentriert sich nur auf das Kurzfristige, trifft taktische Entscheidungen, ohne die längerfristigen Folgen zu berücksichtigen, und ist nicht in der Lage, Veränderungen effektiv zu managen.

Das dritte Problem bestand schlicht darin, dass sich die Mitarbeitenden den auferlegten Veränderungen widersetzten, selbst wenn versucht wurde, die Prozesse auf bestimmte Situationen zuzuschneiden. Ich bin zu der Überzeugung gelangt, dass ein prozessorientierter Ansatz zur Verbesserung der Agilität im Unternehmen in die falsche Richtung geht und die Skalierung von agilen Methoden zum Scheitern verurteilt ist. Mehr als 20 Jahre Praxiserfahrung und etliche Anzeichen deuten darauf hin, dass dies zu stimmen scheint. In den Fällen, in denen groß angelegte Einführungen von agilen Methoden zu funktionieren scheinen, und es gibt nur wenige davon, nehme ich an, dass meine drei Kriterien Beachtung fanden: Es gab eine starke Leadership, eine reife Organisation und die Einführung geschah schrittweise mit einem »finde deinen eigenen Weg«-Ansatz, anstatt einer bestimmten vordefinierten Methodik oder einem Framework zu folgen.

1.6Von Drum-Buffer-Rope zu Kanban-Systemen

Kehren wir zu meiner früheren Eingebung durch Goldratts Engpasstheorie und seinen engpassgetriebenen POOGI-Ansatz zurück. Ich erhielt widersprüchliche Ratschläge von angesehenen Persönlichkeiten wie Donald G. Reinertsen und die Idee war, dass die Arbeitsabläufe von Wissensarbeitern einer übermäßigen Variabilität unterliegen. Das bedeutete, dass es schwierig war, Engpässe zu finden, und dass der Engpass selten an einer Stelle blieb und dass sich das System des Arbeitsflusses nicht stabilisieren würde. Ich habe dies erst 2007 aus erster Hand erfahren, als ich zwei Manager meines Teams dabei beobachtete, wie sie in einem Teammeeting darüber stritten, dass jede ihrer Abteilungen »der Engpass« sei. Die Variabilität unserer Arbeit führte dazu, dass der Engpass von einer Aktivität im Workflow zu einer anderen hin- und herwechselte. Reinertsens Vermutung und seine Ratschläge schienen richtig zu sein. Es dauerte jedoch zwei Jahre, nachdem Don seine Bedenken geäußert hatte, bis ich den empirischen Beweis hatte, der sie bestätigte.

Wenn Ihnen der folgende Abschnitt etwas verwirrend und technisch vorkommt, sehen Sie es mir nach, denn die Details und die Unterschiede, die nur für Insider von Bedeutung sind, sind, wie wir in den letzten 10 Jahren gelernt haben, gar nicht so wichtig.

Es gab noch weitere Bedenken: Im Allgemeinen ist Drum-Buffer-Rope ein Beispiel für eine Klasse von Lösungen, die als Pull-Systeme bekannt sind. Pull-Systeme limitieren die parallel angefangene Arbeit (Work in Progress – WIP-Limit) oder den Bestand in einem Arbeitsablauf, was dazu führt, dass Anforderungen nicht sofort zugesagt werden. Sie benutzen einen Signalmechanismus, um sichtbar zu machen, wenn Kapazität verfügbar ist, um neue Arbeit in das System zu ziehen. Ein Kanban-System ist ein weiteres Beispiel für ein Pull-System. Kanban-Systeme sind robuster gegenüber Schwankungen der lokalen Durchlaufzeiten oder Ungleichmäßigkeiten im Arbeitsfluss, weil sie die Menge an Arbeit in jedem Arbeitsschritt begrenzen, während das Drum-Buffer-Rope-System versucht, die Menge an Arbeit vor einem Engpass zu begrenzen, indem ein Puffer (Buffer) mit einem einzigen WIP-Limit eingerichtet wird, metaphorisch beschrieben als »das Seil« (Rope), das die Menge an Arbeit zwischen dem Systemeingang bis zu diesem Puffer vor dem Engpass begrenzt. Die Menge an Arbeit nach dem Engpass wird in der einfachen Umsetzung des Systems nicht limitiert. Um die Metapher im Namen zu vervollständigen, gibt »die Trommel« (Drum) die Geschwindigkeit vor, in der Arbeit im Engpass erledigt wird. Jedes Mal, wenn eine Aufgabe im Engpassarbeitsschritt abgeschlossen ist, gibt ein Trommelschlag das Signal, dass neue Arbeit am Anfang des Seils in das System gezogen werden kann.

Drum-Buffer-Rope erzeugt Pull-Signale im Tempo des Engpasses und verhindert damit eine Überlastung des gesamten Systems, es erzeugt Stabilität. Allerdings ist es in seiner einfachsten Form nicht robust gegenüber Schwankungen in der Durchlaufzeit oder in Ungleichmäßigkeiten im Arbeitsfluss vor dem Engpass. Wenn der Engpass zum Stillstand käme, würde Arbeit, die schon begonnen wurde, trotzdem weiter in den Engpass fließen. Ein Neustart des Prozesses im Engpass wäre problematisch, weil er durch die Menge an Arbeit überlastet würde, die den Puffer, der ihn schützen sollte, überschwemmt. Dieses Argument ist zwar technisch und nur für Insider verständlich, ich wurde aber von Donald Reinertsen2 davon überzeugt, dass Ungleichmäßigkeiten im Arbeitsfluss entlang des gesamten Prozesses ein immer wieder aufkommendes Problem für Wissensarbeiter wie Softwareentwickler sind. Somit sind Kanban-Systeme in diesem Bereich die geeignetere Form von Pull-Systemen. Es hat sich gezeigt, dass Kanban auch einfacher zu erklären ist: Obwohl der Name aus dem Japanischen stammt, wirft er weit weniger Fragen auf als die Metapher »Drum-Buffer-Rope«. Die Erklärung der Metapher hinter »Drum-Buffer-Rope« als eine Allegorie von Pfadfindern, die auf einem schmalen Bergpfad wandern, war umständlich und ich hatte Mühe, sie glaubwürdig zu vermitteln.

Es stellte sich heraus, dass »Kanban« im Gedächtnis haften blieb, während »Drum-Buffer-Rope« auf die Menschen eher abschreckend wirkte.

In Anbetracht all dessen gab es im Jahr 2004 jedoch immer noch große Bedenken, dass sich die Arbeit in professionellen Dienstleistungsbranchen stark von der Arbeit in Branchen mit materiellen Gütern wie der Fertigung oder dem Supply Chain Management unterscheidet. Es gab keinen Präzedenzfall für den Einsatz von Kanban-Systemen in Bereichen wie der Softwareentwicklung. Es war leicht zu kritisieren, dass Kanban-Systeme nicht für professionelle Dienstleistungen geeignet seien.

Es sollte noch einige Jahre dauern, bis sich der Einsatz von virtuellen Kanban-Systemen für professionelle Dienstleistungen, immaterielle Güter und die Tätigkeiten von Wissensarbeitern im Allgemeinen durchsetzte. Dies ist die Geschichte, wie Kanban aus der Fertigung des 20. Jahrhunderts in die modernen Unternehmensprozesse des 21. Jahrhunderts übernommen wurde. Es ist die Entstehungsgeschichte der Methode, die als die Kanban-Methode bekannt wurde.

Zusammenfassung

Kanban-Systeme stammen aus der Familie von Ansätzen, die als Pull-Systeme bekannt sind.

Die Drum-Buffer-Rope-Anwendung der Engpasstheorie von Eliyahu Goldratt ist eine alternative Umsetzung eines Pull-Systems.

Die fünf Fokussierungsschritte der Engpasstheorie sind ein Beispiel für einen evolutionären Verbesserungsansatz, der durch die Identifizierung von Engpässen getrieben ist.

Eliyahu Goldratt nannte solch einen evolutionären Ansatz POOGI (Prozess der ständigen Verbesserung). Die Motivation, einen Pull-System-Ansatz zu verfolgen, hatte zwei Ausrichtungen: einen systematischen Weg zu finden, um eine nachhaltige Entwicklungsgeschwindigkeit zu erreichen, und einen Ansatz zu finden, um Veränderungen in der Arbeitsweise mit möglichst wenig Widerstand einzuführen.

Der Kaiserliche Garten in Tokio nutzt ein Kanban-System, um die Anzahl der Menschen im Park zu steuern.

Die Menge an Arbeit wird durch die im Umlauf befindlichen Kanban-Karten (Signalkarten) begrenzt.

Kanban-Systeme können zur Verbesserung des Arbeitsflusses in einem System in jeder Situation eingesetzt werden, in der der Wunsch besteht, die Menge der Dinge innerhalb dieses Systems zu begrenzen.

Neue Arbeit wird in den Prozess gezogen, wenn die aktuelle Arbeit abgeschlossen ist und die Kanban-Karte wieder verfügbar wird.

Kanban hat das Dilemma gelöst, einen Ansatz zu finden, der sowohl eine nachhaltige Geschwindigkeit als auch die Einführung von Veränderungen zur Verbesserung der wirtschaftlichen Leistung ohne nennenswerten Widerstand oder Trägheit ermöglicht.

2Ein ehemaliger Athlet und seine neue Herausforderung

Die Motivation für Kanban bei Microsoft im Jahr 2005

»Kanban funktioniert nur mit kleinen Teams, die zusammen an einem Ort arbeiten.« Dies war ein weitverbreiteter Glaube zu der Zeit, als ich das Kanban-Buch (Blue Book) 2010 veröffentlichte, ein Glaube, der sich bis heute hält. Natürlich handelt es sich hier um einen Mythos! Diese Annahme beruhte auf dem Verständnis, dass gemeinsam vor dem Board zu stehen und »darauf zu schauen« das zentrale, wesentliche Element sei. Folglich gab es viele sogenannte Experten, die bereit waren, öffentlich und mit Nachdruck zu erklären, dass Kanban in geografisch verteilten Organisationen nicht funktioniert. Wenn die Menschen nicht gemeinsam vor einem Board stehen können, wurde argumentiert, dann konnte ihnen Kanban überhaupt nichts bieten. Die große Ironie dieses Mythos wird in den beiden folgenden Kapiteln enthüllt, die die Geschichte erzählen, wie wir mit Kanban angefangen haben …

Dragos Dumitriu ist ein freundlicher, humorvoller Amerikaner rumänischer Abstammung mit einem gewinnenden Lächeln und einer Lebensfreude, die andere Menschen dazu zu bringen scheint, ihn zu mögen und seinem Beispiel zu folgen. Er ist groß, kahlköpfig, kräftig gebaut und hat auch im mittleren Alter nur wenig zugenommen. Er macht in seinen handgefertigten, europäischen Maßanzügen und mit der teuren Sonnenbrille eine elegante Figur. Obwohl er mehr als 20 Jahre in den Vereinigten Staaten gelebt hat, ist sein osteuropäischer Akzent immer noch deutlich zu hören. Insgesamt hat Dragos etwas Einschüchterndes an sich, etwas, das sagt: »Macht keinen Unfug, ich habe hier das Sagen!« Man kann sich vorstellen, wie die Kleingangster die Straßenseite wechseln, wenn sie ihn in der Innenstadt von Bukarest aus seinem großen dunklen BMW aussteigen sehen.

Sein Körperbau ist das Erbe seiner Vergangenheit als junger Athlet im rumänischen Olympiateam. Als junger Erwachsener besaß und leitete Dragos in seiner rumänischen Heimat ein Fitnesscenter, arbeitete als Stuntman in Filmen und als Bodyguard. Er ist der Inbegriff einer »überlebensgroßen Persönlichkeit«. Er zog mit seiner damaligen Frau, einer erfolgreichen Ärztin, nach New York, nahm einen schlecht bezahlten Job in einer psychiatrischen Klinik an und stieg innerhalb von zwei Jahren zu deren Manager auf. Er folgte seiner Frau nach Fargo in North Dakota, einer abgelegenen Stadt im Norden der USA, die vor allem durch den gleichnamigen Film und die daraus abgeleitete Serie gleichen Namens bekannt wurde und für ihren bitterkalten Winter berüchtigt ist, und begann bei Great Plains Software als Projektmanager. Es war seine erste Erfahrung in der IT-Branche, obwohl er schon weit über dreißig war.

Nach der Übernahme von Great Plains durch Microsoft, aus der Microsoft Dynamics hervorging, wechselte Dragos 2003 nach Seattle und fand sich als Programmmanager in der IT-Abteilung wieder. Im folgenden Jahr suchte er nach einer neuen Herausforderung und meldete sich freiwillig, die Leitung des kleinen Wartungsteams im XIT-Geschäftsbereich zu übernehmen, dem Team, das bekanntermaßen die schlechteste Kundenzufriedenheit in der gesamten IT-Organisation von Microsoft hatte.

2.1Das XIT-Wartungsteam

Zu dieser Zeit bestand Microsoft aus sieben verschiedenen Geschäftseinheiten. Sie alle wurden wie eigenständige Unternehmen behandelt. Darüber hinaus gab es die Unternehmenszentrale, die diesen sieben Geschäftseinheiten gemeinsame Dienstleistungen wie Personalabteilung, Finanzen, Gebäudemanagement und Sicherheitsfunktionen bereitstellte. Der IT-Bereich dieser Unternehmenszentrale war als XIT bekannt (oder cross-funktionale, übergreifende IT, was auf die Art der gemeinsam genutzten Dienstleistungen hinweist, die sie für die kundenorientierten Geschäftseinheiten bereitstellte).

Dale Christian, der später als CIO von Avanade und noch später als CIO der Bill & Melinda Gates Foundation tätig sein sollte, war der Geschäftsführer von XIT. Das Wartungsteam war ein kleines Team, das mit kleineren Funktionserweiterungen und Fehlerbehebungen außerhalb der Hauptversionen und Anwendungsupgrades beauftragt wurde. Aus buchhalterischer Sicht wurden die Ausgaben für dieses Team als Betriebskosten betrachtet, während die Ausgaben für die Projektteams, die an den Projekten im Gesamtprojektportfolio arbeiteten, als Investitionsausgaben angesehen wurden. Es handelt sich dabei um zwei verschiedene Budgets und während Investitionsausgaben einen Vermögenswert darstellen, sind Betriebsausgaben reine Kosten. Dies wirkte sich sowohl auf das Verhalten der Mitarbeitenden als auch auf die Entscheidungsfindung aus.

Das Team, für das sich Dragos gemeldet hatte, befand sich in Hyderabad in Indien in einem sogenannten Captive-Center, das von der Outsourcing-Firma TCS eigens für Microsoft errichtet worden war. Wenige Jahre zuvor hatte Microsoft die strategische Entscheidung getroffen, seine IT-Bereiche auszulagern. IT gehörte nicht zum Kern von Microsofts Identität und Mission, sondern war eher eine unterstützende Komponente. Daher war es sinnvoll, dass die IT als eine Dienstleistung aus der Ferne bereitgestellt werden konnte. Man hoffte, dass man die Entwickler und Tester, die am Microsoft-Standort in der Nähe von Seattle arbeiteten, für die Arbeit an anderen Produkten der sieben Geschäftseinheiten einsetzen konnte. Der Großteil dieser Umstellung erfolgte im Jahr 2003, sodass die verbleibende IT-Abteilung weitgehend eine Organisation zur Verwaltung von Zulieferern war, die hauptsächlich aus einzelnen Personen mit dem Titel »Programmmanager« bestand. Dragos hatte die Aufgabe, das kleine sechsköpfige Wartungsteam in Hyderabad zu leiten und zu managen.

Zum besseren Verständnis: Seattle liegt, je nach Zeitverschiebung entweder 12,5 oder 13,5 Stunden hinter Hyderabad. Dieser Zeitunterschied bringt sowohl Herausforderungen als auch Chancen mit sich, wenn man Zulieferer in Indien von der Westküste der Vereinigten Staaten aus managt. Der Vorteil ist, dass Dinge über Nacht erledigt werden können. Der Nachteil ist, dass synchrone Kommunikation, wie z.B. Telefonkonferenzen, schwer zu planen ist und wenn in Seattle Freitag ist, ist in Indien bereits Samstag und damit Wochenende. Es stehen effektiv nur vier Tage pro Woche zur Verfügung, um diese Zeitverschiebung zu überwinden.