Neue, wichtige und dringliche Anforderungen in SCRUM
Auch SCRUM als agiles Projektmanagementframework wird es nicht verhindern, dass laufende Prozesse gestört werden bzw. ein Weg gefunden werden muss, um aktuelle Herausforderungen zu meistern.
Ein klassisches Beispiel, welches wohl jeder Product Owner nur zu Gute kennt, sind neue Anforderungen, die während eines Sprints aufkommen. Der Sprint ist begonnen, das Team hat sich auf ein Sprintziel und -umfang geeinigt und dann kommen wichtige und dringliche Themen aus den Product Owner zu, die sofort umgesetzt werden müssen. Um dies mit dem SCRUM Prozess zu harmonisieren, hat sich folgender Weg bewährt.
Problemstellung
Angenommen der Sprintzyklus beträgt zwei Wochen. Das nächste Refinementmeeting steht erst nach der nächsten Sprintplanung an. Das bedeutet, dass neue Anforderung erst in dem nächsten Refinementmeeting besprochen werden und im übernächsten Sprint begonnen werden können. Also von der Anfrage bis zur Finalisierung bestenfalls 5 Wochen.
Diese Inflexibilität hört sich alles andere als agil an. Leicht könnte der Product Owner dazu tendieren, die neuen Themen ohne größeres Refinement noch schnell in den nächsten Sprint „zu drücken“ bspw. direkt im anstehenden Planungsmeeting für den kommenden Sprint. Das ist aber nicht ratsam. Dies löst vielleicht auf den ersten Blick das Problem, dass das Thema möglichst schnell in einen Sprint gelangt, aber spätestens bei der Qualitätssicherung, wenn nicht schon bei der Umsetzung zeigt sich in den meisten Fällen, dass eine fehlende Besprechung des Umfangs der Umsetzung und des fehlenden Verständnisses des Teams für die neue User Story zu weitaus mehr Zeitverzug führt als wenn der Prozess eingehalten worden wäre.
Kurz gesagt: Prozesse über den Haufen zu werfen mögen kurzfristig das Problem lösen, aber langfristig weitere und größere Probleme aufwerfen.
SCRUM – Ad hoc Themen
Diese Erfahrung der täglichen Umpriorisierung aufgrund neuer Aufgaben ist aber auch Modell unabhängig und gerade im klassischen Wasserfallmodell ist man noch viel stärker mit der Problematik konfrontiert.
Empfehlung
Meine Empfehlung hierbei ist, dass der Product Owner für die festgelegte Priorisierung der Themen kämpft. Natürlich liegt es ihm frei, Themen im Backlog umzupriorisieren aber insofern einmal ein Sprint begonnen wurde und somit die Tasks bspw. durch die Entwickler begonnen wurden, sollten diese nicht unterbrochen werden.
Bereits aus dem Zeitmanagement kennt man den sogenannten Sägezahneffekt. Denn unterbricht man eine laufende Entwicklung und setzt sie zu einem späteren Zeitpunkt fort, sind wiederum erneute Einarbeitungszeiten erforderlich. Mit jeder Unterbrechung sinkt das Leistungsniveau.
Da die Welt aber leider nicht immer so ist, wie wir sie uns in der Theorie vorstellen, wird es immer wieder vorkommen, das irgendwo brennende Themen sofort umgesetzt werden müssen. Das mag eine rechtliche Änderung sein oder ein größerer Fehler in der bisherigen Implementierung. Hier wird sicherlich kein Product Owner sagen können, dass das drei Wochen Zeit haben muss. Ein Thema muss aber gemäß dem Eisenhower-Prinzip wichtig und dringlich sein, damit es genau eben diese Berechtigung hat, in den laufenden Sprint mit aufgenommen zu werden.
Vorgehen
Sollte der Product Owner mit einem derartigen Ausnahmethema konfrontiert sein, ist nach SCRUM kein genauer Prozess vorzufinden. In den bisherigen SCRUM Teams hat sich als sehr sinnvoll gezeigt, dass solche Themen durch den Product Owner in das nächste Daily Stand-Up mitgenommen werden.
Zunächst wird dem Team die Dringlichkeit und auch deren Wichtigkeit erläutert. Dies hat primär das Ziel, das Team einzubeziehen und abzuholen, sodass Verständnis für die Sprintänderung aufgebracht werden kann. Anschließend wird dem Team die User Story vorgetragen. Und genau wie im Planungsmeeting wird sich die Zeit genommen, die Akzeptanzkriterien zu schreiben, deren Vollständigkeit zu prüfen und anschließend die Komplexität zu schätzen.
Nun liegt die Entscheidung wie folgt bei dem Team: Einerseits kann es sagen, dass die Story in den laufenden Sprint mit aufgenommen werden kann, ohne das Sprintziel zu gefährden – diese Aussage wird sicherlich die Ausnahme sein. Andererseits kann das Team gemeinsam mit dem Product Owner überlegen, welche User Stories hierfür aus dem Sprint genommen werden, sodass eben das Sprintziel nicht gefährdet wird. Insofern es möglich ist, sollten nur solche User Stories aus dem Sprint genommen werden, die noch nicht begonnen wurden.
Fazit
Für neue dringliche Anforderungen gibt es meines Wissens in SCRUM keinen klaren Prozess, wie diese in den laufenden Sprint umgesetzt werden sollen. Vermutlich um hier auch kein Hintertürchen für das obere Management zu öffnen, die dann gerne auf einen „ich drücke das Thema noch rein“-Prozess noch zurückgreifen könnten.
Das hier beschriebene Vorgehen, sollte eine absolute Ausnahme sein und weder von den Stakeholdern oder dem Product Owner ausgenutzt werden. Der SCRUM Master sollte genau darauf achten und immer wieder auf den eigentlichen SCRUM Prozess hinweisen.
Sollte dennoch eben genau dieser Fall eintreten, ist es wichtig, dass Team einzubeziehen und abzuholen. Es ist der Product Owner, der in diesem Fall dahinter stehen muss, warum es nun so absolut wichtig ist, das Thema umzusetzen. Wenn die Akzeptanz gegeben ist, spricht auch nichts dagegen, hier vom Prozess ausnahmsweise abzuweichen.