On Lean and Agility

Zwölfter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Suchen nach einem Schuldigen.

Dass immer dann, wenn irgendetwas schief gelaufen ist, zuerst nach einem Schuldigen gesucht wird, ist ein verbreitetes Phänomen. Wie konnte das passieren? Wer hat da nicht aufgepasst? Wessen Aufgabe wäre es gewesen das zu verhindern? Wer wäre verantwortlich gewesen für einen Prozess der das verhindert? Solche und ähnliche Fragen sind absolute Klassiker, wenn es um die Aufarbeitung geht, und sie alle haben eines gemeinsam: sie sind nicht besonders zielführend.

Zunächst führen sie immer wieder zu einem erstaunlichen Forschungs- und Exegese-Aufwand, um rückwirkend aus irgendeiner Vorschrift oder Abmachung ableiten zu können, wer sich theoretisch oder nach "gesundem Menschenverstand" hätte verantwortlich fühlen müssen, oder wer irgendwann mal eine Zusage gemacht oder eine Aufgabe übernommen hat, aus der sich die Verantwortung für das mittlerweile eingetretene Missgeschick ableiten liesse.

Umgekehrt ergeben sich aus ihnen ähnlich grosse Aufwände, mit denen alle, die für die Schuld in Frage kommen, belegen wollen, dass sie selbst in keinem Fall verantwortlich sind. Auch von ihnen werden alle möglichen Vorschriften, Abmachungen, Protokolle, Pläne, Zuständigkeitsbeschreibungen und sonstigen Dokumente gewälzt werden um mit deren Hilfe nachweisen zu können, zum jeweiligen Zeitpunkt nicht informiert, verfügbar oder zuständig gewesen zu sein.

Und damit endet es nicht. Sind einer oder mehrere Schuldige gefunden worden, werden sie erfahrungsgemäss erhebliche weitere Aufwände in Distanzierungen, Absicherungen und ähnliche Tätigkeiten stecken, um beim nächsten mal nicht mehr Schuld zu sein. Und sollte die Schuldzuordnung unklar gewesen sein, fliessen häufig erhebliche weitere Aufwände inzusätzliche Regeln, Dokumentations-Pflichten und weitere Massnahmen, um das nächste mal die Schuld klarer zuweisen zu können.

Nichts davon erzeugt einen Mehrwert, alles davon verbraucht Zeit und Energie. Es ist Muda in Reinform. 

Um eine Alternative aufzuzeigen: statt den Schuldigen zu suchen könnte man überlegen, wie man Prozesse sicherer oder unbürokratischer gestaltet, Kommunikation einfacher und direkter möglich macht, Qualitätssicherungs-Massnahmen einführt die nicht nur aus Dokumentations-Pflichten bestehen und vieles mehr. Das wären Schritte, die zwar auch Aufwand verursachen, aber einen der sich auszahlt und nicht bloss alle Beteiligten frustriert.

Bild: Unsplash / Glenn Carstens-Peters - Lizenz

Elfter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: Inspect ohne Adapt.

In gewisserweise handelt es sich bei dieser speziellen Ausprägung um eine (wenn nicht sogar die) "agile Muda", da sie vor allem im Umfeld von (schlecht laufender) agiler Produktentwicklung anzutreffen ist. Sie liegt vor, wenn zwar regelmässig nach Verbesserungspotentialen oder Dysfunktionen gesucht wird, ein Auffinden einer solchen aber keine Schritte zur Folge hat, die den Zustand verbessern sollen. Ein klassisches Beispiel dafür wären Retrospektiven ohne Action Items.

Der Verschwendungs-Charakter dieses (Nicht-)Vorgehens ist offensichtlich: für das Suchen, Identifizieren, Beschreiben und Besprechen schlecht laufender Dinge ist Arbeitszeit nötig, und Zeit ist im Unternehmenskontext gleich Geld. Das ist in gewisser Weise gleich doppelt fällig - zum einen für die gerade genannten Tätigkeiten, zum anderen für das Nachholen anderer Aktivitäten, die wegen der so bereits vergebenen Arbeitskapazitäten in die Zukunft verschoben werden mussten.

Ein weniger offensichtlicher aber in seinen Auswirkungen nicht zu unterschätzender Effekt ist der in diesem Rahmen eintretende Motivationsverlust der Mitarbeiter, die erkennen, dass ihnen mit ihren Problemen nicht geholfen wird. Zum einen kann die daraus entstehende Frustration zu nachlassender Arbeitsleistung führen, zum anderen dazu, dass neu auftretende Probleme gar nicht mehr addressiert und bearbeitet werden, da mit ihrer Lösung gar nicht mehr gerechnet wird.

Im schlimmsten Fall entsteht zusätzlich zu diesen Effekten nochmal ein weiterer Verwaltungsaufwand, nämlich dadurch, dass die identifizierten aber nicht gelösten Verbesserungspotentiale und Dysfunktionen ggf. aufbewahrt und aktuell gehalten werden müssen. Die damit verbundenen Untersuchungs-, Informations-, Aktualisierungs- und Repriorisierungs-Aufwände überfrachten das ohnehin schon sinnlose Inspect ohne Adapt nochmal mit einer weiteren Muda, der Lagerhaltung.

Ein derartiges Verhalten abzustellen sollte aus diesen Gründen für jedes agile Team (aber auch für jedes andere Team bei dem es auftritt) eine hohe Priorität haben. Notwendig dafür ist es allerdings, den Teufelskreis einmal initial zu durchbrechen und dem Inspect auch ein tatsächliches Adapt folgen zu lassen, in diesem Fall eine Verhaltensänderung. Ist das aber einmal gelungen, kann in dem so gestarteten Verbesserungszyklus kontinuierlich an Fortschritten gearbeitet werden.

Bild: Flickr / Rosenfeld Media - CC BY 2.0

Einer der grossen Unterschiede zwischen den beiden populärsten agilen Frameworks, Scrum und Kanban, war immer, dass Scrum mit dem Scrum Guide ein verbindliches Regelwerk hatte, während Kanban trotz weit verbreiteter und allgemein anerkannter Praktiken eher "Open Source" war, so dass jeder hineindefinieren und -interpretieren konnte was er wollte. Diese Unklarheit hat immer wieder den Wunsch nach einem "Kanban Guide" aufkommen lassen.

Die erste Organisation die versucht hat diese Lücke zu füllen (bzw. den damit verbundenen Zertifizierungs-Markt zu erschliessen) war die Lean Kanban University, die 2016 den trotz seines Namens etwas aufgeblähten Essential Kanban Condensed Guide veröffentlichte, der dann 2021 durch den schlankeren "Official" Kanban Guide abgelöst wurde. Aufgrund seines Namens wird der immer wieder für das einzige und verbindliche Kanban-Regelwerk gehalten.

Da der Begriff und die Idee von Kanan nicht geschützt sind, gibt es aber auch Alternativen, unter denen die vielleicht bekannteste schlicht The Kanban Guide heisst. Selbst wenn seine Verfasser Daniel Vacanti und John Coleman mit ProKanban (einer anderen Zertifizierungs-Organisation) verbunden sind, ist das Dokument bewusst nicht mit deren Brand verbunden oder auf deren Website gehostet, um so seinen universellen Anspruch und seinen nicht-kommerziellen Charakter hervorzuheben.

Von seiner Struktur her organisiert er sich sehr stark am Scrum Guide, bis hin zu dem Punkt, dass mehrere seiner Abschnitte fast identisch benannt sind (Purpose of the Kanban Guide statt Purpose of the Scrum Guide, Definition of Kanban statt Scrum Definition, Kanban Theory statt Scrum Theory, etc.).¹ Lediglich in seinem Mittelteil gibt es Abweichungen, gegen Ende entspricht der Aufbau mit End Note und Acknowledements wieder sehr stark dem des Scrum Guides.

Inhaltlich sind es auch vor allem diese mittleren Abschnitte, die Kanban Practices, das Improving the Workflow und die Kanban Measures die interessant sind.² Den grössten Teil nehmen dabei die Practices ein, es handelt sich bei ihnen um Defining and Visualizing the Workflow, Actively Managing Items in a Workflow, Controlling Work In Progress und  Service Level Expectation.³ Nach Ansicht der beiden Autoren handelt es sich dabei um die unverzichtbaren Kernbereiche der Kanban-Methode.

Mit Actively Managing Items in a Workflow sind im Kanban Guide die Tätigkeiten gemeint, die den reibungslosen Durchfluss von Arbeit durch das System sicherstellen oder wiederherstellen sollen. Im Einzelnen sind das Controlling Work in Progress (d.h. dessen Menge), Avoiding work items piling up in any part of the workflow, Ensuring work items do not age unnecessarily (mit Hilfe von Service Level Agreements) und Unblocking blocked work.

