Ein Satz, den ich in letzter Zeit häufiger höre: "Wir nutzen kein Scrum mehr, wir machen jetzt Kanban". Dabei ist Kanban gar nicht so neu, wie es oftmals scheint. Und dennoch muss man feststellen, dass viele Teams, die angeblich jetzt Kanban machen, gar nicht die Konzepte verstanden haben, die hinter Kanban stehen, oder sich deren Bedeutung nicht ausreichend bewusst sind. Häufig reduziert sich „Kanban“ dann auf ein Board mit ein paar Spalten und den Wegfall von Sprints.

Dieser Artikel möchte die zugrunde liegenden Prinzipien erläutern und so ein besseres Verständnis schaffen. Und dabei möchte ich vorausschicken, dass ich ein großer Fan dieser Prinzipen und Konzepte bin, darin aber überhaupt keinen Gegensatz zu Scrum sehe. Vielmehr ergänzen sich beide Welten hervorragend.

Kanban wurde bereits 1947 von Taiichi Ohno bei Toyota entwickelt und stammt somit ursprünglich aus der Fertigung. Die Anwendung von Kanban in der Softwareentwicklung ist eigentlich auch nicht mehr so neu. David J. Anderson beschäftigte sich schon 2005 mit der Anwendung von Kanban-Prinzipien in der Softwareentwicklung und veröffentlichte dann 2010 das Buch "Kanban: Successful Evolutionary Change for Your Technology Business", das als eines der zentralen Werke der modernen Kanban-Bewegung in der Softwareentwicklung gilt. Kanban wird jedoch häufig auf einige wenige Praktiken reduziert, ohne die zugrunde liegenden Wirkmechanismen ausreichend zu verstehen. Genau deshalb lohnt es sich, tiefer einzusteigen.

Kanban = Optimierung von Flow

Ein wesentliches Ziel von Kanban ist die Optimierung des sogenannten Flows, also des Flusses der Arbeit durch ein System. Das System stellt dabei typischerweise den Weg einer Aufgabe von der Idee bis zur Nutzung durch Anwender dar.

Warum ist die Optimierung von Flow aber so entscheidend?

Viele Organisationen optimieren ihre Systeme heute primär auf maximale Auslastung. Oder positiver formuliert: Leerlaufzeiten von Personen sollen möglichst minimiert werden. Dass diese Optimierung auf Auslastung in komplexer Wissensarbeit oftmals keine gute Idee ist, lässt sich an einem einfachen Beispiel verdeutlichen.

Wir stellen uns eine Autobahn vor. Während in der einen Fahrtrichtung nur wenig Verkehr herrscht, bewegen sich die Fahrzeuge in der Gegenrichtung lediglich im Schritttempo. Während auf der einen Seite immer wieder größere Abstände zwischen den Fahrzeugen bestehen, stehen auf der anderen Seite PKWs und LKWs Stoßstange an Stoßstange.

Die Frage ist nun, wo ist die Autobahn besser ausgelastet?

Sicherlich auf der Seite mit dem Stau. Dort befinden sich deutlich mehr Fahrzeuge pro Fläche Autobahn als auf der Seite, auf der der Verkehr flüssig läuft. Aber wo ist der Durchsatz höher? Also wo passieren mehr Fahrzeuge pro Zeiteinheit einen bestimmten Punkt? Vermutlich dort, wo der Verkehr flüssig läuft. Genau das ist das Äquivalent zu Flow. Genau diesen Zustand wollen wir auch in unserem System erreichen, das Software produziert. Features und Bugfixes sollen möglichst reibungslos und zügig durch das System fließen, statt sich zu stauen und lange auf ihre Fertigstellung zu warten. Dabei geht es allerdings nicht nur darum, schneller Software auszuliefern. In moderner Produktentwicklung geht es zunehmend auch darum, schneller zu lernen. Kleine Arbeitspakete, kurze Durchlaufzeiten und schnelle Rückkopplung helfen Teams dabei, Hypothesen früher zu validieren und schneller Erkenntnisse zu gewinnen.

