Fallstudie: Agil mit Continuous Delivery statt SAFe

In dieser Fallstudie geht es um ein Unternehmen, dass mehrere Jahre versucht hat, mithilfe des Scaled Agile Framework (SAFe) das Unternehmen agiler zu machen — leider ohne Erfolg. Der Durchbruch kam, als Continuous Delivery als Treiber für die Transformation eingesetzt wurde.

Auch wenn es in diesem Fall um ein reines Softwareprojekt ging, so können die hier gelernten Erkenntnisse auch im Systems Engineering angewendet werden.

In eigener Sache: Bitte nimm an unseren KI-Umfragen zum Anforderungsmanagement teil (geht schnell): Umfrage 2 >> | Umfrage 1 >> | Ergebnisse

Die Fallstudie

Die vollständige Fallstudie ist bei InfoQ unter dem Titel Agile Rehab: Replacing Process Dogma with Engineering to Achieve True Agility zu finden. Geschrieben wurde sie von Bryan Finster, einem Berater, der viel mit Continuous Delivery im Bereich Security gearbeitet hat.

In dem Unternehmen, um das es geht, wurden die Dinge auch nach Jahren der „Agilen Transformation“ mit dem Scaled Agile Framework (SAFe) nicht besser, sondern eher schlechter. Daher führte Änderungen zur Einführung von Continuous Delivery (CD) vornahmen, was letzten Endes zum Durchbruch führte.

Bryan nennt weder den Kunden noch das Produkt. Es handelt sich jedoch um ein internes Enterprise-Softwaresystem, das aus dem Verschmelzen von insgesamt vier Legacy-Systemen entstanden war und aus ca. 25 Millionen Zeilen Code bestand (ohne Kommentare).

Die Architektur „Spaghetti“ zu nennen, wäre eine schwere Beleidigung für Nudeln.

Das Hauptproblem: Geschwindigkeit

Bryan konnte das Problem vor der Einführung von CD erschreckend gut quantifizieren:

• 12 Monate: Die Vorlaufzeit für die Bereitstellung einer neuen Fähigkeit für das Unternehmen
• 3–4 Mal pro Jahr: Auslieferung neuer Features
• 3 Tage: Die Mindestzeit für die Umsetzung einer Änderung, egal wie klein (eine Zeile Code)

Die Möglichkeit, täglich liefern zu können, verbesserte die Geschäftsergebnisse und die Moral des Teams. Das ist eine menschlichere Art zu arbeiten.

Bryan Finster

Architektur: Herunterskallieren und Entkoppeln

Das System musste refactored werden. Dazu nutze das Team Domain Driven Design, um die geschäftlichen Funktionen zu entwirren. Die Teams wurden ebenfalls entsprechend organisiert, im Einklang mit Conway’s Gesetz.

Um die Teile des Systems zu entkoppeln, begannen die Teams, Contract Driven Development (CDD) einzuführen, wodurch die Schnittstellen stabil und verlässlich wurden. Dadurch wurden die Release-Zyklen der Teams unabhängig voneinander. Dieses Vorgehen revolutionierte die Entwicklung, sowohl im konsumierenden als auch im bereitstellenden Team. Bei der Einführung von neuen Features wurde zuallererst die Schnittstelle definiert und getestet, bevor der Rest implementiert wurde.

In 18 Monaten zum ersten täglichen Release mit CD

Bis das erste Pilotprojekt in der Lage war, tägliche Releases durchzuführen, vergingen 18 Monate. Doch tägliche Releases sind absolut essentiell für agiles Arbeiten: Wie können wir behaupten, agil zu sein, wenn es zwei oder mehr Wochen dauert, eine Idee zu validieren? Continuous Delivery ist auch ein Befähiger für viele andere Praktiken und Dinge:

• Continuous Delivery erzwingt die Einführung von Continuous Integration (CI).
• CI wiederum erfordert, dass Verifizierung (Tests) Teil des Releases sind.
• Damit Tests Teil eines Releases sind, muss schon bei der Entwicklung (automatisiert) getestet werden.
• Um frühzeitig Testen zu können, müssen die Anforderungen präzise sein.
• Das wiederum zwang das Team dazu, die geschäftlichen Anforderungen zu verstehen und die Unklarheiten bei den Abnahmekriterien unerbittlich zu beseitigen.

Für den Betrieb optimiert

Sämtliche Abläufe müssen primär für den Betrieb ausgelegt sein, um diesen nicht zu gefährden. Daher bleiben auch bei Betriebsproblemen die Abläufe bestehen und dürfen nicht umgangen werden. Die Pipeline liefert alle Änderungen deterministisch und mit allen Validierungen, um sicherzustellen, dass ein Artefakt „veröffentlichungsfähig“ ist. Ein gut gestalteter Prozess mit effizienten Tests gewährleistet sichere Notfallkorrekturen. Ein weiteres wichtiges Prinzip war, dass jede Komponente ohne die Integration des gesamten Systems lieferbar sein muss. End-to-End-Tests wurden durch schnellere und präzisere virtuelle Services ersetzt, wodurch Probleme schneller erkannt und behoben werden konnten.

Code ist besser als Prozesse

Das Team hat festgestellt, dass Code (in der Form von Automatisierung) einen ähnlichen Zweck erfüllt wie Prozesse, aber wesentlich effizienter ist.

Wenn Teams Abhängigkeiten mit Code behandeln, dann ist PI-Planung (Program Increment-Planung) überflüssig. PI-Pläne sind statisch, Code ist dynamisch

Bryan Finster

Roadmaps werden anhand der Ergebnisse angepasst. Wenn wir Tage mit Planung zu verbringen, um Abhängigkeiten mit dem Prozess verwalten und die Teams zu synchronisieren, bedeutet das, dass jedes Team im Tempo des langsamsten Teams liefert. Entkopplung und Dezentralisierung befreien die Teams: Die Kosten sinken, die Entwicklungsschleifen verkürzen sich, die Mitarbeitenden sind zufriedener.

Die Bedeutung von Metriken

Messen ist essentiell, um den eigenen Fortschritt zu bewerten und um Entscheider zu überzeugen. Gerade bei Änderungen im Management ist es wichtig, den eigenen Erfolg nachweisen zu können. Bryan ist dabei ein gebranntes Kind, denn er war in Situationen, wo das Management andere Ideen hatte, die er ohne Metriken nicht stoppen konnte. Das Ergebnis: Die Qualität und Moral verschlechterten sich, gute Mitarbeiter verließen das Team.

Continuous Delivery ist auch im Systems Engineering möglich

Auch im Bereich des Systems Engineering, wo Software, Mechanik und Elektronik in komplexen Systemen zusammenkommen, ist Continuous Delivery möglich, wenn auch ein gutes Stück schwieriger. Schwieriger, jedoch nicht unmöglich. Schon vor über zehn Jahren hat Joe Justice mit Wikispeed Pionierarbeit geleistet, die er später bei Tesla, SpaceX und Mercedes umgesetzt hat.

Fazit

Bryan Finster zeigt in dieser Fallstudie auf beeindruckende Weise, dass Automatisierung ein wichtiger Enabler für Agilität ist. Aus der Softwareentwicklung, wo Unternehmen wie gitHub täglich bis zu Tausend Releases veröffentlichen, sind die Techniken und Best Practices längst bekannt. Es wird Zeit, dies auch verstärkt im Systems Engineering anzuwenden.