XXL-Projekte mit agilen Methoden bewältigen

In den letzten 20 Jahren wurden agile Modelle für die Software-Entwicklung wie Extreme Programming, Feature Driven Development oder Scrum immer beliebter. Sie setzen auf flexibles Arbeiten statt auf lange Planungsphasen und starre Projektvorschriften. Längst ist das Konzept nicht mehr nur auf die Software-Entwicklung beschränkt, komplette Unternehmen sollen heute nach agilen Prinzipien funktionieren.

Scrum und andere agile Ansätze lassen sich jedoch nicht ohne Weiteres auf größere Projekte oder ganze Organisationen übertragen, da sie für kleine Teams konzipiert sind. Eine Reihe von Framework-Initiativen tritt an, diese Beschränkung mit „Large-Scale Agile Frameworks“ zu überwinden und agile Methoden auch im großen Maßstab nutzbar zu machen. Die wichtigsten werden im Folgenden vorgestellt.

Scaled Agile Framework (SAFe): Das von dem Methodiker Dean Leffingwell gegründete Framework ist das älteste und derzeit am meisten genutzte Large-Scale Agile Framework. Laut dem von dem Software-Hersteller Collab.net VersionOne herausgegebenen „12th State of Agile“-Report aus dem Jahr 2018 verwenden 29 Prozent aller befragten Unternehmen, die Methoden und Ansätze zur Skalierung nutzen, das Scaled Agile Framework. SAFe ist ab einem Projektumfang von 50 bis 60 Mitarbeitern einsetzbar, im Wesentlichen aber für sehr große Umgebungen mit Tausenden von Beteiligten konzipiert. Das Framework, das aktuell in Version 4.6 vorliegt, deckt nahezu alle Anwendungsfälle ab und gibt detaillierte Handlungsempfehlungen, es ist allerdings auch sehr komplex. „SAFe ist inzwischen mindestens so umfangreich wie ein Bachelor-Studium“, erklärt Peter Vollmer, Solution Architect & Agile Evangelist beim Software-Unternehmen Micro Focus. „Es gibt ungefähr 150 Fachbücher und zahlreiche Fachbeiträge zu den verschiedenen Aspekten des Frameworks.“ Vollmer muss es wissen, denn als SAFe 4 Certified Program Consultant Trainer (SPCT) hat er die höchste Stufe im Zertifizierungsprogramm des Frameworks erreicht und darf andere SAFe-Trainer ausbilden. Selbst er tut sich schwer, die rasante Weiterentwicklung in den unterschiedlichen Teilbereichen in der Tiefe zu verfolgen. „Es geht nicht nur um neue Aspekte, die in das Framework aufgenommen werden, sondern auch um die Bewertung aktueller Trends, um an der Entwicklung neuer SAFe-Versionen mitwirken zu können“, erläutert der Experte. Besonders positiv bewertet Vollmer das umfangreiche Angebot an Schulungen und Kursen. „Die Trainings bauen nach dem Multiplikatorenprinzip aufeinander auf, sodass ich intern sehr schnell Skalierungseffekte erzielen kann, statt teuer externe Coaches einkaufen zu müssen.“

Laut den vielen Case-Studies auf der SAFe-Homepage verkürzt das Framework die Zeit bis zur Markteinführung um 30 bis 75 Prozent. Es steigert die Produktivität um 20 bis 50 Prozent, die Qualität der Produkte um 25 bis 75 Prozent und die Mitarbeiterzufriedenheit um 10 bis 50 Prozent. Solche Angaben sind allerdings mit Vorsicht zu genießen, warnt Micro-Focus-Experte Vollmer: „Es kommt schließlich immer auf die Ausgangswerte an, auf denen sie basieren.“

Large-Scale Scrum (LeSS): Das Framework LeSS wurde von den Agile Coaches Bas Vodde und Craig Larman für die agile Produktentwicklung mit maximal acht Teams und jeweils acht Mitgliedern pro Team konzipiert, kann aber als „LeSS Huge“ auch in Umgebungen mit einigen Tausend Projekt­beteiligten eingesetzt werden. Wie der Name schon andeutet, versteht sich LeSS vor allem als eine Skalierungsmethode für Scrum. Viele Komponenten dieses Konzepts werden übernommen. So gibt es einen gemeinsamen Product Backlog für alle Teams, einen Product Owner und eine gemeinsame DoD (Definition of Done). Alle Teams arbeiten am selben Sprint, an dessen Ende ein funktionsfähiges Produkt steht. Ergänzend kommen unter anderem gemein­same Sprint-Planungssitzungen und Retrospektiven hinzu.