Flow ist damit nicht nur Delivery-Optimierung, sondern auch Lernbeschleunigung. Welche Vorteile ein optimierter Flow darüber hinaus noch bietet und wie das erreicht werden kann, das soll in diesem Artikel beleuchtet werden. Einige der hier vorgestellten Konzepte wirken zunächst kontraintuitiv und erscheinen auf den ersten Blick unlogisch. Deshalb verlangt der Artikel ein gewisses Maß an Offenheit, um die Konzepte nicht vorschnell abzulehnen. Es lohnt sich definitiv, tiefer in die Welt des Flows einzutauchen.

Kanban Kernpraktiken

Kanban basiert auf vier wesentlichen Kernpraktiken:

1. Visualisiere den Fluss der Arbeit.
2. Begrenze die Menge angefangener Arbeit.
3. Miss und steuere den Fluss.
4. Mache die Regeln für den Prozess explizit und passe sie nach Bedarf an.

Diese Praktiken lassen sich auf nahezu jeden bestehenden Prozess anwenden. Damit ist Kanban weniger als konkreter Prozess zu verstehen, sondern vielmehr als Methodik zur Verbesserung bestehender Prozesse. Kanban ist nicht zwingend auf die agile Softwareentwicklung beschränkt. Auch klassische Vorgehen wie beispielsweise das V-Modell könnten mit Hilfe von Kanban optimiert werden. Im Folgenden betrachten wir diese Kernpraktiken und deren konkrete Umsetzung näher.

Schritt 1 - Fluss der Arbeit visualisieren

Als ersten Schritt muss ein gemeinsames Verständnis davon geschaffen werden, wie Arbeit durch das System fließt. Diese Definition bezeichnen wir im Weiteren als Workflow. Teilweise sieht man statt „Arbeit“ auch Begriffe wie „Nutzen“, „Wert“ oder den englischen Begriff „Value“ und daraus folgend auch den Begriff Value Stream als äquivalent zum Workflow.

Zunächst müssen Start- und Endpunkt unseres Workflows festgelegt werden. Das klingt zunächst trivial, wirft bei genauerer Betrachtung aber einige interessante und hochwichtige Fragen auf. Startet unser Workflow dann, wenn ein neuer Featurewunsch gemeldet wird? Oder erst dann, wenn wir das Feature verbindlich eingeplant haben? Oder gar erst, wenn wir mit der Umsetzung begonnen haben? Konkret also die Frage: Ist das Product Backlog Teil unseres Workflows?

Endet der Workflow, wenn die Implementierung abgeschlossen wurde? Wenn getestet wurde? Wenn deployt wurde? Oder vielleicht sogar erst dann, wenn genügend Daten gesammelt wurden, um die hinter dem Feature stehende Hypothese zu validieren? Unterscheiden sich diese Definitionen für neue Features und die Behebung von Fehlern?

Diese Definitionen sind keineswegs nebensächlich. Sie haben einen erheblichen Einfluss darauf, welche Probleme sichtbar werden und welche Optimierungen möglich sind. Für den Moment genügt festzuhalten, dass es verschiedene valide Optionen gibt und es zunächst vor allem wichtig ist, sich auf eine klare gemeinsame Definition zu einigen. Es können aber auch mehrere Workflow-Definitionen für das selbe System genutzt und somit verschiedene Perspektiven bzw. Abstraktionsebenen geschaffen werden.

Zwischen Start- und Endpunkt werden nun die verschiedenen Aktivitäten beschrieben, die ein Arbeitselement im System durchläuft. Das können für Softwarefeatures im einfachsten Fall beispielsweise die Stufen „Implementieren“ und „Testen“ sein. Es können aber auch weitere Unterteilungen oder eine andere Definition sinnvoll sein. Damit kann der Workflow wie in Abbildung 1 visualisiert werden.

Abbildung 1 - Start- und Endpunkt sowie Aktivitäten eines simplen Workflows

Pull statt Push

Ein weiteres wichtiges Konzept in Kanban ist das sogenannte Pull-Prinzip. Das bedeutet, dass Arbeit aktiv in eine Aktivität „gezogen“ wird, wenn dort Kapazität vorhanden ist, statt dass vorausgehende Stationen fertige Arbeit einfach weiterreichen. Die Bedeutung dieses Prinzips wird später insbesondere beim Thema Engpässe deutlich. Um das Pull-Prinzip in unserem Workflow zu unterstützen, unterteilen wir die Aktivitätsspalten in einen Bereich für aktive Arbeit und einen Bereich für abgeschlossene Arbeit, die bereit für den nächsten Schritt ist. Von dort können sie dann "gepullt" werden, wenn das Team Kapazität für den nachfolgenden Bearbeitungsschritt hat.

