Scaled Agile: 7 Praxistipps für die SAFe-Implementierung

Read this article in English.

SAFe-Einführung – die Basis

Bevor wir uns den Praxistipps zuwenden, ist es wichtig, noch einmal auf ein paar kritische Stadien der Implementierung hinzuweisen. Es gibt einige notwendige Schritte, die für die Transition unverzichtbar sind – speziell dann, wenn eine Organisation sich anschickt, SAFe von Grund auf einzuführen und dabei nicht auf externe Unterstützung zurückgreifen will:

  • Training der Mitarbeiter zu den Prinzipien der agilen Entwicklung
  • Training des Ausführungsteams zu den Lean-Agile-Prinzipien des Managements
  • Bildung funktioneller Teams, die mit Scrum und/oder Kanban vertraut sind

Wenn diese Voraussetzungen gegeben sind, folgen weitere Evaluationen und Aktionen:

  • Identifizieren der Wertströme und Agile Release Trains (ART)
  • Etablierung der ARTs (sofern sie nicht schon aufgesetzt sind), um die identifizierten Wertströme zu realisieren
  • Ausrollen weiterer ARTs, Erweiterung auf das Portfolio und Wiederholung für alle andere Teile des Unternehmens.

Mehr Details zu diesen Implementierungsvoraussetzungen finden Sie im Blog-Beitrag Das Einmaleins der SAFe-Implementierung: Die Anleitung in zehn Schritten für Ihre Organisation.

Sieben Best Practices für die Implementierung

1. Training und Ermächtigung

Um den organisatorischen Wandel des Unternehmens erfolgreich voranzutreiben, braucht es ein dediziertes Team. Anfangs kann dieses Team aus externen Beratern gebildet sein, aber auf lange Sicht sollten hier interne Lean-Agile Change Agents tätig sein.

Dies ist das Team, das das Wissen und die Fähigkeiten mitbringt, um den Wandel anzutreiben. Wichtig ist hier, dass die Leute im ganzen Unternehmen wissen, wer die Lean-Agile Change Agents sind, damit das Team während (und auch nach) der SAFe-Implementierung als zentrale Ressource und Unterstützung angesehen wird.

2. Balance zwischen Teamautonomie und Synchronisierung

Ein zweiter Aspekt für die Anwendung von SAFe im Enterprise-Umfeld ist die Balance zwischen der Unabhängigkeit des Teams und der Zusammenarbeit im Unternehmen. Teams bilden Agile Release Trains, um Lösungen für komplexe Probleme zu entwickeln und auszuliefern. Für Manager ist es unmöglich, all diese Arbeiten über die diversen Wertströme hinweg eng zu verfolgen.

Die Teammitglieder müssen in der Lage und dazu ermächtigt sein, unabhängig und entscheidungsbefugt in ihren Teams zu arbeiten. Das bedeutet natürlich nicht, dass sie nicht teamübergreifend agieren und wirken dürfen und müssen (siehe unten). Aber sie sollten die Verantwortung für ihre Arbeit tragen und ihre Expertise einbringen können – analog zu den oben erwähnten Lean-Agile Change Agents.

Die Mitglieder der ganzen Teams müssen aber auch in möglichst perfekter Synchronizität miteinander und mit anderen Gruppen arbeiten, um echte Cross-Funktionalität zu etablieren. Menschen müssen also nicht nur gut innerhalb ihrer Teams zusammenarbeiten, sondern auch über viele Teams hinweg, da ein ART typischerweise aus 50 bis 125 Leuten besteht.

3. Frühzeitige und regelmäßige PI-Planung

Die agilen Teams brauchen Klarheit über die erwarteten Resultate eines jeden Programminkrements (PI). Deshalb ist das PI-Planning eine essenzielle Voraussetzung für die Einführung von SAFe. Während dieser Planungsmeetings kommen alle Mitglieder der Gruppen eines ARTs zusammen, um die Ziele der kommenden Iteration zu besprechen, die normalerweise zwischen acht und zwölf Wochen dauert. (Die individuellen Teams haben kürzere Sprints innerhalb dieser übergreifenden Iterationen.)

Erst dann kehren die einzelnen Teams an ihre Boards zurück, um zu diskutieren, wie sie darauf hinarbeiten können, den geforderten Wert mit umzusetzen. Sobald ein Team ein PI beendet, sollte es in der Lage sein, nahtlos ein neues zu beginnen. Die Aufgabe des Planungsteams besteht also darin, dauerhaft einen Backlog mit PI-Initiativen zu pflegen und die Prioritäten für jedes PI festzulegen, sodass die ARTs diese Initiativen in der richtigen Reihenfolge angehen können.

4. Separate Reviews und Retrospektiven

Am Ende eines jeden Programminkrements steht ein Review der geleisteten Arbeit. In diesem Meeting kann das Team zeigen, was es in der letzten Iteration erreicht hat. Das ist für Stakeholder eine gute Gelegenheit, Feedback zu geben, ehe die Arbeiten schließlich an die Kunden ausgeliefert werden.

