The final Countdown

Bild: Wikimedia Commons/Jhong Dizon - CC BY 2.0

Da das Jahr fast zu Ende ist, einige Überlegungen zum Thema "nahende Deadline". Auch in Scrum oder anderen agilen Vorgehensweisen gibt es fixe Liefertermine, zum Beispiel wenn sich die Software ab dem ersten Januar anders verhalten muss um konform zu neuen Gesetzen oder Vorschriften zu sein. Und auch hier kommt es immer wieder vor, dass einige Sprints vor dem Termin absehbar ist, dass sich nicht alles umsetzen lässt was geplant ist. Wie soll man damit umgehen?

Ein verbreiteter Weg besteht darin, das Ergebnis zu "erzwingen". Die Teams werden angewiesen ihre Velocity zu steigern oder ihre Durchlaufzeit zu verringern und zu diesem Zweck Überstunden zu machen, ausserdem gibt man sich mit Umgehungslösungen und halbfertigen Funktionen zufrieden, solange alles "irgendwie funktioniert". Das kann kurzfristig zum Ziel führen, bringt aber mittel- und langfristig die bekannten Probleme:

• überarbeitete Mitarbeiter machen mehr Fehler
• die werden aufgrund der fehlenden Zeit nicht alle korrigiert
• die Anwendung geht mit Notbehelfen in die Produktion
• weitere Fehler werden gar nicht entdeckt, da die Zeit nicht für das Schreiben der Tests gereicht hat
• das nachträgliche Fehlerbeheben und das Ersetzen der Provisorien erweist sich als aufwändiger als gedacht

Am Ende sind Aufräumarbeiten nötig, die sich über Monate ziehen können. Als Nebeneffekt kann ausserdem die Selbstorganisation der Teams schweren Schaden nehmen, wenn diese immer dann "wenn es dringend ist" in den Modus von Befehl und Gehorsam zurückmüssen.

Ein besserer Weg ist der, das Team in die Entscheidungen mit einzubeziehen. Das kann z.B. in Form einer offenen Fragestellung passieren: "Das hier sind die Vorschriften, die zum Stichtag erfüllt sein müssen, das ist die Zeit die wir noch haben - was müssen wir tun um am Tag X das gewünschte Ergebnis zu haben?" Ich selber habe mit diesem Vorgehen sehr gute Erfahrungen gemacht, allerdings bedarf es dazu bestimmter Bedingungen und Voraussetzungen:

• Das Team muss ein gutes fachliches Verständnis des Produktes haben
  Nur wer das große Bild im Kopf hat kann überhaupt wissen was verzichtbar und was unverzichtbar ist. Wer bisher "an der kurzen Leine gehalten wurde" hat dieses Verständnis in der Regel nicht, und um es kurz vor Ende aufzubauen fehlt die Zeit.
• Der Product Owner oder Auftraggeber muss bereit sein, auf bereits geplante Features zu verzichten
  Von der Komfortfunktion über den "machen wir immer so"-Workflow bis hin zum Lieblings-Gadget des IT-Chefs - alles was nicht zwingend zum kleinstmöglichen Funktionsumfang gehört muss rausfliegen. Wenn es wirklich so wichtig ist kann es in einem späteren Release nachgeholt werden.
• Das Team muss (zumindest in dieser Phase) an einem Ort versammelt sein
  Nichts frisst Zeit und Effektivität in vergleichbarem Ausmaß auf wie langsame und schlechte Kommunikation. Unter Termindruck ist schlicht keine Zeit für unverständliche Telefonkonferenzen, langwierigen Email-Verkehr oder wackeliges Screen-Sharing.

Und wenn so etwas einmal geklappt hat kann das auch einen grundsätzlichen Aha-Effekt bedeuten. Die genannten Punkte machen nämlich auch im Normalbetrieb Sinn, selbst wenn es gerade mal keinen Zeitdruck gibt.