Abbildung 2 - Spalten unterteilen, um das Pull-Prinzip zu ermöglichen

Für ein Softwareentwicklungsteam kann das beispielsweise bedeuten: Ein Teammitglied zieht ein neues Feature aus „Geplant“ nach „Implementieren / Aktiv“. Nach Abschluss der Implementierung wandert das Element nach „Implementieren / Abgeschlossen“. Sobald nun jemand Zeit zum Testen hat, wird dieses Element in „Testen / Aktiv“ gezogen, aber nicht früher.

Wichtig dabei:

Die Arbeit wird nicht nach dem Abschluss eines Schrittes weitergeschoben, sondern vom nachfolgenden Prozessschritt gezogen. Gerade dadurch werden Engpässe sichtbar, weil erkennbar ist, wo sich Aufgaben stauen. Und zusammen mit den später noch beschriebenen WIP-Limits kann so der Flow optimiert werden. Ohne Pull kein Kanban.

Definition der Aufgabentypen

Ein weiterer wichtiger Schritt besteht darin, unterschiedliche Arten von Arbeit sichtbar zu machen. Die Visualisierung kann beispielsweise über Farben erfolgen.

Abbildung 3 - Visualisierung der Work Item Arten und Blocker

Eine Besonderheit in Abbildung 3 ist die Visualisierung sogenannter Blocker. Ein Blocker zeigt an, dass ein Element momentan nicht weiterbearbeitet werden kann. Das kann beispielsweise passieren:

• wenn Informationen fehlen,
• wenn externe Zuarbeit benötigt wird,
• wenn technische Probleme auftreten,
• wenn Abhängigkeiten zu anderen Teams bestehen.

Wichtig dabei:

Blockierte Elemente sollten nicht in eine separate Spalte verschoben werden, sondern in ihrem aktuellen Prozessschritt verbleiben und dort deutlich gekennzeichnet werden. Das ist nicht nur deshalb wichtig, um nach Beseitigung des Blockers zu wissen, in welchem Bearbeitungsschritt die Aufgabe war, sondern es ist auch elementar, zu erkennen, wo im Workflow sich wie viele Blocker befinden.

Schritt 2 - Die Menge der angefangenen Arbeit begrenzen

Auf den ersten Blick scheint es nicht unbedingt sinnvoll zu sein, die Menge angefangener Arbeit – den sogenannten Work in Process (WIP) – zu begrenzen. Viel natürlicher erscheint es oft, neue Aufgaben zu beginnen, sobald an einer anderen Aufgabe nicht weitergearbeitet werden kann oder sobald ein Teil der Arbeit abgeschlossen wurde. Der Grund liegt meist darin, dass in viele Organisationen primär versucht wird sicherzustellen, dass möglichst jede Person jederzeit beschäftigt ist. Leerlauf wirkt wie Verschwendung. Gerade in komplexer Wissensarbeit führt diese Denkweise jedoch häufig dazu, dass sich Arbeit staut.
Es entstehen Warteschlangen.
Die Durchlaufzeiten steigen.
Die Vorhersagbarkeit sinkt.
Kontextwechsel nehmen zu.
Und Probleme werden oft erst sehr spät sichtbar.
Damit wird auch klar: Das Ziel ist nicht „möglichst wenig Leerlauf“, sondern ein möglichst stabiler und gleichmäßiger Fluss durch das Gesamtsystem. Das ist eines der Beispiele, wie Flow-Prinzipien kontraintuitiv sein können und es deshalb eines tieferen Verständnisses bedarf, diese tatsächlich umzusetzen. Deshalb wollen wir uns kurz ein wenig mit der Theorie hinter der Limitierung von WIP beschäftigen.

Warum Wartezeiten ein größeres Problem sind, als oftmals angenommen

Eines der primären Ziele von Flow-Optimierung ist die Reduktion von Durchlaufzeiten.

Es gibt zahlreiche Gründe, warum das wichtig ist:

• schnellere Rückkopplung
• höhere Vorhersagbarkeit
• geringeres Risiko
• mehr Effizienz
• schnellerer Return On Invest
• kürzere Lernzyklen
• bessere Qualität