LeSS bietet wesentlich weniger Strukturen und macht weniger Vorgaben als etwa SAFe. „Auf viele Fragen, die bei der Skalierung von agilen Projekten auftreten, findet man in LeSS keine direkte Antwort“, berichtet Peter Vollmer. Die Offenheit von LeSS kann auch zu Problemen führen, wenn es gilt, Dienstleister in Projekte einzubinden oder Compliance-Regeln zu erfüllen. „SAFe geht mit solchen Herausforderungen deutlich strukturierter um“, betont Christian Kabelin, der als Principal Enterprise Architekt bei Ventum Consulting Kundenprojekte vor allem im Automobilbereich betreut.

Die LeSS-Webseite listet eine Reihe von Fallbeispielen auf - Banken wie JP Morgan Chase und UBS und Telekommunikationsanbieter wie Ericsson und Huawei. Auch der Autokonzern BMW gehört zu den LeSS-Nutzern und hat nach den Prinzipien des Frameworks eine Vertriebsplattform (Unified Sales Platform, USP) für das Elektromobil BMW i aufgebaut. Mark Bregenzer vom Coaching-Unternehmen Valtech, das das Projekt betreute, zieht eine positive Bilanz: „LeSS und agile Prinzipien boten eine ausgezeichnete Führung während des gesamten Projekts und waren in vielen Fällen die Grundlage für kritische Projektentscheidungen.“

Nexus: Das von Ken Schwaber, einem der Väter von Scrum, entwickelte Rahmenwerk ist für zwei bis neun Scrum-Teams konzipiert. Bei größeren Projekten werden weitere Nexus-Einheiten gebildet. Wie diese zusammenarbeiten sollen, wird im Modell allerdings nur minimal beschrieben.

Das Framework will Abhängigkeiten zwischen parallel arbeitenden Teams reduzieren und die Integration der Teilergebnisse erleichtern. Es definiert dafür das „Nexus Integration Team“, das die Teams koordinieren und coachen soll. Wie bei LeSS nutzen auch bei Nexus alle Scrum-Teams dasselbe Product Backlog. Um die Transparenz zu erhöhen, gibt es zusätzlich ein Nexus Sprint Backlog, in dem die Abhängigkeiten und der aktuelle Arbeitsstand der einzelnen Teams dokumentiert werden.

Am Ende jedes Sprints steht ein integriertes Inkrement, das funktionsfähig und potenziell releasebar sein muss. Nexus versteht sich als leichtgewichtiges Framework, das möglichst wenig Vorgaben macht. Laut Peter Vollmer lässt es sich gut mit SAFe kombinieren. „Nexus bietet eine gute Zwischenebene für die Skalierung mit SAFe.“

Disciplined Agile (DA): Dieses oft auch als DAD (Disciplined Agile Delivery) abgekürzte Rahmenwerk will Unternehmen Orientierungshilfen bei der Umsetzung einer agilen Strategie liefern. Es basiert auf sieben Prinzipien:

DA ist für mittlere bis große Projekte konzipiert und bietet eine Vielzahl von Optionen. Das hat laut Peter Vollmer Vor- und Nachteile: „Es braucht sehr viel Wissen und Durchsetzungsvermögen, um mit DA eine Organisation zu transformieren“, weiß der Micro-Focus-Experte. „Andererseits lässt sich das Framework bei richtiger Anwendung auch sehr gut an die konkrete Unternehmenssituation anpassen.“ Das Schulungs- und Zertifizierungsangebot von DA basiert auf einem Konzept aus der japanischen Kampfkunst, das die Entwicklung hin zum Meister in die drei Stufen „Shu“ (= Lernen, Wissen erwerben), „Ha“ (= Loslösen, Verstehen) und „Ri“ (= Überwinden, zum Meister werden) einteilt.

