Die obige Grafik veranschaulicht, dass unterschiedliche agile Modelle die verschiedenen Maturitätslevel von Organisationen adressieren. Anders ausgedrückt: Um Kanban oder das SCRUM-Vorgehen zu adaptieren, genügt es bzw. ist es sogar Voraussetzung, dass die Prinzipien (nur) auf der Ebene einzelner Teams umgesetzt werden. Komplexere Modelle wie SAFe, DAD LeSS oder Nexus können jedoch nur dann erfolgreich umgesetzt werden, wenn sie abteilungs- oder gar unternehmensübergreifend mit breitem Portfolio adressiert werden. Eine disziplinierte Führung durch definierte Praktiken und Prozesse ist dabei unerlässlich.

In der Praxis gibt es aber nicht das eine Modell, das eins zu eins auf die bestehende Unternehmenskultur adaptiert werden kann. SAFe ist für mich deshalb ein Werkzeugkasten, den ich insbesondere für grosse und komplexe Herausforderungen zu schätzen gelernt habe und der für Organisationen zunehmend wichtiger wird, je mehr sie ihre agile Reife erhöhen.

Wie ich Agile in meinem Projekt einsetze

Derzeit begleite ich einen Kunden im Rahmen eines globalen Programms mit vielen Abhängigkeiten bei der Einführung einer neuen Lösung, deren Anforderungen noch nicht klar sind. Das Management hat sich deshalb für ein agiles Vorgehen entschieden.

Konkret geht es um die Einführung von Veeva Vault als Lösung für einen global harmonisierten, digitalen End-to-End-Pharma-Herstellprozess für über 100 Standorte. Ich unterstütze in der Rolle als IT Project Manager und Scrum Master in den verschiedenen Organisationseinheiten, die Herstellprozesse auf globalen Level zu vereinfachen, Veeva zu implementieren, konfigurieren und eine nahtlose Integration in die bestehende Systemlandschaft zu ermöglichen.

Neben dem eigentlichen Projektziel habe ich zusätzlich die Aufgabe, Projektstrukturen und ein gemeinsames Mindset für eine agile, effektive und effiziente Zusammenarbeit zu etablieren.

Unsere Projektorganisation haben wir dafür in drei Ebenen unterteilt:

Executive Level (Sponsorship & Steering)

Tactical Level (Program Leadership) arbeitet nach SCRUM-Vorgehen mit einem übergreifenden Product- und Sprint Backlog

Operational Level (3 weitere agile Teams) arbeitet wiederum mit individuellen, vom Product-Backlog heruntergebrochenen Sprint-Backlogs nach SCRUM

Weshalb Scrum? Und wie kommt nun SAFe ins Spiel?

Agile Methoden sind nur dann erfolgreich, wenn sie im Mindset des Teams emotional verankert sind. Da im Unternehmen bereits ein an SCRUM angelehntes Vorgehen im Projektmanagementframework integriert und die SCRUM Prozesse daher weitestgehend bekannt waren, erschien ein Vorgehen nach SCRUM naheliegend. Als Teil der Projektinitiierung und der Etablierung unseres agilen Projektvorgehens haben wir gemeinsam ein SCRUM-Training absolviert. Im Nachgang haben wir unsere individuelle agile Form der Zusammenarbeit (Ways of Working) daraus gemeinsam im Team abgeleitet.

Da wir im Rahmen des Projekts mit mehreren Sub-Teams arbeiten, wurden mir die Grenzen von SCRUM schnell deutlich. Die grosse Herausforderung liegt in der Skalierung auf komplexe Projekte, die mehrere Teams sowie die Integration mit Managementfunktionen auf Unternehmensebene erfordern.

Um die Komplexität für die Teammitglieder nicht zusätzlich zu erhöhen, entschieden wir uns bewusst, auf Begrifflichkeiten aus dem SAFe Framework zu verzichten und zunächst nach dem SoS (Scrum of Scrums) Ansatz dahingehend zu skalieren, dass neben den jeweiligen Sprint Ceremonies, eine weitere Abstimmung zwischen jeweils repräsentativen Mitgliedern der agilen Teams geführt wurde. Dennoch greifen wir auf einige Elemente von SAFe zurück.

Nach dem Motto „aus jeder Welt das Beste“ haben wir bisher die folgenden Vorgehensweisen und Tools im laufenden Programm eingeführt:

Neben dem Scrum Master und Product Owner haben wir jeweils eine übergeordnete Rolle eingeführt, welche eine einheitliche agile Vorgehensweise über alle Programmeinheiten hinweg ermöglichen, die Prioritäten der einzelnen Product Releases festlegen und die jeweiligen Abhängigkeiten untereinander managen.