Mit Controlling Work in Progress und Ensuring work items do not age unnecessarily bekommen die erste und letzte der zuletzt genannten Tätigkeiten noch einen eigenen Abschnitt, in dem tiefergehend erläutert wird, was sich dahinter verbirgt, bzw. welche weiteren Konzepte damit verbunden sind. Hier finden sich u.a. auch das Pull-Prinzip und das probabilistische Forecasting, die damit im Vergleich zu anderen Kanban-Auslegungen eine eher wenig prominente Plazierung haben.

Im Vergleich dazu ist das Improving the Workflow relativ knapp beschrieben. Hervorgehoben wird vor allem, dass es überhaupt stattfinden sollte, dass es auf der Grundlage von Zahlen und/oder Erfahrungen erfolgen sollte und dass es Verbesserungen der Effizienz, Effektivität und Vorhersagbarkeit zum Ziel haben sollte. Bemerkenswert ist, dass explizit nicht nur kleine sondern auch grosse Verbesserungen möglich sind, also nicht nur Kaizen sondern auch Kaikaku.

Die Kanban Measures sind schliesslich wieder die grossen Klassiker: Work in Progress-Menge, Throughput, Work Item Age und Cycle Time (Lead Time dagegen bemerkenswerterweise nicht). Neben ihrer kurzen Erklärung wird noch unterstrichen, dass sie nur zum Zweck der Prozessverbesserung erhoben und kein Selbstzweck sein sollen, und dass es möglich ist, sie um weitere Metriken zu ergänzen, wenn man darin einen Mehrwert sieht.

Was der Kanban Guide nicht (bzw. nur als Nennung optionaler Möglichkeiten) enthält, sind Meetings und Rollen. Es wird zwar erwähnt, dass es möglich ist, Dailies und Retrospektiven (die hier nur Reviewing the Definition of Workflow from Time to tTime heissen) abzuhalten, von einer zu starken Formalisierung wird aber abgeraten. Im Fall der Rollen ist nicht mal das gegeben, sie werden an keiner Stelle des Kanban Guide auch nur erwähnt, geschweige denn vorgegeben.

Zur Bewertung, bzw. Einordnung: das auf den ersten Blick Auffälligste am Kanban Guide dürfte die starke Anlehnung seiner Struktur an die des Scrum Guide sein. Die mag ihre Vorteile haben, da jemand der bisher nur Scrum kennt sich leichter zurechtfinden wird, andererseits wirkt sie etwas gezwungen und z.T. sogar un-originell, etwa in den End Note, die in einigen Passagen eine Eins-zu Eins-Kopie ist. Auch die Definition of Workflow wirkt etwas gezwungen.

In Abgrenzung zum "Official" Kanban Guide der Kanban University ist erkennbar, dass die jeweiligen Verfasser jeweils unterschiedliche Elemente für wichtig oder verzichtbar gehalten haben. Während z.B. im "Official" Kanban Guide Aufbau und Nutzung eines Kanban-Boards einen grossen Platz einnehmen, fehlen sie in The Kanban Guide völlig. Das macht einmal mehr die Gestaltungsoffenheit von Kanban deutlich (die dann allerdings mit den Mindestvorgaben der Verfasser kollidiert).

Genau die Offenheit an dieser Stelle, durch die klar wird, dass Kanban zwar in Form eines Boards mit Kartenoder Kacheln dargestellt werden kann, aber keinerswegs dargestellt werden muss, ist übrigens eine, die grossen Teilen der Kanban-Community fehlt (Alternativen sind Ampelfarben, Kontroll-Charts, Kummulative Flussdiagramme, etc.). Alleine in dieser Hinsicht ist Vacantis und Colemans Guide eine wertvolle Ergänzung.

Auffällig ist ausserdem, dass ihr Regelwerk nochmal kürzer und komprimierter ist als die von Scrum und der Kaban University. Einschliesslich Inhaltsverzeichnis umfasst er nur neun Seiten. Aufgrunddessen kann man ihn auch ohne grossen Aufwand als Ergänzung zum nur unwesentlich längeren Guide der Kanban University benutzen, alleine um verschiedene Blickwinkel auf das Thema Kanban zu bekommen, dass sich mit einem Dokument alleine kaum abbilden lässt.

Bild: Pexels / Ketut Subiyanto - Lizenz

Es ist mal wieder Zeit für eine Agile Success Story. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen, das kann man viel zu oft bei Agile Coaches, Scrum Mastern und ähnlichen Rollen erleben. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich selbst erlebte "agile Erfolgsgeschichten" veröffentliche, heute eine zum Thema Kanban.

Eigentlich hatte ich den Auftrag gar nicht annehmen wollen. Insgesamt sieben verschiedene Abteilungen eines Kunden wollten "ihre Zusammenarbeit agiler machen", davon drei Fachabteilungen, zwei aus der IT, eine aus Operations und eine aus dem Einkauf. Das klang als Herausforderung durchaus spannend, das Problem war aber das Budget - für eine Woche in Vollzeit würde es reichen, danach nur noch für vier Tage pro Monat während des restlichen Jahres. Im Grunde viel zu wenig.

Am Ende liess ich mich darauf ein, wenn auch mit einer klaren Einschränkung: in dieser knappen Zeit würde zu Beginn kaum mehr möglich sein als die Ermittlung und Visualisierung des Value Streams, und in späteren wöchentlichen Terminen ein Inspect & Adapt in kleinen Schritten. Die urspünglich vom Kunden gewünschte Einführung eines agilen Skalierungsframeworks wäre mit diesem geringen Aufwand illusorisch gewesen. Das wurde angenommen, also legten wir los.

Bereits das Value Stream Mapping war dann anspruchsvoll genug. Es handelte sich um eine geschäftskritische Anwendung, die auf Wunsch interner und externer Stakeholder ständig weiterentwickelt wurde. Neue Features wurden jeweils von einer der drei Fachabteilungen beauftragt und entweder von einer der beiden internen IT-Abteilungen oder durch externe Dienstleister (koordiniert durch den Einkauf) entwickelt.

Das, was dieses Vorgehen schwierig machte, waren Unübersichtlichkeit und Intransparenz. Es gab so viele Feature Requests (die natürlich alle dringend waren), dass niemand einen Gesamtüberblick darüber hatte, welche internen oder externen Entwickler gearde im Auftrag welcher Fachabteilung etwas umsetzten. Das Ergebnis waren redundante Arbeiten, die Entwicklung inkompatibler Features, ständige Nacharbeiten, zu hohe Arbeitsbelastung und ständig gerissene Deadlines.

Nach einer Woche intensiven Nachforschens gab es dann ein erstes Ergebnis: abhängig von den beiden Variablen bestehendes/neues Budget und interne/externe Entwicklung liessen sich drei Varianten des Value Streams identifizieren, eine mit 10 Stationen, eine mit 15 und eine mit 19 (!). Da das bei weitem zu viel war um auf einem Bildschirm überblickbar zu sein, fand die Visualisierung in Form eines physischen Kanban-Boards statt - Drei Zeilen mit jeweils 10, 15 und 19 Spalten.¹

Bis zu unserem ersten Einzeltermin hatten die verschiedenen Einheiten sich dann die Aufgabe mitgenommen, alle grösseren Arbeitspakete an denen sie gerade sassen auf dieses Board zu bringen. Als ich nach einer Woche zurückkam war ich erstmal erschlagen - mehr als 60 verschiedene Zettel hingen über das ganze Board verstreut, jeder einzelne davon als Symbolisierung eines Gesamtaufwandes von mindestens einer Personenwoche. Kein Wunder, dass bisher die Übersicht gefehlt hatte.

Eigentlich hatte ich als nächstes vor diesem Board ein Daily etablieren wollen, was aber in einem lauten Proteststurm unterging ("Nicht noch mehr Meetings", wurde gefordert). Worauf sich alle einlassen konnten war aber ein wöchentlicher Termin, in dem Vertreter der sieben Abteilungen alles was in den letzten Tagen stattgefunden hatte auf dem Board aktualisierten, egal ob es neue Requests, Entwicklungsfortschritte, Budget-Zusagen oder sonst etwas waren.

Was in diesen Terminen auffällig war, war, dass nahezu jede Aktualisierung eine mittelgrosse Diskussion auslöste. Deren Inhalte reichten von Überraschung und Interesse über Zustimmung und Feedback bis hin zu Protest und Sinnfragen. Nahezu jeder der teilnahm hatte irgendetwas zu irgendeinem Thema beizutragen, so dass es regelmässig mehr als zwei Stunden dauerte, bis auf dem Board alles auf den aktuellen Stand gebracht war.²

Das wirklich Bemerkenswerte an diesen "Kanban Weeklies" war aber nicht ihre Länge. Anders als man es hätte erwarten können gab es kaum Beschwerden darüber, dass in sie so viel Zeit investiert werden musste oder dass in ihnen so viele Themen diskutiert wurden. Stattdessen wurde regelmässig hervorgehoben, wieviel grösser durch sie Transparenz, Übersichtlichkeit und als Folge dessen auch Planbarkeit und Reaktionsfähigkeit geworden wären.

