zurück zum Artikel

Agile Methoden: Mit SAFe auf dem Weg zu mehr Agilität

Moritz Wagner, Peter Schneider

(Bild: LanKS/Shutterstock.com)

Das Scaled Agile Framework soll Unternehmen bei Entwicklung von Produkten und Services helfen. Es gilt bereits im Voraus die richtigen Bedingungen zu schaffen.

Ganz gleich, ob Produkte, Dienstleistungen oder komplexe Services: Agile Frameworks haben sich inzwischen in vielen Organisationen etabliert – die wohl bekanntesten sind Kanban und Scrum. Die Anforderungen sind jedoch in den vergangenen Jahren stark gewachsen. Arbeiteten früher nur wenige Teams agil an einem Produkt, gilt es nun, eine Vielzahl unterschiedlicher Teams zu steuern, die an mehreren, zum Teil aufeinander aufbauenden Anwendungen arbeiten. Zudem müssen Organisationen flexibel auf veränderte Anforderungen reagieren und wollen ihr Business in größerem Maßstab skalieren.

Zu den größten Herausforderungen zählen der Umgang mit bestehenden Abhängigkeiten, die Organisation der einzelnen Arbeitsschritte sowie die Kommunikation zwischen den Projektteams und Stakeholdern aus anderen Fachbereichen. Entsprechend hoch ist der Koordinationsaufwand für die verantwortlichen Scrum Master, Product- und Process Owner. Diese sind insbesondere dann gefragt, wenn Personen Mitglied in mehreren selbst organisierenden Teams sind und es zu unerwarteten Problemen und Verzögerungen kommt. Gerade wenn Organisationen Projekte und Produktportfolio kontinuierlich weiterentwickeln, sich flexibel an verändernde Marktbedingungen anpassen oder ihr komplettes Geschäft digitalisieren wollen, brauchen sie Werkzeuge, mit denen sie diese komplexen Konstellationen agil managen können.

Scaled Agile Framework – die Entstehung

Dean Leffingwell ist seit vielen Jahren einer der Experten im agilen Bereich. Als Coach und Berater unterstützt er bei der Implementierung und Anwendung des Scaled Agile Framework (SAFe). Durch seine langjährigen Erfahrungen als Unternehmer, Methodiker und Berater hat Leffingwell seine Führungsqualitäten unter Beweis stellen können. 2013 wurde er zum Co-Founder des Unternehmens Scaled Agile. Seine Idee, das Scaled Agile Framework zu entwickeln, entstand aus dem Problem, dass zahlreiche Scrum-Teams innerhalb eines Unternehmens mit vielen Einschränkungen umgehen mussten. Organisation und Koordination der agilen Teams waren die Gedanken, die er mit seinem Framework beantworten wollte. Seit Version 1.0 entwickelte Leffingwell gemeinsam mit seinem Team weitere Releases und stellte sie nach und nach auf dem Markt bereit. Aktuell liegt Version 5.1 vor.

Mit vier sofort einsatzbereiten Konfigurationen unterstützt das Framework das gesamte Produkt- und Anwendungsspektspektrum einer Organisation – angefangen von wenigen kleinen Teams bis hin zu den komplexen Systemen, an deren Entwicklung und Produktivsetzung Tausende Menschen beteiligt sind. Abhängig von Größe, Komplexität und Reifegrad kann dabei Essential SAFe, Portfolio SAFe, Large Solution SAFe oder Full SAFe eingesetzt werden. Der Unterschied der verschiedenen Modelle liegt nach Einschätzung der Autoren in ihrer Komplexität und Zielsetzung. Full SAFe konzentriert sich dabei nicht nur auf komplexe Umsetzungen, die Kunden zur Verfügung stehen, sondern ebenfalls auf die Unternehmensentwicklung. Dazu verweist Scaled Agile immer wieder auf den Begriff Business Agility [1]: die Fähigkeit, im digitalen Zeitalter wettbewerbsfähig zu sein und zu wachsen, indem man schnell auf Veränderungen im Markt und aufkommende Chancen mit innovativen, digital unterstützten Geschäftslösungen reagiert. Business Agility kann neben der Anwendung von Full SAFe auch mit Portfolio SAFe erreicht werden. Essential und Large Solution SAFe können Organisationen dabei helfen, komplexe Lösungen mithilfe mehrerer agiler Teams auf den Markt zu bringen.

