„Machen Sie noch Scrum oder schon Kanban?“ Eine Frage, die man mittlerweile oft in virtuellen Meetings und auf den Fluren vieler agiler Unternehmen hört. Aber ergibt diese Frage Sinn? Kanban, genauer gesagt die Kanban Methode eignet sich besonders im komplizierten Anforderungsraum. Dort wo wiederkehrende Aufgaben mit reproduzierbaren Methoden abgearbeitet werden können. Scrum hingegen ist besonders im komplexen Anforderungsraum stark, dort wo Anforderungen und Lösungen zum Großteil unbekannt sind und erarbeitet werden müssen. Auf dem ersten Blick ergibt die Frage also keinen Sinn, da beide Modelle nicht in Konkurrenz zueinander stehen, sondern vielmehr auf unterschiedlichen Ebenen ihre Wirksamkeit beweisen. Wenn man sich aber mit der neuen Stacy Matrix oder dem Cynefin Modell beschäftigt oder eine zeitlang darüber nachdenkt fällt einem auf, dass es doch das Ziel sein muss alle Prozesse aus einer komplexeren Domäne in eine komplizierte oder sogar einfachere zu transformieren um nicht nur effektiv, sondern eben effizient und damit besonders sparsam an Zeit und Ressourcen zu arbeiten. Wie heißt es so schön? Es ist nicht nötig das Rad neu zu erfinden. Aus diesem Blickwinkel ergibt die Frage daher tatsächlich Sinn. Was also, wenn ich mein Produkt, meine Dienstleistung und/oder meine Kenntnisse soweit entwickelt habe, dass es kaum noch Unbekanntes zu entdecken gibt, aber der Prozess weiterhin betrieben und auch optimiert werden muss? Hier kommt dann tatsächlich Kanban ins Spiel.
Kanban, was so viel wie Laufkarte bedeutet, ist durch das von Toyota entwickelte und in den Siebzigerjahren veröffentlichte Kanban System (oder auch Toyota Production System, TPS) bekannt. In diesem System durchläuft ein Produktionsmittel, symbolisiert durch eine, mittels zusätzlicher Spezifikationen versehene, Laufkarte, durch die Produktionsstraße mit verschiedenen Arbeitsstationen, die die unterschiedlichen Arbeitsschritte aufbrechen und in Ihrer Komplexität verringern. Hierbei soll durch Limitierung der Produktionsmittel und kontinuierlicher Verbesserung der sogenannte Flow, also der Durchfluss, maximiert werden. Anhand verschiedener Metriken lässt sich diese Optimierung nachweisen und ebenfalls erkennen ob getroffene Maßnahmen zur Optimierung fruchtbar waren oder erneut betrachtet werden sollten. Dieses Kanban System und auch viele weitere Prinzipien und Praktiken aus der Entwicklung von Toyota finden heute weltweit ihren Einsatz in der Produktion und Entwicklung von Produkten und Dienstleistungen. So auch in der Softwareentwicklung, wo es in abgewandelter Form als Kanban Methode durch David J. Anderson und Andy Carmichael bekannt wurde.
Durch ihren einfachen Aufbau ist die Kanban Methode nicht nur in der Softwareentwicklung, sondern auch darüber hinaus beliebt. Sie ist überall dort besonders wirkungsvoll wo wiederkehrende Aufgaben mit einer zufälligen Varianz oder Abwandlung in gehäufter Form abzuarbeiten sind. In der Automobilproduktion ist beispielsweise klar, dass an Station A ein Lenkrad eingebaut werden muss, allerdings können es von Fall zu Fall verschiedene sein. Aber Vorsicht! Wie auch bei anderen agilen Methoden gilt hier das Credo: Leicht zu verstehen – schwer zu meistern.
Grundlagen
Aufbauend auf Werten wie Transparenz, Leadership und Flow, folgt die Methode grundlegenden Prinzipien. „Starte mit dem was Du hast“ heißt es dort, oder auch „Manage die Arbeit und lasse die Menschen sich darum herum selbst organisieren“. Letzteres geschieht unter anderem nach dem PULL-Prinzip und mit Hilfe der Limitierung von Arbeit. Beides soll schnell aufzeigen an welchen Stellen Optimierungsbedarfe bestehen, wenn man beispielsweise das Limit der Arbeit nach und nach erhöht. Um den Wandel zum Besseren effektiv zu betrachten, gibt es die drei Agenden mit den Horizonten der Nachhaltigkeit, der Serviceorientierung und des „Überlebens (am Markt)“. Entlang dieser drei Horizonte orientieren sich die Kanban Praktiken.
Praktiken
Die Praktiken stellen das Herzstück der Kanban Methode dar, bei der jeder Arbeitsschritt visualisiert und die Arbeit selbst limitiert wird. Mit Hilfe dieser Praktiken wird es nun möglich den Flow zu managen und den sprichwörtlichen Hahn langsam aufzudrehen und nachzuverfolgen an welchen Stellen das System in Schwierigkeiten gerät, um dort dann gezielt den „Hahn“ wieder zuzudrehen. Am Ende steht als Ergebnis ein durchsatzoptimiertes Produktionssystem.
Eine weitere Praktik lautet „Make Policies explicit“, was dabei hilft Fehler und Missverständnisse zu reduzieren, genauso wie Einarbeitungs- und Rüstzeiten. Auf diese Weise ist auch der Wechsel zwischen verschiedenen Arbeitsstationen für jeden Mitarbeiter grundsätzlich möglich und erhöht zusätzlich die Flexibilität und die Resilienz des Prozesses.
Wie bereits aus Scrum, mit der Retrospektive oder aus Kaizen, bekannt, gilt auch in Kanban die Praktik der kontinuierlichen Verbesserung, welche durch die sogenannten Feedback Loops erreicht wird. Hierbei ist explizit Verbesserung und Weiterentwicklung gefordert.
Rollen
David J. Anderson und Andy Carmichael haben selbst keine dedizierten Rollen für Ihre Methode vorgesehen, allerdings haben sich in der Praxis zwei Rollen als sehr wirkungsvoll herausgestellt. Dabei ist der Service Request Manager verantwortlich für den Kundenfokus und die Ausgestaltung des Produktes bzw. der Dienstleistung und der Service Delivery Manager für die Ausgestaltung des Produktionsprozesses und die Einhaltung aller Praktiken.
Metriken
Da Kanban auf die kontinuierliche Verbesserung und Optimierung des Flows abzielt sind Metriken natürlich unabdingbar und von denen gibt es eine Vielzahl möglicher. Die Lead Time und die Delivery Rate sind hierbei essenziell wichtig.
Die Lead Time bestimmt die Dauer, die ein Produktionsmittel für einen definierten Arbeitsschritt-Abschnitt benötigt. Dies kann von der gesamten Prozesskette bis hin zum einzelnen Arbeitsschritt skaliert werden und hilft nicht nur bei der Vereinbarung von Lieferterminen und Vorhersagen, sondern auch bei der Aufdeckung von Potenzialfeldern im Prozess.
Die Delivery Rate zeigt wie potent das vorliegende System ist und kann aufzeigen, wenn es Probleme gibt oder Maßnahmen zur Verbesserung wirklich gefruchtet haben.
Heute anfangen!
Jetzt sind Sie gefragt! Überlegen Sie doch mal in welcher Domäne Ihre Produkte und Prozesse angesiedelt sind und ob die Kanban Methode in Ihrem Kontext Sinn ergibt. Ein Anfang ist oft mit der Visualisierung und der Limitierung der Arbeit an den einzelnen Stationen getan. Falls Sie Fragen haben oder Unterstützung brauchen, melden Sie sich gerne jederzeit bei uns.
