• 10
  •  
  •  
  •  
  •  
    10
    Shares
Scaled Agile Framework für grosse Unternehmen

SAFe: Ein Weg zu mehr Agilität?

SAFe bringt grosse Unternehmen mit mehreren Entwicklerteams einen Schritt näher zur Agilität. Doch damit das Framework zum Erfolg wird, braucht es Commitment, Know-how und die richtig transformierten Organisationsstrukturen.

03.04.2019Text: bbv0 Kommentare
SAfe
  • 10
  •  
  •  
  •  

Mehr Flexibilität, höhere Produktivität und eine kürzere Time-to-Market: Richtig eingeführt, tragen agile Ansätze wesentlich zur Wettbewerbsfähigkeit eines Unternehmens bei. Gerade in der Softwareentwicklung ist Scrum eine beliebte Methode, um angemessen schnell auf verändernde Kunden- und Marktanforderungen reagieren zu können. Das Problem: Scrum wurde lediglich für die Arbeit eines einzelnen Teams entwickelt. Grosse Unternehmen mit mehreren Entwicklungsteams sind dadurch gefordert: Möchten sie sich agil aufstellen, muss Scrum teamübergreifend richtig koordiniert werden.

Inzwischen gibt es mehrere Rahmenwerke, um agile Arbeitsformen auch in Grossunternehmen einzuführen. Eines davon ist das Scaled Agile Framework, kurz SAFe. SAFe vereint agile Arbeitsweisen mit den Ansätzen aus dem Lean Thinking und erlaubt es, mehr Agilität auch im grossen Massstab in Unternehmen anzuwenden. Gerade für das Management ist daher SAFe interessant: «Agiles Arbeiten nach Scrum bedeutet ja, möglichst wenige Voraussagen zu treffen und Produkte eigenverantwortlich in kurzen Zyklen iterativ zu entwickeln», erklärt Alexander Beck, Software-Architekt bei bbv. «So wie ich das sehe, ist Scrum fürs Management oftmals einfach zu vage. Im Gegensatz zum reinen Scrum bringt SAFe einen grösseren Planungshorizont in die Produktentwicklung. Deshalb fühlt sich die Führungsebene, die vor allem mit Wasserfall-Ansätzen vertraut ist, meiner Erfahrung nach bei SAFe gut abgeholt. Der Aufwand für diese zusätzliche Planung ist aber nicht zu unterschätzen.»

Das Vorgehen mit SAFe

SAFe operiert dazu mit neuen Rollen und Begrifflichkeiten. Im Kern setzt das Framework auf den sogenannten Agile Release Train (ART): Ein Zusammenschluss mehrerer agiler Teams, der zusammen mit anderen Stakeholdern schrittweise eine oder mehrere Lösungen in einem Wertstrom entwickelt. Der ART fasst agile Teams – für gewöhnlich 50 bis 125 Personen – zusammen, die am selben oder an stark zusammenhängenden Produkten arbeiten. Jedes Team enthält die Rollen des Product Owners und Scrum Masters und arbeitet in zweiwöchigen Sprints. Der Agile Release Train wird betreut von einem Release Train Engineer (RTE). Als Hauptverantwortlicher eines ART dient der RTE als Ansprechperson für alle Scrum Master, koordiniert teamübergreifende Abstimmungen und stellt bei Bedarf Support zur Verfügung. Treten im ART Probleme auf, meldet er diese an das Product Management. Dieses überwacht das Produktportfolio und koordiniert mit dem RTE die Lösungsvision und Roadmap innerhalb des ART.

Die Agile Release Trains durchlaufen mehrere Product Increments (PI): In der Regel sind es 10- bis 15-wöchige Zyklen, in denen jene Features eines ARTs umgesetzt werden, die zuvor im sogenannten PI-Planning geplant wurden. Daher ist das PI-Planning elementarer Bestandteil von SAFe: Hier werden Features und Enabler – das sind technische Probleme, die für die Umsetzung der Features zuerst aus dem Weg geräumt werden müssen – für alle Beteiligten vorgestellt. Etwa der Business-Kontext, die Vision des Produkts (durch den Product Manager) oder das Vorgehen beim PI-Planning (durch den RTE). «Im PI-Planning werden die Features für das nächste Product Increment festgehalten», erklärt Beck. «Im Gegensatz zu den User Stories im gewöhnlichen Scrum sind die fürs PI definierten Features aber komplexer. Sie bestehen aus mehreren Stories, die dann von den einzelnen Teams selbstverantwortlich erarbeitet werden.»

SAFe
Das Grundgerüst von SAFe.

SAFe fördert die Agilität von Grossunternehmen

