Sind Sie ein Kanban-Typ?

Sie möchten Ihre Produktentwicklung verbessern, wissen aber noch nicht genau wie? Zu Scrum können Sie sich aufgrund der erforderlichen Veränderungen in Ihrem Unternehmen nicht so recht durchringen. Wenn Sie sich in dieser Beschreibung wiederfinden, sollten Sie über Kanban nachdenken!

Agile Vorgehensweisen liegen im Trend, allen voran Scrum. Nichtsdestotrotz spüren wir in manchen Erstberatungen deutlich, dass Scrum nicht für jedes Unternehmen der passende Weg ist. Manchen Managern ist Scrum zu revolutionär, die Vorstellung einer komplett neuen Struktur und Denkweise lähmt eher als dass sie inspiriert. Wir haben die Erfahrung gemacht, dass diese Unternehmen mit der Alternative Kanban oft sehr viel besser fahren.

Der Klassiker Kanban

Entwickelt wurde Kanban bereits 1947 von Toyota in Japan – zu einer Zeit, als die älteren der heutigen Agilisten gerade in den Windeln lagen. Kanban revolutionierte die Autoproduktion nachhaltig: Erstmals wurde der „Just-in-time“-Gedanke in eine Methodik umgesetzt, die aus heutiger Sicht simpel erscheint.

„Es müsste doch möglich sein, den Materialfluss in der Produktion nach dem Supermarkt-Prinzip zu organisieren, das heißt, ein Verbraucher entnimmt aus dem Regal eine Ware bestimmter Spezifikation und Menge; die Lücke wird bemerkt und wieder aufgefüllt.“ (Kanban-Erfinder Taiichi Ohno)

Kleines Beispiel: Ein Automechaniker baut Lenkräder ein, die er von einem Stapel holt. Am mengenmäßig kritischen Punkt ist im Stapel eine Kanbankarte platziert, die nun zur Lenkrad-Produktion wandert und dort signalisiert: „Die Lenkräder werden knapp, umgehend auffüllen!“ Die anfallende Arbeit wird dabei nicht von oben verteilt, sondern die Arbeiter organisieren sich selbst. Vorteil dieses „Pull-Prinzips“: Der Produktionsfluss wird optimiert und die Lagerbestände reduziert – klassisches Lean-Management.

Was haben Autos und die Entwicklung digitaler Produkte gemeinsam?

„Software-Kanban“ wurde 2007 durch David Anderson populär, als dieser bei Microsoft grundlegende Kanban-Prinzipien in die Softwareentwicklung einführte, u.a. das Pull-System und Tickets, Limitierungen, die Visualisierung durch Kanban-Boards usw. Sein Ziel war es, die Anzahl paralleler Arbeiten (WiP) zu reduzieren, Engpässe sichtbar zu machen und so schnellere Durchlaufzeiten zu erreichen. Wesentlicher Bestandteil von Software-Kanban ist außerdem der kontinuierliche Verbesserungsprozess in kleinen Schritten (japanisch: „Kaizen“) sowie eine Firmenkultur, die von Vertrauen und gegenseitigem Respekt geprägt ist. Die Vorgehensweise ist nicht auf Software reduziert, sondern kann für alle digitalen Produkte eingesetzt werden.

Sehen Sie die Parallelen zu Scrum? Warum sich viele Unternehmen von Kanban mehr angesprochen fühlen, hängt mit dem evolutionären Ansatz zusammen: Software-Kanban ist sehr viel sanfter, es ändert sich auf den ersten Blick wenig an der gewohnten Arbeitsweise. Etablierte Prozesse und der Ist-Zustand werden respektiert und es gibt keine neuen Rollen oder Job-Titel. Während Scrum den Teams häufig das Gefühl vermittelt „Wir müssen künftig alles anders machen“, kommuniziert Kanban „Wir lassen erstmal alles wie es ist und analysieren gemeinsam die Problemstellen“ – das Team einigt sich lediglich auf einen kontinuierlichen Verbesserungsprozess. Entsprechend hoch ist die Akzeptanz, was die Implementierung von Kanban vergleichsweise einfach macht.

