Agilophil-Daily Podcast Episode 20: Kanban für Scrum Teams?

In der letzten Folge habe ich über die Prinzipien und Praktiken von Kanban gesprochen, das war vielleicht etwas theoretisch…daher frage ich mich heute mal – was muss man als Scrum-Team eingentlich ändern, wenn man mal ein bisschen Kanban machen will…oder macht das überhaupt Sinn?

Die Entstehung von Kanban geht ja auf das Jahr 1940 zurück.

Das System wurde von Taiichi Ohno, einem Ingenieur und Geschäftsmann, der die Kanban-Methode für Toyota in Japan entwickelte, geschaffen. Für die Methodik ließ er sich von einer völlig anderen Branche inspirieren — von Supermärkten und ihren Lagerbeständen.

Supermärkte verwalten ihren Bestandsfluss, indem sie nur ausreichend Produkte auf Lager haben, um die Nachfrage der Verbraucher zu befriedigen. Toyota hatte ein ähnliches Problem mit der Bestandsverwaltung. Daher entwickelte Ohno das Signalkartensystem „Kanban“, um die Lagerbestände an den tatsächlichen Materialverbrauch für die Automobilherstellung anzupassen.

Und so funktionierte die ursprüngliche Idee:

1. Die Fabrikmitarbeiter kommunizierten ihre Kapazitäten in Echtzeit, indem eine „Kanban-Karte“ zwischen den einzelnen Montage-Teams weitergegeben wurde.

2. Wenn Materialien in der Produktionslinie aufgebraucht waren, wurde eine „Kanban-Karte“ an das Lager übergeben, um dem Team mitzuteilen, was genau benötigt wurde.

So entstand eine Kommunikationskette: Das Lager konnte dann diesen Bedarf dem Lieferanten mitteilen, der das Material dann zum Lager versenden konnte. Es konnte also nicht zu viel geliefert werden da immer nur dann geliefert wurde, wenn etwas benötigt wird. Du kannst das vergleichen mit dem einfachen Verfahren, was aktuell – also in der Corona-Zeit – in den Geschäften und Supermärkten angewendet wird. Jeder Kunde muss einen Einkaufswagen oder einen Einkaufskorb mitnehmen. Da es nur eine begrenzte Anzahl von Einkaufswagen gibt, kann man so sehr leicht die Anzahl der Kunden im Geschäft limitieren. Es darf immer nur ein Kunde rein, wenn ein anderer Kunde fertig ist und seinen Einkaufswagen wieder abstellt. Einfach – aber genial..(das geniale ist ja immer einfach…)

Dieser Prozess wird auch als „Just-in-Time“ bezeichnet. Ein wesentlicher Aspekt, den ich noch erwähnen möchte, ist, dass in der Industrie der Auftrag für die Produktion erst an die Fabrik gegeben wird, wenn die Bestellung eingegangen ist. Das bedeutet, dass es vermieden wird, auf Verdacht und auf Vorrat zu produzieren – es wird immer genau das produziert, was wirklich gebraucht wird. – ein blaues Auto, wenn ein blaues bestellt ist und ein rotes, wenn ein rotes bestellt ist…

Das Kanban-System wurde dann auf für die Softwareentwicklung populär, nachdem sie von David J. Anderson in seinem Buch Kanban: Evolutionäres Change Management für IT-Organisationen auf die IT übertragen wurde.

Um es mal zusammenzufassen, Kanban ist eine visuelle Methode zur Aufgabenverwaltung und Aufgabenverarbeitung. Es geht bei „Kanban“ um den Arbeitsfluss also darum die „Bewegung von Arbeit zu optimieren. Dazu werden die Aufgaben visualisiert, die laufenden Arbeiten begrenzt und damit wird die Effizienz (oder den Ablauf) optimiert. Kanban-Teams konzentrieren sich also darauf die Zeit vom Start bis zur Vollendung einer Aufgabe (oder einer „User Story“) zu verkürzen. Die Kernprinzipien von Kanban sind auf nahezu jede Branche anwendbar und durch den Grundsatz „Start where you are“ auch an keine Voraussetzungen geknüpft. Daher verwundert es auch nicht, dass die Methodik bei allen Arten von Teams wie im Marketing, Vertrieb, in der Personalbeschaffung und im Betriebsablauf immer beliebter wird.