Bei der Entscheidung für ein Framework kommt es darauf an, welches Ziel eine Organisation verfolgt: Versucht sie komplexe Anwendungen zu liefern wird ein Framework benötigt, dass dabei hilft, mehrere Teams zu koordinieren (Essential SAFe/Large Solution). Portfolio SAFe hingegen versucht die Strategie anhand von Value Streams so zu organisieren, dass durch die Umsetzung der Ziele kontinuierlich Mehrwerte erzielt werden können.

Zu den wichtigsten Kernpunkten gehört die Bildung abteilungsübergreifender Teams, die Organisation von Tätigkeiten in sogenannten Agile Release Trains (ART), sowie kontinuierliche Weiterentwicklung von Projekten, Produkten und Personen.

Die Reise mit dem Agile Release Train

Eine der wichtigsten Voraussetzungen für Agilität ist der Wegfall bisheriger Grenzen: Ein agiles Team besteht nicht nur aus IT-Spezialisten, sondern wird mit weiteren Personen besetzt, die fachlichen Input liefern können oder direkt vom entwickelten Szenario profitieren. Je nach angewandter Methodik kommt ein Scrum Master hinzu, der für die Prozessoptimierung und Hindernisbeseitigung zuständig ist und die Abläufe koordiniert, sowie ein Product Owner, der darauf achtet, dass der erzielte Output eines Teams auch den vereinbarten Anforderungen eines Produktmanagers entspricht. Der Scrum Master kann sowohl bei Scrum, ScrumXP [2] als auch bei Kanban unterstützen.

Agile Teams können Scrum und Kanban in unterschiedlichster Weise anwenden. Ein agiles Team kann innerhalb des Frameworks nach Scrum, Kanban und "Scrumban" arbeiten. Unterschiede gibt es im Framework häufig beim Wording. So wird in SAFe von agilen Teams gesprochen, die genauso aussehen können wie ein Scrum-Team, aber nicht so genannt werden.

Nach Einschätzung der Autoren kann Scrum bei der Implementierung und Anwendung von SAFe hilfreich sein, da durch das bereits gelebte Mindset die Implementierung und das Leben agiler Werte möglicherweise etwas leichter fallen kann. Trotzdem muss verdeutlicht werden, dass nicht das gesamte Scrum-Framework, so wie es gelehrt wird, in SAFe eingesetzt wird.

Zur Realisierung komplexer Projekte werden diese agilen Teams gebündelt und weitere Rollen wie Produktmanagement, Systemarchitekten und Business Owner (Stakeholder) hinzugefügt, und es entsteht ein sogenannter Agile Release Train (ART).

Genau hier liegt einer der Unterschied zur Projektentwicklung nach dem klassischen Wasserfallmodell. Längere Planungsphasen, wie im Projektmanagement gibt es in agilen Frameworks so nicht. Es wird versucht, kleinteiliger zu planen und eher den Fokus auf die Kundeneinbindung zu lenken. Die agile Vorgehensweise ist nicht das Allheilmittel und nicht für jede Organisation passend. Wenn man genau weiß, was für ein Produkt am Ende entstehen soll und ist dabei noch an starke Rahmenbedingungen gebunden, dann ist nach Meinung der Autoren eine klassische Projektplanung und Entwicklung die bessere. Sie selbst haben beispielsweise eine Planungsphase in der sie Projektpläne oder einen Business Case erstellen. In sogenannten Managementphasen versuchen sie, detailliert Arbeitspakete zu definieren, die wiederum einzelne fachspezifische Teams ausarbeiten. Nicht immer, aber häufig, werden diese Teams dabei von älteren Prozessen – und Hierarchischen Strukturen gebremst(eher allgemein und extrem dargestellt).

