Share ZU:
24 March 2014 @ Andreas Becker

Eine Erfolgsgeschichte: Produktentwicklung mit dem Scaled Agile Framework (SAFe)™

Die Ausgangssituation
Unser Kunde ist ein IT-Dienstleister und Hersteller einer Standardsoftware, die im Rahmen eines klassischen Vorgehensmodells entwickelt wurde.
Nach einer Analyse der bisherigen Vorgehensweise, wurden die folgenden Schwachstellen identifiziert: 

  • Zu lange Vorlauf- und Reaktionszeiten bei Änderungswünschen und bei der Umsetzung neuer Anforderungen.
  • Mangelnde Kundenzufriedenheit durch fehlinterpretierte Anforderungen.
  • Massive Qualitätsprobleme bei der Auslieferung neuer Releases.
  • Priorisierungskonflikte zwischen der Entwicklung neuer Anforderungen und der Wartung (Fehlerbehebung und Refactoring).

Zur Behebung dieser Schwachstellen wurde eine agile Vorgehensweise in Betracht gezogen und nach der erfolgreichen Durchführung eines Pilotprojekts entschieden, die weitere Produktentwicklung und Wartung durch agile Teams (Scrum oder Kanban) durchzuführen zu lassen. Noch während die agile Transition der Entwicklungsabteilungen vollzogen wurde, stellen sich neue Problemstellungen heraus. Die agilen Teams sind auf einem guten Weg, aber der Rest der Organisation verharrt noch in der bisherigen Vorgehensweise, so dass schnell offensichtlich wird, nur eine agile Transition der Gesamtorganisation kann die oben aufgeführten Schwachstellen beseitigen.

Das Scaled Agile Framework (SAFe)™
Zu diesem Zeitpunkt kommt das Scaled Agile Framework (SAFe)™ von Dean Leffingwell ins Spiel. Dieses Framework basiert auf Praxiserfahrungen in agil skalierten Umfeldern und integriert neben der agilen Entwicklung auch Lean-Ansätze und Theorien zum kontinuierlichen Fluss einer Produktentwicklung. Abb.1 zeigt einen  guten Überblick über die 3 Ebenen und verdeutlicht die Zusammenhänge von agilen Entwicklungsteams, Backlog-Management, Program- und Portfolio-Ebene. Das eigentliche „Herzstück“ ist der Agile Release Train (ART), der als organisatorische Skalierung der Teamebene zu verstehen ist und für getaktete potentiell auslieferbare Release-Ergebnisse „fährt“. Der ART auf der Programmebene ist mit den Sprints der Teamebene vergleichbar. Prinzipien wie verstehen – vereinbaren – sicherstellen – adaptieren gelten auf beiden Ebenen.

SAFe
Abb. 1 – Scaled Agile Framework (SAFe)™ auf einen Blick

Was sollte durch die Einführung von SAFe™ in unserem Umfeld erreicht werden?

  • Die Etablierung eines Release-Managements und einer gemeinsam durchgeführten Release-Planung. Während dieser Release-Planung werden verschiedene Realisierungsvarianten für die definierten Release-Ziele diskutiert und die zahlreichen fachlichen und technischen Abhängigkeiten, die zwischen den einzelnen Teams bestehen, berücksichtigt.
  • Die Etablierung eines Produktmanagements, um eine Gesamtsicht des Produkts mit einer Ausrichtung zur Marktseite sicherzustellen und um die Product Owner, die eher ein technisch ausgerichtetes Rollenverständnis haben, zu entlasten.
  • Die Etablierung eines Systemteams zur Ausführung von übergreifenden Aufgaben.  Dies umfasst u.a. die Unterstützung der Entwicklungsteams bei Architekturentscheidungen,  die Erstellung einer konsolidierten Benutzerdokumentation und die Durchführung eines E2E-Tests, da die Entwicklungsteams nur ihre Teilprodukte und die unmittelbaren Schnittstellen testen können.
  • Die Etablierung eines Portfolio Managements, um das Produkt „vorzudenken“ und um sich von festen Budget-Zeiträumen zu lösen und durch eine rollierende Budgetierung zu ersetzen

Agile Prinzipien und das Scaled Agile Framework
Die Einführung von SAFe™ ist kein Selbstläufer und es besteht die Gefahr, dass das Framework als neues „silver bullet“ verstanden wird, mit dem die gesamte Organisation endlich „agil“ wird. Man betrachtet das Übersichtsbild und es müssen nur ein paar neue Rollen eingeführt werden, Artefakte erzeugt und neue Events stattfinden – Werte und Prinzipien des Agilen Manifests gelten aber auch bei SAFe™.

So besteht die größte Herausforderung bei unserem Kunden darin, agile Prinzipien, die im Umfeld eines Teams bereits gut angewandt wurden, für eine Skalierung der Agilität zu vermitteln und sie in der gesamten Organisation zum Leben zu bringen. Beispielsweise ist es nötig, eine Kultur der kontinuierlichen Abstimmung mittels direkter Kommunikation sowohl innerhalb einer Ebene als auch zwischen den Ebenen zu etablieren.

Es ist schließlich gelungen, mit einem hohen Aufwand an Agile Coaches, die Reaktionsgeschwindigkeit, die Qualität und damit die Kundenzufriedenheit zu steigern. Gerne hätte ich vor das Wort <steigern> noch <deutlich> gesetzt,  dies wäre aber nicht zutreffend. Know-how, das nicht so schnell aufgebaut werden konnte, Fluktuation der Mitarbeiter, die eine Neuausbildung veranlasste, Rückfälle in alte Denkmuster aus Zeiten des Wasserfalls, die mit viel Überzeugungsarbeit wieder eingefangen werden mussten und Fehler des Managements, teilweise aus Unwissenheit, haben die mögliche Effizienz des Frameworks reduziert.

Einfach ist es nicht mit SAFe™, aber es ist unser Weg, mit vielen Teams ein gemeinsames Produkt zu entwickeln und täglich dazuzulernen und sich und das Framework weiterzuentwickeln.

Wenn Sie mehr über das Scaled Agile Framework erfahren möchten, empfehle ich einen Zertifizierungskurszum Thema „Leading SAFe“, in dem die Zusammenhänge des Frameworks vermittelt werden.

 

 

 

 

Andreas Becker

Kontaktieren Sie Andreas Becker

Andreas Becker ist Agile Transition Coach, Senior Consultant und Trainer bei HOOD GmbH / Agile-by-HOOD. Er begleitet Unternehmen bei der Transition zu agilen Organisationen und unterstützt bei der Implementierung von „Lean Thinking“. Im Fokus seiner Arbeit stehen agile Teams und Business Analysten in agil skalierten Umfeldern. Er ist in der Lean, Agile und Scrum Community aktiv und veröffentlicht Artikel, hält Vorträge und führt Workshops auf internationalen Konferenzen durch und ist zudem Lehrbeauftragter an der Hochschule Rosenheim für "Agile Produktentwicklung". Herr Becker ist zertifizierter Scaled Agile Framework - Program Consultant (SAFe), ScrumMaster und Product Owner. Neben seiner langjährigen Erfahrung im agilen Umfeld hat er in den Bereichen Requirements Engineering, Softwaretest- und Qualitätsmanagement in unterschiedlichen Branchen gearbeitet.