Wichtige Prinzipien von Software-Kanban:

• Wertschätzung des Bestehenden
• Visualisierung des Workflows
• Limitierung der angefangenen Arbeiten (WIP Work in Progress)
• Messung und Steuerung des Workflows
• Ständige Reflexion und der Wille zur Verbesserung

Kanban ist also sehr viel mehr als bunte Zettelchen, die auf einer Tafel hin- und hergeschoben werden: Kanban vereint ausgefeiltes Change Management und Unternehmenskultur.

Und so funktioniert Kanban

Im ersten Schritt wird der Ist-Zustand, sprich der bestehende Workflow in Form eines Kanban-Boards visualisiert – meist ein einfaches Whiteboard mit Haftnotizen bzw. Karteikarten. Jede Karte auf dem Board steht für eine Aufgabe.

Das Board wird in Spalten eingeteilt, die sämtliche Arbeitsschritte bis zur Fertigstellung repräsentieren. Die Zahl und Benennung der Spalten ist dabei nicht vorgeschrieben. Ein typischer Arbeitsfluss in der Entwicklung digitaler Produkte könnte zum Beispiel in „Backlog“, „Design“, „Entwicklung“, „Test“ und „Fertig“ aufgeteilt werden. Jeder Job wird auf einer Kanban-Karte („Ticket“) erfasst und im Lauf des Arbeitsprozesses von links nach rechts über das Board bewegt.

Abb 1: Visualisierung der Prozess-Schritte

Abb 2: Workflow

Für jeden Arbeitsschritt gibt es festgelegte Kriterien der Fertigstellung, an die sich alle Teammitglieder zu halten haben (ähnlich der „Definition of Done“ bei Scrum). Erledigte Arbeiten werden außerdem nicht in die nächste Spalte geschoben („push“), sondern der Teamkollege des nächsten Arbeitsschritts holt sich die Arbeit („pull“), sobald er Zeit dafür hat. Es ist deshalb wichtig, erledigte Arbeiten in einer Spalte zu markieren (z.B. mit einem grünen Sticker) oder jede Spalte nochmals zu unterteilen in „Do“ und „Done“.

Gibt es Arbeitsblockaden z.B. durch fehlende Informationen, so dass die Arbeit an einem Ticket unterbrochen werden muss, wird die Kanbankarte ebenfalls markiert (z.B. durch einen roten Sticker). Vorteil: Aktuelle Problemstellen werden auf einen Blick erkannt.

Ein weiteres typisches Merkmal von Kanban ist die Limitierung: Es wird festgelegt, wie viele Aufgaben parallel bearbeitet werden dürfen (Work in Progress oder kurz „WiP“). Statt zu forcieren, dass jeder möglichst viel Arbeit „auf dem Tisch hat“, geht Kanban genau den entgegengesetzten Weg – meist über Spalten-Limits, d.h. dass beispielweise in der Spalte „Design“ maximal 2 Tickets hängen dürfen. Die Überlegung: Ständiger Aufgabenwechsel produziert unnötigen Mehraufwand – es ist besser 1 Arbeit zu 100 Prozent fertig zu haben als 10 Arbeiten zu 10 Prozent. So wird effizienzminderndes Multitasking reduziert, Blockaden müssen aktiv angegangen werden und jede einzelne Aufgabe wird erfahrungsgemäß schneller erledigt.

Stehzeiten werden bewusst in Kauf genommen. Am Beispiel unseres Kanban-Boards: Hat das Team „Entwicklung“ alle eigenen Tickets abgearbeitet,  holt aber das nachgeschaltete Team „Test“ zu wenig Tickets ab, entsteht bei den Entwicklern durch die Limitierung auf 2 Tickets Leerlauf – sie dürfen sich keine neuen Tickets von „Design“ abholen. In diesem Fall unterstützen die Entwickler die Tester, bis der Arbeitsfluss wieder hergestellt ist.

