Back to the Basics – wie viele Rollen braucht die Agilität wirklich

Das Scaled Agile Framework (SAFe) erlebt in den letzten Jahren einen regelrechten Hype in mittleren und großen Organisationen. Besonders beliebt scheint dabei das Versprechen zu sein, ein „Dual Operating System“ etablieren zu können – also ein System, das es schafft, die bisherige hierarchische Aufbauorganisation mit einer agilen Ablauforganisation zu verbinden.

Ein weiterer Aspekt ist ein gut definiertes Framework mit Prozessen und Rollen, das sich auch in eine bestehende Organisation integrieren lässt. Viele Organisationen, die SAFe einführen, schaffen sogar zusätzliche Rollen, um möglichst wenig „umdenken“ zu müssen und damit viele Strukturen gleich zu halten. Das Ergebnis ist dann oft eine Lösung mit vielen neuen (und alten) Titeln. Diese haben dann alle ihre vermeintlich klar definierten Kompetenzen, was in der praktischen Umsetzung oft zu Silodenken und/oder Entscheidungsunfähigkeit in den Teams führt.

Bei dieser Beobachtung frage ich mich oft, ob man nicht alles so einfach wie möglich halten sollte. Statt einer großen SAFe-Einführung sollte man sich auf die grundsätzlichen Ziele konzentrieren, die man erreichen möchte. Ich gehe davon aus, dass die meisten Organisationen daran interessiert sind, schneller auf Marktveränderungen reagieren zu können. Agile Methoden zielen genau darauf ab. Wenn man sie aber einsetzt, um die Ablauforganisation radikal zu verändern, ohne das „Mindset“ der Aufbauorganisation zu ändern, kann das nur scheitern (siehe Blogpost oben).

Anstatt ein möglichst umfassendes Framework einzuführen, das alle Prozesse in der Organisation von Anfang bis Ende agil macht, warum nicht einen Schritt zurückgehen? Klein anfangen und mit den Grundlagen beginnen. Man braucht keinen voll agilen Business Owner, der mehrere Teams gleichzeitig mit schlank budgetierten Epics versorgt. Man braucht funktionierende agile Teams, die einen Mehrwert für den Kunden liefern. Wenn man mehrere davon hat, müssen sie sich auch irgendwie koordinieren. Und damit sie nicht nur irgendeinen Mehrwert liefern, sondern einen, der zur Unternehmensstrategie passt, brauchen sie auch eine langfristige Vision.

Aus dem letzten Absatz lassen sich bereits drei Ebenen ableiten – eine operative Ebene (das Team), eine Koordinationsebene (mehrere Teams) und die strategische Ebene (das Unternehmen). Dies ist kein Zufall, sondern lehnt sich stark an das Konzept der „Flight Levels“ von Klaus Leopold an. Mit dieser Sichtweise auf agile Entwicklung ließe sich meiner Meinung nach vieles einfacher handhaben.
Man gibt jedem Team ein Board, führt eine Koordinationsebene ein, stellt dafür auch ein Board hin und fängt einfach an zu visualisieren.
„Und wo ist die strategische Ebene?“, wird sich der geneigte Leser jetzt fragen. Die ist im ersten Schritt implizit schon da. Denn wenn die Teams anfangen agil zu arbeiten, haben sie bereits ein Produkt im Kopf, das entweder neu oder weiterentwickelt wird. Die strategische Richtung ist hier schon vorgegeben. Der nächste Schritt wäre, auch hier ein Board aufzusetzen und weiter zu iterieren. Also alles sehr agil.

Das ist jetzt natürlich sehr einfach geschrieben und wahrscheinlich auch etwas naiv. Aber grundsätzlich gilt: Versuch macht klug. Keine Einführung von agilem Arbeiten ist einfach und es ist auch nicht damit getan, eine Methode einzuführen und dann funktioniert alles. Agile Methoden sind keine Methoden, um Probleme zu lösen, sondern Methoden, um Probleme aufzuzeigen. Und das geht nur, indem man anfängt. Und da sollte man nicht kompliziert anfangen, sondern einfach, um sich möglichst wenig selbst im Weg zu stehen. Darüber nachzudenken, wie man jede Rolle ausfüllt und neue Rollen schafft, kann an dieser Stelle nur hinderlich sein. Stattdessen klein anfangen, lernen und dann – mit gestärktem Selbstvertrauen – die agile Transformation der Organisation mit SAFe in Angriff nehmen.

Am Ende stellt sich für mich wieder die grundsätzliche Frage: Hilft das der Organisation jetzt wirklich? Ist das Ziel von „Business Agility“, schneller auf Marktveränderungen zu reagieren, erreicht, wenn alle Teams agil arbeiten?

Aber das Thema ein andermal…