Agile Programmierung mit SCRUM. Was tun wenn Ziele im Sprint nicht erreicht werden können?
Angenommen, das Entwickler-Team stellt zur Hälfte des Sprints fest, dass die Ziele aufgrund von Schwierigkeiten nicht bewältigt werden können. Wie löst man diesen Konflikt? Was sieht die Theorie hier vor? Werden die Anforderungen reduziert? Wird die Länge des Sprints verlängert?
6 Antworten
Die Theorie ist nicht annährend so interessant wie die Praxis von Scrum. Erstere sieht in jedem Fall vor das ein Sprint nicht verlängert wird. Scrum definiert feste Zeiträume und eine vereinbarte Qualität, die einzige Stellschraube ist der Umfang. Im Einverständnis des gesamten Scrum Teams kann entweder der Scope reduziert werden, oder der Sprint abgebrochen.
Praktisch empfiehlt es sich, im Vorfeld genug Aufwand zu investieren, um eine grobe Idee zu haben welche Aufwände vorliegen und dann als Team eher konservativ zu committen. Für das Team sollte das wichtigste Ziel sein, das Sprintziel zu erreichen, nicht so viel Aufgaben wie irgend möglich zu erledigen. Gibt es Risiken aufgrund fehlender Beistellungen sollte eine Story nicht in den Sprint genommen werden bis alles vorliegt.
Kein Problem, wenn das Entwicklerteam zur Hälfte des Sprints Schwierigkeiten hat, die geplanten Ziele zu erreichen. In der agilen Programmierung mit SCRUM geht es darum, flexibel auf solche Situationen zu reagieren.
Zuerst ist es wichtig, die Kommunikation im Team zu stärken. Offenheit ist der Schlüssel. Das Team sollte die Herausforderungen sofort mit dem Product Owner und dem Scrum Master teilen.
Dann könnt ihr die Anforderungen überdenken. Gemeinsam mit dem Product Owner könnt ihr entscheiden, ob weniger kritische Aufgaben aus dem Sprint entfernt werden können, um die wichtigsten Ziele zu erreichen.
Die Länge des Sprints sollte normalerweise nicht geändert werden, um die Planbarkeit beizubehalten.
Übrigens, falls du Interesse daran hast, deine Kenntnisse in agiler Programmierung weiter zu vertiefen und mehr über den Umgang mit solchen Situationen im SCRUM-Kontext erfahren möchtest, könnte diese zertifizierte Kursen für dich von Interesse sein. Dieser Kurs bietet eine vertiefte Auseinandersetzung mit den Herausforderungen und bewährten Methoden im agilen Umfeld und kann dir dabei helfen, deine Fähigkeiten und Verständnis zu erweitern, während du deine berufliche Expertise weiter ausbaust.
Hallo "Wassertuermchen", meiner Meinung nach darf die Länge des Sprints nicht verändert werden. Es erfolgt eigentlich ein sogenanntes "Re-Planning" bei dem der Product Owner (PO) eine Neuausrichtung des Sprints mit den zu dem benannten Zeitpunkt vorhandenen Variablen (Zeit, Personenpower, Ressourcen, Storypoints,...) für den restlichen Sprint neu "justiert".
Vor allem im Bereich der "Agilen Führung" oder "Agilen Organisationsentwicklung" ist dieses immer wieder auf neue Rahmenbedingungen einstellen bzw. nachjustieren eine Kernkompetenz. Viele Infos habe ich dazu erhalten in einem Super Seminar bei campus O. - Schau mal rein unter https://www.campus-o.de/leistungen/seminare-trainings/agile-fuehrung/
Zunächst mal klingt es aussergewöhnlich ist aber der Regelfall.
Im idealfall sind die Stories ohnehin nach Priorität geordnet,
das heisst es ist sichergestellt das die Wichtigsten zuerst angefangen werden.
Wichtig ist bei Scrum es zählt immer was entsprechend Definition of Done fertig ist,
es ist besser 2 Stories Komplett als
5 Stories halb umgesetzt zu haben, stellt also arbeiten ein an Stories die nicht fertig werden zugunsten von Stories die Fertig werden.
Wenn man vor Sprintende absieht das nicht alles fertig ist kann das Team mit dem Product Owner nachverhandeln wie man Aufwand reduzieren kann und welche Stories evtl zugunsten anderer wegfallen.
In der Retrospektive sollte man die Gründe analysieren woran es lag,
manche Teams verschätzen sich manchmal gibt es auch andere Hindernisse die beseitigt werden können.
Die Erkentnisse des letzten Sprints auf jeden fall beim Planen für den nächsten berücksichtigen, also plant weniger oder versucht hinternisse vorher aufzulösen.
Wassertürmchen trifft den Nagel auf den Kopf. Hinter der Forderung der maximalen 40 Stunden-Woche steht der Gedanke, dass jede Zeit danach, dem Projekt nicht zuträglich ist. (Fehlerrate erhöht sich, Burn-Out-Symptome werden wahrscheinlicher, Team-Motivation reduziert sich usw.). Die Nichteinhaltung der 40-Stunden-Woche entspricht nämlich genau dem stark diskutierten Unterchied zwischen Forecast und Commitment. Üblicherweise kann man ein Commitment eher nur dann erfüllen, wenn die 40 Stunden-Woche überschritten wird. Es ist der ewige Kampf zwischen Kontrolle und Vertrauen. Man muss sich halt für eines entscheiden. Wer Scrum wählt, wählt Vertrauen und die Steuerung durch "weiche" Faktoren: Hindernisse aus dem Weg räumen, für gutes Klima im Team sorgen, Team-Zusammenstellung optimieren. Die andere Variante ist die Steuerung durch harte Faktoren: Zeit, Kosten, Qualität.