Im Agilen wird versucht, nicht viel Zeit in große, langfristige Planung zu stecken. Warum nicht? Dafür gibt es drei Gründe: Es ist zum einen noch nicht klar, wie das Produkt am Ende aussehen wird. Darüber hinaus können sich die Anforderungen im Laufe der Entwicklung verändern. Auch die Stakeholder sollen regelmäßig einbezogen werden, um Fortschritte aufzuzeigen oder schneller neue Anpassungen vornehmen zu können.

Da langfristige Planungen immer schwieriger werden, sind viele Unternehmen zu der agilen Denkweise gewechselt. In einer agilen Produktentwicklung und auch in SAFe ist deshalb für einen Value Stream jeweils ein "fixes" Budget eingeplant. Wenn an den Stellschrauben des agilen Dreiecks (Zeit-Kosten-Scope) etwas verändert werden soll, dann meist am Scope. Dazu werden übergeordnete "High-Level"-Ziele definiert, die in dieser Zeit und mit dem definierten Budget zu erreichen sind. Auf dem Weg dorthin werden viele neue Anforderungen zu implementieren und bestehende zu verwerfen sein. Wenn jedoch die agilen Werte und die Denkweise in der jeweiligen Organisation verstanden wurde und auch in der Praxis gelebt wird, dann entsteht am Ende eines definierten Zeitfensters eine Umsetzung, die den betreffenden Kunden zufriedenstellt.

Durch kurze Planungshorizonte, in Entwicklung eingebaute Qualität, mehr Entscheidungsspielraum für Mitarbeiter, Transparenz und häufiges Einbeziehen der Stakeholder wird das möglich. Statt für alle Aktivitäten und Projektschritte einzelne Start- und Endtermine für Implementierung, Test und Bereitstellung festzulegen, werden sie als Agile Release Trains organisiert. Mitglieder verschiedener Abteilungen arbeiten an einer gemeinsamen Lösung und entwickeln diese in klar definierten Iterationsschritten weiter. Die Teams stimmen alle Funktionen und Änderungen gemeinsam mit den Business Ownern (Stakeholder) ab und nehmen eine Priorisierung vor. Ähnlich wie ein Zug, der zu festen Zeiten Fahrgäste aufnimmt, können die einzelnen ARTs Funktionen für das nächste Release beisteuern. Innerhalb dieses Release Trains lassen sich Anpassung schnell umsetzen und Lösungen zu jedem Zeitpunkt On Demand ausliefern.

Die agile Arbeitsweise versetzt Organisationen in die Lage, Produkte schneller und effektiv auf den Markt zu bringen und strategisch weiterzuentwickeln – sofern schon Erfahrungen vorhanden sind. Auf das Service-Management bezogen bedeutet das, dass sich gängige Service-Management-Praktiken wie Änderungskontrolle, Service-Validierung und Release-Management anstelle vieler einzelner Start- und Enddaten mit einem einzigen Programmschritt verknüpfen lassen. Die Ergebnisse der einzelnen Service-Management-Praktiken können dann in die Agile Release Trains geliefert werden: Ist eine Aktivität erledigt, fährt der "Release-Zug" zum nächsten Ziel. Dieses agile Vorgehen kann den Aufwand für die Einstellung und Anpassung von Start- und Endterminen aller Aktivitäten enorm reduzieren. Aufgrund dieser strukturellen Vereinfachung entstehen klare Zeitpläne für jedes agile Team. Außerdem lassen sich Abhängigkeiten verringern/verdeutlichen, die die oben genannten Praktiken unnötig verlangsamen. Dadurch können sich Kunden und interne Stakeholder viel besser auf Änderungen (Changes) vorbereiten, die ihren Geschäftsbetrieb temporär beeinflussen können.

Koordination von Arbeitsschritten