Gleich mehrfach konnten neue Feature Requests einzelner Fachabteilungen bereits im Anbahnungsstatus gestoppt werden, weil eine der anderen darauf hinwies, etwas Vergleichbares bereits beauftragt zu haben. Die Entwicklungsabteilungen konnten besser absehen, wann grössere Arbeitspakete bei ihnen einschlagen würden und sich entsprechend Zeit einplanen. Die Operations-Abteilung konnte sich auf Lastspitzen durch neue Features besser einstellen. Etc, etc, etc.

Selbst wenn es WIP-Limits, Service-Klassen, Durchlauf-Metriken und viele andere Ideen die ich hatte aufgrund des beschränkten Zeitbudgets nicht mehr in dieses Kanban-System geschafft haben, wurden das Board uns seine Benutzung von allen Beteiligten als eine spürbare Verbesserung gesehen, durch die die meisten der oben genannten Probleme (redundante Arbeit, Intransparenz, ständige Nacharbeiten, etc.) spürbar zurückgegangen waren.

Auch ich habe aus diesem Einsatz eine Lehre mitgenommen: auch eine punktuelle Begleitung kann unter Umständen völlig ausreichend sein. Es braucht nicht immer einen Scrum Master, Kanban Coach oder sonstigen Methodiker, der in Vollzeit ein Team begleitet, manchmal kann es genügen, den Arbeitsfluss zu visualisieren, alle Beteiligten dazu zu bewegen ihn sich regelmässig gemeinsam anzusehen und darauf zu vertrauen, dass sich daraus die richtigen Dinge ergeben werden.

Bild: Pexels / Thirdman - Lizenz

Zehnter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann, kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Overthinking.

Zuerst ein Übersetzungsversuch. Für den Begriff Overthinking gibt es keine exkte Entsprechung in der deutschen Sprache, eine sinngemässe Übersetzung wäre "länger über etwas nachdenken als sinnvoll ist" oder "unverhältnismässig lange über etwas grübeln". In beiden Übersetzungs-Varianten ist die Muda-Natur bereits offensichtlich enthalten, bei näherer Betrachtung lassen sich aber ausserdem noch verschiedene Problem-Dimensionen erkennen.

Zum einen kostet ein unnötig langes Nachdenken die Beteiligten (Arbeits-)Zeit und damit ihr Unternehmen auch Geld. Das führt entweder dazu, dass sie nicht mehr für andere Tätigkeiten verfügbar sind (dazu gleich mehr) oder es hat zur Folge, dass zur Kompensation dieser Ausfälle weitere Menschen eingestellt werden müssen. Der zweite Fall wird nochmal schwerwiegender dadurch, dass diese Einstellungen (plus Koordination, Bezahlung etc.) weitere Verwaltungsaufwände erzeugen.

Zum anderen kann es zum Phänomen der Verzögerungskosten (Cost of Delay) kommen. Wird die durch das Overthinking entstehende Mehrarbeit nicht durch zusätzliches Personal kompensiert, schieben sich andere Tätigkeiten zwangsläufig nach hinten, wodurch sich Einnahmen verzögern (und dadurch kleiner ausfallen) können, Geschäfts-Chancen verschwinden können oder zusätzliche Zinsen auf alte oder neue Kredite anfallen können, die zur Kompensation ausfallender Einnahmen nötig werden.

Angesichts dieser Nachteile stellt sich die Frage, warum das Overthinking in vielen (vor allem grossen) Organisationen so weit verbreitet ist. Die Antwort kann natürlich je nach Einzelfall eine andere sein, häufige Gründe sind meiner Erfahrung nach aber Perfektionismus, Machbarkeits- und Steuerbarkeits-Illusionen, Risiko-Aversion (häufig verbunden mit knappen Budgets, deren Verwendung man unter Kontrolle halten will) und fehlende Systemsicht.

Um die nicht gewinnbringende, aber ressourcenverbrauchende Muda des Overthinking in den Griff zu bekommen, ist es daher erfolgsversprechend, zu untersuchen ob eine diese zugrundeliegenden Ursachen gegeben ist, um diese zu thematisieren und möglichst zu beseitigen. Selbst dann wenn das nicht gelingt, kann aber alleine die Erkenntnis der problematischen Effekte ausreichend sein, um ein Zurückfahren der Grübel-Aufwände auf ein sinnvolles Mass zu verursachen.

Zu meinen Lieblingsbeispielen für kontinuierliche Verbesserungsbemühungen zählen Einrichtungen, die man damit nicht sofort assoziieren würde: deutsche Behörden. Optimiert wird auch in ihnen, und da man sie nur in relativ grossen Abständen aufsucht, ist die Chance gross, dass einem jedesmal irgendetwas auffällt, das anders ist als beim letzten mal. In meinem Fall sind es die Bürgerämter meiner Wohnorte (z. Zt der Stadt Bonn), in denen ich etwa einmal pro Jahr erscheinen muss.

Bevor wir zu meinen Beobachtungen kommen, macht zuerst eine kurze Erläuterung zu dem "Verbesserungsgegenstand" Sinn: das was im Bürgerzentrum regelmässig optimiert wird, ist der Durchfluss von Kunden, also Bürgern, die für irgendeinen Verwaltungsakt dort vorstellig werden müssen. Um diesen eine möglichst gute Service-Erfahrung zu geben, und um die Servicekräfte optimal auszulasten, sollten Staus und Wartezeiten so gering wie möglich sein.

In der weit zurückliegenden Anfangszeit der Optimierungen war das noch nicht der Fall. Jeder der mit einem Termin oder als Laufkundschaft zur Stadt kam meldete sich an, setzte sich in einen Warteraum und wartete dort darauf, dass der eigene Name aufgerufen wurde. Wie lang das dauern würde liess sich nicht absehen, Wartezeiten von über einer Stunde waren nicht selten. Diese Unklarheit über die verbleibende Wartezeit war das erste, das durch eine Prozessanpassung behoben wurde.

Irgendwann wurden Wartenummern eingeführt, zu Beginn noch solche in Papierform, die man sich aus einem vor Ort stehenden Automaten ziehen musste. Aufgerufen wurden jetzt nicht mehr die Namen sondern die Nummern, wodurch sich erkennen liess, wie viele andere Personen vor einem selbst bedient werden würden. Liess sich so erkennen, dass es noch dauern würde, konnte man kurz vor die Tür gehen, Geld in die Parkuhr werfen, etwas rauchen oder sonstige kurze Erledigungen machen.

Der nächste Verbesserungsschritt war die Einführung grosser Bildschirme, auf denen die zuletzt aufgerufenen Nummern angezeigt wurden. Für den Fall, dass man verspätet eintraf oder den eigenen Aufruf überhört hatte, konnte man dort sehen, dass man bereits an der Reihe war. Eine darauf aufbauende Verbesserung bestand daraus, dass dort auch die Tischnummer der nächsten freien Servicekraft angezeit wurde, wodurch der bis dahin nötige Gang zum Zentralschalter entfiehl.

Die hinter der Anzeigetafel arbeitende Software wurde später mit einer weiteren verbunden, mit der man Terminbuchungen online vornehmen konnte. Sobald man einen Termin gebucht hatte erhielt man eine Mail. in der nicht nur die Terminbestätigung stand, sondern auch die Wartenummer. Vor Ort musste man dadurch nicht mehr eine Nummer ziehen und warten, sondern konnte direkt überprüfen, ob man bereits aufgerufen wurde.

Die vorerst letzte Optimierung, die mir bei meinem letzten Besuch aufgefallen ist, besteht darin, dass man jetzt vor Ort grosse Touch-Displays hat, auf denen man durch Eingabe seiner online gebuchten Wartenummer mitteilen kann, dass man angekommen ist und aufgerufen werden kann. Verspätungen sind dadurch kein Problem mehr, man rutscht stattdessen weiter nach hinten in die Reihenfolge, aus der zuerst andere Nummern aufgerufen und bedient werden können.

Weitere Prozessverbesserungen dürften in diesem Zeitraum auch ausserhalb des für die Kunden sichtbaren Bereichs stattgefunden haben, alleine im Bereich der Digitalisierung kann man sich so einiges vorstellen. Über die Jahre wird es so zu einem ingesamt beachtlichen Umfang von Veränderungen gekommen sein.

Diese Art der nach und nach stattfindenden Optimierung hat mehrere Vorteile gehabt: grosse, disruptive Veränderungen wurden unnötig, die Folgen der jeweils letzten Umstellung liessen sich aufgrund der kleinen Umfänge besser identifizieren und bewerten, und in Summe ist es so zu einem Prozess gekommen, der nicht nur gut funktioniert, sondern auch einer ist, auf den beim Versuch alles im Voraus zu planen vielleicht niemand gekommen wäre.