Ich komme eigentlich aus der Scrum-Welt und Scrum ist ja auch zumindest in der IT aktuell das weiter verbreitete System…

Wenn Du natürlich selbst ein echter Kanbañero bist oder in der Industrie schon mal mit Lean Manufacturing in Kontakt gekommen bist, wirst Du das wahrscheinlich genau anders herum sehen. Wie ich ja schonmal gesagt habe – für mich sind Scrum und Kanban wie Bruder und Schwester mit durchaus unterschiedlichen Charaktereigenschaften (also Kanban mit dem Flußkonzept und Scrum mit der empirischen Prozesssteuerung) aber doch sehr verwandt. Und einer von den beiden ist nun mal der oder die ältere… In der Tat ist ja Kanban – in der Form, die wir im IT-Kontext sehen, jünger als Scrum…der Ursprung von Kanban, der aus der Automobilindustrie kam, ist wiederum älter als Scrum und kann als wesentlicher Input für die Entwicklung von Scrum angesehen werden.

Wie läuft das denn nun eigentlich in der Praxis?

Insbesondere wenn Du in einem Scrum Team arbeitest, (wie gesagt, aktuell arbeiten ca 80% der IT-Teams im Scrum-Framework), macht es Sinn mal drüber nachzudenken, ob Du nicht ein paar Dinge aus Kanban übernehmen möchtest oder ob Du nicht sogar ganz auf Kanban wechseln willst.

Dieser Wechsel ist im Prinzip gar nicht schwer, da wesentliche Elemente analog funktionieren. Nehmen wir zum Beispiel das Sprint-Planning – In Kanban wird jede Woche der Nachschub im Backlog geplant – der Begriff aus Kanban dazu ist „Replenishment“ ( also Nachschub)- Angenommen wir haben ein Scrum-Team mit einer Sprintlänge von einer Woche – dann ist das Ziel hier analog – wir planen wöchendlich, was wir uns an Arbeitsvorrat vornehmen. (Ich blende hier mal bewusst ein paar Details aus – wie das Sprintziel oder das Commitment des Teams, was es so explizit in Kanban nicht gibt). Aber Du wirst mir zustimmen, dass wir hier ein grundsätzlich analoges Vorgehen haben. Grooming Meetings in Scrum sind mit Release Planning Meetings in Kanban vergleichbar, die in bestimmten Abständen hier vorgesehen sind. Ebenso die Daily Standups- die es in beiden Frameworks gibt. Eine Sprint Retrospektive hat ihre Verankerung in Scrum am Ende des Sprints – in Kanban sind Retrospektiven in bestimmten Abständen auch vorgesehen – nur nicht explizit jede Woche. Doch auch hier gibt es Parallelen. Das einzige, was in der Form wegfällt sind Review-Meetings, die in Kanban nicht so wie in Scrum durchgeführt werden. Feedback der Stakeholder wird in Kanban eher im Sinne einer Flußkontrolle durchgeführt – hier also mit sogenannten Operations Reviews, in denen der Kanban-Fluß an Hand von KPIs also Messwerten – überprüft und ggf. Ideen zu Verbesserung entwickelt werden. Das Feedback zum Produkt selbst steht in Kanban im Hintergrund, da wir hier eher einen „Produktions-„ als einen Produktentwicklung-Kontext haben. In Kanban gehen wir davon aus, dass das „Produkt“ an sich schon fertig ist und es „nur“ Wartungsarbeiten oder kleinere Anpassungen daran gibt. Daher ist ein Stakeholder in einem Kanban System halt daran interessiert, dass seine Anforderung schnell umgesetzt – also schnell produziert wird oder anders ausgedrückt – dass die Verweilest seiner Anforderung im System möglichst kurz ist.