Wer tiefer in dieses Thema einsteigen möchte, findet weiterführende Details in den beiden sehr empfehlenswerten Büchern von Daniel Vacanti:
ActionableAgile Metrics for Predictability und When Will It Be Done?.

In vielen Systemen wird der größte Teil der Durchlaufzeit nicht durch aktive Arbeit verursacht, sondern durch Wartezeiten. Abbildung 4 visualisiert diesen Zusammenhang.

Abbildung 4 - Fluss-Analyse - Wartezeiten vs. Bearbeitungszeiten

Eine Optimierung der eigentlichen Bearbeitungsgeschwindigkeit hat in solchen Systemen oft überraschend wenig Einfluss. Die größeren Hebel liegen meist in der Reduktion von Wartezeiten. Somit ist auch klar, wo angesetzt werden sollte, um die Durchlaufzeiten zu reduzieren. Eine Optimierung der Bearbeitungsgeschwindigkeit wird in dem abgebildeten Beispiel keinen wesentlichen Einfluss auf die Durchlaufzeit haben. Zudem ist es in den meisten Fällen einfacher, die Wartezeiten zu minimieren als Arbeit zu beschleunigen.

WIP-Limits als Steuerungsmechanismus

Genau hier setzt nun die Begrenzung des „Work in Process“ an. Für bestimmte Bereiche des Workflows definieren wir eine maximale Anzahl an Elementen. Wird dieses Limit erreicht, darf keine weitere Arbeit in diesen Bereich gezogen werden. Stattdessen liegt der Fokus darauf, begonnene Arbeit abzuschließen. Der Zusammenhang zwischen WIP und der Durchlaufzeit wurde auch durch John Little in Littles Law beschrieben und mathematisch bewiesen.

Abbildung 5 - WIP Limits festlegen

Wichtig dabei:
Sowohl „Doing“ als auch „Complete“ zählen zum WIP. In Kombination mit dem Pull-Prinzip entsteht dadurch ein Gleichgewicht im Gesamtsystem. Im dargestellten Beispiel würde es vermutlich wenig Sinn ergeben, weitere Arbeit in „Develop“ zu ziehen. Offensichtlich scheint im Bereich „Test“ ein Engpass zu existieren und man sollte sich darauf fokussieren, diesen mit vereinten Kräften zu beseitigen.
Damit wird ein weiteres zentrales Prinzip sichtbar:

System Thinking statt lokaler Optimierung

Flow-Optimierung funktioniert nur dann gut, wenn das Gesamtsystem betrachtet wird. Lokale Optimierungen helfen nur wenig oder können manchmal den Durchfluss des Gesamtsystems sogar behindern. Soll der Flow optimiert werden, dann wird die Optimierung dort am wirksamsten sein, wo es einen Engpass gibt. Alle anderen Optimierungen werden weitgehend wirkungslos sein. Wenn der Engpass im Testprozess liegt, bringt es kaum etwas, die Entwicklungsgeschwindigkeit weiter zu erhöhen. Das lässt sich erneut mit der Autobahn-Metapher verdeutlichen. Wenn der Stau durch einen Unfall verursacht wird, hilft es wenig, die Fahrzeuge vor dem Unfall schneller fahren zu lassen oder durch Freigeben des Standstreifens dort die Kapazität zu erhöhen. Der wirksamste Hebel besteht darin, den Engpass zu beseitigen, und zwar so rasch wie möglich. Das Pull-Prinzip zusammen mit WIP-Limits sorgt dafür, dass nachfolgende Prozessschritte signalisieren, wann neue Arbeit sinnvoll ist. Daher stammt übrigens auch der Name Kanban. Das japanische Wort bedeutet sinngemäß „Signalkarte“. Diese Signalkarte war an einem Transportbehälter befestigt und wenn dieser Behälter an einer Station komplett bearbeitet war, dann wurde die Signalkarte an die vorausgehende Station übergeben, was dort das Signal war, für Nachschub zu sorgen. Das WIP Limit war definiert durch den Platz an jeder Station, der reserviert war, um eine gewisse Menge dieser Transportbehälter aufzunehmen. Dieses Prinzip beeinflusste später unter anderem auch die „Theory of Constraints“ von Eliyahu M. Goldratt.

