Wollen auch Sie in Ihrem Unternehmen den agilen Wandel einläuten? Glauben auch Sie an das Dogma, dass Unternehmen nur mit einer permanenten Startup-Kultur in der VUCA-Welt überleben können? Dann sollten Sie diese Geschichte lesen, bevor Sie Ihre bisherigen, mühsam erworbenen Fähigkeiten über Bord werfen!

Ehemaligen Garagenfirmen und Startups wie Microsoft, Amazon und Google steckt die Agilität in den Genen. Und beständig treten neue Unternehmen in den Markt ein, die traditionell geführten Konzernen das Fürchten lehren. Da ist es kein Wunder, wenn Unternehmen mit gewachsenen, durchaus erfolgreich arbeitenden Aufbau- und Ablauforganisationen die Stärken der Agilität entdecken und für sich nutzen wollen.

Die IT-Tochter eines traditionellen, deutschen Logistikunternehmens wollte vor zwei Jahren genau das tun: Mit einer agilen Transition leistungsfähiger werden. Aber das Gegenteil trat ein: Die Produktivität sank und die Entwicklungsdauern stiegen. Wir begleiteten das Unternehmen nach diesem gescheiterten Versuch dabei, seine Organisation so weiterzuentwickeln, dass einerseits die über eine lange Zeit erarbeiteten Werte beibehalten und andererseits die Vorteile der selbstorganisierten, flexiblen, agilen Arbeitswelt genutzt werden.

Im Folgenden beschreiben wir zunächst die Ausgangssituation, die wir als typisch für viele Unternehmen betrachten, die sich Agilität auf ihre Fahnen schreiben wollen. Dann benennen wir die vier Kardinalfehler, die beim Versuch der Agilen Transition gemacht wurden und welchen Lösungsansatz wir jeweils empfehlen, um diese zu vermeiden. Schließlich plädieren wir für ein spezifisch befähigtes Portfolio Management Office (PMO), das bewährte, traditionelle Organisationsstrukturen und agile Vorgehensweisen erfolgreich zusammenwirken lässt.

Befehl von oben: Wir sind jetzt agil!

Zuerst erkannte das Topmanagement des oben genannten IT-Unternehmens, dass eine mit Freiräumen ausgestattete, auf allen Ebenen hoch motivierte Mannschaft Projekte schneller und besser umsetzen können müsste, als die aktuell im traditionellen Kontext geführte und "durchschnittlich" motivierte. Zudem waren die Abhängigkeiten in und zwischen den vielen Großprojekten unkontrollierbar und die dafür notwendigen Ressourcen nur mehr schwer steuerbar geworden.

Besonders groß war der Leidensdruck bei der Steuerungssoftware für die hauseigene Infrastruktur. Diese sollte innerhalb von Minuten auf betriebliche Verzögerungen reagieren, tage- und wochenweise den Ressourceneinsatz planen und steuern sowie auf Monate und Jahre hinaus den Ressourcenbedarf prognostizieren, um eine vorausschauende Personalplanung zu ermöglichen.

Über Jahre hinweg war erfolglos versucht worden, all diese Anforderungen lückenlos zu erfüllen. Dies lag unter anderem daran, dass zum einen die Anforderungsanalysen zu langwierig waren und zum anderen die Release-Zyklen dieser Software länger als die Wandlungsgeschwindigkeit der Anforderungen. Dadurch war es nicht möglich, aktuellen Änderungsbedarf schnell genug und bedarfsgerecht umzusetzen.

Die Unternehmensführung untersuchte deshalb mehrere aktuell propagierte Management-Ansätze auf ihre Eignung, die Strategie des Unternehmens schneller und nutzbringender operativ umzusetzen. Zugleich sollte das neue Managementsystem die operativen Abläufe des Tagesgeschäfts deutlich unterstützen.

Aus "Start Acting Agile" …

Das Unternehmen entschied sich für die Philosophie der Agilität und ein übergreifend koordinierendes Konzept, um widersprüchliche Entwicklungen durch isoliert voneinander arbeitende agile Teams zu vermeiden. Die Wahl fiel daher auf das Agilität skalierende Rahmenkonzept SAFe 4.0® (Scaled Agile Framework® Version 4.0).

Agilität ist – auch in diesem Rahmenkonzept – eine Philosophie des "start being agile" bevor "start acting agile" und verspricht als zentrales Ergebnis den "Flow", die "Super Produktivität" der Umsetzungsteams. Sie basiert im Wesentlichen auf der Delegation von Verantwortung für kleine, aber dediziert nutzbare und in kurzen Etappen hergestellte Produkte an die Entwicklungsteams, die sich mit ihren Produkten identifizieren.

Das gesamte Management stand hinter dem Transformationsprojekt. Mit externer Unterstützung sollte das Rahmenwerk eingeführt werden und zwar exakt so, wie theoretisch gelehrt. Es wurden unter anderem Scrum Teams gebildet, Agile Release Trains gebündelt, Schnittstellen zum DevOps etabliert und den Teams Agile Coaches an die Seite gestellt. Kurz: Der gesamte Standardwerkzeugkasten von SAFe 4.0® wurde ausgerollt. Die Konsequenz war: Das Unternehmen startete ohne Kulturwandel direkt mit "acting agile".

… wurde "Stop Acting Efficiently"

Nach 15 Monaten mussten die Treiber der agilen Transformation, d.h. die Berater mit ihrem Rahmenwerk und das Management des Unternehmens, aber erkennen, dass sich ihre Erwartungen nicht erfüllt hatten. Die Produktivität war gesunken, die Kosten waren gestiegen, die Entwicklungszyklen waren länger geworden. Konkret bedeutete dies:

• Das Product Backlog für die Steuerungssoftware war größer statt kleiner geworden und somit der Unmut der Bedarfsträger im Konzern gestiegen.
• Den Product Ownern fehlten von den Stakeholdern bewertete Backlog Items.
• Die Integrationen der Inkremente der Sprints schlugen fehl, weil nicht übergreifend spezifiziert worden war.
• Die Teams identifizierten sich nicht mit den Produkten.
• Die Mitarbeiter klammerten sich an ihre von der Linie vorgegebenen Stellenbeschreibungen.

Die 4 Kardinalfehler der gescheiterten Agilen Transition

Rückblickend betrachtet lässt es sich natürlich einfach erklären, warum die erwartete Verbesserung nicht eintrat: Es war mit dem agilen Handeln begonnen worden, bevor Agilität verstanden worden war. Das Grundprinzip "be agile" anstatt "act agile", war missachtet worden. Die angestrebte höhere Produktivität wurde gerade deswegen nicht erzielt, weil sie explizit als Zielvorgabe des Transformationsprozesses eingefordert worden war. Stattdessen hätte das Etablieren der agilen Denkweise im Vordergrund stehen müssen. Die Produktivitätssteigerung hätte sich dann als logisches Ergebnis der eigenständigeren Zusammenarbeit gewissermaßen "von selbst" ergeben.

In der nachträglichen Analyse erkannten wir vier Kardinalfehler, die den ursprünglich richtigen Ansatz ad absurdum führten und die agile Transformation scheitern ließen.

Fehler 1: Agilität nach Lehrbuch

Wie die meisten Vorgehensmodelle stellt SAFe® – seiner Allgemeingültigkeit folgend – eine konsistente Nomenklatur und einen vollständigen Beispielsatz an Methoden zur Verfügung. Allerdings überlasen die Verantwortlichen für die Einführung den Grundsatz, hier nur das zu verwenden, was in der konkreten Situation tatsächlich benötigt wird. Führung und Mitarbeiter waren deshalb damit beschäftigt, die neuen Verfahren und die neue Terminologie zu erlernen und fast "auf der grünen Wiese" zu implementieren.

Alle konkreten Erfahrungen aus vergangenen Projekten, alle gelebten Standards, die etablierte Unternehmenssprache (Nomenklatur), die gespeicherte Erfahrung des Unternehmens und der Mitarbeiter, dieses intellektuelle Vermögen der Organisation wäre in unserem Beispielfall zwar verfügbar gewesen, wurde aber dem agilen Rahmenwerk untergeordnet bzw. außen vor gelassen.

Der Ansatz, es "richtig" zu machen, war zu eng angewandt worden. Dies führte z.B. dazu, dass fachlich versierte und somit erfolgskritische Knowhow-Träger beim Backlog Refinement nicht gehört wurden, weil sie (noch) nicht auf den Zug der Agilität aufgesprungen waren und somit nicht ausrollbare Inkremente entwickelt wurden. Diese Knowhow-Träger hatten empfohlen, zunächst Piloten zu projektieren, um die Lösungen zu komplexen Anforderungen zu verproben und somit Planungssicherheit in den Agilen Ansatz einzubauen.

Lösungsansatz: Die Theorie sollte der Praxis helfen

Es wäre der richtige Ansatz gewesen, je nach Charakter des Vorhabens agile und traditionelle Best Practices gleichermaßen in Erwägung zu ziehen und gegebenenfalls diese dann vorsichtig zu mischen. Dies umso mehr, als nicht jedes Vorhaben für rein agile Methoden prädestiniert ist.