Es ergeben sich aus meiner Sicht noch eine Reihe von weiteren Fragen und die erste, die sich mir – und wahrscheinlich jedem, der mit seinem Team agil arbeiten möchte — in den Sinn kommt, ist

Wie analysiert man den Arbeitsprozess? – also den Workflow des Teams?

Da Kanban letztlich ein visueller Workflow ist, wird für die Aufgabenplanung und die Aufgabenverfolgung entweder ein physisches oder digitales Board verwendet. Ein Kanban-Board verwendet Karten, Rubriken und das Konzept der kontinuierlichen Verbesserung. So kann sich ein Team ständig selbst kontrollieren und für anstehende Arbeiten koordinieren.

In Anlehnung an David J. Anderson, den ich ja schon erwähnt habe, gibt es folgende Komponenten in einem Kanban-Board:

Visuelle Signale (normalerweise Karten)
Spalten oder Listen
Pull System
Work-in-Progress-Limits
Einen Verpflichtungspunkt
Eine Lieferstelle

Die Spalten oder Listen werden für die Darstellung des Workflows verwendet: Einer der häufigsten und einfachsten Workflows ist „To Do“, „In Bearbeitung“ und „Done“. Dieser Workflow ist meist auch die Basis in einem Scrum-Board. Kanban geht hier allerdings etwas genauer vor:

Wenn wir uns jetzt mal überlegen, welche grobe Tätigkeiten in der Spalte „In Bearbeitung“ stecken, können wir den Workflow detaillieren. Hier kannst Du zum Beispiel Dinge wie „Analyse, Konzeption, Programmierung, Dokumentation und Test einfügen um den Workflow des Teams zu beschreiben.

Voraussetzung ist, dass jede Karte die festgelegten Arbeitsschritte durchlaufen muss, um am Ende realisiert zu werden. Typisch hierfür sind kleinere Änderungen oder Bug-Fixes an bestehenden IT-Systemen.

Dann komme ich jetzt mal zum Pull Prinzip: Ein wesentliches Element im Kanban Board ist das Pull System. Pull bedeutet – im Gegensatz zu Push – dass in jedem Prozessschritt derjenige, der die Arbeit vornimmt entscheidet, wann er etwas beginnt. Und das mit der Maßgabe, dass er nicht zu viele Dinge gleichzeitig bearbeiten darf. Dieses Konzept wird die Limitierung des Work in Progress genannt – also WIP-Limit. Wo die Limitierung liegt wird von Team festgelegt und immer mal wieder justiert.

Auch in Scrum gilt das Pull Prinzip, wird in der Praxis jedoch oft ignoriert, da es nicht mit einem Kontrollmechanismus wie den WIP-Limits verbunden ist. Hier sehe ich zum Beispiel einen guten Ansatz, um Scrum mit einem Element aus Kanban zu erweitern. Ein Punkt, der dabei gleich ins Auge springt, sind die Unterkategorien „in Arbeit“ und „fertig“ in jeder Spalte bzw. In jedem Workflowschritt. In Scrum bekannt ist ja die „DoD“ -also die Definition of Done: in Scrum verstehen wir hiermit die allgemein gültigen Kriterien, die jede Userstory erfüllen muss um in die Spalte „Fertig“ verschoben zu werden. Gemeint sind hiermit nicht die inhaltlichen Dinge – diese sind in den Akzeptanzkriterien festgehalten – nein gemeint sind hiermit die übergeordneten Dinge wie „test erfolgt, Dokumentation geschrieben, In dem Master ge-merge-t, oder ins Integrationstest-System transportiert…

Wenn wir das Pull Prinzip verankern wollen, müssen wir solche Regeln für jeden Prozessschritt einzeln klar formulieren und damit explizit festlegen, wie die Arbeit durch die einzelnen Stationen fließt. In jeder Station wird die Arbeit dann entsprechend der Kriterien in die Unterkategorie „Fertig“ geschoben und kann dann von dem Kollegen oder der Kollegin, die den nächsten Arbeitsschritt durchführt abgeholt werden. Es ist also was anderes, wenn Du Dein Stück auf den Schreibtisch des nächsten legst im Sinne von „hier, ich bin fertig und jetzt bist Du dran“ – das wäre dann nämlich das Push-Prinzip – was man ja auch übersetzen kann mit „hier, ich drücke Dir die Arbeit auf“

