Methoden und Wissen
Agile Systeme skalieren: Warum es kein Patentrezept gibt
27. Juli 2026 / Annekathrin Gut
Ein Team lernt Scrum in wenigen Wochen. Schwierig wird es, wenn das Produkt mit der Zeit so groß geworden ist, dass es ein einzelnes, iterativ arbeitendes Team nicht mehr allein bearbeiten kann. Wenn mehrere Teams gemeinsam an derselben Produktentwicklung arbeiten müssen, schlägt die Stunde der agilen Skalierung: Ein Framework wird eingeführt, mehrere Teams werden geschult, alle Rollen werden besetzt. Einige Zeit später stellen viele Unternehmen fest: Es hakt.
Entwicklung wird komplizierter
Oliver Schaper begleitet als agiler Berater der HEC seit Jahren genau solche Vorhaben. Zwei Herausforderungen tauchen nach seiner Erfahrung fast immer auf. Die erste entsteht ganz am Anfang: Ein großer Arbeitsvorrat muss in Aufgaben zerlegt werden, die einzelne Teams tatsächlich bearbeiten können. „Da der Backlog riesig ist, brauchen Produktverantwortliche sehr viel Erfahrung und sehr viel Fingerspitzengefühl, wie aus großen Aufgabenpaketen handhabbare Stories werden“, weiß Oliver Schaper.
Die zweite Herausforderung zeigt sich erst im laufenden Betrieb: Teams können sich nicht ausreichend synchronisieren. Abhängigkeiten, die innerhalb eines Teams noch überschaubar sind, vervielfachen sich, sobald mehrere Teams am selben Produkt beteiligt sind. „Dem kann man nur mit exzellenter Planung begegnen“, so Schaper.
Drei Projekte, ein wiederkehrendes Muster
Dieses Muster zeigt sich beispielhaft in drei Projekten, die wir beraten haben:
Ein Finanzdienstleister aus dem Automobilsektor hatte das Scaled Agile Framework (SAFe) schon seit Jahren etabliert. Trotzdem arbeiteten die Teams nur teilweise am selben Produkt und stimmten sich kaum ab. Die Analyse zeigte: Die meisten Störungen entstanden außerhalb der eigentlich dafür vorgesehenen SAFe-Termine, weil dort schlicht zu wenig Zeit für die relevanten Themen blieb. Die Lösung war gezielt und wirksam: genau zugeschnittene Meetings, teils sogar zusätzliche, dafür aber deutlich kürzere Termine. In Summe bedeutete das weniger Aufwand bei mehr Klarheit.
Bei einem europäischen Versicherungskonzern war die gesamte IT in SAFe geschult worden. Der verantwortliche Release Train Engineer konnte die stark funktional aufgeteilten Teams jedoch nicht mehr synchronisieren. Es zeigte sich, dass selbst Teams aus demselben Unternehmensbereich, die ähnliche Probleme schilderten, nicht mit denselben Lösungen geholfen werden konnte. Hier wurde der Wunsch nach einem einheitlichen Vorgehen bewusst durchbrochen – zugunsten einer individuellen Herangehensweise pro Team.
Standardframeworks stießen auch bei einem mittelständischen Unternehmen aus der Energiewirtschaft an ihre Grenzen. Hier sollten bis zu zehn Software- und Hardware-Entwicklungsteams in einem skalierbaren, agilen Vorgehensmodell am selben komplexen Produkt zusammenarbeiten. Doch kein einzelnes bekanntes Framework passte auf diese Konstellation. Deshalb wurden Elemente aus mehreren Skalierungsmodellen, etwa LeSS, Nexus und dem Spotify-Modell, zu einem eigenen Vorgehen kombiniert.
Warum bekannte Frameworks oft die falsche Antwort sind
Die drei Fälle illustrieren, wovor Oliver Schaper eindringlich warnt: „Niemals überhastet auf ein Modell setzen, nur weil es den Anschein macht, es hätte eine Best-Practice-Lösung in der Tasche.“ Besonders größeren Unternehmen setzen häufig auf SAFe. In der Praxis werde das Rahmenwerk jedoch oft anders eingesetzt, als es gedacht sei: „SAFe ist ausschließlich für das gemeinsame skalierte Arbeiten an einem einzigen Produkt gedacht. Die Praxis sieht aber in den meisten Organisationen anders aus. Gerade im technischen Betrieb gibt es fragmentierte Produktumgebungen und Services, die nach einer sinnstiftenden Synchronisation verlangen. Das ist etwas völlig anderes.“
Bevor Unternehmen ein Modell wählen, sollten sie erstmal genau hinschauen: Wie ist die eigene IT-Organisation tatsächlich aufgestellt? Diese Analyse muss nicht aufwendig sein. Oft reichen ein bis zwei Workshoptage, um passende Empfehlungen zu entwickeln. Schaper empfiehlt zudem, eine Transformation nie allein durchzuführen. Man solle bewusst eine externe, mehrdimensionale Perspektive einbeziehen, denn die Zeit der Patenrezepte sei lange vorbei.
Beteiligung macht Transformation nachhaltig
Ein neues Vorgehen wirkt nur dann nachhaltig, wenn Teams von Beginn an mitgestalten, statt ein Framework übergestülpt zu bekommen. Oliver Schapers alltagsnaher Vergleich: Wenn man Prozesse vorschreibt sei das so, wie wenn ein Kind einen noch größerer Teller Spinat am Abend bekäme, weil es diesen mittags nicht essen wollte. Niemand lernt dadurch, den Spinat zu mögen!
„Mutet euren Teams Verantwortung zu! Menschen können das“, appelliert Schaper. Dafür brauchen die Mitarbeitenden relative Autonomie, also eine beschriebene Handlungsfreiheit in einem definierten und vereinbarten Rahmen.
Am besten werde ein Modell passend zur eigenen IT-Organisation entwickelt oder die Vorlage an die spezifischen Gegebenheiten angepasst. „Es ist ja eh die Idee aller iterativen Vorgehensmodelle, die eigenen Artefakte, Events und Rollen immer wieder zu überprüfen.“
Führung statt Steuerung
Zu den häufigsten Fehlern zählt Oliver Schaper neben dem unreflektierten Übernehmen von Modellen vor allem schlechte oder fehlende Führung. Anders als viele denken, brauchen auch agile Systeme Führung – nur eben nicht im Sinne von „Command & Control“. Auch der Begriff „Steuerung“ führt häufig in die Irre, wenn er als Steuerung von Menschen statt als Steuerung eines Systems verstanden wird: Rahmen setzen, messbare Indikatoren definieren, an der Wertschöpfungskette statt an Einzelpersonen ansetzen.
Für Entscheider, die vor einer agilen Skalierung stehen, lässt sich daraus eine Kernbotschaft ableiten: Kein Modell passt unverändert sowohl zum einen wie zum anderen Unternehmen, nicht einmal innerhalb derselben Firma. Wer zuerst genau hinschaut, wie die eigene Organisation tatsächlich arbeitet, und Teams echte Verantwortung statt bloßer Vorgaben gibt, hat die besten Chancen: Dann wird aus der agilen Skalierung ein gelebtes und produktives Framework.
Unser Experte für agile Transformation
