Erprobte Modelle für die Skalierung von Agilität
Die agilen Methoden der ersten Generation wie Scrum und Kanban waren vor allem auf die Implementierung in überschaubaren Teams gemünzt. Die Methode Scrum kennt lediglich drei feste Rollen für die Beteiligten (Product Owner, Scrum Master, Team Member). Während es noch ersichtlich ist, dass solche relativ autonomen Strukturen auf diesem Basisniveau gut funktionieren können, stellt sich die Frage nach der Praktikabilität auf dem Niveau von mehreren hundert oder sogar tausend Mitarbeitern. In der Praxis haben sich hierfür bereits einige übergeordnete Modelle bewährt, die im Folgenden kurz vorgestellt werden.
Nexus Framework: Das Nexus Framework stellt eine Art "Exoskelett" dar, das zwischen drei bis neun Scrum-Teams vermittelt. Es gibt nur ein gemeinsames Backlog, auf dessen Basis ein integriertes Inkrement erstellt wird. Um Abhängigkeiten so gering wie möglich zu halten, wird das Nexus Backlog in so kleine Teile wie möglich aufgeteilt und diejenigen, welche die größte Abhängigkeit erzeugen, priorisiert behandelt.
Large Scale Scrum (LeSS): Der LeSS-Ansatz bildet die Scrum-Methode auf größere Organisationen ab, indem das Entwicklungs-Team einfach "vergrößert" wird. Ganze Teams nehmen die Rolle ein, die zuvor der einzelne Mitarbeiter hatte. Grundsätzlich gibt es nur einen Product Owner, egal wie groß das Team ist. Bei der Sprint-Planung sind alle Teams anwesend, unter Umständen auch nur Stellvertreter. Hier werden die einzelnen Aufgaben nach der Reihenfolge des Backlogs unter den Teams verteilt. In sehr großen Projekten lässt sich die starke Zuspitzung auf einen Product Owner vermeiden, indem die Funktionalität des Produkts auf verschiedene Bereiche mit einem jeweils eigenen Product Owner aufgeteilt wird. Somit lässt sich eine mittlere Ebene hinzufügen.
Scaled Agile Framework (SAFe): Dieses Modell unterscheidet die drei Ebenen Portfolio, Programm und Team. Auf der Portfolio-Ebene sind alle strategischen Themen wie Investment und Governance angesiedelt. Auf der mittleren Programm-Ebene sorgt der "Agile Release Train" für eine enge Verzahnung von strategischer und operativer Ebene, beispielsweise bei der Frage, wann ein Produkt oder einer seiner Bestandteile bereit für die Auslieferung sind. Auf der Team-Ebene finden schließlich die bekannten Methoden ihren Niederschlag.
An dieser Stelle kann nur ein grober Überblick über Vielzahl der einzelnen Methoden gegeben werden. Weitere Angebote sind der Agile Scaling Cycle oder die Spotify-Methode. Es ist je nach Anwendungsfall zu entscheiden, welches Framework am besten zu den Anforderungen des Unternehmens passt. SAFe beispielsweise setzt auf einer sehr hohen Ebene an und ist dann erforderlich, wenn die Software- und IT-Entwicklung tatsächlich auch eine strategische Bedeutung für das Unternehmen einnimmt. Je nach Organisationsanforderungen und -kultur sind die diejenigen Frameworks einzurichten, die am besten zu ihnen passen. Prinzipiell gilt die Faustregel: So viel Freiheit wie möglich, so wenig Regeln wie nötig. Zumeist kann der Idealfall aber aufgrund von externen Faktoren nicht umgesetzt werden, weshalb Modelle mit komplexeren Regelwerken auch ihre Berechtigung haben. Skalierung findet zudem auf der horizontalen (mehr Teams, Mitarbeiter, etc.) wie auch vertikalen Ebene (mehr Aufgaben, Verantwortung, Vertiefung in der Wertschöpfungskette, etc.) statt. Externe Berater können in diesem Thema sehr hilfreich sein, um den Bedarf zu klären und das jeweilige Modell zu finden und implementieren.
Ein Wertewandel im gesamten Unternehmen ist erforderlich
Wollen Unternehmen einen Wandel zur umfänglichen Agilität hin gestalten, stehen sie bereits auf dieser Ebene vor einer Herausforderung. Denn Agilität ist nicht einfach ein "weiteres Werkzeug", das einfach so eingekauft und als "Plug & Play"-Ansatz eingestöpselt wird, sondern erfordert einen grundlegenden Kulturwandel. Der agile Wandel setzt voraus, dass Vorgesetzte Verantwortung an ihre Mitarbeiter abgeben und die Mitarbeiter wiederum bereit sind, die Verantwortung aufzunehmen. Aus vormaligen Einzelkämpfern werden Teamplayer, die ihren selbst geschriebenen Code zur Disposition und freien Verfügung des Teams stellen.
Die agile Transformation findet zwischen zwei Gegenpolen statt: Strikte Logik auf der einen und Kreativität auf der anderen Seite. Weder das eine, noch das andere Prinzip darf völlig dominieren, was eine ständige Abwägung nach beiden Seiten hin erfordert. Der Weg zur agilen Organisation ist daher selbst wieder agil: Wie die Organisation am Ende aussieht und funktioniert, entwickelt sich im Prozess und steht erst am Ende der Entwicklung fest. Wer diesen Weg konsequent geht, wird am Ende auch die Vorteile agiler Methoden genießen können: Die Funktionalitäten der IT-Produkte entsprechen stets den aktuellen Bedürfnissen.