Ein ART wird jeweils von einem Release Train Engineer geleitet. Ziel dieser Rolle ist die Prozessoptimierung für alle beteiligten Teams. Darüber hinaus hat er die Aufgabe, alle Events des gesamten ART zu organisieren und zu moderieren. Er steuert sowohl die Beseitigung von Hindernissen und arbeitet aktiv daran, die agile Arbeitsweise mithilfe von SAFe in der gesamten Organisation auszurollen. An der für die Lösung notwendigen Planung (Program Increment Planning, kurz PI Planning [3]) nimmt immer der komplette Release Train teil. Bis zu 125 Personen planen innerhalb von etwa zwei Tagen vier Iterationen mit einer Best-Practice-Dauer von jeweils zwei Wochen im Voraus. Neben den vier Entwicklungsiterationen gibt es in SAFe noch eine weitere, die sogenannte Innovation & Planning Iteration, in der ein Zeitpuffer für weitere Entwicklung, Dokumentation geschaffen wird. Neben diesem Puffer findet in dieser Iteration das PI Planning statt und es wird versucht Ergebnisse abzunehmen und mögliche Probleme zu lösen.

Reaktionen wie "Wissen Sie wie viele Personentage das sind? Über 100 Personen, die in diesen zwei Tagen doch nicht arbeiten können." zeigen einen Punkt, der in der Praxis häufig zu Staunen und Kritik führt. Solche Aussagen hören Berater in der Praxis des Öfteren. Hier gilt es zu vermitteln, warum man diesen Austausch mit allen Beteiligten benötigen und auch warum es an zwei und nicht einem einzigen Tag gemacht werden soll. Vor Corona sah die Planung für Release Train Engineers (RTE) etwa folgendermaßen aus: Einladungen und Agenda verschicken, Räumlichkeiten organisieren (häufig Hotels), Verpflegung, Anreise der Kollegen koordinieren, sowie ein Abendprogramm mit einem teamfördernden Programm organisieren. Das Event trotzdem auf zwei Tage zu splitten halt die Autoren für äußerst wichtig. Einen Tag ist bei einer Planung von vier Iterationen anstrengend für alle Beteiligten. Häufig fallen bestimmte Dinge im Anschluss des ersten Tages auf, wenn die Ergebnisse in Ruhe einem Review unterzogen werden. Wird die Planung jedoch an einem Tag erledigt, steigt die Wahrscheinlichkeit, dass im Nachgang weitere Gespräche mit Kollegen und Beteiligten des ARTs notwendig sind, um Fragen und Unklarheiten zu klären. Dies Vorgehen ist sehr ineffizient und es empfielt sich die Planung mit etwas Abstand an einem zweiten Tag zu erledigen.

Durch die andauernde Corona-Pandemie ist die physische Durchführung solcher PI Plannings derzeit nicht möglich, und das Team hinter Scaled Agile musste überlegen, wie sie derartige Treffen auch digital realisieren können. Dafür werden stabile Audio-, Video- und Visualisierungstools benötigt. Nach anfänglicher Skepsis zeigte sich jedoch, dass es funktionieren kann. Notwendig sind vor allem klare Regeln, eine veränderte Meeting-Kultur. Die Einarbeitung in die verwendeten Tools stehen dabei jetzt im Fokus und sind unumgänglich. Es ist möglich, dass nach der Pandemie viele Unternehmen bei der digitalen Variante bleiben. Es funktioniert ebenso und spart zudem Geld.

Dennoch sollte man in Zukunft nicht komplett auf eine physisch durchgeführte PI Plannings verzichten. Fast jeder wird im Homeoffice bei Telefonkonferenzen und Schulungen abgelenkt und erledigt viele Dinge parallel. Dabei kommt es häufig vor, dass Informationen nicht aufgenommen werden oder verloren gehen. Dieser Informationsverlust muss im Nachgang wieder ausgeglichen werden und kostet wieder Zeit. Da der Teamgedanke und die Dynamik eines ART sehr starken Einfluss auf den Erfolg einer Lösungsentwicklung hat, halten die Autoren es für sinnvoll, dass PI Plannings künftig als Wechselmodell durchgeführt werden. Release Train Engineers sollten dabei immer auf klare Regeln achten und die Teilnehmenden des betreffenden ARTs vorab informieren, was sie in diesen zwei Tagen erwartet.

