[Book Review] Kanban – Successful Evolutionary Change for Your Technology Business

Kanban: Successful Evolutionary Change for Your Technology Business

David J. Anderson beschreibt im Buch Kanban als Change Management Ansatz , der es ermöglicht, von jeder bestehenden Arbeitsweise schrittweise auf Kanban zu wechseln ohne großen Widerstand zu erzeugen. Im Vergleich zu XP und Scrum definiert Kanban dabei weniger Regeln und verspricht generischer und reibungsloser in Unternehmen einführbar zu sein. Ein Kanban System ermöglicht durch die Limitierung des “Work-in-progress” und die Minimierung von “Waste” (Lean-Gedanke) die Durchlaufzeiten und den Durchfluss (Flow) zu optimieren und eine Kultur der kontinuierlichen Verbesserung zu schaffen.

Inhalt:

Meine persönlichen inhaltlichen Highlights aus dem Buch möchte ich kurz zusammenfassen.

Kanban als Change Management Methode:

Anderson beschreibt in 6 hintereinander folgenden Schritten die “sanfte” Transformation von einem bestehendem System (z.B. Wasserfall) zu einem Kanban System:

  • Fokus auf Qualität: Laut Anderson sollte man sich zuerst auf die Verbesserung der bestehenden Qualität kümmern, da dies den geringsten Widerstand erzeugt und der eigene Einfluss auf die Qualität meist groß ist.
  • Work-in-Progress limitieren: Hat man die ersten “Quick-Wins” durch erhöhte Qualität erzielt empfiehlt Anderson WiP Limits einzuführen um den Flow zu steuern und zu optimieren.
  • Häufig ausliefern: WiP Limits erzeugen eine verkürzte Durchlaufzeit, was dazu führt, dass häufiger Released werden kann. Häufige Releases erzeugen Vertrauen bei Auftraggebern und anderen Stakeholdern.
  • Nachfrage und Durchfluss balancieren: Um eine konstant hohen Durchfluss zu erzielen müssen Nachfrage (Jene, die Arbeit für das Kanaban Team erzeugen) und Durchsatz des Teams aufeinander abgestimmt sein. In diesem Schritt werden Bottlenecks im Wertestrom sichtbar. Ruhende Ressourcen führen zu freien Kapazitäten (“Slack”), die wiederrum genutzt werden um kontinuierliche Verbesserung voranzutreiben.
  • Priorisieren: Im nächsten Schritt wird der Fokus auf den Wert der Deliverables gelegt. Die Anforderungen werden ihrem Business-Value entsprechend priorisiert und abgearbeitet.
  • Variabilität verringern um Planbarkeit zu erhöhen: Variabilität (Größe der Arbeitseinheiten, Schlecht definierte Requirements, Blockaden im Wertestrom,…) erhöht den WiP und verringert den Durchfluss. Da Variablität im Ausmaß und Zeitpunkt nicht vorhersehbar sind verringert sie auch die Planbarkeit des Kanban Systems. Daher muss Diese kontinuierlich verringert werden.

Theory of Constraints als Basis für kontinuierliche Verbesserung:

David J. Anderson wurde bei der Entwicklung der Kanban Methode maßgeblich von Eli Goldratt’s “Theory of Constraints” beeinflusst. Goldratt definiert in seiner Theorie 5 Fokus-Schritte als Basis für kontinuierliche Verbesserung:

  1. Identifiziere eine Einschränkung (engl.: Constraint)
  2. Entscheide wie die Einschränkung behoben werden kann
  3. Richte die Pläne und dein Handeln nach der Entscheidung von Schritt 2 aus (Optimierung)
  4. Behebe die Einschränkung durch Verbesserung (Innovation)
  5. Finde die nächste Einschränkung und fahr mit Schritt 2 fort

Anderson greift auf diese Theorie zurück, indem er sie als Grundlage für die kontinuierliche Verbesserunge des Wertestromes eines Kanban Systems heranzieht. Auf Kanban bezogen bedeuten die 5 Schritte folgendes:

  1. Identifiziere einen Bottleneck im Wertestrom
  2. Analysiere und vergleiche den potentiell möglichen Durchfluss (SOLL-Zustand) mit dem aktuellen Durchfluss (IST-Zustand) im Bottleneck (Was muss getan werden um den SOLL-Zustand zu erreichen?)
  3. Nutze das maximale Potential des Bottlenecks durch Implementierung der Ideen von Schritt 2 aus (Optimierung)
  4. Wenn der neu erreichte Durchfluss noch immer zu gering ist führe mittels einer Verbesserung (Innovation) im Bottleneck oder Anderswo eine Erhöhung des Durchflusses im Bottleneck herbei
  5. Gebe dem System Zeit um sich zu stabilisieren. Identifiziere nun den nächsten Bottleneck im Wertestrom und führe den Prozess bei Schritt 2 fort.

Visualisierung des Wertestroms:

Im Unterschied zu Scrum Boards, die standardmäßig 3 Spalten “ToDo”, “In Progress” und “Done” für den Arbeitsfluss im Sprint vorsehen, werden Kanban Boards individuell auf den Wertestrom des Unternehmens angepasst. Damit ist das Board flexibler und es kann der Wertestrom weit über die Entwicklungstätigkeiten hinaus visualisiert werden. Ein Beispiel für einen visualisierten Wertestrom zeigt die folgende Abbildung:

KanbanFlow

Im obigen Beispiel dienen die Spalten “Dev Ready”, “Build Ready”  und “Release Ready” als Buffer zwischen den eigentlichen Arbeitsschritten. In den Buffern “warten” Tasks darauf, bis sie von einem dahinter liegenden Arbeitsschritt angefordert werden. Um den Wertefluss steuern zu können – die Verweilzeiten der Tasks in den Buffern und in den Arbeitsschritten verkürzen – setzt Kanban Work-In-Progress Limits ein.

Work-In-Progress Limits:

WiP Limits können, müssen aber nicht auf allen Spalten angewendet werden. Zumindest muss jedoch ein Schritt im Wertefluss mit einem WiP Limit versehen werden. Je “straffer” (kleiner) die WiP Limits gewählt werden, desto kürzer wird die Durchlaufzeit der Tasks. Je “großzügiger” (größer) sie gewählt werden, desto mehr WiP hat man und die Durchlaufzeit erhöht sich. Durch “straffe” WiP Limits kann es vorkommen, dass nicht alle Ressourcen ausgelastet werden. Diese “Slack-Time” ist zu einem gewissen Maß gewollt und soll bewusst zur Weiterbildung, Prozessverbesserung, Innovation, etc. verwendet werden. Die Wahl der Limits ist in jedem Fall individuell an die Gegenbenheiten anzupassen und kann auch verändert werden. Die folgende Abbildung zeigt ein Beispiel für WiP Limits für den vorhin definierten Wertestrom:

KanbanFlowWIP

Neben WiP Limits auf  konkreten Arbeitsschritten (Spalten) können auch WiP Limits auf Issue Klassen definiert werden. Zum Beispiel kann die Anzahl an Incident Tickets, Tasks, User Stories, Improvements usw. im gesamten Workflow limitiert werden. Die unterschiedlichen Issue Klassen können entweder farblich (Farbe der Post-it Zettel) oder durch einziehen von Swimlanes (am Kanban Board) voneinander unterschieden werden.

Ein ökonomisches Modell von “Lean”:

Wie Scrum, bedient sich auch Kanban dem Lean-Gedanken des Toyota Production Systems (TPS). Hinter dem wörtchen “Lean” steckt eine radikale Vermeidung bzw Reduktion von “Waste” oder “muda” (jap.) – das sind Tätigkeiten die im Produktionsprozess keine Wertschöpfung bringen. Da der Begriff “Waste” für Wissensarbeit etwas abstrakt erscheint, bezeichnet Anderson “Waste” schlicht als “Kosten” und zeichnet folgendes Modell:

economicmodelofleanswdevelopment21

Jedes Projekt hat eine gewisse Zeitspanne, in der Wertschöpfung generiert wird. In einem Softwareprojekt, ist das jene Zeit, in der die Software erzeugt (analyisert, designed, entwickelt, getestet, usw.) wird. Impediments behindern den Wertschöpfungsprozess und sind daher Kosten bzw im Lean-Jargon “Waste”. Bevor jedoch die Entwicklerteams mit ihrer Arbeit beginnen können müssen gewisse Projektvorbereitungen getroffen werden (z.B. Angebotslegung, Risikomanagement, Vertragsverhandlungen, Infrastruktur beschaffen, Staffing,…). Am Ende des Projektes fallen wieder Kosten an (z.B. Auslieferung, Reorganisation der Ressourcen, Ramp-down der Entwicklungsumgebungen, Retrospektiven,…). Diese Kosten (bzw. “Waste”) für Projektsetup und Cleanup bezeichnet Anderson als Transaktionskosten. Über die gesamte Projektlaufzeit fallen ebenfalls Kosten für die Koordination (Meetings über Taskverteilung, Verwendung von Tools, Releaseplanung,…) an.

Ziel ist es durch Selbstorganisation, Visualisierung des Prozesses und des WiP, Optimierung des Arbeitsplatzes (z.B. durch Automatisierung, schnelle Hardware,…) und kontinuierlicher Verbesserung des Prozesses die Transaktions- und Koordinationskosten sowie die Impediments zu minimieren.

Conclusio:

Anderson vermittelt mit dem Buch sehr gut worum es ihm mit Kanban geht und wodurch er bei der Entwicklung der Methode beeinflusst wurde. Wer Kanban ganzheitlich verstehen möchte, der wird mit dem Buch glücklich sein. Auch wenn Anderson sich teilweise lange mit Theorien und Details aufhält, wird das Essentielle stehts gut beschrieben und dem Leser klar gemacht. Aus meiner Sicht eine klare Empfehlung für alle, die sich mit agiler Softwareentwicklung, Change Management, Lean, KVP oder Organisationsentwicklung in der IT auseinandersetzen.

Advertisements

Published by

Stefan Wunder

My name is Stefan Wunder and I am a passionate Lean & Agile Coach from Graz, Austria. I have been applying Lean & Agile methodologies in various industries and contexts since 2006. Since 2014 I am working as Agile Coach at AVL List GmbH, the world’s largest independent company for development, simulation and testing technology of powertrains (hybrid, combustion engines, transmission, electric drive, batteries and software) for passenger cars, trucks and large engines. I have a Master of Science in software development and business economics. I am Certified Systemic Coach, Certified Scrum Professional (CSP), Certified Scrum Master (CSM), Certified SAFe Program Consultant (SPC) and Certified LeSS Practitioner. I am speaker at conferences, and moderator of the Scrum User Group Graz.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s