Kleine Arbeitspakete und Variabilität

Ein weiterer wichtiger Aspekt moderner Flow-Systeme ist die Reduktion von Variabilität.

Große Arbeitspakete verursachen häufig:

• lange Feedbackzyklen,
• hohe Unsicherheit,
• größere Schwankungen,
• schwierigere Prognosen,
• spätere Fehlererkennung.

• den Flow,
• die Vorhersagbarkeit,
• die Rückkopplung,
• die Lernfähigkeit.

Das bedeutet nicht, dass komplexe Arbeit plötzlich einfach wird. Gerade Softwareentwicklung bleibt hochgradig von Unsicherheit geprägt. Aber stabile Systeme mit begrenztem WIP und kleineren Arbeitspaketen erzeugen oft deutlich robustere Prognosen als aufwendige Detailschätzungen. Auch dieses Thema wird heute intensiv diskutiert. Wer tiefer einsteigen möchte, findet dazu weitere Gedanken in meinem separaten Artikel zu Forecasting, Variabilität und probabilistischen Prognosen. [Link zum Artikel über Forecasting und probabilistische Prognosen]

Schritt 3 - Regeln für den Prozess explizit machen

Innerhalb des Workflows gilt es nun, die Regeln sichtbar und explizit zu machen. Nur dadurch entsteht ein gemeinsames Verständnis. Und nur explizite Regeln können bewusst verbessert werden. Im Folgenden sollen einige der wichtigsten Regeln im Workflow beschrieben werden.

Exit Criteria

Mit Hilfe sogenannter Exit Criteria wird definiert, wann ein Prozessschritt als abgeschlossen gilt und somit gepullt werden kann. Diese Exit Criteria werden demnach pro Spalte festgelegt. In den Spalten, die in „Aktiv“ und „Abgeschlossen“ unterteilt werden, bestimmen sie also, wann ein Element in die „Abgeschlossen“ Spalte übergehen kann. Für „Develop“ könnten dies beispielsweise sein:

• Code Review wurde durchgeführt.
• Der Build ist grün.
• Technische Dokumentation wurde angepasst.
• Akzeptanzkriterien wurden geprüft.

Pull Policies

Erlaubt das WIP-Limit neue Arbeit, stellt sich die Frage: Woran arbeiten wir als Nächstes? Das kann dann beispielsweise über eine Pull Policy geregelt werden. Ein Beispiel:

• Blocker haben Vorrang.
• Ältere Items haben Vorrang.
• Neue Arbeit wird erst gezogen, wenn WIP unterschritten wird.

Service Level Expectations (SLE)

Die sogenannte Service Level Expectation beschreibt die zu erwartende Durchlaufzeit mit einer bestimmten Eintrittswahrscheinlichkeit. Zum Beispiel:

• 7 Tage oder weniger mit 50 Prozent Wahrscheinlichkeit
• 16 Tage oder weniger mit 85 Prozent Wahrscheinlichkeit

Abbildung 6 - Cycle Time Scatter Plot

Und das erlaubt nicht nur bessere Prognosen. Schließlich macht es wenig Sinn, die 85 Prozent der Elemente zu betrachten, die innerhalb der vorgesehenen SLE abgeschlossen werden konnten. Gerade die wenigen Elemente, die deutlich länger benötigen als erwartet, liefern oft die wertvollsten Erkenntnisse über Probleme im System.

Schritt 4 - Den Fluss der Arbeit aktiv überwachen und steuern

Nachdem der Workflow nun in einer ersten Version inkl. den Regeln und den WIP Limits festgelegt wurde, geht es nun darum, diese Werkzeuge aktiv zur Verbesserung des Flows zu nutzen. Dabei sollen Störungen im Ablauf identifiziert und dafür Verbesserungen implementiert werden. Was sich trivial und selbstverständlich anhört, hat jedoch weitreichende Auswirkungen auf die Arbeitsweise eines Softwareentwicklungsteams. Denn dafür ist ein wichtiger Perspektivwechsel, ja sogar ein Paradigmenwechsel notwendig. Nicht die optimale Auslastung einzelner Personen steht im Mittelpunkt, sondern der möglichst reibungslose Fluss der Arbeit durch das Gesamtsystem. Das bedeutet, dass Leerlaufzeiten in einem gewissen Rahmen nicht nur akzeptiert, sondern sogar erwünscht sind. In einem System, das nahe an seine Kapazitätsgrenze betrieben wird, ist nicht nur anfällig für Störungen. Auch werden die Wartezeiten und amit die Durchlaufzeiten in einem solchen System recht hoch sein. Gibt es im System immer wieder auch einen gewissen Leerlauf, dann wird das System als ganzes resilienter und effizienter.

