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

Inhaltsverzeichnis

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: 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 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.