Was ist SAFe?

SAFe, ausgeschrieben Scaled Agile Framework for Lean Enterprises, stellt eine Möglichkeit dar, den von Jeff Sutherland und Ken Schwaber publizierten Scrum Guide auf große und komplexe IT-Projekte zu skalieren. Dass SAFe aktuell eine gewisse Relevanz im agilen Projektmanagement zugesprochen werden kann, zeigt eine Studie, wonach SAFe in über 70% der Fortune 100 US Unternehmen Anwendung findet. Dieser Blogartikel gewährt Einblicke in unsere Erfahrungen bei einer SAFe Implementierung und kann als Hilfestellung für andere Projekte genutzt werden.

Der Grundstein für den SAFe Erfahrungsbericht: Die Strukturen, die wir geschaffen haben.

Allgemein wurde zu Beginn des Projektes das gewünschte Ergebnis definiert – dieses wurde in einer Vision verankert, mit KPI messbar gemacht und mit klaren Handlungsthemen hinterlegt, die zu entwickeln waren. Für das Herunterbrechen der Handlungsthemen hin zu detaillierten Produktinkrementen, die von den Scrum Teams entwickelt werden können, haben wir folgenden Ablauf für die Produktverfeinerung implementiert: Grundsätzlich wird ein Handlungsthema in ein sogenanntes Epic zusammengeschnürt und von einem Epic Owner verantwortet. Dieser erstellt einen Business Case für das Epic, auf dessen Grundlage die Genehmigung des Epics geprüft wird. Sofern das Epic genehmigt wird, wird dieses in Features heruntergebrochen. Ein Feature ist groß genug geschnitten, um alleinstehend einen Nutzen darstellen zu können, jedoch klein genug, um innerhalb eines definierten Zeitraumes implementiert zu werden. Der maximale Implementierungszeitraum ist das Program Increment (PI), welches aus mehreren Iterationen (Iterationen werden im klassischen Scrum als Sprints bezeichnet) besteht. Bei der Dauer des PI haben wir uns an die von SAFe vorgeschlagenen 4 Entwicklungs-Iterationen sowie der darauffolgenden Innovations- und Planungs-Iteration gehalten. Definiert, priorisiert und verantwortet wird ein Feature vom Produktmanagement. Da die agilen Teams iterationsweise arbeiten, ein Feature in der Regel jedoch nicht innerhalb einer Iteration fertiggestellt wird, lässt es sich in mehrere Userstories unterteilen. Per Definition bietet eine Userstory einen Teil der gewünschten Funktionalität und kann innerhalb einer Iteration entwickelt werden. Der Product Owner eines jeden Scrum Teams stellt sicher, dass diese ausreichend beschrieben sind und nimmt eine Priorisierung des Team-Product Backlogs vor. Schlussendlich haben wir so eine Struktur geschaffen, in der jedes Scrum Team innerhalb des Projektes sein eigenes Team-Product Backlog erhält. Die Herausforderung hierbei ist, dass durch die vielen Team-Product Backlogs der Blick auf das „große Ganze“ nicht verloren geht. Anders als im klassischen Scrum, wo der Product Owner das Produkt ganzheitlich verantwortet, ist er innerhalb von SAFe lediglich für das jeweilige Team-Product Backlog verantwortlich. Diese Rollendefinition hat dazu geführt, dass wir einen hohen Fokus auf die Zusammenarbeit von Product Ownern und dem Produktmanagement gelegt haben, die das teamübergreifende Product Backlog festlegen und priorisieren. Zudem bedeutet das Verteilen von Features auf die Team-Product Backlogs von mehreren Teams, dass Abhängigkeiten vor Entwicklungsbeginn bekannt und währenddessen kontinuierlich berücksichtigt werden müssen. Beispielsweise wurden von zwei Teams unterschiedliche Features entwickelt, die aus funktionaler Sicht nicht zusammenhängen, jedoch technisch starke Abhängigkeiten aufwiesen. Damit es beim Zusammenführen der Features nicht zu Chaos kam, war eine saubere Koordination essenziell. Daher haben wir, ergänzend zum SAFe Standard, mit dem Release Manager eine Rolle definiert, welche teamübergreifend die Releases koordiniert. Zunächst überprüft der Release Manager vorgegebene Kriterien, die für eine Codeübergabe von der Entwicklungs- in die nächsthöhere Systemumgebung erfüllt sein müssen. Während der Testphasen auf den unterschiedlichen Testumgebungen fungiert er zudem als Problemlöser für kurzfristig auftauchende Störungen, indem er eine Anpassung der Release Zeitfenster oder der Testressourcenverteilung vornehmen kann.

Welche Rolle spielt die Teamzusammensetzung für den Erfolg?

