Sprint abgeschlossen, aber nicht alle Features sind fertig: Was nun?
Sprint abgeschlossen, aber nicht alle Features sind fertig: Was nun?
Herausforderungen der Lieferfähigkeit im Scrum-Framework meistern.
Im Sprint-Review-Meeting werden die Funktionalitäten den Stakeholdern gezeigt, die wir im Sprint umgesetzt haben. Es kann aber durchaus vorkommen, dass wir es in einem Sprint nicht ganz schaffen, alle Storys, Tasks und Bugs fertig zustellen. Was passiert dann?
Was passiert, wenn wir eine Funktionalität zum Sprint-Ende nicht liefern können?
Genau diese Frage stellte mir ein Entwickler im Daily-Scrum-Meeting.
Meine kurze Antwort war damals: "Dann wird es nicht im Review gezeigt, weil es nicht fertiggestellt ist."
Im Rahmen eines Workshops hatten wir später ausreichend Zeit, um uns mit verschiedenen grundlegenden Fragen einmal tiefergehend zu befassen. So auch mit dieser.
Sprint-Review verbindet eine Feature-Demo mit einem Workshop
Das Sprint-Review ist eine produktbezogene Rückschau, bei welcher sich das Scrum Team mit den Stakeholdern trifft. Wir schauen zurück auf den letzten Sprint, um zu überprüfen, welcher Wert erzeugt wurde. Dazu präsentiert das Team die verschiedenen fertig gestellten Funktionalitäten, also die Sprint-Ergebnisse.
Wir unterhalten uns nicht über aufgehübschte Powerpoint-Slides und Gantt-Diagramme, sondern wir sprechen über die tatsächlichen Ergebnisse. Dadurch wird nicht nur Vertrauen bei den Stakeholdern aufgebaut, sondern wir haben auch eine ganz andere Grundlage für unser Gespräch.
Die Stakeholder können durch die Demonstration viel besser den aktuellen Stand einschätzen. Sie können uns als Team Feedback geben zu dem, was wir geschaffen haben. Gleichzeitig können sie noch einmal darüber nachdenken, ob es wirklich das ist, was sie haben wollten.
Manchmal gibt es zum Beispiel Kommunikationsprobleme (nicht richtig verstanden, was gemeint war oder nicht nachvollziehbar ausgedrückt) oder auch veränderte Umstände (neue Informationen im Laufe der zwei Wochen), die dazu führen, dass eine Anforderung noch einmal nachgeschärft werden muss. Da wir uns aber alle zwei Wochen zusammensetzen und dieser Zeitraum sehr kurz ist, gibt es in der Regel keine großen Überraschungen.
Wirklich vital wird das Review erst durch seinen Workshop-Charakter. Die Stakeholder stellen Fragen zu den Features oder geben Kommentare und Kontext-Informationen. Wir diskutieren anschließend gemeinsam darüber, wie die Funktion ausgestaltet wird und wo die Reise weiter hingehen soll. Diese Diskussion ist sehr wichtig für das gemeinsame Alignment und das Gefühl an einem Strang zu ziehen.
Als Ergebnis dieser Diskussion haben wir unsere Anforderungen überprüft und miteinander abgeglichen. Möglicherweise haben wir neue erstellt. Wir haben herausgefunden, ob sich etwas bei den Stakeholdern geändert hat, was Einfluss auf unsere nächsten Sprints haben könnte. An diese neuen Informationen passen wir unseren Produkt-Backlog an.
Aber zurück zur ursprünglichen Frage.
Abschätzen von unvorhergesehenen Herausforderungen
Natürlich wollen wir es gar nicht so weit kommen lassen, dass wir eine Funktionalität nicht liefern und präsentieren können. Schließlich nehmen wir uns ausreichend Zeit, um die Arbeit im Refinement und im Planning gründlich vorzubereiten.
Wir versuchen so gut es geht, alle Unwägbarkeiten für die zwei folgenden Sprint-Wochen vorherzusehen. Aber jeder weiß, wie das mit der Realität nun einmal so ist: die Dinge verändern sich. Während des laufenden Sprints aktualisieren wir deshalb jeden Tag unseren Sprintplan im Daily Scrum Meeting, um geänderten Umständen gerecht zu werden.
Nach dem Daily arbeiten wir wieder am Code. Was passiert jetzt, wenn wir, während wir entwickeln, plötzlich feststellen, dass wir noch eine ganz andere Komponente anfassen müssen, um das Feature fertigstellen zu können? Wir haben nicht daran gedacht, sondern erst die Arbeit mit dem Code hat das aufgedeckt. Wir haben die Komplexität des Features nach besten Wissen und Gewissen geschätzt. Dabei gab es aber Unbekannte und durch diese haben wir den Umfang falsch antizipiert.
Wahrscheinlich hat jeder Entwickler schon einmal diese Erfahrung gemacht? Diese Erfahrung kann verstärkt dann auftreten, wenn man als Team eine oder mehrere Komponenten eines anderen Teams übernommen hat und sich noch nicht so tief darin einarbeiten konnte. Oder wenn man als Team eine sehr große Anzahl von Komponenten betreuen muss, sodass man gar nicht alle wirklich gut überblicken kann.
Zugegeben, wir sollten Komplexität niemals als Ausrede dafür verwenden, unser Zeug nicht zu beherrschen. Aber manche Sachen kann man einfach schwer vorhersehen. Das ist die Natur von komplexen Aufgaben. Es gibt immer eine Unsicherheit.
Überprüfen und anpassen auf dem Weg zum Review
Wie dem auch sei. Was passiert nun mit dem Review?
Wir sind noch mitten im Sprint und haben noch ein paar Tage Zeit. Wir haben unsere formalen Inspect-and-Adapt-Gelegenheiten, die Scrum Events, genutzt, um Unwägbarkeiten zu identifizieren und wollen angemessen darauf reagieren.
Zunächst versuchen wir das Feature in Zusammenarbeit mit unserer Product Ownerin neu zu schneiden. Wir könnten bestimmte Bestandteile in dieser Iteration herausnehmen, sodass die Funktion für unsere Kunden trotzdem noch eine Wertsteigerung darstellt. Dann machen wir aus einem Feature zwei. Das neue würden wir dann im nächsten Sprint entwickeln und das erste zeigen wir im kommenden Review.
Wenn das Neuschneiden nicht möglich wäre, dann würden wir zurückkommen zur kurzen Antwort: Wir zeigen es nicht im Review Meeting.
Lernen und Verbessern durch Reflexion
Direkt nach dem Review-Meeting findet die Retrospektive statt. Als letztes Event bildet sie den Abschluss des Sprints. Dort reflektieren wir, was im Sprint alles gut lief und welche Praktiken wir beibehalten sollten.
Natürlich lenken wir unseren Fokus auch auf das, was nicht gut lief, woran wir arbeiten und was wir verbessern können. Das Beispiel mit der übersehenen Komponente werden wir dort wieder aufgreifen.
Sicherlich können wir auch auf die Motivation hinter der ursprünglichen Frage schauen. Was passiert denn mit uns als Team, wenn wir nicht liefern können? Könnte hinter der Frage auch die Vermutung stecken, dass man mit Schuld, Strafe oder persönlichen, negativen Konsequenzen rechnen muss? Schließlich ist diese Art von Denken in vielen Kulturen verankert.
Nein, es geht nicht um Beurteilung und Strafe, sondern es geht in erster Linie um Lernen und um Verbesserung. Es geht um kontinuierliches Wachsen, um konstante Veränderung hin zum besseren.
Bei Belohnung und Strafe geht es oft um das Wollen. Es geht um den Glauben, dass die Motivation des Mitarbeiters verbessert und er von außen motiviert werden müsste. Ich habe jedoch die Erfahrung gemacht, dass die Kollegen in unseren Teams oft sehr stark motivierte Menschen sind. Sie müssen nicht von außen motiviert werden, sondern sie wollen aus sich selbst heraus einen guten Job machen. Das macht die Arbeit an sich ziemlich cool.
Aber trotzdem kommt es vor, dass eine Funktionalität nicht geliefert werden kann. Wenn es nicht an der Motivation, also an dem Wollen, liegt, dann geht es um das Können. Wir reden hier von wirklich gut ausgebildeten Kollegen. Wenn sie ihre Fähigkeiten nicht auf die Straße bringen können, dann liegt es oft daran, dass irgendwo Steine im Weg liegen.
Diese Hindernisse zu identifizieren und aus dem Weg zu räumen, ist die große Krux. Wenn wir die Hindernisse beseitigen, dann verbessern wir unseren Prozess und unsere Fähigkeit zu liefern. Wenn wir im Sprint lernen, unsere Lieferfähigkeit zu verbessern, dann werden wir beim nächsten Mal die Funktion auch liefern können.