safe big picture

Das Scaled Agile Framework (SAFe) beruht auf dem Agile Release Train und verwendet dabei 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. Ursprünglich wurde diese Metapher für einen Liefertakt verwendet, inzwischen ist es ein Planungstakt - ausgeliefert wird idealerweise kontinuierlich, d.h. so oft wie möglich.

Übertragen auf ein größeres Software-Vorhaben heißt das, jedes Team muss zwei Pläne verfolgen:

  • Seine Funktionalität so früh wie möglich integrieren, also mit der nächsten S-Bahn mitfahren - Plan A.
  • Für den Fall, dass die Funktionalität nicht fertig ist, darf es auf keinen Fall die pünktliche Abfahrt verhindern, d.h. dass es die notwendige Infrastruktur bereitstellen und eventuelle API-Änderungen einpflegen muss, um die bestehende Funktionalität nicht zu brechen - Plan B.

Dies bedeutet, daß eine Erweiterung der agilen Praktiken und spezielle Maßnahmen notwendig sind, denn

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

Durch eine 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 oder auch nur häufig ausliefern: 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 SAFe gibt es dafür eine klare Vorgehensweise:

  • Taktung von Planungen, z.B. im 3-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 in einem synchronisierten Sprint-Takt von z.B. 2 Wochen und integrieren die Ergebnisse kontinuierlich
  • Im letzten Sprint eines Release-Zeitpunkts wird keine neue Funktionalität entwickelt, er dient der Planungsvorbereitung und der Innovation.

SAFe definiert jedoch nur eine valide Lösung für den ersten Schritt. Um zu einer optimaleren Lösung zu kommen, bedarf es weiterer Ideen und Maßnahmen, 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.

Das aktuelle Buch zu SAFe 4.5 "SAFe - Das Scaled Agile Framework, Lean und Agile in großen Unternehmen skalieren" von Christoph Mathis, gibt einen praxisorientierten Überblick über Struktur, Rollen, Schlüsselwerte und Prinzipien von SAFe. 

safe buch christoph mathis