Einen Sprint abbrechen oder ändern

Einen Sprint abbrechen? Kenne ich schon.

Sklave einer Methode zu sein, ist nie gut, und manchmal kann trotz aller Planung etwas schief gehen. Wirklich schief. Wenn das passiert, ist es vernünftig, aus dem Zug auszusteigen, bevor er über die Klippe stürzt. Auf diese Weise können sich alle neu gruppieren, die Situation in Ruhe analysieren, feststellen, was schief gelaufen ist, Wege besprechen, wie so etwas nicht noch einmal passieren kann, und neu anfangen. (Vorausgesetzt, es wäre vermeidbar - manchmal greift die weite Welt ein. Hacks, Infrastrukturkatastrophen, Kunden, die in den Süden gehen usw.)

Häufiger habe ich jedoch gesehen, dass ein einzelnes Team seinen Sprint komplett neu arrangiert hat. Typischerweise, weil Teammitglieder abgezogen wurden, um sich mit einem Notfall zu befassen/etwas Auffälliges auftauchte. In diesem Fall wurden die Geschichten für das verbleibende Team neu ausgewählt oder neu geschrieben (d. h. aufgeteilt), um besser zum verbleibenden Fachwissen zu passen.

Fazit: Sprints sind ein Werkzeug, ein Mittel zum Zweck. Manchmal bringen sie dich aus unzähligen Gründen nicht dorthin.

Dies hängt davon ab, wie Sie das Projekt durchführen möchten und wer die „Kosten“ des abgebrochenen Sprints trägt. Am Ende kann es triftige Gründe geben, den gesamten Sprint einfach abzubrechen und den gesamten bis dato erstellten Code „zurückzustellen“ und von vorne zu beginnen.

Ich würde empfehlen, die Stakeholder in den Raum zu holen und die schwierige Frage zu stellen – wenn wir diesen Sprint abbrechen und die geleistete Arbeit wegwerfen, wer wird die Kosten tragen? Dies führt dazu, dass Sie entweder den Fokus erhalten, den Sie benötigen, und Sie können den Sprint umgestalten, um einige/alle geleistete Arbeit zu retten, oder Ihre Entscheidung, den Sprint abzubrechen, bestätigen.

Letztendlich sind Sprints, wie Gary sagte, ein Werkzeug/Regelwerk. Ich mag Regeln, sie helfen Entwicklern, Kunden und PMs, die richtigen Entscheidungen zu treffen – einen Sprint abzubrechen kann die richtige Entscheidung sein und oft besser sein, als die Ziele des Sprints langfristig zu verschieben.

Sprints können als anormale Beendigung abgebrochen werden, zum Beispiel könnte das Team abbrechen, wenn es das Ziel nicht erreichen kann. Der nächste Schritt ist ein neues Sprint-Planungsmeeting.

Sprints können und sollten beendet werden, wenn ein legitimer geschäftlicher Bedarf dafür besteht.

Den Inhalt eines Sprints statisch zu halten, ist gut für die geistige Gesundheit Ihres Teams und im Allgemeinen hilfreich für die Planung.

Was es wirklich leistungsfähig ist , ist der Schutz des Entwicklungsteams vor Scope Creep durch Stakeholder, die vorbeifahren und nach neuen Funktionen usw. fragen könnten. Wenn Sie jedes Mal, wenn dies passiert, diesen Sprint als abnormal beendet markieren, erstellen Sie eine Aufzeichnung zur Kommunikation an den Rest der Geschäftsführung.

Wenn Sie den Fortschritt Ihres Projekts mit der Führung überprüfen und zeigen, dass sowohl Sprint 15 als auch Sprint 16 beendet wurden, weil Stakeholder Xyz zusätzliche Funktionen angefordert hat, werden rote Fahnen gezündet, um zu zeigen, dass entweder die Planung nicht angemessen ist, die Vision nicht klar/konsistent ist oder Stakeholder Xyz spielt zu viel mit dem Team.

Außerdem wird es einem Stakeholder deutlich machen, welche Auswirkungen das Hinzufügen eines neuen Umfangs zu einem Sprint hat, und es weniger wahrscheinlich machen, dass er sich einmischt oder bis zu den geeigneten Zeiten wartet, um den Entwicklungsplan zu beeinflussen (z. B. Sprint-Planungsmeeting).

Agilität ist keine Anarchie, sondern funktioniert, indem es eine Struktur rund um Agilität bereitstellt und somit die Grenzen dafür definiert, wie agil Sie sein können.