Ein weiterer Trend hält die Agile Welt in Atem.

ScrumBan

Ist dies ein Irrläufer oder doch die Lösung für „gescheiterte“ Scrum und Kanban Projekte?
Ich gebe zu, das auch ich geneigt bin hin und wieder auf ScrumBan auszuweichen, da die Realität der Projekte eher selten eine heile Welt Szenario bereithält.

Durch Krankheit und Urlaub wechselnde Teamgrößen, Hotfixes die im laufenden Betrieb eingespielt werden müssen und ein Backlog so groß, das man eigentlich von zwei/drei eigenständigen Produkten sprechen möchte?

Scrum berücksichtigt das Interesse aller Parteien durch feste Iterationen und Planbarkeit, ein genauer Satz an definierten Aufgaben, die wenig Platz für eine dynamische Arbeitswelt lassen. Personal Ausfälle, Code Red Tickets und Störungen durch Umpriorisierungen werden schnell zu einem gefühlten Problem.
Dies kann schonmal zu einem vorgezogenen Sprintabbruch führen, was, falsch verstanden, als Management/Team Fehler gewertet werden kann.

Kanban als hochdynamisches Flow Werkzeug tritt diesem entgegen und lässt per se erstmal jegliche Störung zu, allerdings auf eine Weise die den beteiligten Parteien gleichermassen Rechnung trägt. Das Team hat einen überschaubaren Pool an Aufgaben und das wichtigste, ein begrenztes ArbeitsLimit:

WIP.

Dadurch kann die Arbeit gleichmässig im Flow erledigt werden und die störenden Aufgaben, die ansonsten in Scrum für Unterbrechungen sorgen, werden in dem Pool von den zuständigen Projektmanagern einpriorisiert und damit weniger schädlich mit bearbeitet.
Eine zuverlässige Planung, wie in Scrum, entsteht dadurch jedoch erstmal nicht und Aufgaben werden fertig, sobald sie eben fertig sind und nicht wie in Scrum nach 4 Wochen bei der Abnahme.

Um eine einigermassen verbindlichere Planung in Kanban zu etablieren, sind ein zwei Kunstgriffe aus Scrum möglich: Auswertung der Zykluszeiten vergangener Aufgaben basierend auf ihrer Größenordnung sowie Planung von Iterationen. Man kann auf Basis der Zykluszeiten eine Abschätzung geben, wann das nächste Arbeitspaket zur Verfügung gestellt werden kann. Anhand der Planung was alles zu tun ist wird in Relation der Zeiten ein Zieltermin abgegeben, der, im Gegensatz zu Scrum, wenn er nicht eingehalten werden kann nicht die gleichen gefühlt negativen Reaktionen hervorrufen wird, als ein „gescheiterter“ Sprint.

Rechtzeitiges Aktualisieren des Zieltermins auf Basis einer veränderten Grundlage natürlich vorausgesetzt.

Kanban ist entgegen Scrum kein festgelegter Prozess den man strikt einhalten sollte, es ist als Visualisierung und Kennzeichnung weiterhin zu verstehen. In Kanban sollen Prozesse visualisiert und der WIP begrenzt werden um eine Effektive und gleichmässige Auslastung innerhalb eines Projektes zu erzielen.
Dies bedeutet, das auch aus Scrum Methoden die sich bewährt haben in Kanban abgebildet werden dürfen.

Wenn man dies beherzigt und die wichtigsten Regeln verinnerlicht

• Kaizen – Regelmässiges Überprüfen der Arbeitsprozesse
• WIP – Beschränkung der parallel durchgeführten Aufgaben

sollte einer erfolgreichen Kanban Implementierung nichts im Weg stehen.

Während lange Zeit „Scrum“ als das präferierte Projektmanagement Framework in aller Munde und Anwendung war, etabliert sich mittlerweile eher ein Trend hin zu „Kanban“.

Scrum, als Projektmanagement Framework hat seine Vorzüge bei großen, schwer zu überschaubaren Features und Implementationen, die noch einiges an Aufwand bieten, bis man diese fertigstellen kann. Man erkauft sich die Planungssicherheit für diese Brocken durch einen langen Sprintintervall von bis zu 4 Wochen.
Für die Teams ist ein überschaubar gleich großer Zeitraum an Arbeitspensum vorhanden und damit verbunden eine kontinuierliche Abarbeitung der Themen ohne Störung möglich.

Was macht Scrum allerdings in einer nicht so idealen Welt?
Wie reagiert man in Scrum auf Tickets, Änderungswünschen und Neuanforderungen?

Zwar kann man in Scrum auch flexibel reagieren, dennoch kann das Korsett, was man sich bei Change Requests, BugFixes und co durch Scrum auferlegt hat, an manchen Stellen zu eng werden. Neue Features und Änderungen werden oft nur durch das nächste Planungsmeeting in x Wochen beauftragt und müssen dann noch durch die volle Sprintlänge, im schlimmsten Falle 2 Monate.

Hier springt Kanban als Change Management Prozess in die Bresche und eröffnet Möglichkeiten, die häufig doch recht lebhafte Beziehung zu den Stakeholdern und Kunden, nach dem ersten Release eines Produktes zu besänftigen.

Kanban fördert durch die starke Prozessorientierung durchaus den Wechsel zwischen neuen Anforderungen, Bugtickets und selbst Umbau von Altlasten in einem gleichmässigen Arbeitsrythmus. Planungsmeeting und Review können in dem Alten Modus der Kontinuität wegen verweilen, die größte Änderung befindet sich jedoch im Sprintbacklog das auf die aller wichtigsten Themen begrenzt wird und jeweils neu priorisiert wird, wenn durch bearbeitete Features Platz geschaffen wurde.
Während in Scrum 8-10 Stories pro Sprint keine Seltenheit sind, wird in Kanban wert darauf gelegt, das alles im Fluss bleibt und mit maximal soviel Stories, wie auch bearbeitet werden kann.
Man beschränkt die Anzahl der Stories und Tasks auf jedem Prozess, so das keine Behinderung im Ablauf durch Multitasking und Co gegeben sind.

Hier wird dann auch recht schnell klar, das wenn nur wenige Themen in Bearbeitung sind, Änderungen sehr viel schneller eingeworfen werden können, als es in Scrum der Fall ist. Ist ein Item abgearbeitet, kann ein neues, womöglich frisch hochpriorisiert angefangen werden. Dies kann dann eine Neue Anforderung, Bugticket oder sonst was sein.

Was ist nun besser, Scrum oder Kanban? Die Frage wird derzeit häufig gestellt.
Man kann es nicht in 2 Sätzen zusammenfassen, beide Ansätze sind sehr gut einzusetzen, aber beide haben auch ihren Spezialfall und sollten damit abgewogen werden, was wann eingesetzt wird.

Meine Präferenz liegt hier für große, langfristige Projekte und Features bei Scrum. Hier kann man in Ruhe planen und Umsetzen.
Releases finden alle 4 Wochen statt und damit ist eine Planungssicherheit gegeben.

Werden viele kleinere Änderungen und Neuerungen notwendig ist Kanban die bessere Alternative, da Änderungen und Features nahezu dann eingespielt werden können, sobald sie wirklich fertig sind. Dies eignet sich oft besser für die Zeiten nach dem Release eines Produktes.