Zeiten im Wandel – Scrum oder Kanban

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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.