Weitere Frameworks

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.