Scaled Agile: Release Trains (II)

Bild: Pixabay / Annca Pictures - Lizenz

Die grosse Skepsis mit der die agile Community SAFe betrachtet hat dazu geführt, dass auch viele der mit diesem Skalierungs-Framework in Verbindung gebrachten Ideen abgelehnt werden. Das ist in den meisten Fällen bedauerlich, schliesslich wurde fast nichts von SAFe selbst erfunden sondern so gut wie alles aus anderen Kontexten übernommen, in denen die Umsetzung deutlich näher am agilen Idealbild war. Ein Beispiel an dem man das gut nachvollziehbar machen kann ist der Release Train.

In seinem Kern beruht dieses Konzept auf einer frühen Vor-Form von Continuous Delivery. Die ursprünglich üblichen Quartals- oder Jahres-Releases sollten vermieden werden, gleichzeitig waren automatisierte Build Pipelines und Continuous Integration zum Entstehungszeitpunkt der Release Train-Idee noch wenig verbreitet. Die Lösung für dieses Problem waren regelmässige (wöchentliche oder monatliche) Releases, die jeweils alles enthielten was zu diesem Zeitpunkt fertig entwickelt war.

In diesen regelmässigen Releases waren verschiedene relativ langwierige Vorgänge enthalten, die nicht unterbrochen oder übersprungen werden durften wenn die Qualität des Ergebnisses sichergestellt sein sollte, etwa das Konfigurieren von Staging-Umgebungen, das Einspielen von Testdaten, das Durchführen automatisierter und manueller Tests, etc. Für alle Features die zum Release-Zeitpunkt noch nicht fertig entwickelt waren war daher "der Zug abgefahren". Aus diesem Bild entstand dann die Benennung.

Aus heutiger Sicht erscheint das alles nur eingeschränkt agil (die aktuelle Benchmark sind beliebig viele Releases pro Tag), in der damaligen Zeit (frühe 2000er Jahre) war es dagegen revolutionär und verhalf Unternehmen wie Yahoo, Netscape, AOL, eBay und Google zu ihren damals marktbeherrschenden Positionierungen. Es gibt Vermutungen, dass Release Trains ursprünglich von eBay erfunden wurden, wozu passen würde, dass zu den frühesten Quellen der ehemalige eBay-Manager Marty Cagan gehört.

In bestimmten Konstellationen können Release Trains sogar heute noch Sinn machen, z.B. überall dort wo Regressionstests mehrere Stunden oder Tage dauern können (ein typischer derartiger Fall wäre die Embedded Software von autonomen Fahrzeugen oder Robotern, deren Testzyklus-Dauer durch die maximale Fahrtgeschwindigkeit und durch die Menge der möglichen Navigations-Manöver bestimmt wird und dadurch ggf. sehr lange sein kann).

Interessant und kontrovers ist schliesslich die Frage ob es in Release Trains spezifische Management-Rollen geben sollte. Im oben verlinkten Marty Cagan-Artikel aus dem Jahr 2007 ist allgemein von Projektmanagern und spezifisch von der Rolle des so genannten Conductor (Schaffner) die Rede, in SAFe gibt es den Release Train Engineer (Lokführer). Aus einer "agilen Perspektive" sollte man den beteiligten Teams dagegen zutrauen sich unkompliziert selbst zu koordinieren.

Leider drehen sich mittlerweile die meisten Release Train-Diskussionen nur noch um diesen Aspekt, bis zu dem Punkt, dass (SAFe-) Release-Trains heute primär über ihre Koordinations-Rollen und -strukturen definiert (und wegen ihnen abgelehnt) werden. In den Vordergrund zu stellen wie die Idee eigentlich gemeint ist könnte dabei helfen die Debatten wieder fokussierter und zielführender zu machen.