Episode 19: Kanban oder Scrum – was ist besser?

  • letztes Jahr

In den letzten beiden Episoden haben wir uns mit SCRUM beschäftigt. SCRUM ist eine tolle agile Methode, aber auch nicht die Einzige. Das ist auch gut so, weil SCRUM nicht für alle Anwendungsgebiete gleichermaßen geeignet ist.

Daher möchte ich heute eine andere agile Methode hinterher schieben: KANBAN. Software-KANBAN um genau zu sein.

Hier möchte ich einen knappen Einblick in Kanban geben. Nicht mit dem Anspruch die Methode vollständig erklärt zu haben, aber um dir einen ersten Eindruck zu vermitteln. Auf dieser Basis kannst du dann entscheiden, ob Kanban für dich interessant ist oder eher nicht.

Produktionssteuerung mit KANBAN

KANBAN kommt aus der Produktionssteuerung. Schauen wir uns zunächst mal das Original an, danach übertragen wir es dann auf ein Umfeld außerhalb einer Massenproduktion.
Kanban kommt aus Japan und bedeutet so viel wie „Karte“, zu der Karte kommen wir auch gleich.

Im Kern geht es darum die Materialflüsse in der Produktion zu optimieren. Klassisch wird in einem Produktionsprozess der gesamte Materialbedarf zentral bestimmt und koordiniert. Bei Kanban wird die Materiallogistik dezentral betrachtet: die Mitarbeiterinnen und Mitarbeiter eines Produktionsschritts, welcher Material benötig, fordern so viel Material an, wie sie aktuell benötigen. Es wird also kein Material auf Vorrat angefordert und gelagert. Umgekehrt darf der vorgelagerte Produktionsschritt, der das Material produziert nicht auf Halde produzieren, sondern muss die angeforderte Menge produzieren. Diese Prinzipien ziehen sich durch alle Produktionsschritte der Produktionskette.

Wie genau funktioniert die Steuerung der Materialanforderungen? Hier kommen jetzt die Karten ins Spiel, die der Methode auch den Namen gegeben haben.
Es ist ganz simple, auf einer Karte ist das Material und die Menge beschrieben. Karte und Material lieben in einem Behälter. Der Behälter wandert zu dem Produktionsschritt, wo er benötigt wird. Bevor im Prozessschritt dieses Material genutzt wird, wird die beiliegende Karte entnommen und an die Abteilung, die das Material produziert zurück geschickt. In der Prozesskette wandert die Karte also einen Prozessschritt zurück. Dort löst die eingehende Karte die Produktion des auf der Karte beschriebenen Materials in der angegeben Menge aus.

Das Grundprinzip ist also sehr einfach.
Dadurch, dass das Material vor Ort nach Bedarf angefordert wird, müssen keine großen Vorräte angelegt und Puffer eingerichtet werden. Es braucht auch keine Verwaltung die zentral etwas plant und sich dann immer mit den Realitäten vor Ort abgleichen und neu planen muss.
Selbstverständlich gibt es bei Kanban in der Produktion noch viele Aspekte, die ich hier einfach weglassen möchte.

Kanban in der Software-Entwicklung

Dafür möchte ich jetzt auf die Abwandlung eingehen, die man zum Beispiel für die Software-Entwicklung einsetzt.

In der Software-Entwicklung habe ich kein Material und keine Behälter, die ich bewegen kann. Und wenn man dort irgendwelche Karten einführen möchte, dann wird man von den Informatikern nur ausgelacht.
Das Prinzip bleibt dennoch das Gleiche, aber es sieht ein wenig anders aus. Wie es dort funktioniert möchte ich kurz erklären – auch hier lasse ich die Details weg und beschränke mich auf das Grundprinzip.

In der Software-Entwicklung geht es statt um Material um Anforderungen, die in Form von Anwendergeschichten („User Stories“) beschrieben sind. Dabei beschreibt man in einem kleinen Szenario, wie sich das künftige Software-System verhalten soll. Diese User Stories werden in SCRUM im Product Backlog gesammelt und daraus der Sprint Backlog abgeleitet. Bei Kanban arbeite man mit einer Kanban-Wand („Kanban Board“). Dieses Board ist in Spalten unterteilt. Die rohen Anforderungen schreibt man einfach in die linke Spalte. Gegebenenfalls ist eine Story noch zu umfangreich und man kann sie in kleinere Arbeitsaufträge unterteilen. In der linken Spalte stehen also die Arbeitsaufträge für das gesamte Team.

