Scaled Agile: Release Trains

Bild: Wikimedia Commons / David Gubler - CC BY-SA 3.0

[Edit: Da dieser Artikel immer wieder für Irritationen sorgt - er beschreibt weder die Release Train-Variante von SAFe noch die Ursprungs-Variante, sondern die mit der ich zur Zeit der Verfassung beschäftigt war. Der Begriff hat mehr als eine Bedeutung.]

Die Idealwelt ist die von der man hört wenn von Netflix, Zalando und Spotify die Rede ist. Statt einer großen, monolithischen Anwendung gibt es viele kleine Module (Microservices), die unabhängig voneinander deploybar sind und ihren Teams dadurch hohe Autonomie sichern. Die Realität ist häufig eine andere - Microservices existieren nicht (oder sind ungünstig geschnitten), so dass es doch dazu kommt, dass verschiedene Teams ihre Features gemeinsam auf Produktion bringen müssen. Wie passt das zu agiler Softwareentwicklung?

Der typische Management-Reflex ist "Koordination", womit in den meisten Fällen gemeint ist, dass ein koordinierender Manager eingesetzt wird, der den Teams vorgibt wann sie was fertigzustellen haben. In der Theorie sorgt das dafür, dass zusammengehörende Features gleichzeitig fertigwerden, in der Realität ist das leider seltener der Fall. Eher kommt es hier zu den aus dem Wasserfall bekannten Effekten: es passieren ungeplante Entwicklungen, die Geschwindigkeiten der Teams laufen auseinander, es kommt zu Leerlauf, Merge-Konflikten, etc.

Es könnte auch anders laufen, und um zu wissen wie braucht man nur auf einen ähnlichen Fall zu schauen - auf zu erreichende Deadlines. Auch damit können agile Teams zurechtkommen indem sie auf Komfortfunktionen verzichten, einfache Lösungen bevorzugen oder auf andere Art den Scope reduzieren. Ein langsameres Team kann auf diese Weise seinen zeitlichen Rückstand wieder aufholen. Umgekehrt kann gegebenenfalls das schnellere Team einen Gang zurückschalten und mehr Zeit in Refactoring, Bugfixing oder Wissenstransfer stecken, auch dadurch erreichen alle gleichzeitig den gemeinsamen Release-Zeitpunkt.

Als Analogie bietet sich der Bahnverkehr an: wenn in Hamm die Züge aus Duisburg und Köln zusammengekoppelt werden sollen, dann kann der langsamere (in diesem Fall aus Duisburg) schlimmstenfalls einen der vielen Stops im Ruhrgebiet ausfallen lassen, etwa den in Bochum. Umgekehrt könnte der schnellere (in diesem Fall der aus Köln) auch einen Zusatzhalt in Dortmund einlegen. In beiden Fällen würden beide gleichzeitig ankommen und gemeinsam ihre Fahrt nach Berlin fortsetzen.

Bleibt nur die Frage: könnte das nicht auch von einem koordinierenden Manager orchestriert werden? Nur bedingt. Da es erfahrungsgemäß nicht nur zu einer ungeplanten Entwicklung kommt sondern zu mehreren müssen im Zweifel alle beteiligten Teams permanent (in Scrum jeden Sprint, d.h. alle 1 bis 4 Wochen) Korrekturen vornehmen, das mit den Stakeholdern und anderen Teams abstimmen und die Planungen entsprechend aktualisieren. Schon bei zwei Teams wäre das für einen Koordinator eine Herausforderung, bei noch mehr Teams kaum zu schaffen.

Direkt miteinander kommunizierende autonome Teams können sich dagegen ohne Entscheidungs-Engpässe oder Stille Post-Effekte abstimmen und jedes für sich Kurs und Geschwindigkeit so anpassen, dass Vorsprünge und Verspätungen sich ausgleichen. Das Zusammenkoppeln kann dann reibungsloser stattfinden und der gemeinsame "Release-Zug" Fahrt aufnehmen.