Zuletzt hat der KVP (Kontinierliche Verbesserungsprpzess) im Bürgeramt noch einen Vorteil auf der Meta-Ebene: er hat an einem Ort stattgefunden, den jeder Mensch in Deutschland kennt, ins Bürgeramt muss früher oder später jeder. Es ist damit ein Praxisbeispiel das sofort jeder nachvollziehen kann und anhand dessen man Prozessoptimierungen auch für Menschen, die selten damit zu tun haben, nachvollziebar erklären kann.

Grafik: Wikimedia Commons / Daniel Penfield - Public Domain

Dritter Teil der Übersicht über die Lean-Metriken. Nach einer allgmeinen Übersicht über die Typen von Durchlaufzeiten im ersten Teil (zu finden hier) und die einer Einführung in die Flusseffektivität im zweiten Teil (zu finden hier) soll es heute um die Flusseffizienz gehen. Um diese ähnlich klingenden Begriffe zu unterscheiden: während es bei der Effektivität darum geht die eigenen Tätigkeiten auf Sinnhaftigkeit zu optimieren (→ wenig Waste) hat Effizienz die Leistungsfähigkeit als Ziel (→ hoher Ausstoß). Zu beachten ist dabei natürlich, dass beides angestrebt werden sollte, hier soll es aber jetzt nur um Metriken für die Flusseffizienz gehen.

Takt Time

Die Takt Time bezeichnet die (anzustrebenderweise) immer gleich bleibende Zeit die zur Fertigstellung eines Liefergegenstandes benötigt wird, beispielsweise die 30 Sekunden die für einen Stanz- oder Fräs-Vorgang nötig sind. Eine der Lean-Metriken die nur schwer in die Software-Entwicklung übertragbar sind, wenn überhaupt eher auf automatisierte Prozesse als auf Programmiertätigkeiten.

Throughput Time

Auf Deutsch der Durchsatz. Bei ihm wird nicht mehr die Dauer einzelner Arbeitsvorgänge gemessen, sondern die Anzahl der erzeugten Ergebnisse (Produkte, Features, etc.) pro Zeiteinheit. Ein Beispiel wären 500 Autos die pro Tag in einer Fabrik gebaut werden. Aus dem Versuch die Throughput-Messung in die Software-Enwicklung zu übertragen ist das Konzept der Velocity entstanden.

Maintenance Time

Eine Metrik die leicht für einen Teil der Blocked Time gehalten werden kann, da Maintenance (Wartung) ähnlich wie diese dafür sorgt, dass die eigentliche Arbeit nicht stattfinden kann. Die Differenzierung: statt die Gesamtzeit der Nichtverfügbarkeit zu messen geht ist hier um die Durchschnittsdauer eines Wartungsintervalls, die idealerweise möglichst kurz sein sollte.

Recovery Time

Dieser Metriken-Typ ist von Bedeutung wenn es trotz Wartungen zu unfallbedingten Ausfällen kommt und misst die Durchschnittsdauer der Reparaturen und und der anschliessenden Wiederinbetriebnahme. Diese Dauer möglichst kurz zu halten ist nochmal wichtiger als bei der Maintenance Time, da das Eintreten von Zwischenfällen und Recovery-Phasen meistens unvorhersehbar und nicht planbar ist.

Flusseffizienz

Sowohl in Bezug auf die Produktion von Ergebnissen (Produkte, Features, etc.) als auch in Bezug auf Wartungen und Wiederinbetriebnahmen ist es das Ziel, die durchschnittliche Erstellungs- oder Bearbeitungszeiten so kurz wie möglich zu halten. Mit Hilfe der hier genannten Metriken darauf zu optimieren ermöglicht eine höhere Effizienz im Arbeitsfluss, die aber nicht ohne Risiko ist.

Eine ausschliessliche Fixierung auf Flusseffizienz macht vor allem in der Serienfertigung Sinn, in der Produktentwicklung besteht das Risiko, dass man in der Build Trap landet, also versehentlich das Falsche produziert, davon aber sehr schnell sehr viel. Hier solte also regelmässig überprüft werden, ob man noch immer in der richtigen Richtung unterwegs ist.

Bild: Pixabay / Prawny - Lizenz

Zweiter Teil der Übersicht über die Lean-Metriken (Teil 1 ist hier). Auch mit dieser Erweiterung ist die Aufzählung sicher noch nicht vollständig, irgendwann kommt mindestens noch ein dritter Teil (Nachtrag: hier ist er). Zunächst aber soll es hier um die Fluss-Effektivität gehen, also um Metriken, mit deren Hilfe sich erkennen lässt, ob überhaupt die richtigen Tätigkeiten stattfinden oder ob gerade unnötig Geld und Zeit verbraucht werden. Wichtig ist dabei, dass sie im Zusammenhang mit den Durchlaufmetriken des ersten Teils gesehen werden können, und zwar sowohl für die Lead Time/Gesamtdurchlaufzeit als auch für ihre einzelnen Teilstrecken (dazu am Ende mehr).

Value Adding Time

Der Idealfall. In etwa als "Wertschöpfungszeit" übersetzbar sollte die Value Adding Time eigentlich den grössten Teil der Durchlaufzeiten ausmachen. Was dort geschieht kann je nach Art des Produkts oder der Dienstleitung sehr unterschiedlich sein, im Normalfall sind aber Tätigkeiten enthalten, die zur Erstellung, Vermarktung und Inbetriebnahme von Produkt oder Dienstleitung gehören, ggf. einschliesslich von Vorarbeiten wie dem Einkauf oder nachgelagerter Tätigkeiten wie dem Kundenservice. Die Wichtigkeit ergibt sich daraus, dass es im Wesentlichen diese Tätigkeiten sind, für die Kunden Geld bezahlen.

Transportation Time

Der erste zu vermeidende Typ und gleichzeitig ein alter Bekannter. Transporte sind eine der klassischen Mudas des Toyota Production System (TPS), also eine nicht gewinnbringende aber Ressourcen verbrauchende Tätigkeit. Je nachdem, in welchem Rahmen sie gemessen wird, kann auch die Transportation Time sehr unterschiedlich aussehen, angefangen vom Werkstoff-Transport zum anderen Ende der Firma bis zum Containerschiff, dass das Produkt rund um die Erde fahren muss. Eine weitere Variante wäre das langsame Herunterladen eines digitalen Produkts durch eine schlechte Telefonleitung.

Waiting Time

Ebenfalls eine Muda, und dazu die vielleicht die am weitesten verbreitete. Überall dort, wo die Menschen oder Maschinen mehr Arbeit zu erledigen haben als sie bewältigen können, werden sich Aufgaben aufstauen und auf ihre Erledigung warten, was in grossen Organisationen auch Monate und sogar Jahre dauern kann. Als Zusatzeffekt erzeugen Wartezeiten, sobald sie auftreten, noch weitere Aufwände, da die wartenden Aufgaben aktuell gehalten und ggf. verworfen, neu formuliert, neu verhandelt oder repriorisiert werden müssen.

Blocked-Time

Die Blocked Time wird häufig mit der Waiting Time verwechselt, hat aber eine andere Natur. Wartende Aufgaben könnte man selbst erledigen, wenn man denn die Zeit hätte. Geblockte Aufgaben müssen durch jemanden anderen erledigt werden, der dafür zuerst seine gegenwärtige Tätigkeit abschliessen und sich die Aufgabe erklären lassen muss (ggf. kommen noch Preisverhandlungen und Beauftragungen dazu). Besser wäre es, diese Tätigkeiten selbst erledigen zu können, wodurch die Blocked Time verschwinden würde.

Repair Time

Noch eine Muda. Wenn man Repair Time nicht als den Reparaturaufwand nach einem Unfall versteht, sondern als die Zeit die für die Behebung von Hardware-Produktionsfehlern und Software-Bugs nötig ist, ist klar, dass sie so gering wie möglich sein sollte. Auch hier kann es zu negativen Zusatzeffekten kommen, da auch Reklamationen und Umtausche Aufwände erzeugen und die mit den Reparaturen betrauten Menschen dadurch aus ihren aktuellen Tätigkeiten herausgerissen werden, mit Verlangsamungen durch Context Switching und Rüstzeiten als Folge.

Red Tape Time

Hinter der Red Tape Time verbirgt sich die letzte Muda dieser Übersicht, das Overprocessing. Red Tape ist im Englischen ein Sammelbegriff für unnötig komplizierte Prozesse und unnötig bürokratische Vorschriften, und wer bereits in grossen Organisationen gearbeitet hat wird wissen, dass sie dort weit verbreitet sind (hier ein besonders verstörendes Beispiel aus einer deutschen Behörde). Und dass derartige Tätigkeiten nichts zur Wertschöpfung beitragen dürfte ebenfalls offensichtlich sein.

Process Effectivity