Als Best Practice zur anschließenden Umsetzung haben sich zweiwöchige Iterationen bewährt, sodass jedes Team versucht, acht Wochen im Voraus zu planen. In enger Zusammenarbeit mit Business-Ownern werden Anforderungen und Ziele definiert und anschließend als Aufgaben an die einzelnen Teams verteilt. Diese schätzen ihre Kapazitäten und Aufwände und verteilen die notwendigen Aktivitäten auf ihre Iterationen. Der Vorteil dieser "Großraumplanung" besteht darin, dass alle Teams gemeinsam an einem klar definierten Ziel arbeiten sowie Abhängigkeiten ermitteln und visualisieren können. Auch mögliche Risiken lassen sich häufig direkt klären, sodass die Teams sie bereits bei der Priorisierung und Zeitplanung berücksichtigen können. Nach Abschluss der Planungsphase werden im Optimalfall folgende Ziele erreicht:

Herausforderungen bei der Einführung von SAFe

Einige Organisationen entscheiden sich für eine Skalierungsform nach SAFe, ohne dass sie überhaupt skalieren müssen. Führungskräfte sollten sich die Frage stellen, ob ihre Organisation lediglich Produkt- und Lösungsentwicklung betreiben soll oder sie tatsächlich organisatorische Veränderung anstreben. In beiden Fällen kann SAFe helfen, jedoch sollten sie sich entscheiden, ob sie zum Einführungszeitpunkt die Konfigurationen Essential, Portfolio, Large Solution oder Full SAFe implementieren wollen. Der eigentliche Erfolg hängt in hohem Maße vom passenden Mindset ab und erfordert einen starken Mitarbeiterfokus:

Agiles Mindset: Führungskräfte müssen in Entwicklungsteams die Bereitschaft erzeugen, agil mit Menschen aus anderen Abteilungen an einer gemeinsamen Aufgabe zu arbeiten. Sie sollten auf sie gut vorbereitet werden und genügend Freiraum erhalten, sodass sie sich eigenständig entwickeln und auf die vereinbarten Aufgaben und Ziele fokussieren können. Das bedeutet auch, dass der ganze Fokus auf den agilen Teams und dem Agile Release Train liegen muss.

Transparenz schaffen: Organisationen sollten Transparenz in Entwicklungs- und Unternehmensabläufe bringen und auf klassische Reports an Vorgesetzte oder Management verzichten. Teams und Stakeholder wissen dadurch genau, woran andere gerade arbeiten und können sich somit zu jeder Zeit mit allen Informationen versorgen, die sie für ihre Arbeit benötigen.

Kontinuierliche Weiterentwicklung: Teams müssen die Möglichkeit erhalten, sich gemeinsam zu verbessern und weiterzubilden. In SAFe ist dazu sogar eine eigene Iteration (Innovation and Planning Iteration) enthalten, in der Zeit für persönliche Weiterentwicklung, innovative Entwicklungsmöglichkeiten, Entwicklungspuffer und PI-Planning vorgesehen ist.

Fehlerkultur etablieren: Fehler sind ein wichtiger Bestandteil in der agilen Entwicklung. Sie müssen ausdrücklich erlaubt sein, jedoch transparent gemacht werden. Die Transparenz stellt sicher, dass die Probleme oder Missgeschicke nicht erneut geschehen und die Teams erfahren, wie sie sie vermeiden können. Darüber hinaus sollte man ausreichend Zeit zur Fehlerbeseitigung einräumen.

Zusammenhalt stärken: In der Praxis ist die Eigendynamik, die innerhalb agiler Teams besteht, sehr gut zu erkennen – insbesondere, wenn sie selbstorganisierend arbeiten. Führungskräfte sollten deshalb darauf achten, dass sie diesen Prozess durch zu viele Umstrukturierungen nicht unnötig ausbremsen.

