Wenn Scrum nicht funktioniert

Je nachdem wie im Team dann weiter vorgegangen wird, kann es sein, dass dieses Inkrement auch tatsächlich veröffentlicht oder zunächst nur einem begrenzten Personenkreis zur Verfügung gestellt wird. Im zweiten Fall erfolgt dann ein Release in gebündelter Form mit den Ergebnissen mehrerer Sprints. Gerade zu Beginn ist es auch bei agilen Projekten üblich, dass das Team zunächst mehrere Sprints lang am Projekt arbeitet, bevor die erste Version der Software an die eigentlichen Nutzer verteilt wird. Dies soll sicherstellen, dass die Software schon über genügend Funktionalität verfügt, damit sie im Alltag der Nutzer auch sinnvoll einzusetzen ist. In jedem Fall wandelt sich aber auch hier der Ablauf, sobald die Laborbedingungen wegfallen und sich die Software mit den ersten Fehlerberichten und Änderungsanforderungen aus dem Livebetrieb konfrontiert sieht. Dies kann dann auch einer der Momente sein, in denen Scrum für manche Teams nicht mehr zu funktionieren scheint, denn ihre eigentliche Stärke und ihre ableitbare Planbarkeit erhalten Scrum-Projekte dadurch, dass mit einer Iteration ein fester  Zeitbereich definiert wird, in dem das Team seine Arbeit selbstverantwortlich ausführen kann.

Eigentlich sollten während eines Sprints keine Änderungen an den Aufgaben vorgenommen werden. Kommen plötzlich weitere Arbeitspakete hinzu, dann stört dies den Ablauf von Regelterminen (wie Review, Planning oder Retro), führt zu nicht abzuschätzenden Mehraufwänden und macht damit die ursprünglichen Einschätzungen zunichte.

Wenn jedoch die Schätzungen des Teams zu oft und zu weit von den tatsächlichen Werten abweichen, zerstört dies wiederum das Vertrauen in das gesamte Vorgehen, wodurch agile Arbeitsweisen schnell einmal komplett in Frage stehen können.

Typische Kritikpunkte am agilen Vorgehen wie „endlose Entwicklungszeiten“, „unerwartet hohe Aufwände“ und „unkoordinierte Aufgabenbewältigung“ ergeben sich somit nicht zuletzt auch, weil die eigentliche Evolution von Software falsch verstanden und ungünstig auf sie reagiert wurde. So lässt sich den beschriebenen Schwierigkeiten beispielsweise durch eine Verkürzung der Sprint-Zeiten auf zum Beispiel eine Woche entgegenwirken oder indem gleich von Scrum auf Kanban umgesattelt wird.

Zuvor aber wäre zunächst zu prüfen, warum so oft auf Meldungen aus der Produktion reagiert wird, und ob dies überhaupt in einer Geschwindigkeit passieren muss, die den gesamten Entwicklungsprozess aus den Angeln hebt. Häufig kann hier schon geschickte Planung und Priorisierung auf Kundenanfragen helfen. Dazu ist jedoch klar einzuschätzen, welche Dinge tatsächlich wie zu handhaben sind. Das betrifft einen der Kernpunkte der Wissenschaft hinter der Software-Evolution.