Von links nach rechts schließt sich dann der Entwicklungsprozess an: für jeden Produktionsschritt (bzw. bei der Software-Entwicklung: Entwicklungsschritt) gibt es eine eigene Spalte. In die Spalte ganz rechts schreibt man dann alle fertigen Arbeitsaufträge. Im einfachsten Fall hat man nur drei Spalten: links der Arbeitsvorrat, in der Mitte Aufträge in Arbeit und rechts erledigte Aufträge.

Stellen wir uns vor, ich möchte für die Podcast-Produktion Kanban einsetzen. Für die Podcast-Produktion könnte ich ein Kanban-Board mit folgenden Spalten einrichten: „Ideen“, „Recherche“, „Vorbereitung“, „Aufnahme“, „Schnitt“, „Veröffentlichen“ und „Erledigt“.
Eine Episode würde ich zunächst als Idee anlegen und dann durch die einzelnen Spalten bewegen.

Für mich allein ist diese Methode wohl etwas übertrieben. Zur Veranschaulichung lass uns – auch wenn es nicht stimmt – annehmen, dass wir gemeinsam ein Team von 7 Podcastern wären. Bestimmt hat jeder seine Stärken und Schwächen, aber keiner aus dem Team möchte nur einen Produktionsschritt durchführen, sondern jeder möchte alles machen – zumindest gelegentlich.
Wie komme ich nun an Arbeit? Ganz einfach, ich schnappe mir eine Episode, die noch nicht fertig ist und erledige einfach den nächsten Produktionsschritt. Danach lasse ich die Episode quasi wieder los und stelle sie im Kanban Board für die weitere Verarbeitung in die nächste Spalte weiter rechts ein. Selbstverständlich kann ich an derselben Episode weitermachen. Aber es wäre auch nicht ungewöhnlich, wenn eine Kollegin oder ein Kollege diese Episode übernimmt. Die Episode gehört mir nicht. Also, wenn ich zum Beispiel eine Episode aufgenommen habe, dann könnte ein Kollege den Schnitt machen.

In der Produktion sorgt Kanban mit den wandernden Karten dafür, dass jeder Produktionsschritt ausgelastet ist. In einem Produktionswerk bleiben die Arbeiter typischerweise an einer Stelle im Produktionsprozess und die Aufträge ziehen an ihm vorbei. Es wäre total unpraktisch, wenn alle Arbeiter eine Woche nur am ersten Produktionsschritt arbeiten würden und dabei eine riesige Halde mit Zwischenergebnissen erzeugt. In der zweiten Woche würden alle Arbeiter den zweiten Produktionsschritt durchführen usw. Wochenlang würde das Unternehmen keine Produkte ausliefern können und keine Rechnungen stellen. Das Material und die Löhne für mehrere Wochen der Produktion müssten vorfinanziert werden.
Analog ist es auch in der Software-Entwicklung. Wenn man es so machen würde, dann würden wir ja wieder bei einer klassischen Entwicklung landen: zuerst alles Konzipieren, dann Codieren, Testen, Integrieren usw. Aber wir wollen ja agil, kleine Anforderungspakte zeitnah umsetzen. Ebenso beim Podcast: wer möchte schon alle 10 Wochen gleich 10 Episoden auf einmal hören?

Um den kontinuierlichen Fluss sicher zu stellen, gibt es eine maximale Anzahl von Einträgen in jeder Spalte. Ich kann also nicht links neue Aufträge (Episoden) nachziehen, sondern muss mir die Arbeit von rechts suchen. Damit liegt das Augenmerk eher auf die Fertigstellung von bereits angefangenen Aufgaben und nicht auf dem starten von neuen Aufträgen.
Soweit der kurze Abriss über die Funktionsweise von Kanban.

Zusammenfassung von Kanban

