Was ist Agile Skalierung?

Von Bernhard Fink

In meiner Praxis treffe ich oft auf Situationen, wo der Kunde / die Kundin schon eine bestimmte Idee bzw. Erwartung hat, dass eine agile Skalierung die Lösung ist – aber nicht genau weiß, wie das am besten umzusetzen ist. Agile Strukturen sind anders als hierarchische Strukturen. Das macht es schnell sehr kompliziert, wenn man die Erfahrung nicht hat. Und manchmal treffe ich auch auf besondere Herausforderungen, weil man schon mitten drin ist und Probleme auftauchen…

Vorab aber noch ein Warnschuss vor den Bug: Wer agiles Arbeiten deshalb einführen möchte, weil es gerade hip und in vieler Munde ist, der soll besser die Finger davon lassen. Denn es kommt damit Komplexität ins Haus, die man vielleicht noch nicht kennt und versteht. Wenn agiles Arbeiten funktioniert, kann es sehr gut gehen – aber der Weg dorthin ist mit klassischem Management-Denken im Sinne von Command & Control nicht machbar.

Wann kann bzw. soll man agil skalieren?

Agile Skalierung ist dann sehr gut anwendbar, wenn ein Unternehmen schon Erfahrung mit agilem Arbeiten hat – zum Beispiel in einzelnen Teams, die für sich autonom an einzelnen Produkten arbeiten. Besteht dann plötzlich eine Notwendigkeit, dass an einem Produkt viele Leuten gleichzeitig arbeiten müssen, weil schnell oder viel geschafft werden soll … also wenn plötzlich 50 oder 100 Personen agil an einer Initiative mitwirken, dann ist agile Skalierung die richtige Wahl.

Skalieren, also größer machen, ist schon im klassisch-hierarchischen Kontext kompliziert und nie ganz einfach … und es wird nicht einfacher, nur weil man agil skaliert. Letzteres bringt jedoch den Vorteil, dass man agile Grundsätze in großen Teams anwenden kann – und man dadurch anpassungsfähiger an neue Situationen ist: Zum Beispiel wenn sich der Wunsch des Kunden / der Kundin ändert, kann man schnell(er) darauf reagieren, auch wenn 100 Leute an dem Projekt arbeiten.

Mit agiler Skalierung ist eine Organisation in größerem Umfang flexibler und schneller anpassungsfähig. Durch die Selbstorganisation verändert sich die Aufgabenverteilung zwischen den Beteiligten. Aber einfacher wird es durch Agilität in der Skalierung nur dann, wenn man es konsequent und gut umsetzt.

Begriffs-Erklärungen zur „Agilen Skalierung“ – unterschiedliche Komponenten / Sichtweisen / Möglichkeiten

„Agile Skalierung“ als Begriff hat keine streng abgegrenzte Definition. Einige verstehen darunter das alleinige „Größermachen“ – also zum Beispiel aus 10 unabhängigen Scrum-Teams im nächsten Jahr 100 aufzubauen. Damit macht man zwar mehrere Teams, aber es geht da nicht primär darum, die Zusammenarbeit zwischen diesen Teams zu steuern – was aus meiner Perspektive der eigentliche Sinn einer agilen Skalierung ist.

Um das zu unterscheiden ist es angebracht, zwei Blickwinkel des Begriffes separat zu betrachten:

Eine vertikale Skalierung beschreibt den Zusammenhang und die Auswirkungen auf den Wertschöpfungsprozess. Es geht darum, dass ein Team an einem größeren Teil des Leistungsprozesses beteiligt ist. Man gibt zB einem Team mehr Kompetenzen: Ein agiles Team, das früher nur Software entwickelt hat, könnte dann für die Anforderungserhebung und den Kundenkontakt zuständig sein – also mehr von der Wertschöpfungskette machen. Stichwort „Development & Operations“ (DevOps) oder „Business Development & Operations“ (BusDevOps). Es geht darum, dass ein Team mehr macht – auch eine Art von Skalierung.

Was in der Skizze oben steht – Agile Organisation – meint jenen Teil, für dessen agile Veränderung man den Begriff „Agile Transformation“ verwendet: Die grundsätzliche Veränderung einer Organisation, um agile Grundprinzipien in der ganzen Organisation zu ermöglichen. Es geht hier um das Ermöglichen von agilen Prinzipien wie „Anpassungsfähigkeit“ oder „Reaktionsschnelligkeit“ über die ganze Organisation hinweg, nicht nur als einzelnes kleines oder großes Team, da muss auch die Führung stark mitwirken… was man auch als Skalierung von Agilität im Sinne der Ausweitung auf die ganze Organisation sehen kann.

