Cost of Delay (4): Verzögerungskosten durch die Verzögerung des Starts

Wie Fred Brooks in seinem berühmten Buch "The Mythical Man-Month" so weise sagte: "Wie kommt ein Projekt ein Jahr in Verzug? … Ein Tag nach dem anderen."

Mehr Infos

Cost of Delay

• Verzögerungskosten durch Perfektion
• Verzögerungskosten aufgrund von Experten
• Verzögerungskosten durch die Wiederholung des Falschen
  

Manchmal wird ein Projekt ewig nicht gestartet, da eine Entscheidung fehlt. Und manchmal wurde die Entscheidung für das Projekt zwar frühzeitig getroffen, aber das Team zögert, wirklich zu starten. Es gibt einige grundlegende "Smells", die auf die Verzögerung des Starts hinweisen:

• Sprint null: Er wird vor allen anderen regulären Sprints eingeplant, um vorzubereiten, was immer vorbereitet werden muss (z. B. das Product Backlog, die Infrastruktur etc.). Das heißt, Teams verlangen nach einem Sprint Null, weil sie (glauben) dies und das vorbereiten (zu) müssen, bevor sie wirklich starten können. Darüber hinaus wird der Sprint null oft verlängert – dadurch dauert dieser Sprint meist tatsächlich länger als alle anderen folgenden Sprints. Anstatt den Sprint null zu verlängern, gibt es manchmal auch mehrere Sprint null. Das Konzept des Sprint null ist häufig eine Entschuldigung dafür, nicht starten zu müssen und nicht direkt zu liefern. Natürlich gibt es Fälle, in welchen man vorab Dinge aufsetzen muss. – Aber was ist der Grund dafür, nicht auch die Vorbereitungsarbeit als Lieferung zu betrachten und dafür die Brauchbarkeit und Funktionsfähigkeit der Vorbereitung darüber hinaus nicht auch durch die Lieferung einer (sehr) kleinen Funktionalität zu verifizieren?
• Definition of Ready (siehe hierzu auch Ausrede DoR): Sie ist eine Übereinkunft über die Definition oder Beschreibung einer Story (das könnte auch auf reguläre Anforderungen zutreffen), sodass die Entwickler genug wissen. um die Funktionalität implementieren zu können. Das Verlangen nach einer Definition of Ready untergräbt die ursprüngliche Idee der Agilität, dass eine Story ein Versprechen für ein Gespräch ist. Ein Gespräch über die Funktionalität, sobald diese adressiert werden soll. Das heißt, ursprünglich war eine Story eine Art Gutschein, der sicherstellte, dass die Fach- und die Entwicklungsseite sich über die nachgefragte Funktionalität im Gespräch austauschte. Die Definition of Ready hingegen wird häufig von Entwicklern verwendet, um nicht an einer Story zu arbeiten, da diese nicht auf eine "akzeptable" Weise beschrieben wurde. Das heißt, anstatt über die Funktionalität gemeinsam zu diskutieren und diese zu implementieren, werden jetzt Stories mehrfach "über die Mauer" zwischen der Fach- und der Entwicklungsseite geworfen. Das führt offensichtlich dazu, dass die Funktionalität später als gedacht geliefert wird.

Beide Prinzipien – Sprint Null und Definition of Ready sind tatsächlich Verzögerungstaktiken und erzeugen dementsprechend Verzögerungskosten. Bevor Sie das nächste Mal einen Sprint null starten, denken Sie deshalb darüber nach, ob dieser wirklich notwendig ist. Und wenn er notwendig ist, definieren Sie ein Ziel und Akzeptanzkriterien auch für diesen Sprint, wie Sie es auch für jeden anderen Sprint tun. Eventuell hilft es auch, diesen Sprint nicht Sprint null zu nennen, sondern Sprint eins. So wird es einfacher, mit dem Erreichen des Sprintziels auch etwas zu liefern. Falls Ihr Team nach einer Definition of Ready fragt, diskutieren Sie im Team, welches Problem mit dieser Definition gelöst werden soll. Und reflektieren Sie auch darüber, warum die Fach- und die Entwicklungsseite eigentlich nicht gemeinsam an den Stories arbeiten kann.

So stellen Sie sicher, dass der Start nicht verzögert wird – weder der Start des Projekts noch der Implementierungsstart jeder einzelnen Story. ()