Bevor man mit der eigentlichen Arbeit an den Aufträgen beginnen kann, muss man die Arbeitsabläufe identifizieren und als Spalten auf dem Kanban-Board dazustellen.

In der Praxis wird man nicht nur die Spalten mit Namen versehen, sondern auch die Bedeutung aller Spalten beschreiben. Möglicherweise wird man auch Kriterien oder Regeln festlegen, wann ein Auftrag eine Spalte weiterziehen darf und wie mit Aufträgen umzugehen ist, die im Prozess einen Schritt zurück machen müssen (z.B. weil sich die Anforderungen an das System geändert haben, die Qualität für den anstehenden Prozessschritt nicht ausreicht oder schlicht etwas vergessen wurde).
Spannend ist auch die Frage, wer wählt einen Auftrag zur Bearbeitung aus und nach welchen Kriterien wird der nächste Auftrag gewählt. Dies muss nicht alles vor Beginn geregelt sein, aber sobald es eine Unzufriedenheit diesbezüglich gibt, sollte eine Regelung gefunden, vereinbart und aufgeschrieben werden.

Werden dann die einzelnen Aufträge in die Spalten des Boards geschrieben, dann hat man stets die Übersicht über den Lauf der Aufträge im Prozess.
Durch das Festlegen einer maximalen Anzahl von Aufträgen pro Spalte kann man verhindern, dass zu viel angefangen und zu wenig beendet wird.

Man kann selbstverständlich auch weitere Parameter im Prozess betrachten, z.B. Die Verweildauer der Aufträge in einer Spalte, um zu verhindern, dass sich einzelne Aufträge in einer Spalte festsetzen und alle anderen Aufträge daran vorbeiziehen. Oder den Durchsatz an Aufträgen pro Woche, das könnte hilfreich für Prognosen sein, wann werden die bekannten Aufträge erledigt sein, spätestens wann müssen neue Aufträge nachgelegt werden. Um diese Parameter zu optimieren, müssen dafür geeignete Messgrößen erhoben werden. Sinnvoll ist es diese Größen ebenfalls auf dem Kanban-Board zu visualisieren.

Kanban könnte man klassisch einsetzen, dann würde es einen Hauptverantwortlichen geben, der die Aufgaben zuteilt, die Metriken und Regeln überwacht. So richtig agil wird die Methode erst dann, wenn sich alle Team-Mitglieder gemeinsam für das Geschehen auf dem Kanban-Board interessieren. Jedes Mitmitglied sich nicht nur an der Abarbeitung der Aufträge beteiligt, sondern auch Verbesserungen einfordert und mitgestaltet. Das Team braucht ein gemeinsames Verständnis über den Existenzgrund des Teams – dann können sie den Prozess nach diesem Existenzgrund optimieren und brauchen keine Führungskraft, die den Prozess verantwortet.
In diesem Sinne ist der Prozess auch nicht etwas statisches, das von einer höheren Instanz vorgegeben wird. Der Prozess ist einfach der Ablauf, der im Augenblick für am besten geeignet gehalten wird.

Vergleich SCRUM vs. Kanban.

Wenn wir nun Scrum und Kanban vergleichen, dann erkennt man einige Unterschiede. Anhand dieser Unterschiede kannst du nun herausfinden welche der beiden Methoden für deine Problemstellung besser geeignet ist.

Kanban für gleichlaufenden Prozesse

SCRUM kann viele Stärken ausspielen, wenn man ein Zusammenhängendes Produkt erzeugen möchte. Du erinnerst dich bestimmt noch an die Produktvision, mit der ein erfahrener Product Owner wie Jochen Lipowec immer startet. In jedem Sprint entsteht wieder ein Stück des Produktes und man nähert sich der Produktvision an.