Prinzipiell kann jedes Unternehmen mit SAFe arbeiten, sofern die dafür notwendigen Rahmenbedingungen (Mindset, Ressourcen, Strukturen, Werte) vorhanden sind. Für die Auswahl der passenden Konfiguration kommt es auf das zu entwickelnde Produkt oder die Umsetzung und dessen Komplexität an: Für Organisationen, die einzelne Bereiche – beispielsweise ihr eigenes Service-Management – agiler gestalten wollen, sind Essential SAFe oder Portfolio SAFe gute Startoptionen. Wollen Führungskräfte jedoch das volle Potenzial agiler Methoden ausschöpfen, Business-Agilität erreichen und große komplexe Lösungen liefern, dann ist die Konfiguration Full SAFe mit hoher Wahrscheinlichkeit die bessere, aber gleichzeitig auch die schwierigste Implementierungsform. Für den Start eignet sich Essential SAFe. Gleichzeitig sollte man versuchen, die Denkweise fest im Portfolio-Level zu verankern.

SAFe ist sicherlich besonders für Softwareunternehmen interessant. Doch auch in anderen Bereichen ist der Wunsch nach Effizienz, Geschwindigkeit und Flexibilität allgegenwärtig. Die Entwickler von Scaled Agile haben sich deshalb in ihrer Terminologie ganz bewusst für den unscharfen Begriff "Solution" entschieden. Neben komplexen Produkten lassen sich mit SAFe auch Services, IT-Systeme oder Dienstleistungen entwickeln. Auf Portfolioebene werden beispielsweise Ideen für neue Services evaluiert und ermittelt, nach welchen der Markt auch tatsächlich verlangt. Anschließend werden sie priorisiert und können dann von einzelnen Agile Release Trains aufgenommen und entwickelt werden. Doch auch wenn die Erwartungen hoch sind, Entscheider sollten beim Start mit SAFe das Wort "schnell" besser aus ihrem Wortschatz streichen. Organisationen und Teams brauchen erst genügend Zeit, um sich mit der agilen Methodik vertraut zu machen, sodass sie sich später voll auf die eigentliche Entwicklung fokussieren können. Erst wenn Teams die oben genannten Aspekte verinnerlicht haben, können Organisationen die Entwicklung und Einführung von Services effizienter gestalten – und damit auch schneller werden.

Es steht außer Frage, dass sich SAFe nicht eins zu eins auf jede Organisation anwenden lässt. Aktuell sind es insbesondere Konzerne und große Unternehmen aus der Automobil- und Kommunikationsbranche, die mit der schrittweisen Einführung von SAFe begonnen haben und damit ihre Organisationsstrukturen verändern und effizienter gestalten wollen.

Unabhängig von der Entscheidung für eine Konfiguration liegt der Vorteil des SAFe-Frameworks darin, dass alle an der Entwicklung beteiligten Personen zusammenarbeiten können. Die Erfahrungen haben gezeigt, dass der Prozess auch in Zeiten von Homeoffice bei korrekter Implementierung gut funktioniert. Über entsprechende Tools kann jederzeit ein offener Austausch stattfinden, bei dem der Fokus auf Abhängigkeiten und der stetigen Verbesserung von Produkt und Arbeitsprozessen liegt. Business Owner haben dabei beispielsweise intensiven Kontakt mit Entwicklern. Diese erfahren quasi aus erster Hand, warum beispielsweise gewisse Features höher priorisiert oder in eine bestimmte Richtung entwickelt werden.

Organisationen, die SAFe jedoch lediglich als neues Tool zur Skalierung von Scrum sehen, raten die Entwickler des Tools von einer Implementierung ab, denn sie werden nicht den gewünschten Effekt erzielen. Erst wenn sie die notwendigen Organisationsstrukturen schaffen, Offenheit und Transparenz garantieren sowie eine auf mehrere Ebenen verteilte Implementierung durchführen, werden sie liefern können, was Kunden oder Business verlangen: schnelle Mehrwerte und höhere Agilität

