Sie würden gern in einem festen Rhythmus liefern, aber es kommt immer wieder etwas dazwischen? (Teil 1, Teil 2)
“So kann das nicht rausgehen” – mal wieder zeigen sich gravierende Probleme bei einem Feature, das wir eigentlich für fertig gehalten hatten. Das können Bugs sein, oder Performance-Probleme, oder Missverständnisse bei der Spezifikation. Was auch immer, jetzt müssen wir nacharbeiten, und das gefährdet den Release-Termin, ganz zu schweigen von dem zusätzlichen Stress für das Team.
Machen Sie das Release unabhängig von einzelnen Features. Der Release-Termin ist Feature Nummer 1, er sollte nicht von einem einzelnen Feature über den Haufen geworfen werden können. Nutzen Sie daher Feature-Switches, d.h. Konfigurationseinstellungen, die ein ganzes Feature an- und abschaltbar machen. So können Sie immer noch in letzter Minute die Reißleine ziehen und das unfertige Feature im Release verbergen.
Verlegen Sie die bösen Überraschungen nach vorne. Sobald ein Feature “fertig entwickelt” ist, machen Sie die nötigen Tests. Demonstrieren Sie es dem Fachbereich, um Feedback zur Funktionalität zu bekommen. Bauen Sie regelmäßig das Gesamtsystem zusammen und machen Sie Regressionstests darauf.
Überdenken Sie Ihre “Definition of Done” – ein Feature ist erst fertig, wenn es die Regressionstests bestanden hat, wenn es ein Demo beim Fachbereich gab usw. Wenn das Feature also in diesem Sinne wirklich “Done” ist, sollten die meisten bösen Überraschungen schon hinter uns liegen.
Setzen Sie eine Grenze für die Anzahl an unfertigen Features (WIP limit). Damit wird das Team dazu angehalten, erstmal die späteren Phasen abzuschließen, bevor ein neues Feature angefangen wird.
Eine vereinfachte Variante, die nicht ganz so effektiv ist: Ab einem bestimmten Zeitpunkt, z.B. nach 2/3 des Release-Zyklus, níchts Neues mehr anfangen (einen “Feature Freeze” ausrufen). Damit beenden Sie den Zufluss in den Entwicklungsprozess und gewinnen Spielraum, um sich den bösen Überraschungen zu widmen. Wenn der Zeitpunkt richtig gewählt ist, werden Sie gelegentlich “Leerlauf” haben, d.h. es gibt gerade keine aktuelle böse Überraschung, aber es könnten weitere in unregelmäßigen Abständen folgen. Nutzen Sie diese Zeit für kontinuierliche Verbesserungen, um zukünftige Überraschungen zu verhindern. Sie können etwa automatisierte Lasttests schreiben, oder das Aufsetzen von Testumgebungen vereinfachen u.ä. Wenn dann eine Überraschung kommt, sollten Sie alles stehen und liegen lassen und sofort reagieren.
Gehen Sie den Überraschungen auf den Grund und beheben Sie die Ursachen. Natürlich müssen wir zunächst das akute Problem lösen, also z.B. den Bug fixen. Entscheidend ist, was danach kommt: wenn wir jetzt nicht die Ursachen der Überraschung angehen, wird ein ähnliches Problem im nächsten oder übernächsten Release wieder auftreten.
Fragen Sie also: Was waren die tiefergehenden Ursachen für diese Überraschung? Wie hätten wir das verhindern können? Investieren Sie auf der Stelle etwas Kapazität in die Behebung der Ursachen.
Ich weiß, an diesem Punkt kommen immer Einwände, dass das unrealistisch ist – wir sind schließlich spät dran, einige Ursachen brauchen tage- und wochenlange Entwicklungsarbeit usw. Das verdient eine ausführliche Antwort, die ich gern in einer zukünftigen Email geben will.
Matthias Berth