Ein weiteres Element in SAFe ist die Iterations-Retrospektive (analog zur Sprint-Retrospektive). Hier diskutiert das Team, was in der gerade absolvierten Iteration gut gelaufen ist und was verbessert werden könnte. Kontinuierliche Verbesserung ist ein Eckpfeiler des agilen Manifests und auch ein fester Bestandteil agiler Methoden. Durch die Retrospektive hat das Teams die Chance zu erkennen, welche Verbesserungspotenziale es in seinem Bereich des ARTs gibt.

Diese Meetings müssen separat voneinander und fokussiert stattfinden. Im Review besprechen und demonstrieren wir die Funktionalitäten des Produkts oder Dienstes. In der Retrospektive diskutieren wir unseren Prozess und seine Optimierungsmöglichkeiten für die nächste Iteration.

Produkt-Reviews werden von den Teammitgliedern abgehalten und beziehen sich auf die Produktfunktionen, die mit dem Ende der gerade absolvierten Iteration fertiggestellt worden sind. Retrospektiven drehen sich darum, Aspekte aufzudecken, die in der kommenden Iteration verbessert werden können. Beide Meetings sind essenziell für die Implementierung von SAFe, denn sie schaffen Raum für Innovationen durch bessere Ideen, wenn die Dinge nicht so laufen wie geplant.

5. Kontinuität etablieren

SAFe-Teams haben die Aufgabe, kontinuierliche Wertströme für ein Produkt oder einen Dienst zu etablieren. Manche Organisationen müssen DevOps-Praktiken und Automatisierungen anwenden, um sicherzustellen, dass sie kontinuierlich Wert ausliefern und ihre Bugfixes und Features integrieren. Das hilft nicht nur, die Kunden durch Neuerungen beständig bei der Stange zu halten, sondern sorgt auch dafür, dass die Mitglieder der Organisation während der Entwicklungsstadien stets auf ein und derselben Seite stehen.

6. Inspect & Adapt

Neben der Prozessevaluation in Retrospektiven sollten die Teams, die für die Implementierung von SAFe verantwortlich sind, die ARTs fortlaufend überprüfen. Hilft SAFe, die sogenannte Lead Time zu reduzieren? (Das ist die Zeit vom Wertversprechen bis zum ausgelieferten Inkrement.) Sind die Teams dahingehend koordiniert, woran sie arbeiten und warum? Kennen die Leute auf allen Ebenen den Sinn und Zweck ihrer Arbeit entsprechend der übergreifenden Unternehmensvision? SAFe-Health-Checks helfen dabei, diese Fragen belastbar zu beantworten.

7. Langsame Skalierung

Einer der letzten Schritte auf der Implementierungs-Roadmap für SAFe ist die Erweiterung auf das Portfolio. Das bedeutet im Prinzip, dass die SAFe-Praktiken auf andere Teile des Unternehmens ausgeweitet werden. Dabei wird es zahlreiche zusätzliche Wertströme und ARTs zu definieren und zu verfeinern geben. Aber dafür braucht es Zeit.

Das Unternehmen sollte auf jeden Fall abwarten, bis mehrere Iterationen des initialen Programminkrements durchgelaufen sind, um das Gelernte aus den ersten Iterationen auf die anderen Teile der Organisation anwenden zu können. SAFe ist keine Blaupause, die ohne Weiteres für jedes Unternehmen passt – und das gilt auch für die Implementierung.

Wer sich genügend Zeit dabei lässt, die ARTs, die Wertströme und den Program Backlog sorgfältig zu definieren, wird auf lange Sicht viele Vorteile daraus ziehen. Und bei dieser Skalierung sollten die Teams eine "Jetzt wissen alle, wie man es macht"-Denke möglichst vermeiden, denn sie wird der Komplexität des Vorhabens nicht gerecht.

Wie gesagt: Es gibt keinen Königsweg, um SAFe erfolgreich zu implementieren. Die Dynamik und die Komplexität, die großen Organisationen, ihren Prozessen und ihren Geschäftsfeldern innewohnen, sorgen zuverlässig für Überraschungen. Doch die Implementierungs-Roadmap und die bewährten Einführungspraktiken helfen, sich dafür zu wappnen und eine möglichst reibungsarme Transition auf dem Weg zu Business Agility mit dem Scaled Agile Framework zu erreichen.

SAFe mit Atlassian-Tools: Agile Hive jetzt kennenlernen!

Wollen Sie mehr über die Software-gestützte Umsetzung von SAFe wissen? Eine Lösung dafür heißt Agile Hive. Gerne diskutieren mit Ihnen über Ihre Anforderungen an ein unternehmensweites agiles Produktentwicklungs- und Produktmanagement und demonstrieren Ihnen die Funktionen der Software in einer persönlichen Session. Melden Sie sich bei uns! In unserer Infothek finden Sie Details zu unseren Agile-Hive-Einführungsprojekten.

Weiterführende Infos

Agile Hive 3.0 – SAFe ganz einfach!
Brandneues PI-Planning: Digitale Breakout und Program Boards sowie Program Increments – Agile Hive 3.0 ist da
SAFe in Jira versus SAFe in Jira mit Agile Hive
Einführungsprojekte zu SAFe und Agile Hive

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.