In der Praxis hören Berater häufiger kritische Fragen zu SAFe. Auf einige soll der Artikel ein paar Antworten geben.

SAFe ist doch nur neuer Wein aus alten Schläuchen?! Nicht direkt. SAFe bedient sich an schon "älteren" Frameworks und Methoden, das stimmt – bietet aber dazu noch weitere Vorgehensweisen, wie das PI Planning oder der Agile Release Train und versucht dadurch neuere "Modelle" mit bereits bestehenden zu kombinieren.

SAFe behauptet agil zu sein, aber durch die vielen Strukturen und Rollen geht doch eher Agilität verloren? Agil bedeutet nicht, dass Strukturen oder Rollen fehlen oder unnötig sind. Besonders in der Anfangszeit sind diese zwingend erforderlich. Wenn sich Erfolge zeigen, das Mindset in der gesamten Organisation verändert und agile Werte gelebt werden, können diese Strukturen etwas gelockert werden, um mehr Freiraum zu ermöglichen.

SAFe stoppt doch jegliche Flexibilität. In der Tat gibt es Frameworks wie LESS, das nach Einschätzung der Autoren um einiges agiler ist als SAFe. Warum? Weil LESS in den Scrum-Rollen bleibt und nur wenige bis keine hierarchische Strukturen bietet. Es soll dabei so viel wie möglich an die Entwicklungsteams übertragen werden, sodass Selbstorganisation noch stärker im Fokus steht. Das bedeutet jedoch nicht, dass SAFe keine Flexibilität ermöglicht. Es dient dazu agile Methoden einzuführen und Unternehmen dabei zu unterstützen. Die Umsetzung und Anpassungen können aufgrund der notwendigen Strukturen jedoch etwas länger dauern.

Gibt es in SAFe zu viele Rollen? Eine allgemeingültige Antwort ist nur schwer zu geben. Zusätzlich zu den bekannten Scrum-Rollen finden sich bei SAFe das Produktmanagement oder der Release Train Engineer. Oft herrscht Unklarheit bezüglich des Unterschieds zwischen Product Owner und Produktmanagement. Jedes agile Team hat einen Product Owner. Dieser ist, wie aus Scrum bekannt, für den Output eines Teams zuständig. Die übergeordnete Rolle Produktmanagement ist für den gelieferten Output aller agilen Teams verantwortlich – und damit sinnvoll und notwendig. Nach Ansicht der Autoren gibt es nicht zu viele Rollen in SAFe, wenn ...

Je nach Komplexität des Projektes können Aufgaben auf weniger Personen verteilt werden – beispielsweise kann ein Scrum Master mehrere agile Teams betreuen. Damit das funktioniert, müssen mindestens die oben genannten Punkte erfüllt sein und erste Erfahrungen bei der Entwicklung vorhanden sein.

Agil mit Vorbereitung

Viele Organisationen, die zum ersten Mal mit SAFe in Kontakt kommen, sehen in dem Framework vor allem ein Tool zur effizienten Produktentwicklung mit mehreren Teams. Gleichzeitig erhoffen sie sich dabei Antworten auf die Frage, wie sie schneller und effizienter in dynamischen Märkten agieren können. Doch genau darin steckt die Gefahr. Die eigentlich angestrebte Business-Agilität ist eine Fähigkeit, die den Willen zu agiler Zusammenarbeit voraussetzt und sich nicht per Knopfdruck einführen lässt. Das bedeutet im Klartext: Damit Teams mit dem Framework sinnvoll arbeiten können, sollten bereits im Vorfeld die richtigen Voraussetzungen geschaffen werden, nämlich ein passendes Mindset, gemeinsame Werte sowie die Bereitschaft zu Transparenz und gemeinsamer Weiterentwicklung.