Neben SAFe, LeSS, Nexus und DA gibt es eine ganze Reihe weiterer Frameworks und Methoden, um agile Projekte zu skalieren. Zu nennen wäre zum Beispiel das Modell des Streaming­anbieters Spotify, das etwa bei ING DiBa und Deutscher Telekom Anwendung findet. Es definiert vier Stufen der Organisation: „Squads“ entsprechen in etwa den Feature Teams in Scrum und bestehen aus nicht mehr als acht Personen. Mehrere Squads, die gemeinsam an einem Projekt arbeiten, bilden einen „Tribe“. Innerhalb eines Tribes schließen sich Spezialisten mit gemeinsamen Kenntnissen und Fähigkeiten zu Squad-übergreifenden „Chapters“ zusammen.

Und dann gibt es in diesem System auch noch „Gilden“, informelle Zusammenschlüsse von Mitarbeitern verschiedener Tribes, die gemeinsame Interessen verfolgen. Über allem wacht der „Chief Architect“, der die Architektur des Systems definiert und Abhängigkeiten im Blick behält. Obwohl das Spotify-Modell auf den ersten Blick kompliziert wirkt, gilt es als sehr flexibel, weil es Abhängigkeiten und komplexe Prozesse weitgehend vermeidet und die Autonomie der Mitarbeiter stärkt. Diese Autonomie kann laut Experte Vollmer allerdings auch zum Problem werden: „Ich brauche sehr erfahrene Leute, um ein solches offenes Konzept zum Erfolg zu führen.“

Scrum@Scale schließlich wurde von Jeff Sutherland entwickelt, der wie Ken Schwaber zu den Begründern von Scrum gehört. Das Framework verspricht die effiziente Koordina­-tion einer unbegrenzten Zahl von Scrum-Teams durch eine „scale-free“ Architektur, die keine starren Regeln vorgibt, sondern ein organisches Wachstum ermöglichen soll. Wie bei Scrum wird die Definition, was produziert werden soll, von der Frage, wie es produziert wird, getrennt betrachtet. Dabei wacht ein „Chief Product Owner“ über das Was, ein „Chief Scrum Master“ über das Wie. Ein Executive Action Team (EAT) steht im Zentrum der Entwicklung. Es besteht aus höherrangigen Managern, die Probleme lösen und Schwierigkeiten aus dem Weg räumen. Peter Vollmer bezweifelt allerdings, dass sich große Projekte so einfach in einem skalierten
Scrum-System abbilden lassen: „Skalierung ist nicht so rekursiv wie es in Scrum@Scale dargestellt wird.“

Nicht alle Experten sind vom Sinn der Frameworks überzeugt. „Ich habe bisher noch keinen Kunden gesehen, der ein solches Framework out of the box eingesetzt und damit den gewünschten Erfolg erzielt hat“, berichtet Fabian Schiller, Agiler & Scrum Coach beim Beratungsunternehmen Agile Elevation. Allenfalls eigneten sich die Frameworks als Methodenbaukasten für die Lösung organisatorischer Probleme, die in großen agilen Projekten auftreten können. Schiller warnt daher davor, sich zu dogmatisch an ein Framework zu halten: „Das ist fast schon eine Garantie für den Misserfolg.“

Christian Kabelin von Ventum Consulting sieht das ähnlich: „Viele verfolgen agile Prinzipien mit nahezu religiöser Überzeugung, ohne einen Blick für die Herausforderungen und Bedürfnisse der Gesamtorganisation zu haben“, kritisiert der Consultant. „Das führt zu großen Spannungen und frustriert letztendlich alle.“ Wichtiger als die Wahl eines Frameworks seien eine Veränderung der Denkweise, ein agil handelndes Management, Kompetenzentwicklung und Änderungsbereitschaft. „Das sind aus meiner Erfahrung die größten Hebel, um ein Unternehmen agil zu transformieren.“

Vorbehalte gegenüber den Frameworks gibt es auch bei vielen Unternehmen. Laut dem eingangs erwähnten „12th State of Agile“-Report setzen viele Befragte auf alternative Ansätze. So nutzen 19 Prozent das Scrum-Paradigma auch in großen Projekten und erweitern es lediglich um ein zusätzliches Meeting mit Mitgliedern der einzelnen Scrum-Teams, das „Scrum of Scrums“. Bei weiteren 10 Prozent kommen selbst entwickelte Methoden zum Einsatz. Beliebt sind auch Ansätze wie Lean Management und Agile Portfolio Management (APM), das klassische Methoden des Portfolio-Managements mit agilen Ansätzen kombiniert.