Setzt man jetzt die Value Adding Time und die ressourcenverbrauchenden aber nicht wertschöpfenden Varianten Transportation Time, Waiting Time, Blocked Time, Repair Time und Red Tape Time in Verhältnis zueinander, erhält man die Prozess-Effektivität. Wenn die gesamte Durchlaufzeit nur aus Value Adding Time besteht ist das Ergebnis ideal, wenn die Zeit überwiegend für die anderen Typen verbraucht wird ist es eher schlecht. In diesen Fällen macht es sinn, den Prozess so zu verändern, dass diese Aufwände zurückgehen.

Was sind eigentlich die im Lean Management verwendeten Metriken? Die darauf häufig gegebene Antwort ist Durchflussmessung, was auch grundsätzlich richtig ist (wenn auch nur ein Teil der Antwort). Allerdings gibt es mehr als eine Art davon, so dass sich eine Aufschlüsselung lohnt. Wichtig zum Verständnis ist dabei, dass es nirgendwo eine zentrale Stelle gibt, die die Begriffe und ihre Bedeutungen festlegt. Je nachdem wo man ist kann es also Unterschiede geben, die grundlegenden Typen werden aber die gleichen sein.

Customer Lead Time

Die Gesamtzeit zwischen der Beauftragung durch einen Kunden und dem Beginn der Nutzung des bestellten Produkts oder Service durch ihn. Eine der eher selten erhobenen Zahlen, aus Kundensicht aber eine der wichtigsten. Sie zu messen kann verhindern, dass zwar die internen Produktions- und Lieferprozesse optimiert sind, gleichzeitig aber unbemerkte Verzögerungs- und Frustrationsfaktoren bei beim Kunden vorliegen, z.B. ein kompliziertes Einloggen in Bestellportal oder ein langwieriger Schulungsprozess der Anwender.

Feedback Loop Time

Diese Zahl ist der ersten ähnlich, geht aber noch einen Schritt weiter. Gemessen wird nicht nur die Gesamtzeit zwischen der Beauftragung durch einen Kunden und dem Beginn der Nutzung des bestellten Produkts oder Service, sondern zusätzlich auch die Zeit die für eine erste Nutzung, das Sammeln von Feedback und dessen Übermittlung an den Produzenten nötig sind. Vereinfacht gesagt: erst nach dem ersten Feedback Loop weiss man, ob man dem Kunden h,elfen konnte.

(Production) Lead Time

Das ist die erste rein interne Metrik, und vermutlich auch die bekannteste. Erhoben wird die Gesamtdauer aller Vorgänge vom Auftragseingang bis zur Auslieferung. Grundsätzlich ist das zwar relativ einfach zu erheben, kompliziert wird es aber dann, wenn Zulieferer Hardware- oder Software-Komponenten vorfertigen, die dann nur noch eingebaut werden müssen. Die Bestellung, Erstellung und Lieferung dieser Komponenten muss ggf. in die Lead Time mit einbezogen werden.

Pre-Processing Lead Time / Processing Lead Time / Post Processing Lead Time

Bei diesen drei Typen wird die Lead Time in drei unterschiedliche Abschnitte unterteilt, die sich so fast überall wiederfinden und separat betrachtet werden können. Die Pre-Processing Lead Time umfasst alle Verhandlungs, Bestell- oder Beauftragungsprozesse, die Processing Lead Time ist die eigentliche Anfertigung inclusive Qualitätssicherung, die Post-Processing Lead Time umfasst die nachgelagerten Auslieferungs- und Rechnungsstellungs-Prozesse.

Cycle Time

Nach der Lead Time die vermutlich zweitbekannteste Metrik. Für ihre Erhebung werden die übergreifenden Abschnitte nochmal unterteilt, z.B. die Processing Lead Time in Vormontage, Endmontage und Qualitätssicherung. Diese Unterteilung kann u.a. deshalb Sinn machen, weil verschiedene Cycle Times parallel laufenden Prozessen entsprechen können (z.B. zwei verschiedenen Vormontagen), die aufeinander abgestimmt werden sollen.

Process Step Time

Die kleinste Einheit, die nur noch wenigen manuellen oder automatisierten Vorgangsschritten entspricht. In der Hardware-fertigenden Industrie wäre das z.B. eine Station am Fliessband, bei Software-Releases kann eine Build Pipeline-Station so gemessen werden. Wichtig bei der Process Step Time ist, dass sie v.A. bei repetitiven Tätigkeiten und Prozessen Sinn macht, nicht in der Wissensarbeit (z.B. in Journalismus und Softwareentwicklung), wo sie aufgrund fehlender Vergleichbarkeit kaum Aussagekraft hat.

Bild: Wikimedia Commons / Anick Marie - CC BY-SA 2.0

Dass es bei der Einführung von Kanban gibt es so einiges gibt, auf das man achten muss, dürfte hoffentlich klar sein, sowohl in Bezug darauf woran man auf jeden Fall denken sollte, als auch in Bezug auf das was man besser lassen sollte. In der letzten Kategorie findet sich aber auch etwas das viele überraschend finden - man sollte am Anfang besser keine Work in Progress-Limits (WIP-Limits) einführen. Wenn überhaupt ist das ein späterer Schritt, zu Beginn macht er fast nie Sinn.

Auf den Einen oder Anderen mag das verwirrend wirken. Sind WIP-Limits nicht ein zentraler Teil von Kanban? Und funktioniert die Einführung von Kanban nicht so, dass man alle Arbeit auf einem Board visualisiert und dann begrenzt wie viel davon gleichzeitig durchgeführt wird, damit das was begonnen wird dadurch schneller fertig werden kann? Die Antwort: ja und nein. Ja WIP-Limits sind zentral, und nein, man sollte sie nicht so früh einführen, selbst wenn das gut gemeint ist.

Am einfachsten zu verstehen ist das in dem Fall, in dem alle bisherigen Arbeitspakete einfach auf ein To Do-In Progress-Done-Board gepackt werden. Dann wird sich dort gleichzeitig Arbeit aus verschiedenen Be- oder Verarbeitungsphasen befinden, mit einem gemeinsames WIP-Limit für alle. Dieses würde aber einzelne Gruppen wie z.B. die UX-Designer in die Untätigkeit zwingen, wenn andere, etwa die Tester, so viel parallele Arbeiten durchführen, dass dadurch die Obergrenze erreicht ist.

Aber auch bei ausdifferenzierteren Systemen, wie z. B. Design-Umsetzung-Test-Rollout können frühe WIP-Limits kontraproduktiv sein. Es kann zwar nicht mehr der zuletzt genannte Fall vorkommen, in dem sich verschiedene Phasen gegenseitig blockieren, in einem System das seine Umstellung auf Kanban gerade erst begonnen hat wird es aber noch Abhängigkeiten nach aussen geben, z.B. zu einer Einheit die Testdaten so langsam bereitstellt, dass ein WIP-Limit auch hier Leerlauf erzwingen würde.

Man kann sich noch weitere vergleichbare Konstellationen vorstellen, die zentrale Erkenntnis ist aber klar: wenn eine Organisationseinheit ihre Rahmenbedingungen nicht selbst unter Kontrolle hat erzwingen Work in Progress-Limits im Zweifel nicht mehr Focus und schnelle Fertigstellung sondern führen zu erzwungener Untätigkeit und zu Konflikten mit anderen Einheiten, auf deren Zulieferung oder Beteiligung man angewiesen ist um die selbstgesetzte (den anderen ggf. gar nicht bekannte) Obergrenze zu halten.

Die bessere Reihenfolge im Rahmen einer Umstellung auf Kanban wäre daher, zuerst die Arbeit zu visualisieren (was schon schwieriger ist als man denken sollte), dann den Beteiligten das Wissen und die Berechtigungen geben um ihre Rahmenbedingungen zu verändern und dann erst über WIP-Limits nachzudenken. Es kann (und sollte) dann natürlich auch zu ihnen kommen, der Punkt an dem das passiert liegt dann aber nicht mehr am Anfang sondern deutlich später.

Um zuletzt ein häufiges Gegenargument gleich abzufangen: ja, man könnte es für eine Übergangszeit zulassen, dass die WIP-Limits regelmässig verletzt werden und währenddessen daran arbeiten, dass das irgendwann nicht mehr nötig ist. Das hätte aber eine (unbewusste) Erziehung zur Normverletzung zur Folge, und das ist etwas wovon man jeder Organisation nur dringend abraten kann, wenn sie nicht in ganz andere Probleme geraten will.

Bild: Wikimedia Commons / Toyota Commemorative Museum of Industry and Technology - CC BY-SA 3.0

Ich fürchte, ich muss mal wieder mit japanischen Fremdwörtern um mich werfen. Heute geht es um Jidōka (自働化), einen Begriff der (wie viele andere aus dieser Sprache) nur schwer zu übersetzen ist. Autonome Automation (Autonomation), intelligente Automation oder Automation mit menschlichem Antlitz sind Übersetzungsversuche, die aber alle nur teilweise korrekt und nur schwer verständlich sind. Dabei ist das dahinterstehende Prinzip eigentlich recht einfach.