Zudem müssen Organisationen, die über lange Jahre gepflegte Kluft zwischen Business und IT endlich schließen und Mitarbeiter von Fachabteilungen enger mit den Entwicklern zusammenbringen. Die Schaffung der Grundlagen für eine agile Organisation ist also mindestens genauso anspruchsvoll wie die Einführung der eigentlichen Methoden/Frameworks. Der dafür notwendige Change-Prozess sollte ein Sponsor aus dem Management initiieren und ein erfahrener Manager begleiten und umsetzen. Dieser sollte nicht nur über die klassischen Kenntnisse der Teamführung verfügen, sondern Mitarbeiter vor allem für agile Methoden begeistern können.

Insbesondere in der Startphase ist es für Führungskräfte wichtig, ihre Erwartungen an SAFe sowie klare Ziele für sich und die Organisation zu definieren – und in kleinen Schritten zu starten. Rückschläge werden dabei nicht ausbleiben. Dabei sollten alle Schritte kritisch hinterfragt werden. Scaled Agile bietet mit seinem Big Picture eine Übersicht, die für manche gleichzeitig Fluch und Segen sind. Vor allem für Personen, die sich bislang noch nicht wirklich mit diesem Framework beschäftigt haben, kann das Big Picture eher abschreckend und überlastend wirken. Scaled Agile lockt mit dem Gedanken Ad Hoc auf Agile umstellen zu können. Ein schwieriger Punkt, der in der Praxis schon häufig zu Unverständnis und Frustration geführt hat. Viele haben Ad Hoc begonnen und haben den Zug sehr schnell gegen "die Wand gefahren".

Trotzdem sollte klar sein, dass man gewisse Erfahrungen gesammelt haben muss, um sich mit solchen Skalierungsthemen auseinanderzusetzen, da ansonsten die Implementierung schwer wird und länger dauern kann. Es empfiehlt sich, sich die Zeit zu nehmen, Agilität zu verstehen und zu leben und versuchen, langsam aber sicher die Strukturen der Skalierung einzubauen. Gleichzeitig gilt es darauf zu achten, genügend Freiraum für Entwicklung und Misserfolge zu lassen. Doch der anfängliche Schmerz sorgt für wichtige Erfahrungen, die die gesamte Organisation ihrem Ziel näherbringt: Marktgerechte Produkte, zufriedene Kunden und Mitarbeiter sowie eine positive Unternehmenskultur.

Scaled Agile bietet viele verschiedene Kurse zum Thema SAFe. Für alle die wissen wollen, was SAFe ist und eine Gesamtübersicht von dem Framework erhalten möchten, empfehlen die Autoren des Artikels das Leading SAFe Training. Dieses Training gibt eine gute Übersicht und reicht vollkommen aus, um einen Ersten Einblick in das Framework zu bekommen. Zu jeglichen Rollen innerhalb dieses Frameworks wird ebenfalls ein Training angeboten, das einen tieferen Einblick in die Aufgaben bieten soll. Zertifiziert ist man dann, wenn nach dem Training auf der Online Plattform von Scaled Agile eine Prüfung abgelegt wird. Diese unterscheiden sich in Zeit und Fragenpool. Durch das Bestehen der Prüfung, erhalten Interessierte einen Zugang für die Community-Plattform, auf der sie viele weitere Tools und Techniken kostenfrei wiederfinden.

Moritz Wagner
ist als Senior Consultant bei SERVIEW für alle agile Skalierungsprodukte verantwortlich und Lead Trainer für das Thema SAFe. Er verfügt über tiefgreifende Erfahrungen mit agilen Projekten und hat bereits zahlreiche Unternehmen bei der Implementierung und Skalierung mit SAFe unterstützt.

Peter Schneider
ist als Chief
Product Officer bei Efecte für den Bereich Produktmanagement verantwortlich. Er ist seit 2014 im Service Management tätig und hat zahlreiche Projekte im Bereich Enterprise and IT-Lösungen erfolgreich umgesetzt.

(mdo [4])

URL dieses Artikels:
https://www.heise.de/-6001726

Links in diesem Artikel:
[1] https://www.scaledagileframework.com/business-agility/
[2] https://www.scaledagileframework.com/business-agility/
[3] https://www.scaledagileframework.com/pi-planning/
[4] mailto:mdo@ix.de

Copyright © 2021 Heise Medien