An einer Alternative zu Large-Scale Agile Frameworks arbeitet der Lehrstuhl Software Engineering for Business Information Systems (sebis) an der TU München. Der Lehrstuhl, der seit vielen Jahren im Bereich Enterprise Architecture Management (EAM) forscht, stellte früh fest, dass Unternehmen Regelwerke nicht buchstabengetreu einführen. „Frameworks werden nie eins zu eins umgesetzt, sondern immer an die Unternehmensanforderungen angepasst“, weiß Lehrstuhlinhaber Florian Matthes. Die Forscher leiteten aus ihren Beobachtungen ein System von Patterns ab - Musterlösungen für typische, immer wieder auftretende Herausforderungen. Im Unterschied zu den Frameworks gibt es dabei nicht eine Antwort für ein Problem, sondern verschiedene Alternativen, die je nach Kontext mehr oder weniger sinnvoll sind. Bereits 2008 publizierte der Lehrstuhl dazu einen EAM-Pattern-Katalog, der mittlerweile in einer zweiten Version vorliegt. Er beschreibt Muster in den Methoden (M-Patterns), Perspektiven (Viewpoint, V-Patterns), dem Informationsmodell (I-Patterns) und der Datenerhebung (Data Collection, DC-Patterns).

Eine Arbeitsgruppe um den wissenschaftlichen Mitarbeiter Ömer Uluda arbeitet derzeit an einem analogen Katalog für den Bereich Large-Scale Agile Development. Er definiert Muster der Koordination (Coordination, C-Patterns), der Methoden und Prinzipien (M- und P-Patterns) und der Perspektive (V-Patterns). Außerdem gibt es sogenannte Anti-Patterns die verlockend und sinnvoll erscheinen, agile Projekte aber typischerweise zum Scheitern bringen oder zumindest behindern. „Anti-Patterns sind eine Art
Katzengold der agilen Entwicklung“, erläutert Matthes.

Der Katalog basiert im Wesentlichen auf den Erfahrungen, die Uluda und Kollegen aus der Beobachtung konkreter Projekte gewinnen. „Wir arbeiten mit großen Einzelhandelsketten wie Media Markt Saturn, Automobilherstellern und Versicherungsunternehmen wie der Versicherungskammer und der Allianz zusammen und beobachten, wie dort große agile Vorhaben umgesetzt werden“, erklärt Matthes. Auch Christian Kabelin von Ventum Consulting ist an den Projekten beteiligt: „Wir untersuchen gemeinsam, wie die agile Adaption vom Reifegrad her voranschreitet.“

In den Projekten wird strukturiert erfasst, welche Prozesse und Rollen vorkommen, welche rollenspezifischen Herausforderungen es gibt und wie die Firmen darauf reagieren. Methodenmuster, die dabei mindestens drei Mal auftreten, werden in den Pattern-Katalog aufgenommen. Der Kritik von anderen Wissenschaftlern, dem Pattern-Ansatz fehle es an einer theoretischen Grundlage, begegnet Matthes mit Gelassenheit: „Das Verhalten in Organisationen wird durch so viele Einflussfaktoren geprägt, die sehr wenig rational sind“, erklärt der Professor. „Daher ist es sinnvoll, empirisch zu untersuchen, was funktioniert und was nicht.“

Große Projekte oder ganze Unternehmen agil zu transformieren, ist eine enorme Herausforderung. Frameworks bieten dafür Leitplanken und Möglichkeiten der Erfolgskontrolle. Je nach Komplexität des Frameworks erfordert sein Einsatz jedoch ein gerüttelt Maß an Wissen, auch Zeitaufwand und Kosten können erheblich sein. Dennoch lohnt es, vor der Skalierung agiler Ansätze einen näheren Blick auf die Frameworks zu werfen - nicht um dann eines dogmatisch umzusetzen, sondern um Ansätze und Ideen zu verstehen und ihre Anwendbarkeit auf die eigene Situation evaluieren zu können. Am Ende zählt weniger die Wahl des richtigen oder falschen Frameworks, sondern viel mehr, wie das agile Denken in den Alltag integriert wird.