Die agilen Teams bestehen stets aus einem Product Owner, einem Scrum Master sowie dem Entwicklungsteam. Das Entwicklungsteam ist so aufgestellt, dass das Fachwissen aller für die Entwicklung benötigten Funktionen innerhalb des Teams verfügbar ist (cross-functional Team). Innerhalb unseres Projektes ist pro benötigte Applikation mindestens ein Entwickler im Team, zudem noch ein Tester sowie ein Testautomatisierer. Auch wenn nicht per SAFe Definition vorgesehen, haben wir zudem noch einen Business Analyst an die Seite des Product Owners gestellt, welcher bei der Ausformulierung der Userstories unterstützt und dem Team für Rückfragen hinsichtlich funktionalen Produktanforderungen zur Verfügung steht. Die richtige Zusammensetzung der Teams ist erfolgskritisch. Daher war es uns wichtig, abhängig vom Team, den benötigten Erfahrungsschatz pro Funktion zu bewerten und danach die Teams zusammenzustellen. Der Erfahrungsschatz bezieht sich hier auf das technische Wissen, dem funktionalen Verständnis des Produktes (-inkrements) sowie der Methodenkompetenz. Andernfalls könnte es zu Überforderung einzelner Teammitglieder kommen und das Team kann zugesicherte Entwicklungen nicht realisieren. Dies wiederum würde dazu führen, dass andere Teams aufgrund von Abhängigkeiten zu diesem Team ebenfalls ihre Zusagen nicht liefern können – oder aber ein Entwickler aus einem anderen Team hilft bei Engpässen mit aus, wodurch jedoch die Leistungsfähigkeit des anderen Teams reduziert wird.

Die Kommunikation in SAFe

Ähnlich wie im klassischen Scrum Guide legt auch SAFe einen starken Fokus auf die Zusammenarbeit und Kommunikation innerhalb des agilen Teams. Zum einen hat jedes der agilen Teams die gewohnten Zeremonien, bestehend aus Planungs-, Review- und Retro-Meeting sowie dem Daily. Zum anderen haben sich weitere Interaktionen als hilfreich erwiesen: Exemplarisch wäre hier die 3-Amigo-Session zu nennen, in der sich Product Owner, Entwickler und Tester zusammensetzen, um Rückfragen zu klären, Fortschritte vorzustellen sowie verbleibende Aufgaben abzustimmen. Gamification ist ein schöner Motivator, um dies zu fördern. So haben wir den 3-Amigo-Award ins Leben gerufen, der ein besonderes Engagement eines Teammitgliedes auszeichnet. Ein anderes Beispiel ist das Review-Preparation-Meeting, eine Art Generalprobe des Review-Meetings. Speziell am Anfang haben wir sehr gute Erfahrungen mit diesem Meeting gemacht. Auf der einen Seite können „Agile-Neulinge“ innerhalb des Teams sich selbst ausprobieren und den Ablauf üben. Auf der anderen Seite sorgt dies natürlich auch für einen professionellen Auftritt in dem tatsächlichen Review-Meeting gegenüber den Stakeholdern. Neben der Interaktion innerhalb des Teams spielt die teamübergreifende Kommunikation eine bedeutende Rolle. Grundsätzlich bilden mehrere agile Teams einen Agilen Release Train (ART). Innerhalb eines ART arbeiten alle agilen Teams synchron, sie starten und beenden die Produktentwicklung gleichzeitig. Zudem haben wir Expertenrunden etabliert, in denen die Fachexperten der einzelnen Teams regelmäßig zusammenkommen. So gibt es das Scrum of Scrum (SoS) für den Austausch zwischen den Scrum Mastern, Product Owner-Runden, aber auch Communities of Practice (CoP) für die einzelnen Funktionen. Diese werden für Updates genutzt, um sich gegenseitig zu schulen oder aber auch für die Diskussion und Festlegung von teamübergreifenden Standards. Besonders hinsichtlich Kommunikation, Dokumentation und Qualität war es uns wichtig, einheitliche Standards festzulegen. So ist es zum Beispiel ratsam, ein gemeinsames Verständnis zu haben, welche Kriterien erfüllt sein müssen, damit mit der Entwicklung eines Produktinkrements gestartet werden kann (Definition of Ready). Ebenso wichtig sind Kriterien, die eine erfolgreiche Entwicklung überprüfen (Definition of Done). Diese Prüfstellen helfen, ein einheitliches Qualitätsverständnis sicherzustellen. Eine oft geführte Diskussion war, ob die agilen Teams örtlich zusammensitzen sollten oder nicht. Dies lässt sich vermutlich nicht pauschal mit ja oder nein beantworten, da beides seine Vor- und Nachteile mit sich bringt – ein örtliches Beisammensein erleichtert Abstimmungen, den Aufbau einer Teamkultur und die Durchführung der Scrum Zeremonien. Auf der anderen Seite sind An- bzw. Abreise kosten- und zeitintensiv. Hinzu kommen allgemeine Themen wie Räumlichkeiten mit ausreichend Platz und professioneller Büroausstattung für all die Teams. Insgesamt lässt sich jedoch festhalten, dass gerade zu Beginn der SAFe Implementierung die genannten Vorteile überwogen haben.

Fazit

Zusammenfassend lässt sich sagen, dass wir mit SAFe eine Methodik genutzt haben, um Größe und Komplexität des Projektes durch strukturierte Abläufe und Rollendefinition besser steuern zu können. Allerdings versteht sich SAFe als Rahmenwerk, wodurch im Detail Fragen aufgekommen sind, die SAFe nicht beantwortet. Für zukünftige Implementierungen empfiehlt es sich daher, ausreichend Zeit einzuplanen, um gerade diese Detailfragen mit den fachlichen sowie technischen Experten des Unternehmens beantworten zu können. Zudem ist grundsächlich immer die Unterscheidung zwischen Methodik und Kultur zu berücksichtigen. Eine Implementierung der SAFe Methodik stellt noch keine agile Transformation dar. Hiervon kann erst gesprochen werden, wenn auch die Arbeitskultur aller Projektbeteiligten agil wird. Wie auch im klassischen Scrum Guide ist dies sicher die größte Herausforderung.