Jidōka geht aus von der Erkenntnis, dass bestimmte Reparaturen oder Überprüfungen zwar nur von Menschen vorgenommen werden können, dass komplizierte oder komplexe Systeme aber so unübersichtlich sind, dass ein Mensch gar nicht überblicken kann an welcher Stelle Reparaturen oder Überprüfungen gerade nötig sein könnten. Um das zu beheben werden Maschinen oder Programme erstellt, die den Menschen auf Anomalien hinweisen können.

Das älteste und vielleicht bekannteste Beispiel dafür ist der Webstuhl, der von Toyoda Sakichi, dem Gründer der Firma Toyota, erfunden wurde. Um zu verhindern, dass fehlerhafte Stoffe produziert wurden, überprüfte ein Mechanismus ob die zur Verarbeitung geleiteten Fäden angespannt waren. War das nicht der Fall wurde der Webvorgang angehalten und ein Arbeiter benachrichtigt, der dann überprüfen konnte ob ein Faden gerissen war und neu eingespannt werden musste.

Derartige Jidōka-Mechanismen wurden später zu einem der Grundpfeiler des Toyota Production System, in dem sie durch das automatisierte Anhalten sich ungewöhnlich verhaltender Maschinen und Fertigungsstrassen dabei helfen Produktionsfehler zu verhindern. Zusammen mit Andon (行灯), den von Menschen ausgelösten Fertigungsstops, gehören sie zu den wichtigsten Qualitätssicherungs-Massnahmen im Lean Management.

Über diese Fertigungs-Ursprünge hinaus kommt Jidōka mittlerweile (allerdings in der Regel ohne diesen Namen) auch in rein digitalen Anwendungen oder in kombinierten Hardware/Software-Produkten vor. Ein Beispiel dafür sind die Warnungen und Not-Abschaltungen von sich überhitzenden Mobiltelefonen, ein anderes die im FinOps-Framework vorhandenen Verhinderungs-Mechanismen von unbeabsichtigt steigenden Cloud-Kosten.

Durch die auf diese Art deutlich beschleunigten Reaktionszeiten ist Jidōka sowohl in der Hardware-Fertigung als auch in der Software-Entwicklung ein guter Weg zu mehr Agilität, Flexibilität und Resilienz. In vielen Fällen ist dieses Konzept sogar so selbstverständlich geworden, dass es gar nicht mehr als bewusst eingerichtete Massnahme auffällt. Vermutlich ist das einer der stärksten Indikatoren für den auf diese Weise erzeugten Mehrwert.

Zuletzt noch einmal zu der Übersetzung. Wenn autonome Automation, intelligente Automation oder Automation mit menschlichem Antlitz nicht wirklich zutreffende Übersetzungen sind, was wäre dann eine? Die vermutlich zutreffendste Erläuterung kommt aus der Wikipedia: "Der Begriff geht auf ein Wortspiel Taiichi Ōnos zurück, der im Begriff Jidoka (自動化 für Automation) dem darin enthaltenen Wort für Bewegung (動) das Personenradikal 人 mit der Bedeutung „Mensch“ hinzufügte." Nun ja. Vielleicht muss man auch nicht bei Allem versuchen es ins Deutsche zu übertragen.

Bild: Unsplash / Eden Constantino - Lizenz

Bei der Einführung von Kanban gibt es so einiges auf das man achten sollte. Zum einen Dinge die man tun sollte (einige davon finden sich hier) aber solche bei denen es besser wäre wenn man sie lässt. Nach über einem Jahrzehnt Erfahrung glaube ich, dass ich mittlerweile genug anekdotische Evidenz für eine starke Aussage gesammelt habe: unter allen möglichen Fehlern gibt es einen der mit weitem Abstand am häufigsten auftritt (und auf dem Foto in diesem Beitrag ist er zu sehen).

Die Rede ist davon, dass in einem ersten Schritt alle Mitglieder der sich umstellenden Einheit alles was sie machen auf physische Post-Its oder in digitale Kacheln schreiben und die dann auf ein Board mit den Spalten To Do, in Progress und Done platzieren.¹ Die Absicht dahinter ist auch gut, es soll visualisiert werden woran gearbeitet wird und wie hier der Fortschritt ist. In den meisten Fällen ist das Ergebnis aber das genaue Gegenteil.

Warum das so ist: fast alle Tätigkeiten in klassisch arbeitenden Organisationen beziehen sich nur auf einen kleinen Teil einer langen Be- oder Verarbeitungskette. Vorne wird geplant und konzipiert, in der Mitte gebaut, entwickelt oder getestet, am Ende finden Betrieb, Verkauf oder Kundenbetreuung statt. Nur in Summe ergeben alle der aufeinanderfolgenden Schritte Sinn, für sich genommen wirkt jeder einzelne von ihnen generisch und hat wenig Aussagekraft (und viel zu viele sind es auch).

Beispiele gefällig? Vorne könnte "Marktanalyse" stehen oder "Konzept schreiben". In der Mitte könnte es "Eingabemaske im Frontend erweitern" sein oder "Software auf die Hardware aufspielen". Am Ende finden sich schliesslich "Auslieferung" oder "Übergabe an den Kundenservice". Oft sind sie noch generischer, z.B. "Test" oder "Entwicklung", jeweils mit Ticket-Nummer. Genau so sind übliche Arbeitspakete eben geschnitten, damit sie von einzelnen Fachkräften schnell erledigt werden können.

Wenn wir uns jetzt ein mit solchen Aufgaben gefülltes Board vorstellen wird das Problem offensichtlich: Tätigkeiten die eigentlich sequentiell stattfinden hängen ohne die richtige Reihenfolge über- oder nebeneinander in einer der drei Spalten To Do, in Progress und Done. Es wird nur noch klar mit welchen Riesenmengen an Detailschritten die Kollegen gerade beschäftigt sind, wie diese zusammenhängen und aufeinander aufbauen ist völlig intransparent. Das ist nicht im Sinn der Kanban-Idee.

Alleine das wäre bereits ausreichend problematisch, in der Regel geht es aber sogar noch darüber hinaus. Häufig arbeiten Teams an mehr als einem Feature-Set, Produkt oder Service parallel, die Folge davon ist, dass die dazugehörigen Einzelaufgaben auf dem gemeinsamen Board nicht klar voneinander abgrenzbar nebeneinanderhängen. Zu welchem dieser Aufgaben-Pakete eine Aufgabe wie "Integrationstest" dann gehört ist fast nur noch für den Bearbeiter nachvollziehbar.

Wie es besser geht: bevor damit begonnen wird Post-Its oder Tickets zu erstellen sollte zuerst die Abfolge der jeweiligen Arbeitsschritte explizit gemacht und visuell festgehalten werden. In einem Fall den ich in einer Einheit miterlebt habe, die kleinteilige Erweiterungen einer Altanwendung machte, hatten wir z.B. nach einem ersten Workshop die folgenden Schritte identifiziert (vereinfachte Darstellung, in Wirklichkeit war es ein kleines bisschen komplizierter):

Auf Basis einer solchen Darstellung kann dann das Board erstellt werden, mit einer Entsprechung von jeweils einem Arbeitsschritt zu einer Spalte. Und ja, in diesem Fall würde das bedeuten, dass das Board acht Spalten hat, wenn die jeweils in die jeweiligen Unterspalten Doing und Done unterteilt werden sogar sechzehn. Das kann sich zuerst nach (zu) viel anfühlen, es ist aber nichts anderes als die Realität, die nun mal irgendwie so entstanden ist.

Selbst wenn man Kanban-Systeme (meiner Meinung nach) nicht zu früh komplizieren sollte ist in den meisten Fällen noch eine weitere Ergänzung sinnvoll: die Regel, dass Arbeitspakete die zu einem gemeinsamen Feature-Set, Produkt oder Service gehören kenntlich gemacht werden sollten, etwa durch eine gemeinsame Farbe oder eine gemeinsame Zeile. Dann (aber auch wirklich erst dann) sollte mit dem Schreiben der Post-Its oder Tickets begonnen werden.

Wie an diesem Beispiel zu sehen ist,² kann die ganze Art wie Aufgaben geschnitten werden jetzt eine andere sein. Statt Detailaufgaben werden ganze Features beschrieben, deren genauer Arbeitsfortschritt sich aus der Spalte ergibt in der sie hängen. Das ist deutliche informativer. Und auch weitere Informationen fallen sofort ins Auge, die sonst schwerer erkennbar sein würden: in Feature-Set A gibt es einen Nachzügler, Feature-Set B hängt anscheinend in der Genehmigung fest.

Natürlich ist der Weg zu einem solchen Kanban-System deutlich anspruchsvoller als das einfache Aufhängen eines To Do, in Progress, Done-Boards voller Detailaufgaben. Daher scheuen viele Teams diesen Weg (oder kennen ihn gar nicht). Es sollte aber klar sein - wer sich auf die (scheinbar) einfache Lösung beschränkt wird bestenfalls die einfachste der möglichen Kanban-Varianten haben: irgendetwas Sichtbares. Wirklich besser wird dadurch kaum etwas werden.

Bild: Flickr / Paul Downey - CC BY 2.0

"Wir machen Kanban" ist eine Aussage die man mittlerweile von sehr vielen Teams hören kann. Schaut man sich einzelne davon näher an lassen sich allerdings grosse Unterschiede erkennen, zum Teil sogar so grosse, dass praktisch keine Vergleichbarkeit mehr gegeben ist. Das hat mit dem Fehlen eines offiziellen Regelwerks zu tun (sorry, Kanban University), mit Missverständnissen und mit Cargo Cult, selbst wenn man das in Betracht zieht bleibt aber noch eine erstaunliche Vielfalt übrig. Der Grund dafür - es gibt mehrere Varianten von Kanban, die sich z.T. deutlich unterscheiden:

Irgendetwas Sichtbares

Da Japanisch und Deutsch sich stark unterscheiden ist eine wörtliche Übersetzung schwierig, je nach Auslegung lautet sie aber "visuelles Signal", "sichtbare Information" oder etwas Vergleichbares. Damit können zum Beispiel die farbigen Signallampen an Fabrikstrassen oder an Warteschlangen als Kanban bezeichnet werden (was aber fast ausschliesslich japanische Muttersprachler tun). Zur Abgrenzung: nicht in diese Kategorie fallen Zahlen, Buchstaben und Diagramme, für die es eigene Bezeichnungen gibt.

Irgendetwas mit Karten oder Post-Its

Ein spezifischerer Übersetzungs-Versuch ist Signal-Karte oder Informations-Karte (Kan = Sichtbare Information, Ban = Karte oder Post-It). Das ist enger gefasst als die wörtliche Übersetzung, umfasst aber noch immer recht viel, neben den verbreiteten Boards oder Wänden auf denen Post-Its hin und her geschoben werden z.B. auch Kamishibai-Visualisierungen, Planning Poker-Karten und ggf. sogar aus Papierzetteln erstellte Kunstwerke.

Durchfluss-Visualisierungen

Die vermutlich am weitesten verbreitete Definition. In ihr wird unter einem Kanban-System oder Kanban-Board eine Darstellung aufeinanderfolgender Arbeitsschritte verstanden, die von den einzelnen Arbeitspaketen durchlaufen werden (hier ein Beispiel). Dargestellt werden diese Pakete durch Post-Its (physisch) oder Kacheln (digital). Auch hier gibt es eine Abgrenzung: werden keine Arbeitsschritte abgebildet sondern To do, Doing und Done ist es ein Task Board, kein Kanban-Board.

Erweiterte Durchfluss-Visualisierungen

Hier beginnt es für die Tool- und Methoden-Nerds interessant zu werden. Häufige visuelle Elemente in erweiterten Kanban-Systemen sind Work in Progress-Limits (sowohl für die Unter- als auch für die Obergrenzen), Zähl-Punkte für die Messung von Lead Time und Cycle Time und "Parkplätze" für blockierte oder wartende Arbeit, es gibt aber noch zahllose weitere. Für viele "Überzeugungstäter" darf sich nur Kanban nennen was solche Erweiterungen enthält.

Eine Change Management-Methodik

Die vermutlich engste Definition von allen. In ihr hat sich Kanban weitgehend von seinen Ursprüngen in der Visualisierung, bzw. Informations-Übermittlung gelöst und ist zu einer Methode des Change Managements geworden. Die Darstellung eines Arbeitsflusses durch aufeinanderfolgende Arbeitsschritte ist nur noch ein Mittel zum Zweck, und der ist die kontinuierliche und behutsame Optimierung und Effizienzzsteigerung des Gesamtsystems.

Grober Unfug

Wie oben erwähnt, Cargo Cult gibt es überall, also auch hier. Eine seiner häufigsten Manifestationen ist der Glaube Kanban wäre "Scrum mit weniger Meetings" (mitunter auch "Scrum ohne Sprints" oder "Scrum ohne Rollen"). Dahinter steckt meistens guter Wille, falsch ist es aber trotzdem (und auch die Wortschöpfung "Scrumban" macht es nicht besser). Das heisst nicht, dass man das nicht machen könnte, es hat dann aber mit Kanban ähnlich wenig zu tun wie mit Scrum.

Und noch mehr ...

Bei weiterem Suchen würde man mit Sicherheit noch weitere Varianten von Kanban finden, gute, schlechte und viele die irgendwo in der Mitte sind. Wichtig ist es dabei sich über die jeweiligen Unterschiede im Klaren zu sein, denn eines ist angesichts dieser Vielfalt sicher: "Wir machen Kanban" ist zu wenig Information um zu erkennen was genau da gemacht wird.

Bild: Pixabay / Blickpixel - Lizenz

Zur Zeit darf ich mal wieder für einen Kunden tätig sein der nicht nur Software herstellt sondern auch die dazugehörige Hardware. Das was derartige Einsätze aus methodischer Sicht spannend macht ist, dass in ihnen häufig zwei verschiedene Optimierungsansätze aufeinandertreffen: die aus der (agilen) Produktentwicklung kommende Effektivitätsoptimierung und die aus der Fabrikation kommende Effizienzoptimierung.

Eine zum zweiten Ansatz gehörende Methode trägt den schlichten Namen 5S. Sie kommt aus dem erweiterten Umfeld von Lean Management und ist darum interessant, weil sie zwar in der Hardware-Fertigung erfunden wurde, sich aber bei leichter Neuinterpretation auch in der Softwareentwicklung einsetzen lässt, und zwar nicht anstelle der hier gängigen methodischen Frameworks wie Extreme Programming, Scrum, etc. sondern in Kombination mit ihnen.

Zunächst zum grundlegenden Verständnis: 5S ist in Japan entstanden als traditionelle Prinzipien des Ordnung Haltens aus Haushalt und Küche in die Industrie übertragen wurden. Dabei wurden fünf von ihnen als besonders zentral und wichtig erkannt, und da sie alle mit dem Buchstaben S beginnen erhielt die Methode so ihren Namen: es sind Seiri (整理), Seiton (整頓), Seisō (清掃), Seiketsu (清潔) und Shitsuke (躾), bzw. deren Übersetzungen, für die man auch versucht mit S beginnende Begriffe zu finden.

Grafik: Wikimedia Commons / Nikita Klyuchko - CC BY-SA 3.0

Seiri (Sort out/Selektieren)

Ständiges Aussortieren und Entfernen unbrauchbarer oder unnötiger Rohstoffe und Komponenten, um im Arbeitsalltag ausschliesslich mit hochwertigen Materialien arbeiten zu können. Im der Hardware-Fertigung ursprünglich auf minderwertige Werkstoffe und defekte Bauteile bezogen, in der Software etwa anwendbar auf nicht mehr benötigte Branches oder obsolete Schritte in Skripten.

Seiton (Set in Order/Sortieren)

Sortiertes Anordnen und gut sichtbares Bereithalten aller Arbeitswerkzeuge. Klassische Hardware-Beispiele wären nach Länge und Durchmesser sortierte Schraubenschlüssel oder Schraubenzieher an der Wand oder im Werkzeugkasten, in der Softwareentwicklung könnte es das gut geordnete Product Backlog sein oder die Übersichtsseite mit Links zu allen Entwicklungs-, Test- und Staging-Umgebungen.

Seisō (Shine/Sauberkeit)

Regelmässiges Säubern und Sauberhalten des Arbeitsplatzes. In der Fabrik kann das die Entfernung von Staub, Spänen und allem anderen sein, was zum sprichwörtlichen Sand im Getriebe werden könnte, in der Software wäre eine Entsprechung das Löschen von auskommentiertem Code oder von veralteten und kontaminierten Testdaten.

Seiketsu (Standardize/Standardisieren)

Übertragen bewährter Vorgehensweisen auf vergleichbare Anwendungsfälle. An dieser Stelle sind Sinn und Effekt in Hardware- und Softwareentwicklung die Gleichen. Die Verwendung gleicher Abläufe, wiedererkennbarer Visualisierungen und identischer Begriffe ermöglichen ein schnelles Zurechtfinden und arbeitsfähig werden in neuen Umgebungen.

Shitsuke (Sustain/Selbstverständlich machen)

Verinnerlichung der ersten 4 S, so dass sie zu einem selbstverständlichen Teil der Arbeit werden. Das Ziel ist es, durch tägliche Übung die Anwendung in eine Habitualisierung zu überführen, so dass sie auch ohne Anleitung und Erinnert Werden stattfinden. Ein häufig verwendetes Hilfsmittel sind visuelle Erinnerungsstützen wie z.B. Kamishibai-Boards.

Soweit die schnelle Übersicht, weitere Anwendungsfälle wird sich jeder herleiten können der in der professionellen Softwareentwicklung arbeitet. Der Vollständigkeit halber sei auch erwähnt, dass 5S zwar die häufigste, aber nicht die einzig mögliche Mengengrösse dieser Methode ist. Es gibt auch 4S (meistens ohne Shitsuke), 6S (häufig mit Safety/Sicherheit als sechstem Element) und in manchen Firmen auch noch höhere, je nach Fall anders belegte Nummern.

