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.