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.