© Africa Studio/shutterstock.com
Let there be Flow - Teil 1

Die Magie hinter Kanban und Flow


Ein Konzept findet in der Softwareentwicklung in letzter Zeit immer mehr Beachtung: Kanban. Von den einen als die bessere agile Alternative gepriesen, von anderen wegen der Flexibilität und Einfachheit geliebt. Dabei ist Kanban gar nicht so neu, wie es oftmals scheint. Dieser Artikel möchte die zugrunde liegenden Prinzipien erläutern und so ein besseres Verständnis schaffen.

Kanban wurde bereits 1947 von Taiichi Ohno bei Toyota entwickelt, stammt also aus der Fertigung. Lediglich die Anwendung von Kanban in der Softwareentwicklung ist relativ neu. David Anderson hat dazu 2010 ein Buch veröffentlicht [1], das als Ausgangspunkt für diese Bewegung gilt. Kanban wird oft auf wenige Kernpraktiken reduziert, ohne dass dabei die Wirkmechanismen im Hintergrund ausreichend verstanden werden. Schauen wir uns diese deshalb genauer an.

Kanban = Optimierung von Flow

Ein wesentliches Ziel von Kanban ist es, den sogenannten Flow, also den Fluss der Arbeit, durch ein System zu optimieren. Das System stellt dabei typischerweise die Bearbeitung einer Funktionalität von der Anforderung bis zur Auslieferung dar – hierzu später mehr. Warum aber ist die Optimierung von Flow so entscheidend? Viele Systeme werden heute vor allem auf maximale Auslastung hin optimiert oder, um das etwas positiver zu formulieren, es sollen Leerlaufzeiten bei den Bearbeitenden minimiert werden. Dass diese Optimierung auf Auslastung oftmals keine so gute Idee ist, lässt sich an einem kleinen Beispiel sehr gut verdeutlichen. Wir stellen uns eine Autobahn vor. Während in der einen Fahrtrichtung nicht sehr viel Verkehr ist, bewegen sich die Fahrzeuge in der Gegenrichtung nur im Schritttempo. Während in der einen Richtung immer wieder auch größere Abstände zwischen den Fahrzeugen sind, stehen in der anderen Richtung 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 haben wir 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 werden mehr Fahrzeuge je Zeiteinheit einen bestimmten Punkt passieren? Vermutlich beim flüssigen Verkehr. Genau das ist das Äquivalent zu Flow. Diesen Zustand wollen wir auch in unserem System, das Software erstellt, erreichen. Dort sollen die Features und Bugfixes möglichst zügig und reibungslos durchfließen, statt sich zu stauen und ewig darauf zu warten, endlich fertig zu werden.

Welche Vorteile ein optimierter Flow bietet und wie das erreicht werden kann, das soll in diesem Artikel beleuchtet werden. Einige der hier vorgestellten Konzepte sind kontraintuitiv und erscheinen zunächst unlogisch. Deshalb verlangt der Artikel von der Leserin ein hohes Maß an Offenheit ab, um die hier vorgestellten 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 Prozess zu verstehen, sondern vielmehr als eine Prozessverbesserungsmethodik, die genutzt werden kann, beliebige Prozesse zu verbessern. Zudem ist Kanban nicht zwingend auf die agile Softwareentwicklung beschränkt, auch wenn es sich dort besonders gut anwenden lässt. Im Folgenden wollen wir diese Kernpraktiken und ihre konkrete Umsetzung näher betrachten.

Schritt 1: Fluss der Arbeit visualisieren

Als erster Schritt muss ein gemeinsames Verständnis davon geschaffen werden, wie die Arbeit durch unser System bewegt wird. Diese Definition bezeichnen wir im Weiteren als Workflow. Teilweise sieht man statt Arbeit auch den Begriff Nutzen oder Wert bzw. den englischen Begriff Value und daraus folgend auch den Begriff Value Stream als Äquivalent zum Workflow. Zunächst müssen der Start- und der Endpunkt für unseren Workflow festgelegt werden.

Das mag zunächst trivial klingen, wirft bei näherer Betrachtung aber auch viele Fragen auf. Startet unser Workflow dann, wenn ein neuer Featurewunsch von einem Kunden oder einer anderen Person gemeldet wird, oder erst dann, wenn wir wirklich beginnen, daran zu arbeiten? Endet der Workflow, wenn das Feature umgesetzt wurde, wenn es getestet ist oder wenn es ausgeliefert und durch die Kunden genutzt werden kann? Diese unterschiedlichen Definitionen der Grenzen unseres Workflows haben wichtige Auswirkungen, auf die wir etwas später noch näher eingehen wollen. Für den Moment genügt es, festzuhalten, dass es verschiedene valide Optionen gibt und es zunächst nur wichtig ist, sich auf eine klare und gemeinsame Definition zu einigen.

Zwischen dem Start und dem Ende des Workflows werden nun verschiedene Aktivitäten beschrieben, die ausgeführt werden müssen, während ein Element unseren Workflow durchläuft. Das können für Softwarefeatures im einfachsten Fall 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 dargestellt visualisiert werden.

schissler_kanban_1.tif_fmt1.jpgAbb. 1: Start- und Endpunkt sowie Aktivitäten eines simplen Workflows

Ein weiteres wichtiges Konzept in Kanban ist das sogenannte Pull-Prinzip. Das bedeutet, dass ein Element aktiv in eine Aktivität „gezogen“ wird, wenn dafür Kapazität vorhanden ist, statt dass die vorausgehende Station fertige Arbeit in diese Aktivität schiebt. Die Wichtigkeit des Pull-Prinzips wird deutlich, wenn wir später noch über das Konzept von Engpässen bzw. Bottlenecks sprechen. Für den Moment soll lediglich erläutert werden, wie wir das Pull-Prinzip in unserem Workflow ermöglichen. Dazu unterteilen wir die Aktivitätsspalten in einen Bereich für Elemente, an denen aktiv gearbeitet wird, und Elemente, die in dieser Aktivität abgeschlossen sind und somit bereit sind, in die nächste Aktivität gezogen zu werden (Abb. 2).

schissler_kanban_2.tif_fmt1.jpgAbb. 2: Spalten unterteilen, um das Pull-Prinzip zu ermög...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang