Scrum in einem Großprojekt – geht das überhaupt? Wenn viele Teams, widersprüchliche Anforderungen und eine komplexe Stakeholder-Landschaft im Spiel sind, dann stößt diese Methode oft an ihre Grenzen. Das heißt aber nicht, dass es nicht gelingen kann. Es gibt durchaus Ansätze, um Scrum in großen Projekten zu implementieren. Entdecke, wie agile Prinzipien auch im Großformat funktionieren können.

Ein international aufgestellter Mittelständler schickt sich an, eine neue Unternehmenssoftware zu entwickeln. Nach einigem Hin und Her entschied man sich schließlich, dieses Großprojekt nach Scrum durchzuführen. Zu Beginn schien das Team von der Flexibilität und den schnellen Iterationen begeistert. Doch bald traten Schwierigkeiten auf, die die Vorteile der agilen Methodik in Frage stellten. So arbeiteten beispielsweise aufgrund der Projektgröße eine Vielzahl von Scrum-Teams parallel, was die Koordination und Kommunikation untereinander erschwerte. Unterschiedliche Teams entwickelten Funktionen, die nicht nahtlos integriert werden konnten, da es an einer klaren übergreifenden Architektur fehlte. Zudem waren viele Stakeholder involviert, deren Anforderungen oft widersprüchlich waren.

Größere Unternehmen sind es gewöhnt, ihre Projekte nach traditionellen Wasserfallmethoden durchzuführen. Da ist es nur allzu verständlich, dass es Ihnen schwerfällt, sich auf agile Prinzipien einzulassen. Dies führte im genannten Beispiel schnell zu Verzögerungen bei wichtigen Entscheidungen und hinderte das Projektteam daran, schnell auf Veränderungen zu reagieren. Letztlich zeigte sich, dass trotz der anfänglichen Begeisterung für Scrum in einem so großen Kontext eine klare Struktur und zentrale Steuerung notwendig waren, um den Projekterfolg sicherzustellen.

Die agile Theorie klingt einfach und funktioniert auch oft in kleineren Unternehmen. Je größer das Unternehmen, desto eher wird aber versucht, Scrum zu adaptieren. Leider wird dadurch meist der Nutzen des agilen Vorgehens ganz oder teilweise zerstört.

Abweichungen von den Scrum-Praktiken

Ken Schwaber hat die Adaptionen der Scrum-Methodik liebevoll „Scrum, but“ genannt. Längst wird der Begriff in der agilen Gemeinschaft verwendet, um eine verzerrte oder nicht vollständige Anwendung der Scrum-Methodik zu beschreiben. Oft hören wir in größeren Unternehmen oder Projekten die Formulierung: “Wir machen Scrum, aber…”, gefolgt von Bedingungen oder Ausnahmen, die von den grundlegenden Scrum-Prinzipien abweichen.

Eine der problematischsten Adaptionen ist der Umgang mit dem Projektleiter. Fakt ist: Scrum kennt keinen Projektleiter. Leider wird aus genau diesem Grund in größeren Unternehmen, die mit dem agilen Modell starten wollen, oft der Fehler gemacht, die Scrum Master aus den Reihen der Projektleiter zu rekrutieren. Damit meint man gleich zwei Fliegen mit einer Klappe zu schlagen. Zum einen erübrigt sich dadurch die Suche nach einem geeigneten Scrum Master und zum anderen ist geklärt, was aus jenen Personen wird, die über lange Jahre Projekte geleitet haben.

Leider werden durch diesen „Move“ nur neue Probleme geschaffen, da die Rolle des Scrum Masters meist falsch interpretiert wird. Ein Scrum Master hat die Aufgabe, für die Einhaltung des Scrum-Prozesses zu sorgen, die Eigenverantwortung im Team zu fördern und Probleme und Widerstände im Projektumfeld zu beseitigen. Ein klassischer Projektleiter nimmt dagegen meist steuernde und leitende Aufgaben wahr. Diese Anspruch lässt sich kaum ablegen wie ein in die Jahre gekommenes Kleidungsstück. Im Gegenteil: Der Begriff „Master“ wird dann schnell als „Meister“ oder „Gebieter“ übersetzt, und schon übernimmt der Scrum Master wieder die Regie im Projekt.

Frameworks müssen skalierbar sein

In Großprojekten, die oft mehrere Teams und komplexe Anforderungen umfassen, ist die Skalierung agiler Methoden wie Scrum unerlässlich. Traditionelles Scrum kann in solchen Kontexten schnell an seine Grenzen stoßen, da die Koordination zwischen verschiedenen Teams und die Integration ihrer Arbeit zu einer echten Herausforderung werden kann. Hier kommen agile Frameworks wie SAFe (Scaled Agile Framework) oder LeSS (Large Scale Scrum) ins Spiel, die speziell entwickelt wurden, um diese Herausforderungen zu bewältigen.

SAFe bietet beispielsweise eine strukturierte Herangehensweise, indem es mehrere Ebenen der Planung und Ausführung einführt: Team-, Programm- und Portfolio-Ebene. Dies ermöglicht eine klare Sicht auf die Gesamtstrategie und fördert die Zusammenarbeit zwischen den Teams. Durch regelmäßige Synchronisationsmeetings, wie das „Scrum-of-Scrums“, können Abhängigkeiten identifiziert und Probleme frühzeitig gelöst werden. LeSS hingegen fokussiert sich auf die Vereinfachung der agilen Prozesse und betont die Bedeutung von Transparenz und empirischem Lernen über alle Teams hinweg. Es ermutigt zur gemeinsamen Arbeit an einem Produkt-Backlog, was die Integration der Ergebnisse erleichtert.

Beide Frameworks haben eines gemeinsam: Sie fördern eine Kultur der kontinuierlichen Verbesserung und Anpassungsfähigkeit, was in dynamischen Großprojekten entscheidend ist. Durch klare Rollenverteilungen, regelmäßige Feedback-Schleifen und eine gemeinsame Vision wird sichergestellt, dass alle Beteiligten auf dasselbe Ziel hinarbeiten.

Die Gefahr einer Villa Kunterbunt

Sobald mehrere Teams ein Gebäude errichten, ist Vorsicht geboten. Die Eigenständigkeit der Teams kann schnell dazu führen, dass die Lösungsarchitektur schnell einer „Villa Kunterbunt“ gleicht. Deshalb empfiehlt sich von Anfang an die Bildung eines übergreifenden Architekturteams. Diese Gruppe fungiert als Bindeglied zwischen den verschiedenen Scrum-Teams und stellt sicher, dass die technische Architektur konsistent und zukunftssicher bleibt. Ihre Hauptaufgabe besteht darin, Standards und Richtlinien für die Lösungsarchitektur zu definieren, um eine einheitliche Basis für alle Teams zu schaffen.

Darüber hinaus überwacht die Gruppe die Integration der verschiedenen Komponenten, um sicherzustellen, dass diese nahtlos zusammenarbeiten. Sie identifiziert potenzielle technische Abhängigkeiten frühzeitig und fördert den Austausch von Best Practices zwischen den Teams. Regelmäßige Workshops und Meetings ermöglichen es der Architektur- und Integrationsgruppe, Feedback zu sammeln und Anpassungen vorzunehmen, bevor Probleme unnötig eskalieren.

Durch diese zentrale Anlaufstelle wird nicht nur die Qualität des Endprodukts erhöht, sondern auch die Effizienz der Entwicklungsprozesse gesteigert. Letztlich trägt eine solche Gruppe dazu bei, Risiken zu minimieren und die Agilität im gesamten Projekt zu fördern.

Alles eine Frage der Synchronisation

Wenn in größeren Projekten gleich mehrere Scrum-Teams arbeiten, dann sind regelmäßige Koordinationsmeetings, wie das „Scrum-of-Scrums“, ein absolutes Muss. Diese Meetings sollen die Zusammenarbeit und den Austausch zwischen den einzelnen Teams fördern, indem sie eine Plattform bieten, um Fortschritte, Herausforderungen und Abhängigkeiten zu besprechen.

In einem Scrum-of-Scrum treffen sich Vertreter der verschiedenen Teams, um Updates über ihre jeweiligen Arbeiten zu geben. Dabei werden spezifische Themen wie Blockaden oder technische Herausforderungen besprochen, die andere Teams betreffen könnten. Durch diese Transparenz können Probleme frühzeitig identifiziert und Lösungen gemeinsam erarbeitet werden.

Ähnlich kritisch ist die Etablierung klarer Kommunikationskanäle zu den Stakeholdern. In größeren Projekten sorgen diese Kanäle dafür, dass alle Beteiligten über Fortschritte, Herausforderungen und Änderungen informiert sind, was Vertrauen und Transparenz fördert. Klare Kommunikation hilft, Missverständnisse zu vermeiden und sicherzustellen, dass die Erwartungen der Stakeholder am Ende auch erfüllt werden.

Kein Projektleiter, aber ein Programm-Manager

Sobald mehrere Scrum-Teams in einem Projekt arbeiten, ist eine Erweiterung der traditionellen Scrum-Rollen zwingend notwendig. Normalerweise wäre dies der Zeitpunkt, um doch wieder über einen klassischen Projektleiter nachzudenken. Um aber nicht unnötig Verwirrung zu stiften, nennen wir die neue Rolle lieber Programm-Manager. Seine Aufgabe ist es, die Komplexität und den Umfang solcher Großprojekte teamübergreifend zu steuern und den Scrum-Teams den Rücken frei zu halten. Der Programm-Manager fungiert dabei als Bindeglied zwischen den einzelnen Teams, indem er strategische Ziele definiert und sicherstellt, dass alle Teams auf diese Ziele hinarbeiten.

Der Beitrag eines Programm-Managers liegt in der Koordination und Synchronisation der verschiedenen Scrum-Teams. Er überwacht Abhängigkeiten, identifiziert Risiken und fördert die Kommunikation zwischen den Teams, um sicherzustellen, dass alle Beteiligten informiert sind und zusammenarbeiten. Zudem kann der Programm-Manager Ressourcen effizienter verwalten und Prioritäten setzen, was besonders in dynamischen Umgebungen wichtig ist.

Survival-Tipps

• Achte darauf, dass bei der Adaption von SCRUM-Prinzipien in größeren Projekten die Vorzüge agiler Frameworks nicht leichtfertig geopfert werden.
• Setze in größeren Projekten auf skalierbare Scrum-Frameworks wie SAFe oder LeSS, um mehrere Teams effektiv zu koordinieren.
• Bilde ein übergreifendes Architekturteam, das die technische Integration und die Einhaltung von Standards zwischen den einzelnen Teams sicherstellt.
• Führe regelmäßige Synchronisationsmeetings durch, um den Austausch zwischen den verschiedenen Scrum-Teams zu fördern und Abhängigkeiten zu managen.
• Etabliere klare Kommunikationskanäle und regelmäßige Feedback-Runden mit den verschiedenen Stakeholdern, um deren Anforderungen frühzeitig zu erfassen.
• Erweitere die Scrum-Rollen, z.B. durch einen Programm-Manager oder einen Release-Trainer, um die übergreifende Planung und Koordination zu gewährleisten.