Abb 3: Beispiel einer Blockade-Situation

Kanban kann mehr als Zettel-Schieben

Zugegeben alles vergleichsweise einfache Maßnahmen, die aber allein durch die Visualisierung zu sehr viel mehr Transparenz führen: Wer macht gerade was? Wieviele Aufgaben stehen an? Wie weit sind die einzelnen Aufgaben fortgeschritten und wo gibt es Engpässe?

In der Praxis ist der exemplarisch vorgestellte Kanban-Ablauf noch weitaus differenzierter, u.a. werden zur Priorisierung von Aufgaben verschiedene Service-Klassen definiert („Service Level Agreements“) oder es wird zumindest mit einer „Fast Lane“ gearbeitet, auf der Tickets mit absoluten Vorrang durchgeschleust werden. Zusätzlich können „Swimlanes“ eingeführt werden – eine zusätzliche horizontale Gliederung der Aufgaben nach Aufgabentypen, um die Übersichtlichkeit auf dem Board zu erhöhen (z.B. in „Feature“, „Change Request“ und „Bugs“).

Abb 4: Kanban-Board mit Fastlane

Kanban geht aber weit über die reine Visualisierung des Ist-Zustands hinaus. Um den gewünschten Flow der Tickets zu erreichen, wird alles kritisch unter die Lupe genommen, was diesen behindert: An welchen Stellen gibt es häufig Blockaden und warum? Wie hoch sind Durchlaufzeiten, Durchsatz und Fehlerquote? Müssen die Limits oder Teamstärken angepasst oder Puffer eingeführt werden? Ein sehr wichtiger Aspekt von Kanban ist die sogenannte „Engpass-Theorie“: Wo stauen sich Tickets („bottlenecks“), während an den nachfolgenden Stationen Leerlauf herrscht? Durch die Visualisierung wird der erste Engpass gefunden und behoben – was zum nächsten und übernächsten Engpass führt und so den Prozess in seiner Gesamtheit langsam, aber kontinuierlich optimiert.

Für die laufende Evaluierung kennt Kanban verschiedene Metriken, Modelle und Maßnahmen, die – konsequent angewandt – zu einer beeindruckenden Verbesserung aller Arbeitsschritte im Unternehmen führen. Grundsätzlich ist „Kaizen“ in Kanban nicht formalisiert, die meisten Teams halten aber Daily Standups am Kanban-Board ab und werten in regelmäßigen Retrospektiven umfangreichere Datensammlungen aus.

Ja, aber …

Kanban erfährt jede Menge Gegenwind von überzeugten Scrum-Evangelisten, die Kanban nicht wirklich zu den agilen Methoden zählen. Wir sind hingegen der Ansicht, dass in Kanban jede Menge agiles Mindset steckt. Nicht selten ist Kanban ein Türöffner für Scrum – der Beginn einer sanften Revolution. Wir lassen uns von der wachsenden Agilität unseren Kunden auf jeden Fall immer wieder gerne überraschen!

Auch der umgekehrte Fall kommt häufig vor: Unternehmen, die bereits erfolgreich mit Scrum arbeiten, suchen nach weiteren Verbesserungsmöglichkeiten. Kanban kann helfen, die Durchlaufzeiten weiter zu verkürzen und die Releaserate zu erhöhen.

Egal in welcher Reihenfolge oder Kombination: Schon die Begründer des Agilen Manifests waren sich einig, dass Prozesse und Tools den Individuen und deren Interaktionen unterzuordnen sind. Solange also einem Unternehmen mit den Kanban-Abläufen perfekt gedient ist, ist Kanban für dieses Unternehmen auch „richtig“.

Haben Sie Interesse an Software-Kanban? Gerne erzählen wir Ihnen in einem kostenlosen Erstgespräch mehr über dieses Prozessmodell und klären gemeinsam, ob es für Ihr Unternehmen geeignet ist!