Für Software-Teams ist 5S vor allem dann zu empfehlen, wenn sie das Gefühl haben, dass bei ihnen die schnelle Liefer- und Reaktionsfähigkeit zu sehr auf Kosten von Ordnung und Übersichtlichkeit herbeigeführt wurde. Die Methode für einige Sprints einzuführen und bei eintretenden Verbesserungen dauerhaft beizubehalten kann in solchen Fällen ein sinnvoller Weg sein. 

Als scheinbar kleiner, in seinen Auswirkungen nicht zu unterschätzender Nebeneffekt kommt noch dazu, dass man plötzlich ungeahnte Gemeinsamkeiten mit den Kollegen aus der Hardware-Fertigung entdecken kann, wodurch gegenseitiges Verständnis und Zusammengehörigkeitsgefühl in der Firma gefördert werden. Vielleicht kommt es dann dadurch zu einem weiteren Austausch, aus dem sich die Idee ergibt welche weitere Arbeitsmethode der anderen Seite man sich näher ansehen sollte.

Bild: Unsplash / Mufid Manjun - Lizenz

Dass Lean Management keineswegs nur für die Optimierung von Fabriken geeignet ist dürfte sich schon länger herumgesprochen haben, nach einfach nachvollziehbaren Beispielen dafür musste man aber etwas suchen - bis jetzt. Mitten in der Corona-Pandemie ist es gelungen mit diesem Vorgehen eine der Einrichtungen zu optimieren die im Augenblick im absoluten Mittelpunkt des öffentlichen Interesses stehen: ein Impfzentrum.

Eine kurze Rückblende. Bis Mitte April waren alle Berichte über das Impfzentrum des Rhein-Kreises Neuss eher negativ. Lange Warteschlangen und bürokratische Prozesse sorgten für Unwillen unter den Bürgern die sich für ihre Impfung im kalten Wetter anstehen mussten und angesichts der dort aufgestauten Menschenmengen einem erhöhten Ansteckungsrisiko ausgesetzt waren. Das einzig Gute an diesen Missständen: die Notwendigkeit von Verbesserungen wurde durch sie offensichtlich.

An dieser Stelle kam das sprichwörtliche Glück im Unglück ins Spiel. Unter den freiwilligen Helfern befand sich auch der Lean-Experte Andreas Syska, der ab März mit der Optimierung der Abläufe betraut war. Aus seinem ersten Bericht kann man entnehmen welche Praktiken nach und nach eingeführt wurden: Wertstrommapping, Line Balancing, Verschwendungsanalyse, Kreidekreis, Standardisierte Arbeitsprozesse und bessere Visualisierung.

Die Ergebnisse dieser Massnahmen werden jedem bekannt vorkommen der schon einmal mit der Optimierung von Produktions- und Geschäftsprozessen befasst war. Flaschenhälse wurden erweitert, Rückstaus aufgelöst, Laufwege selbsterklärend gestaltet und unnötige oder redundante Abläufe abgeschafft. Bereits Ende April gehörte das Impfzentrum dadurch zu den effektivsten in Deutschland. Einen kleinen Einblick gibt dieses Video:

Überhaupt scheint das Impfzentrum des Rhein-Kreises für Innovationen grundsätzlich sehr aufgeschlossen zu sein. So gehörte es zu den ersten die es impfwilligen Personen ermöglichten per SMS über Impfstoff-Restposten informiert zu werden um sich selbst als Nachrücker anzubieten. Letztendlich nichts anderes als eine Kombination aus Digitalisierung und Pull-Prinzip. Und für noch mehr Beschleunigung sind mobile Impfteams unterwegs.

Das Beispiel aus Neuss zeigt sehr gut zu welchen Effektivitätssprüngen selbst öffentliche Einrichtungen in der Lage sind wenn sie sich auf moderne Management-Methoden einlassen. Und neben den geimpften Bürgern profitieren auch die deutschen Agile- und Lean-Coaches, die jetzt über ein weiteres plakatives Beispiel verfügen um die Vorteile ihrer Ansätze für jeden nachvollziehbar zu erklären.

Nachtrag 10.06.2021:

Auch in Japan gibt es vergleichbare Initiativen. Wenig überraschend.

Nachtrag 03.01.2022:

Anllässlich der Wiedereröffnung nach zeitweiser Schliessung fasst Andreas Syska nochmal Erfolge und Erfolgsfaktoren zusammen.

Bild: Wikimedia Commons / NASA - Public Domain

Gegenstand dieser Geschichte ist das Container-Frachtschiff Ever Given, das am 23.03. beim Passieren des Suez-Kanals so unglücklich von einem Sandsturm getroffen wurde, dass es sich quer stellte und an beiden Enden auf Grund lief, wodurch der Kanal, die bedeutenste Wasserstrasse der Welt, tagelang blockiert wurde. Zahllosen anderen Schiffen blieben dadurch nur zwei Möglichkeiten: bis zur Befreiung der Ever Given warten oder den zehn Tage längeren Umweg um Afrika nehmen.

Verschiedene Aspekte lassen sich für Vorträge oder Workshops verwerten. Zunächst ein häufig übersehener: ein Flaschenhals ist nicht zwingend die einzige Stelle durch die ein Wertstrom fliessen kann, es ist aber die schnellste oder wirtschaftlichste. Andere können zwar existieren (in diesem Fall die Route um Afrika) gleichwertige Alternativen sind sie allerdings wegen der mit ihnen verbundenen zusätzlichen Aufwände nicht.

Ein weiterer Punkt der sich anhand der Suez-Blockade gut vermitteln lässt ist das mit Flaschenhälsen verbundene Risiko: ein einziger feststeckender "Liefergegenstand" kann weitreichende Auswirkungen haben. Darüber hinaus lassen sich auch Schwarze Schwäne mit ihr veranschaulichen, also Risiken die praktisch nicht vorhersehbar waren. Dass ein so grosses Schiff hier auf Grund laufen könnte war aus gutem Grund nicht zu ahnen - bis 2018 gab es einfach noch keine in dieser Grössenordnung.

Ebenfalls gut mit diesem Beispiel zu erklären sind die beiden eigentlich abstrakten Konzepte von totem Kapital und Cost of Delay. Dass die Ladungen der über 350 an ihrer Weiterfahrt gehinderten Frachtschiffe dem Wirtschaftskreislauf entzogen (und damit "tot") sind dürfte auch für Nicht-Wirtschaftswissenschaftler offensichtlich sein, und für die Verspätungskosten gibt es sogar eine Zahl: mehr als zehn Milliarden dürfte der wirtschaftliche Gesamtschaden am Ende betragen.

Bild: ESA, Contains modified Copernicus Sentinel data 2021 - CC BY-SA 3.0 IGO

Es sind aber nicht nur die negativen Seiten von Flaschenhälsen die sich anhand des Unfalls der Ever Given erzählen lassen, auf der anderen Seite sind es auch die möglichen Arten mit diesem Risiko umzugehen. Die naheliegendste davon dürfte sein, den Engpass zu erweitern, etwa im Fall des Suez-Kanals durch eine zweite Fahrrinne. Das ist zwar in der Umsetzung teuer, im Vergleich zu möglichen Unfallkosten (siehe oben) aber ggf. zu rechtfertigen. (Nachtrag 11.05.: so ist es gekommen)

Auch die Sinnhaftigkeit kleinerer Lieferpakete lässt sich hier darstellen: zum einen würde bei vielen kleineren Schiffen nur ein Teil des zu liefernden Werts von einem blockierten Flaschenhals betroffen sein, zum Anderen kann davon ausgegangen werden, dass diese kleineren Fahrzeuge nur einen Teil der Engstelle blockieren würden - oder aufgrund ihrer geringeren Grösse äusseren Einflüssen (wie dem Sandsturm) eine viel kleinere Angriffsfläche bieten würden.

Wie alle Analogien hat natürlich auch die der Suez-Blockade ihre Grenzen, als plakativer und leicht nachvollziehbarer Einstieg in den Themenkomplex Flaschenhälse und Wertströme ist sie aber definitiv verwendbar. Ein vertiefteres Eingehen ist danach ja noch immer möglich. Und als eingängiges Schaubild dürfte die quer im Kanal steckende Ever Given geeignet sein wie wenige sonst.

Die beste Metapher für alles, was gerade schief läuft ...#suez pic.twitter.com/TVRrZDDEa2

— Sonja M. Lauterbach (@SolautSonja) March 26, 2021

Die Lieferung von zusätzlichem Impfstoff verzögert sich bis auf Weiteres.#Impfstoff #Evergreen pic.twitter.com/0WcaqqEgJr

— Rhetorische Antwort (@RhetorischeA) March 24, 2021