You are here

Der Agile Release Train

Der Agile Release Train (ART) wird als Begriff zur Beschreibung einer skalierten Auslieferung zur Zeit sehr populär. Das geht sehr stark auf Dean Leffingwell zurück, der sein SAFe-Framework ursprünglich unter ART veröffentlicht hatte.

Was ist der Agile Release Train

Der Agile Release Train verwendet die Metapher eines Zugs, besser einer S-Bahn mit regelmäßigem Takt. Wann immer die Abfahrtszeit der nächsten S-Bahn kommt, fährt sie ab – ob ich eingestiegen bin oder nicht. Ich muss dann eben die nächste S-Bahn nehmen.

Übertragen auf ein größeres Software-Vorhaben heißt das, dass in regelmäßigen Intervallen, z.B. alle drei Monate, ein Release ausgeliefert wird. Jedes Team muss zwei Pläne verfolgen:

  • Entweder seine Funktionalität ist zu diesem Zeitpunkt integriert, es kann also mit der S-Bahn mitfahren. Das ist Plan A.
  • Für den Fall, dass die Funktionalität nicht fertig ist, darf es auf keinen Fall die pünktliche Abfahrt verhindern. Das heißt normalerweise, dass es notwendige Infrastruktur bereitstellen muss und eventuelle API-Änderungen einpflegen muss, um bestehende Funktionalität nicht zu brechen. Das ist Plan B.

Das Problem

Größere Entwicklungen erfordern eine Erweiterung der agilen Praktiken und spezielle Maßnahmen, denn 

  • Der Kommunikationsaufwand nimmt mit der Zahl der beteiligten Personen zu (m*n)
  • Für die Mensch-zu-Mensch-Kommunikation gibt es die bewährte Größe von Team unter ca 10 Personen
  • Bei einer Aufteilung in mehrere Teams entstehen ganz neue Fragen der Koordination zwischen Teams

Software-Praktiken

Durch die beschriebene Aufteilung in mehrere Teams kann man den Mensch-zu-Mensch Teil der Kommunikationsprobleme reduzieren, man hat eine engere Kopplung in den Teams und eine lose Kopplung zwischen den Teams. 

Das lässt eine andere, implizite Kopplung außer Betracht, die genauso viele Auswirkungen hat: das gemeinsame Produkt, in der Software ist das die gemeinsame Codebasis. Mit einer schlechten, eng gekoppelten Codebasis kann man gar nicht sinnvoll kontinuierlich integrieren: jede Änderung birgt die Gefahr, dass man Funktionalität für eines der anderen Teams bricht und man sich damit dauernd gegenseitig „das Standbein wegtritt“.

In der SAFe-Blaupause gibt es dafür eine klare Vorgehensweise:

  • Taktung von Releases, z.B. Im drei-Monats-Rhythmus
  • Ein Release-Planungs-Meeting zu Beginn jedes Release-Zyklus und Abstimmung der Entwicklungsziele der einzelnen Teams für den Release
  • Danach arbeiten die Teams relativ autonom in einem synchronisierten Sprint-Takt von z.B. 2 Wochen
  • Der letzte Sprint vor dem Release-Zeitpunkt ist ein Stabilisierungs- und Integrationssprint, in dem keine neue Funktionalität entwickelt wird.

Wie kann es weitergehen

Es lohnt sich, ein paar Annahmen näher anzusehen, um zu hinterfragen, was man an diesem Ansatz verbessern kann.

Die Grundidee bei der Einführung eines Lean Prozesses kann man in den folgenden zwei Schritten zusammenfassen:

  • Schritt 1: einen stabilen Prozess mit Taktung etablieren
  • Schritt 2: kontinuierliche Verbesserung aufsetzen

Die Blaupause definiert eine valide Lösung für den ersten Schritt. Was könnten Schritte der Verbesserung sein? Man könnte in das kombinierte Arsenal von Scrum und Lean greifen und sehen, was sich davon anwenden läßt:

  • Continuous integration: das ist auf Teamebene ein Muss, sie stellt sicher, dass ein Team jederzeit lieferfähig ist und auch ein valides Mass an Wertschöpfung hat - wie kann man dies auch auf der Integrationeebene möglich machen.
  • Verbesserung der Codebasis durch lose Kopplung. Das ist recht schwierig anzugehen, wenn man es nicht von Anfang der Entwicklung betreibt. Eine interessante Idee ist die Adaption des Open Source-Prinzips: wenn ein Team nicht in der Lage ist für ein anderes eine Anpassung vorzunehmen, dann kann dieses die Codeteile duplizieren und verändern (man muss dabei allerdings laufend beobachten, wo sich neuer Bedarf für Integration und Refactorings ergibt)
  • One-Piece-Flow und Feature Toggles: One-Piece Flow bedeutet, dass ein Team möglichst immer eine User Story fertigstellt und dann mit der nächsten beginnt. Jede Story wird mit einem Feature-Toggle versehen, d.h. sie bis zur Fertigstellung abgeschaltet werden, so  dass sie im Release nicht sichtbar sind. 

Es gibt sicher noch weitere Ideen und Massnahmen, mit denen man sicherstellen kann, dass man jederzeit lieferfähig ist. Führende Organisationen schaffen es, mehrere Deployments täglich auszuliefern, zum Teil parallel in verschiedenen Varianten für einen Teil der Benutzer sichtbar zu machen. Damit wird es möglich, die time-to-market dramatisch zu verkürzen und Risiken zu reduzieren.

Die Taktung im Agile Release Train ist ein dramatischer Fortschritt gegenüber einer klassischen Wasserfall-Entwicklung. Sie sie aber kein statischer Zielzustand, sondern ein Zwischenstand, ein Teil einer Agilen Evolution des gesamten Wertschöpfungsprozesses.

Nachtrag

Ein ziemlich gut dokumentierter Stand von Leffingwells Version findet man in Leffingwells Buch Scaling Agile Development.

Vielleicht helfen meine Notizen für einen schnellen Überblick:

Add new comment