Wegen seiner Komplexität wird SAFe oftmals vorgeworfen, nur bedingt zur Agilität in Unternehmen beizutragen. Dazu kommt, dass der User nicht mehr direkt bei den Teams platziert ist, wie beim Scrum. Der Kontakt zum User findet häufig auf Large-Solution-Ebene statt; aus den Teams heraus kann nur bedingt mit ihm kommuniziert werden, ein «Fast Feedback» ist kaum oder gar nicht möglich. Auch die zwei- bis dreimonatigen Product Increments drosseln die gewünschte Flexibilität: «Durch die Product Increments sind die Prozesse fürs oberste Management recht starr», hält Beck fest. «Kämen unerwartet neue Features hinzu, könnten sie nur mit grossem Aufwand in das laufende PI aufgenommen werden, da Features ja bereits priorisiert wurden. Nichtsdestotrotz trägt SAFe zur Agilität in grossen Unternehmen bei – weil es trotz langer Zyklen das Mindset für agiles Arbeiten auch auf Management-Ebene schärft und die fachlichen, technischen Abhängigkeiten zwischen den Teams berücksichtigt wurden.»

Damit SAFe erfolgreich in Unternehmen zum Einsatz kommt, müssen laut Beck die Features priorisiert werden, die einen möglichst grossen Mehrwert für den Kunden erzeugen. Dazu bricht SAFe im Idealfall altgewohnte Prozessabläufe wie Analyse, Implementierung und Testing auf, um den Schwerpunkt wieder verstärkt auf das Kundenfeature zu lenken; die Beteiligten müssten auch mehr Eigenverantwortung erlernen: «Wenn niemand Features fürs Planning vorbereitet hat, dürfen sie konsequenterweise nicht in den Backlog aufgenommen werden – auch wenn sie im Grunde genommen wichtig wären», erklärt Beck. «Dass neue Funktionalitäten der Verantwortung aller unterliegen, muss den SAFe-Beteiligten beigebracht werden.»

bbv hilft bei der Einführung von SAFe

Allem voran muss SAFe aber durch alle Unternehmensbereiche durchgedrungen sein – nur so entfaltet das Framework sein Potential. Alexander Beck ist derzeit als externer Mitarbeiter bei einem Kunden tätig, der SAFe eingeführt hat – und weiss, was es heisst, wenn das Framework konsequent angewendet wird: «Wir hatten das Glück, dass der Wunsch nach SAFe vom oberen Management kam – und deshalb strikt umgesetzt wurde», erklärt er. «In unserer Abteilung gibt es keine Projektleiter mehr, das Product Management konzentriert sich verstärkt auf die einzelnen Iterationen und nicht mehr auf das Projekt als Ganzes, Projekt-Milestones verschwanden praktisch ganz, und die Prozesse wurden für SAFe umgeschrieben.»

Doch um das Framework in Unternehmen einzuführen, sind mehrere Zyklen nötig, bis es sich über die einbezogenen Unternehmensbereiche hinweg eingespielt hat – je nachdem dauere die agile Transformation bis zu fünf Jahre. Umso wichtiger sei es deshalb, jemanden zu haben, der bereits Erfahrungen in der Unternehmenstransformation mit SAFe gesammelt hat. Prozessrelevante Rollen wie die des RTEs und Scrum Masters sollten mit erfahrenen Personen besetzt werden, um schnelle Erfolge sicherzustellen. Oder es wird ein ganzes Transformations-Team gecoacht, das genau prüft, ob SAFe konsequent angewendet wird – oder ob ein Unternehmen wieder in alte Muster zurückfällt. Hier kann bbv unterstützen: «Wir bei bbv leben das agile Mindset tagtäglich», erklärt Beck. «Unsere Mitarbeitenden können sich schnell an SAFe anpassen und ‘SAFe-Neulinge’ entsprechend coachen. Mit diesem Know-How lässt sich SAFe konsequent in einer Firma implementieren.»

Fazit

Unternehmen müssen sich bei der SAFe-Transformation der eigenen Strukturen und Prozesse genau bewusst sein. Ausgehend davon kann der Weg in die agile Welt gestartet werden – mit SAFe als zugrundeliegendes Vehikel. Wo die agile Organisationsstruktur bereits gelingt und wo noch (tiefgreifende) Änderungen nötig sind, wird durch das Framework schnell ersichtlich. Liegen auf dem Weg zum agilen Unternehmen immer noch Stolpersteine, ist es am RTE und Scrum Master, aufgrund ihrer Erfahrung entsprechend zu reagieren und alle Anpassungen vorzunehmen, die für eine agile Unternehmensorganisation unerlässlich sind.

Der Experte

Alexander Beck

Alexander Beck ist Senior Software-Architekt Embedded bei bbv. Qualität steht bei ihm im Fokus – sei es bei der zielorientierten Produktrealisierung oder als Software-Architekt bei komplexen Herausforderungen. Dabei arbeitet er am liebsten in einem agilen Umfeld. Beck leitet zudem die IoT Community von bbv.

Unser Wissen im Abo

Change Management – Teil 2

Gegenwind bringt den Wandel voran

Digitalisierung
Change Management – Teil 1

Kurs halten in stürmischen Zeiten

Change Management
Software modernisieren

Warum Softwaremodernisierung oft die beste Lösung ist

Softwareentwicklung

Artikel kommentieren

Die E-Mail-Adresse wird nicht publiziert. Notwendige Felder sind mit einem * versehen.