Mir ist wichtig, die unterschiedlichen Arbeitsgruppen kunden- und wertorientiert selbstorganisiert und effizient arbeiten zu lassen. Trotzdem gilt es aber die Abhängigkeiten wie Inputs, Outputs, Meilensteine und Pre-Requisites zueinander und zu weiteren parallellaufenden Initiativen und Lebenszyklen relevanter Systeme zu berücksichtigen. Deshalb wurde neben der Scrum of Scrums Abstimmung ein übergreifender Product Backlog auf Programmebene eingeführt. Daraus werden dann die für das Team relevanten User Stories abgeleitet und im Sprint Backlog auf Teamebene heruntergebrochen.

Ein mit allen Teams gemeinsam entwickelter Major Release Plan und die Planung von Programmphasen geben den einzelnen agilen Sub-Teams zusätzliche Orientierung bei der Planung ihrer jeweiligen Sprints.

Ich möchte, dass das Team nach jedem Sprint reflektiert, lernt und das gemeinsame Vorgehen kontinuierlich verbessert. Nur so entsteht Bedarf, Stück für Stück weitere Elemente aus dem agilen Werkzeugkoffer einzuführen. Neben Sprint Planning und Review werden deshalb auch SCRUM Retrospectives durchgeführt.

Bisher hilft ein simples Reporting mit Burndownchart Diagramm und Storypoints dem Team dabei, ein Gefühl dafür zu bekommen, wie viele Aufgaben für den nächsten Schritt geplant werden können und gibt dem Committment zur Übernahme von Arbeitspaketen gleichzeitig mehr Gewicht. Zusätzliche Reports werden je nach Bedarf und Nutzen iterativ eingeführt.

SAFe verdeutlicht den Einfluss der Unternehmensstrategie und des Portfolio Managements auf die Entwicklung der Unternehmenslösung. Der monatliche Austausch mit dem Portfolio Management ermöglicht dem Programm den Blick aus der Vogelperspektive auf die parallellaufenden und teilweise voneinander abhängigen Einführungen von Unternehmenslösungen.

Zur Prägung des agilen Mindsets des Teams setze ich auf Kommunikation und Zusammenarbeit auf Basis des Agilen Manifesto und den SAFe Core Values, welche sowohl Scrum als auch SAFe zugrunde liegen. Darüber hinaus lege ich Wert auf Servant Leadership und eine Governance des Programms gemäss SAFe Lean-Agile Principles.


Darüber hinaus erachte ich die folgenden SAFe Elemente und Tools als für mich besonders wertvoll:

Die 1. Regel des Skalierungsansatzes: „Nicht skalieren“ – und das macht durchaus Sinn, denn anhand dieser Regel überlegt man sich gut, ob, wann und wie man effektiv skaliert.

Alles dreht sich um Business Agility, also um die gesamte Organisation, nicht nur um Delivery-Prozesse auf Teamebene. Die kunden- und wertorientierte Lieferung steht dabei stets im Mittelpunkt. Dies sollte bei der Einführung oder kontinuierlichen Verbesserung bei jedem Prozessschritt gründlich hinterfragt werden.

Ready-to-use-Assessments zur „Reifegradbewertung der Geschäftsagilität“ und der „Kultur des kontinuierlichen Lernens“ (im Toolkit verfügbar) helfen bei der Einführung von SAFe, die individuell passenden Ansätze abzuleiten.

Das ART-(Agile Release Train-)Konzept zur Verwaltung mehrerer verwandter agiler Teams kann echten Mehrwert bieten, ist aufgrund der Komplexität aber nur für Organisationen mit hoher Maturität zu empfehlen.

Meine wichtigsten Take-Aways

Um wieder auf die anfängliche Definition von SAFe zurückzukommen: Das Stichwort „Wissensdatenbank“ ist für mich das ausschlaggebende.

SAFe stellt für mich bei der Projektdurchführung kein Ersatz zu SCRUM dar, sondern ein Werkzeugkasten für agile Teams. Einzelne Elemente aus SAFe helfen mir dabei, mehrere voneinander abhängigen agile Teams so auszurichten, dass sie gemeinsam auf dasselbe Ziel zuarbeiten.

Die Organisation und das Team müssen für die Verwendung von SAFe Elementen bereit sein, um sie erfolgreich einzusetzen. Deshalb empfehle ich, neue Elemente Stück für Stück bspw. über Sprint Retrospectives jeweils dann einzuführen, wenn der Bedarf dafür entsteht.

Entsprechend setze ich für die Skalierung des agilen Vorgehens in meinem Projekt im ersten Schritt mit SoS (Scrum of Scrums) um. Dabei werden Vertreter einzelner Teams in Abstimmungsmeetings anderer Teams involviert sein, um sicherzustellen, dass die Abhängigkeiten zueinander berücksichtigt werden.

Die Einführung der übergreifenden Product Manager und Scrum Master ermöglicht die Harmonisierung der agilen Vorgehensweisen in den einzelnen Teams und das Management von Major Releases und Abhängigkeiten untereinander, aber auch unternehmensweit.


Welche Erfahrungen haben Sie bereits mit SAFe gemacht? Welche Elemente haben sich für Sie besonders bewährt und wie kombinieren Sie diese mit anderen agilen Methoden?