Grundsätzlich kann man das auch bei Kanban machen, ist aber in der Methode so nicht vorgeschrieben. Kanban kann viele Stärken ausspielen, wenn alle Aufträge immer die gleichen Schritte durchlaufen. Man kann mit dem aller einfachsten Kanban-Board mit nur drei Spalten („Neu“, „in Arbeit“ und „Fertig“) starten und bei Bedarf weitere Spalten hinzufügen oder auch wieder heraus nehmen. Zunächst fallen dir vielleicht keine Prozessschritte ein, aber vielleicht sind es ganz einfache Aspekte wie eine Qualitätsprüfung, eine Freigabe, eine Archivierung oder eine Ergebnispräsentation, die bei dir immer vorkommen. Also mach’ dir keinen Kopf, die Prozessschritte, die in deinem Umfeld regelmäßig vorkommen, musst du nicht suchen, sie drängen sich dir im Laufe der Zeit auf.

Taktung vs. kontinuierlicher Fluss

Ein sehr großer Unterschied zwischen Scrum und Kanban besteht in der Taktung in Scrum durch die Sprints.

Jeder Sprint ist gleich lang, das Team schätzt die Menge an Arbeit, die sie sich in dem aktuellen Sprint vornehmen. Für die Dauer eines Sprints werden keine Änderungen oder neue Anforderungen zugelassen. Dies ist erst im nächsten Sprint möglich. Logischerweise müssen alle Aufträge soweit aufgeteilt werden, dass sie in einem Sprint erledigt werden können.

Bei Kanban fließt die Arbeit kontinuierlich durch die Spalten. Das macht die Abarbeitung flexibler, Aufträge können auch unterschiedliche Größe haben (was jedoch dazu führen kann, dass Kennzahlen wie zum Beispiel Durchlaufzeiten an Aussagekraft verlieren). In Kanban gibt es kein Sprintende und damit auch keine Aussage über mögliche Fertigstellungstermine der Aufträge.

Teams vs. Prozess

In Scrum sind die Rollen (also „Scrum-Master“, „Product Owner“ und „Development Team“) vorgegeben. Scrum beschreibt die Arbeitsweise eines Teams, das ein Produkt erstellt – eine teamübergreifende Zusammenarbeit ist in Scrum nicht beschreiben. Daraus ergibt sich, dass alle nötigen Kompetenzen für die Erstellung des Produkts in diesem einem Team vorhanden sein müssen.

Kanban macht keine Einschränkungen bezogen auf Teams: Ein Board kann von einem Team genutzt werden, genauso wäre denkbar, dass für einzelne Spalten ein eigenes Team zuständig ist. Man könnte auch noch mehrere Zeilen im Kanban-Board einzeichnen. Dann bekommt jedes Team eine Zeile zugewiesen und erlegt für ihre Aufträge alle Prozessschritte. Mit Kanban können also auch teamübergreifende Vorgänge gesteuert werden. Kanban fokussiert nur auf den Prozess und kennt Streng genommen den Team-Begriff gar nicht.

Abschluss

Nun kannst du dir überlegen welche Methode auf deine Problemstellung besser passt.

Wenn es dir schwer fällt den immer gleichen Prozess von Aufträgen zu finden, dann könnte dies ein Hinweis sein, dass du mit Scrum besser klarkommst.

Fällt es dir dagegen schwer immer gleich große Iterationen einzuführen, dann könnte möglicherweise Kanban die bessere Wahl sein.

Vielleicht passen auch diese beiden Methoden überhaupt nicht oder in Teilen nicht. Wie immer gilt – nimm was dir hilft, experimentieren ist erlaubt. Die Herausforderung lautet ja nicht, die Methode mustergültig umzusetzen, sondern Kundenprobleme zu lösen. Falls eine Methode nicht so richtig zündet, ändere sie oder schwenke um auf eine andere Methode. Es gibt viele Software-Entwicklungsteams, die mit Scrum begonnen haben und schließlich Kanban machen. Aber auch Teams, die von Kanban zu Scrum gegangen sind.

In diesem Sinne wünsche ich dir Mut und Experimentierfreude mit den agilen Methoden. Da darf ich auch Jochen Lipowec aus der Episode 18 über die Werte von Scrum zitieren: man braucht bei der Einführung die Haltung, dass scheitern zum Einführungsprozess dazu gehört und dass man daraus lernt. Fail fast – learn fast.

Ich hoffe ich konnte dir ein wenig Lust machen, Agilität in deinem Umfeld umzusetzen.

>