Seite 2: Koordination von Arbeitsschritten

Inhaltsverzeichnis

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

• Alle Teams haben ihre Iterationspläne und Leistungsziele für den gesamten Entwicklungszeitraum (in der Regel für die nächsten acht Wochen) erstellt und alle Abhängigkeiten visualisiert.
• Mögliche Risiken wurden identifiziert, verteilt und im besten Fall schon im Vorfeld gelöst.
• Die einzelnen Teams können zeitgleich mit ihrer Entwicklung starten und hören zeitgleich auf.
• Innerhalb dieser Iterationen arbeiten die Teams häufig nach Scrum, Kanban oder einer Mischung aus beiden Methodiken.

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.

SAFe im Einsatz

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