Single-Piece-Flow

Aus Perspektive des Flows wäre ein Single-Piece-Flow ideal. Dabei würde sich das Team zu jedem Zeitpunkt auf ein einziges Arbeitselemente konzentrieren. Sobald ein Teilschritt abgeschlossen ist, würde sofort der nächste Schritt umgesetzt, weil die dafür notwendigen Personen bereits parat stehen. So entstehen keine Wertezeiten. In der Praxis ist das jedoch kaum umsetzbar umsetzbar. Ein Konzept, das diesem Ansatz jedoch sehr nahekommt, ist beispielsweise Mob-Programming. Dabei arbeitet eine Gruppe, ggf. das gesamte Team gemeinsam an einer einzelnen Aufgabe. Diese kann dann "in einem Rutsch" umgesetzt werden, weil alle zur Fertigstellung der Aufgabe notwendigen Kompetenzen in der Gruppe vorhanden sind. Informationen müssen nicht ausgetauscht werden, da alle bereits seit Beginn an der Umsetzung beteiligt waren und schon früh ihre Perspektive und Erfahrung einbringen konnten. Aber auch ohne Mob-Programming und Single-Piece-Flow können Teams Durchlaufzeiten signifikant reduzieren, wenn der Fokus auf das Abschließen von Aufgaben gelegt wird. Das wird auch sehr schön durch einen bekannten Slogan aus der Kanban-Community beschrieben:

Stop starting, start finishing

Viele Daily Scrums enden implizit mit der Frage: „Hat heute jede/jeder genügend Arbeit?“ Genau diese Perspektive ist aus Sicht des Flows jedoch problematisch. Sie optimiert primär die Auslastung einzelner Personen statt den Fluss der Arbeit durch das Gesamtsystem. Die entscheidendere Frage wäre daher: „Was können wir heute gemeinsam tun, um möglichst viele der bereits begonnenen Aufgaben abzuschließen?“ Der Fokus verschiebt sich damit von individueller Beschäftigung hin zum gemeinsamen Ziel, angefangene Arbeit fertigzustellen, Wartezeiten zu reduzieren und den Flow im System zu verbessern.

Work Item Aging

Eine Technik, die genau dabei helfen kann, ist das sogenannte Work Item Aging. Dabei wird sichtbar gemacht, wie lange sich ein Element bereits in Bearbeitung befindet. Das Alter eines Elements kann anschließend mit der definierten SLE verglichen werden. Dadurch wird frühzeitig sichtbar, wo eine Überschreitung wahrscheinlich wird. Das Team kann gezielt reagieren und den Fokus auf gefährdete Elemente legen. Dadurch werden Ausreißer reduziert und das System insgesamt stabiler.

Workflow-Grenzen bewusst definieren

Eine wichtige Rolle für die Optimierung des Flows spielt nun, wie wir den Start- und den Endpunkt unseres Workflows definiert haben. Nur für diesen Bereich greifen unsere Visualisierung und die erwähnten Metriken. Es macht daher einen erheblichen Unterschied, ob unser Workflow damit endet, dass die Implementierung inkl. Qualitätssicherung abgeschlossen und das Feature genutzt werden könnte oder ob das Deployment bis zum Anwender inkludiert ist. Ist das Product Backlog Teil unseres Workflows? Das wird vermutlich bei vielen Teams dazu führen, dass die Durchlaufzeiten stark durch die Wartezeit im Product Backlog bestimmt werden. Aber vielleicht zeigt das auch gerade ein wesentliches Problem im aktuellen System? Ein WIP-Limit für das Product Backlog kann beispielsweise helfen, die Menge gleichzeitig versprochener Arbeit zu begrenzen. Dadurch reduziert sich nicht nur die Menge unnötiger Planung, auch die Vorhersagbarkeit verbessert sich. Der Flow vom Kundenwunsch bis hin zur Nutzung durch die Anwender wird dadurch betrachtet und optimiert. Abbildung 7 zeigt einen solchen erweiterten Workflow.