oder

wenn die fertige Arbeit auf Deinem Schreibtisch liegen bleibt bis sie abgeholt wird. Wenn der eigene Schreibtisch voll ist, darfst oder kannst Du nichts mehr anfangen…das bedeutet, die erzeugst keine Verschwendung, denn es sind aus deinem Arbeitsschritt ja genügend fertige Stücke vorhanden. Der Enpass liegt also hinter dir und Du kannst helfen, den Engpass zu beseitigen, da Du ja in dem Moment nichts zu tun hast.

Du siehst – anders herum wird es weniger gut funktionieren: wenn du den Schreibtisch deines Nachfolgers zum Überlaufen bringst, verschlimmerst Du ja sozusagen den Enpass, weil der Haufen immer größer wird. Du produzierst unbeirrt Deine Dinge weiter und kümmerst Dich nicht darum, was nach Dir passiert…(das passende Sprichwort dafür ist dann „Nach mir die Sindflut“) – Halb fertige Produktbestandteile liegen herum und die stellen Verschwendung dar, da ja Arbeitskraft dafür eingesetzt worden ist – die aber keinen Nutzen trägt, da die halb fertigen Items eben noch nicht verwendet werden können. Und Verschwendung ist das, was wir in Kanban vermeiden wollen (und übrigens in Scrum auch – nur hier liegt der Fokus auf Dinge, die wir unnötigerweise produzieren und die im Nachhinein nicht gebraucht werden, weil wir sie am Bedarf vorbei produziert haben. )

Relativ einfach bekommst Du das hin, wenn Du zunächst mit Deinem Team definierst was in jedem Arbeitsschritt erfüllt werden muss, damit eine Karte auf „fertig“ gelegt werden kann. Diese Regeln solltest Du dann auch ausdrucken und an das Board hängen, da – wie bei allen agilen Frameworks – die Transparenz ja eine wesentliche Rolle spielt – und – wir haben das ja auch in der letzten Folge gehört – die Dinge transparent machen, gehört zu den Kernpraktiken des Kanban..

An dem Beispiel von eben mit den Schreibtischen wird auch klar, welcher Vorteil in der Limitierung von Work in Progress liegt – obwohl das ja eher kontraintuitiv erscheint. Also es klingt zumindest unlogisch. Wieso soll ich mehr schaffen, wenn ich mich beschränke? Ich will mich doch nicht beschränken, sondern ich will mehr schaffen, also kann es doch nur gehen, wenn ich in jedem Arbeitsschritt das Maximum erreiche – oder?

Ich gehe darauf nochmal in der kommenden Folge ein. Hier will ich nur nochmal bemerken, dass es die „reine Lehre“ in der Realität ja meistens nicht gibt und wir durchaus mit Mischformen experimentieren können. Ich hatte ja am Anfang die unterschiedlichen Charaktereigenschaften der beiden Geschwister Kanban und Scrum erwähnt – Scrum begründet sich auf dem „inspect und adapt“ und Kanban basiert auf „start where you are“ – Scrum ist revolutionär, weil fest vorgeschrieben – Kanban evolutionär, weil sich langsam entwickelnd…Daher gehe ich – wie immer möglichst pragmatisch und offen vor und diskutiere mit dem Team, wie wir vorgehen wollen und was wir ausprobieren wollen – denn eins ist sicher – wir arbeiten ja in einer komplexen Welt – und daher müssen wir Experimente machen um den Weg zu finden. Vor uns war da noch niemand…(also von uns war da noch niemand) – wie auch immer – Du weist schon was ich meine…Und was natürlich auch bei Geschwistern gilt – Pack schlägt sich – Pack verträgt sich…

Danke fürs zuhören und viel Erfolg beim Spiel mit den agilen Elementen, will ich es mal nennen…