Sie würden gern in einem festen Rhythmus liefern, aber es kommt immer wieder etwas dazwischen? Gestern haben wir zwei mögliche Ursachen dafür besprochen: Der Zeitaufwand für Features wird unterschätzt, und einige Features brauchen so lange, dass sie nicht in einen Release-Zyklus passen.
Ein schwerwiegender Bug hat sich im Produktivbetrieb gezeigt und muss unbedingt noch behoben werden. Wir haben uns zu einer Kooperation verpflichtet und müssen die entsprechenden Anpassungen am Webshop innerhalb von zwei Wochen machen. Solche Prioritätsverschiebungen in letzter Minute können den besten Release-Plan über den Haufen werfen.
Scrum ist da ganz rigoros: Wir fixieren am Anfang der Iteration (Sprint), was gemacht werden soll. Wer nach dem Start der Iteration ein neues Feature X haben will, hat zwei Optionen: (1) Sich bis zur nächsten Iteration gedulden, oder (2) die laufende Iteration abbrechen und mit Feature X eine neue Iteration starten.
Eine Option (3) – wir schieben Feature X irgendwie dazwischen – gibt es nicht, egal wieviel Druck in dieser Richtung aufgebaut wird. Meist kühlen sich die Gemüter dann schnell ab, man geduldet sich noch etwas, weil Option (2) zu drastische Auswirkungen hätte.
Genauso können Sie es natürlich auch mit einem Release halten: “Nichts geht mehr”, den Relase-Termin zu halten, ist wichtiger als Feature X.
Die weichere Variante dazu: bieten Sie an, das neue Feature gegen ein oder mehrere andere auszutauschen. Machen Sie ganz klar, welche Kosten damit verbunden sind: “OK, wir könnten Feature X noch in diesem Release machen. Dafür müssten wir Features A und B opfern. Der bisherige Aufwand für A und B wäre so gut wie verloren, weil sich die Entwickler im nächsten Release wieder quasi von vorn einarbeiten müssen. Sollen wir das wirklich so machen?” Für solche Diskussionen ist es natürlich hilfreich, wenn Sie eine visuelle Übersicht zum Inhalt des Releases zur Hand haben, z.B. ein Kanban-Board.
Es lohnt sich, den Ursachen für dringende Last-Minute Anforderungen nachzugehen.
Warum wird oft soviel Druck gemacht? Können die Leute mit ihren Wünschen nicht bis zum nächsten Release warten? Es kann einfach daran liegen, dass Ihre Release-Zyklen so lang sind. Wenn Sie z.B. nur alle drei Monate liefern, wird jede Anforderung automatisch um mindestens drei Monate verzögert. Wenn Sie dagegen jede Woche liefern, fällt es leichter, sich noch etwas zu gedulden. Wenn ich die U-Bahn in Hamburg verpasse, ist das meist nicht so schlimm: in 5 Minuten kommt die nächste. Aber wehe, wenn ich den Flug von Rostock Laage nach Teneriffa verpasse: der geht nur einmal pro Woche.
Woher kommen die unerwarteten Anforderungen? War es ein Bug, der z.B. im vorigen Release eingebaut wurde? Dann sollten wir z.B. in Regressionstests investieren. Oder war es eine Anforderung, die wir einfach nicht auf dem Zettel hatten, als wir das Release planten? Dann waren eventuell nicht alle relevanten Stakeholder bei der Planung vertreten, oder wir haben uns nicht genug Beispiele geben lassen.
Kanban bzw. Lean Software Development behandelt Last-Minute Anforderungen so: Idealerweise ist der Software-Lieferprozess stabil, d.h. man kann Zusagen machen wie: “95% der Anforderungen brauchen bei uns weniger als 10 Tage, bis sie produktionsreif sind”. Meist reicht das – wenn der Release-Termin erst in 14 Tagen ist, starten wir Feature X morgen und sind ziemlich sicher, dass es im Release landen wird.
Wenn diese Zusagen nicht ausreichen, kann man eine gesonderte Überholspur (Priority Lane) im Kanban-Board einrichten. Sobald ein Feature auf der Überholspur ist, wird es bevorzugt bearbeitet. Im Extremfall können Sie die Regel aufstellen, dass ein Feature auf der Überholspur alle Arbeiten in dieser Phase unterbrechen kann. Etwa so wie ein alle Autos anhalten müssen, sobald ein Krankenwagen mit Blaulicht vorbeifahren will. Für die Überholspur ist es besonders wichtig, ein WIP-Limit einzurichten, damit die übrige Arbeit nicht total chaotisch wird. So kann man etwa sagen, dass es nur maximal zwei Tickets auf der Überholspur geben darf, über alle Phasen der Software-Lieferung hinweg.
Wenn es häufig solche Last-Minute Anforderungen gibt, verschlechtert sich die Durchlaufzeit der übrigen Anforderungen – wenn einer in der Warteschlange vordrängelt, müssen alle anderen etwas länger warten. Die regelmäßige Evaluierung der Durchlaufzeiten ist im Kanban-Prozess eingebaut, sie wird dieses Problem früher oder später offensichtlich machen. Das sollte dann den Anstoß geben, die Last-Minute Anforderungen durch kontinuierliche Verbesserung zurückzudrängen.
Morgen gibt es die vorläufig letzte Email zum Thema “Regelmäßig liefern”, dann geht es um böse Überraschungen, die gegen Ende des Release-Zeitraums auftreten.
Matthias Berth