Abbildung 7 - Erweiterter Workflow

Technischer Flow als Voraussetzung

Gerade in der Softwareentwicklung hängt organisatorischer Flow stark von technischem Flow ab. Langsame Builds, manuelle Deployments, fragile Testpipelines oder große Merge-Konflikte wirken direkt auf die Durchlaufzeit. Deshalb lassen sich moderne Flow-Konzepte nur schwer von Themen wie Continuous Delivery, DevOps oder schneller technischer Rückkopplung trennen. Wer tiefer in diesen Zusammenhang einsteigen möchte, findet dazu weitere Gedanken in meinem separaten Artikel zu den drei Wegen von DevOps, den ich in Kürze hier auf dem Blog veröffentliche.

Fazit

Die Konzepte hinter Kanban und Flow stehen teilweise im Gegensatz zu klassischen Denkmodellen über Effizienz und Auslastung. Gerade deshalb lohnt es sich, die Zusammenhänge wirklich zu verstehen. Wer sich darauf einlässt, entdeckt häufig, dass bessere Ergebnisse und entspannteres Arbeiten kein Widerspruch sein müssen. Flow-Optimierung bedeutet nicht einfach „mehr Geschwindigkeit“.

Es geht vielmehr darum:

• Arbeit sichtbar zu machen,
• Engpässe zu erkennen,
• Wartezeiten zu reduzieren,
• kleinere Feedbackzyklen zu schaffen,
• Lernen zu beschleunigen,
• und das Gesamtsystem bewusster zu steuern.

Weiterführende Folgen zur Artikelserie zu Kanban:
Teil 1 - Let there be flow – Die Magie hinter Kanban und Flow (dieser Artikel)
Teil 2 - Flow mit Metriken beherrschen -> Erscheint in Kürze

Noch zwei abschließende Gedanken:

WIP - Work in Process oder Work in Progress?

Die Abkürzung WIP wird in der Literatur unterschiedlich verwendet. Oft liest man „Work in Progress“, teilweise aber auch „Work in Process“. Der Unterschied mag zunächst klein erscheinen. Das zugrunde liegende Denkmodell ist jedoch wichtig. Bei „Work in Progress“ stellt sich schnell die Frage: Was zählt eigentlich dazu? Zählen blockierte Aufgaben? Zählen Elemente, die bereits auf den nächsten Bearbeitungsschritt warten? Gerade für die Optimierung von Flow ist entscheidend, dass sämtliche Elemente betrachtet werden, die sich im System befinden. Deshalb verwende ich in diesem Artikel bevorzugt den Begriff „Work in Process“.

Scrum und Kanban - Konkurrenten oder Dreamteam?

Scrum und Kanban werden häufig als konkurrierende Vorgensmodelle dargestellt. Oder als Baukasten, aus dem man sich einfach die angenehmen Teile herauspickt. Grundsätzlich spricht nichts dagegen, Vorgehensweisen sinnvoll an die eigene Situation anzupassen. Allerdings sollte man sich dabei ehrlich eine wichtige Frage stellen:

„Verbessern wir unser System wirklich oder vermeiden wir nur unangenehme Veränderungen?“

Gerade bei Kanban sieht man häufig Missverständnisse. Nicht selten bedeutet „Wir machen jetzt Kanban“ in Wirklichkeit:

• keine Sprints mehr,
• weniger Verbindlichkeit,
• ungefilterter Ticketstrom,
• keine klare Verbesserungsschleife,
• beliebig viele parallele Aufgaben.

• explizite Regeln,
• aktive Steuerung,
• konsequente WIP-Limits,
• Transparenz,
• datenbasierte Verbesserung.

Umgekehrt bietet Scrum aber auch eine ganze Reihe von sinnvollen Konzepten, die Kanban effektiver machen.

• Sprint-Ziele und Produkt-Ziele, die helfen, fokussiert zu bleiben
• Einen Rhythmus, der dem Team Struktur und klar definierte Reflexionspunkte gibt
• Drei klar abgegrenzte Verantwortungsbereiche die zur erfolgreichen Produktentwicklung essenziell sind
• Einen Rahmen, der Teams vor allem zu Binn eine gute Orientierung bietet