Doch bleiben wir bei der agilen Skalierung im Sinne des GROSS-Machens für ein Vorhaben.

Worauf kommt es bei einer agilen Skalierung an?

Agile Skalierung baut auf einer agilen Haltung und den agilen Prinzipien auf, und setzt das nur im größeren Kontext um.
Agile Skalierung braucht eine gute Struktur, denn es geht darum, dass viele Menschen zusammenarbeiten sollen.
Wichtig im Führungs-Kontext ist es, anders (neu) zu denken: Nicht das zentrale Management von Aufgaben, sondern das Entwickeln von Eigenständigkeit und das zielgerichtete Zusammenwirken von Menschen steht im Vordergrund.
Die Auftraggeber müssen dieser Vorgehensweise zustimmen, oder mehr noch, sie müssen es wirklich wollen!

Schritt 1: Der Zweck

Der erste Schritt im Zusammenhang mit einer agilen Skalierung muss immer dem Zweck (englisch: Purpose) gewidmet sein! Denn die Frage nach dem Grund, dem Auslöser, warum man etwas tun möchte, beschreibt die weitere Richtung.

Wenn der Grund zum Beispiel darin liegt, dass man ein großes Projekt bewältigen muss, an dem viele Leute arbeiten, dann ist es vermutlich ratsam, sehr methodenorientiert vorzugehen und ein paar Coaches an Bord zu holen, die Erfahrung haben, um schnell 50-100 Leute organisieren zu können. Da hilft eine Methode deshalb sehr gut, weil sie Strukturen vorgeben kann, die man anwendet und sehr schnell ein Ergebnis erzielen kann.

Wenn es hingegen um eine zukunftsorientierte Ausrichtung geht, um größere Initiativen besser zu organisieren und am Aufbau einer Transformation zu arbeiten – dann macht es Sinn, sich die bestehende Struktur etwas näher anzusehen, und Dinge zu verwenden, die auf die bestehende Organisation besser aufsetzbar sind. Hier eine beliebige Methode zu nehmen und unreflektiert umzusetzen, wäre vielleicht nicht hilfreich … wobei wir bei Schritt 2 sind.

Schritt 2: Die Richtungsentscheidung

Der zweite Schritt resultiert aus der Frage, ob man eine bestehende Methode nimmt oder ob man ein eigenes Konzept entwickelt – oder man macht eine Mischung aus beiden. Von dieser Entscheidung ist es auch abhängig, ob man sich zum Beispiel Coaches für bestimmte Methoden ins Haus holt, die dann dabei helfen, die jeweilige Methode bestmöglich anwendbar zu machen. Die Richtungsentscheidung ist oft recht bald notwendig, um hier nicht unnötig Zeit, Geld und Ressourcen zu verschwenden.

Welcher der beiden Wege empfehlenswerter ist, hängt vom Kontext ab, den man sich sehr genau ansehen muss, und insbesondere davon, was die Organisation bzw. die Situation braucht und was am besten hilft.

Hier empfiehlt es sich auf jeden Fall, externe Sichtweisen und versiertes Coaching einzubinden – es sei denn, man hat diese Kompetenzen schon in der Organisation. Vor allem in der Anfangsphase macht es Sinn, sich dieser Experten und Expertisen zu bedienen. Denn wenn man hier zu voreilig oder gar unprofessionell agiert, kann es passieren – und passiert es leider sehr häufig –, dass man viele Personen über einen gewissen Zeitraum in die falsche Richtung schickt.

Schritt 3: Ausprobieren der Methoden & Arbeitsweisen

Je nachdem, ob man sich dafür entscheidet, eine Methode selbst zu entwickeln oder eine fertige Methode anzuwenden, folgt jetzt der dritte Schritt, eine Art „Experiment-Modus“: Man verändert etwas, schaut sich das an und reagiert auf Erfahrungen. Fehler machen gehört hier dazu! Denn in jeder Veränderung macht man Fehler und insbesondere in der Agilität soll man sehr transparent mit Fehlern – und mit der Erlaubnis, Fehler zu machen – umgehen.

Wenn man den anderen Weg geht und eine fertige Methode nimmt, würde jetzt noch nicht das Experimentieren beginnen, sondern die Einführungsphase. Die meisten Methoden sind im Normalfall schon sehr gut beschrieben; man muss sich lediglich überlegen, ob man die Methode so nimmt, wie sie ist oder ob man sie anpasst.
Also je nach Richtungsentscheidung zuerst mit der Methode beschäftigen und sicherstellen, dass ausreichend Leute die Methode verstehen und wissen, wie sie damit umgehen – in Schulungen in der Beschäftigung mit dem Thema.
Oder, wenn man selbst entwickelt – dann sollte man verschiedene Methode kennen und verstehen und dann versuchen, die für die eigenen Zwecke hilfreichen Konzepte und Ideen anzuwenden bzw. auch neue Ansätze zu entwickeln.
Und da geht es schnell in den Erfahrungsmodus, um zu lernen und die Methoden zu verbessern.

Schritt 4: Laufende Verbesserungen

Im nächsten Schritt geht es um konsequentes Entwickeln der neuen Struktur – für beide Varianten: Dass man eine Form gewählt hat, beziehungsweise mit einer Form begonnen hat und dann in kurzen Abständen reflektiert: Wie geht es uns damit? Was soll man als nächstes verändern, um es dann wieder neu/anders zu probieren? Bei der agilen Skalierung macht man das nicht nur in den einzelnen Teams, sondern unbedingt auch in der ganzen betroffenen Organisation.

Mit einer bestehenden Methode wird man auf einem höheren Niveau schneller gut sein und sich von dort verbessern. Der Nachteil einer fertig beschriebenen Methode liegt darin, dass diese gleichzeitig sehr viel Veränderung in der eigenen Arbeitsweise braucht, weil man sonst die Methode nicht umsetzen kann. Man muss sich hin zu dieser Methode verändern. Wenn man die Methode selbst entwickelt, ist die gefühlte Veränderung nicht so groß; passt vielleicht besser auf die Organisation – dann muss man aber mehr experimentieren, mehr Erfahrungen sammeln und viel mehr Fehler machen … und das dauert eher länger.

Schritt 5: Entwicklung des involvierten Managements

Einer der Grundsätze in der agilen Arbeitswelt besagt, dass Selbstorganisation viel Freiraum und dennoch Abstimmung braucht. Das hat großen Einfluss auf die möglicherweise noch vorherrschende klassische Führungsstruktur im Unternehmen. Es geht also darum, die von der agilen Skalierung betroffenen Führungskräfte in der laufenden Weiterentwicklung der Skalierung zu beteiligen. Eine gute Methode, um das zu erreichen ist es, in kurzen Abständen Reflexionen („Retrospektiven“) zu veranstalten, die Aufschlüsse geben, was gut und was schlecht funktioniert hat. Diese Erkenntnisse gilt es dann, als Basis für laufende Verbesserung auf der Ebene der Führungskräfte zu nutzen.

Nur wenn das auch mit den involvierten Führungskräften kontinuierlich und andauernd stattfindet, kann eine skalierte agile Organisationseinheit entstehen, die sich gut entwickeln kann und die anpassungsfähig wird … die kein Problem mit Veränderungen hat.

Führung neu definieren

Was man oft zu sehen bekommt, ist die Situation, dass eine klassische hierarchische Organisation plötzlich agil arbeiten möchte: Weil eine große Initiative auftaucht, muss eine agile Skalierung her. Dann bedient man sich zum Beispiel eines SAFe-Frameworks … und lässt 100 Leute damit arbeiten. Das ist dann aber plötzlich nicht nur eine Teamsache, sondern geht weit in die Organisation hinein – weil die Entscheidungen, die bisher im Management getroffen wurden, plötzlich in diesen agilen Teams getroffen werden sollen. Da prallen zwei verschiedene Managementsysteme aufeinander.

Man darf aber auch nicht in den Fehler verfallen, dass man in Zusammenhang mit Agilität die Aufgaben, die Kompetenzen und den Wert des mittleren Managements infrage stellt beziehungsweise unterschätzt. Tatsache ist, dass es auch in einem agilen Umfeld eine bestimmte Form von Führung – Achtung: nicht „Management“ – mit veränderten Anforderungen und Aufgaben braucht! Für die Führungskräfte, die bei einer agilen Veränderung mitwirken, geht es nicht (mehr) darum, die operativen Entscheidungen zu treffen, sondern darum, Rahmen zu schaffen, dass die operativen Entscheidungen in den agilen Teams selbst getroffen werden können.