AGILE TRANSFORMATION

EIN INDUSTRIEÜBERGREIFENDER PRAXISBERICHT
Die wichtigsten Erfahrungen aus großen agilen Transformationsprogrammen in Deutschland

Christin Zörner
Deutsche Telekom
Daniel Poelchau
Allianz
Kirsten Weisbender
Commerzbank

Warum wir dieses Whitepaper geschrieben haben

In den letzten Jahren haben sich zahlreiche Großunternehmen mit der agilen Transformation beschäftigt. Das Thema scheint allgegenwärtig und als Lösung für derzeitige Herausforderungen wie gemacht. Die meisten Unternehmen nutzen agile Methoden bereits in der IT, nur ganz wenige arbeiten schon komplett agil. Viele Großunternehmen stehen nun vor der Entscheidung, ob und wie sie Agilität in ihrer Organisation in der Breite verankern sollen. Gleichzeitig versinkt das Thema in einem diffusen Buzzword-Bingo aus Theorien, Frameworks und neuen Rollen. Allein LinkedIn liefert 258.000 Ergebnisse bei der Suche nach einem agilen Coach.

Wir Autoren kommen aus der Praxis der agilen Transformation, mit ganz unterschiedlichen Perspektiven. Aus unterschiedlichen Branchen, Firmen und Bereichen. In B2B und B2C. Aus der IT, dem Personalbereich und Fachbereichen. In der Funktion als Tribe-Leader, Transformation-Lead oder Coach und Berater. Insgesamt haben wir mehr als 1.000 Teams begleitet und haben gemeinsam mehr als 15 Jahre praktische Erfahrung in der agilen Transformation gesammelt.

Grund genug, einmal neun Erfolgsfaktoren aufzuschreiben, die unserer geteilten Erfahrung nach für das Gelingen der agilen Transformation wichtig sind. Dabei geht es uns nicht um eine Blaupause oder eine exakte Marschroute. Daran glauben wir nicht. Jedes Unternehmen muss seinen eigenen Weg gehen. Aber egal welchen Weg man wählt – an einigen Stellen kommen alle vorbei. Und hierfür möchten wir Tipps geben. Nicht aus Lehrbüchern, sondern aus guten und schlechten Erfahrungen, die wir gemacht haben. Aus der täglichen Arbeit, aus persönlichen Gesprächen, Diskussionen an runden Tischen und gegenseitigen Vor-Ort-Besuchen. Wir hoffen, dass wir mit diesem Praxisbericht vielen Unternehmen auf Ihrem Weg in der agilen Transformation wichtige Reisetipps geben können!

Christin Zörner, Daniel Poelchau, Dominik Bauersch, Holger Neinhaus und Kirsten Weisbender

DIE 9 ERFOLGSFAKTOREN DER AGILEN TRANSFORMATION IN GROSSUNTERNEHMEN


I. DAS TOP MANAGEMENT – MITTEN DRIN ODER NUR DABEI

In vielen Organisationen gibt es bereits agil arbeitende Teams als Pioniere und Experimente, oft auf Basis der Eigeninitiative von einzelnen Personen. Der Start in eine agile Transformation sollte jedoch nicht einfach „passieren“. Vor der Skalierung agiler Arbeitsweisen braucht es eine intensive Auseinandersetzung im Top-Management:

- Welche Bedeutung soll Agilität für uns als Unternehmen haben?
- Welchen Herausforderungen wollen wir damit begegnen?
- Welche Ziele wollen wir damit erreichen? Welche Probleme lösen?
- Welche Strukturen sollen „agilisiert“ werden und welche nicht?
- Stehen wir als Management dahinter oder werden wir vom Trend getrieben?
- Wie viel geben wir top-down vor und was soll bottom-up entstehen?
- Sind wir mittelfristig wirklich zu tiefgreifenden Veränderungen bereit?

Der viel zitierte „Purpose“ der Transformation sollte klar sein. Es braucht eine klare Vision und Richtung, konkrete Zielsetzungen und formulierte Erwartungen. Denn ohne Kompass und Leadership, das die Veränderung anführt, verlaufen die Prozesse richtungs- und kraftlos. Es braucht klares Committment, Konsequenz und Mut aus dem Top-Management, damit die Transformation gelingt. Es geht um das Kerngeschäft, Kultur, Budgets und Macht. Recht oft scheitern Vorhaben schon vor dem Start am fehlenden Alignment im Top-Team.

Um die Diskussion im Top-Management anzustoßen, haben wir sehr gute Erfahrungen damit gemacht, Management-Teams zu „Go and See Trips“ und „Learning-Journeys“ bei bereits agilen Unternehmen vor Ort zu bringen . Der Blick in den Maschinenraum einer agil arbeitenden Organisation sowie der informelle Austausch mit anderen Führungskräften liefern wertvolle Impulse und die Möglichkeit, die eigenen Erwartungen zu kalibrieren. Und die Bereitschaft zum industrieübergreifenden Erfahrungsaustausch ist dabei wirklich groß.

Nach dem „Kick-off“ bedarf es einer regelmäßigen Überprüfung des Kurses, einer kontinuierlichen inhaltlichen Auseinandersetzung und Kommunikation durch das Top-Management. Denn das Top-Management darf die Transformation nicht nur starten, sondern muss sie auch konsequent anführen. Was für agile Teams gilt, zählt auch bei der organisatorischen Skalierung: kein Big Bang, der die ganze Organisation von heute auf morgen auf links dreht. Nicht alle Abläufe müssen verändert werden. Auch hier geht es Schritt für Schritt.

Das Top-Management muss auch die neue Steuerung vorantreiben. Viele Unternehmen streben danach, sich nach Wertströmen und Customer-Journeys auszurichten, und so kundenorientierter, schneller und effizienter zu werden. Die Umstellung der Steuerung auf agile Kadenzen wie ein Quarterly Business Review oder die Finanzierung von Tribes als „Unternehmen im Unternehmen“ statt auf Ebene einzelner Maßnahmen und Projekte sind Beispiele wie das neue Management gelingen kann. Dies wird aber unweigerlich scheitern, wenn die alten Strukturen, Boards und Prozesse im Hintergrund dauerhaft bestehen bleiben. „Alte Prozesse“ sind oft eine große Herausforderung und Sorgen für Frust in den agilen Teams, die neue Wege gehen wollen und sollen.

Wenn das Top-Management diese Veränderungen nicht aktiv treibt, werden Tribes oder Chapter oft in den bestehenden Strukturen abgebildet. Die bestehende, klein- und arbeitsteilige Organisation wird dann „agilisiert“ – ohne, dass neue bereichsübergreifende Strukturen und Abläufe entstehen.

Insgesamt muss das Top-Management die richtige Balance finden: Klarheit, Richtung und Unterstützung von oben und gleichzeitig viel Freiraum geben, damit die Agile Transformation auch das Werk der Mitarbeiter werden kann. Eben mitmachen, vorleben und ermutigen.


II. AGIL ≠ IMPROVISIERT – DIE BEDEUTUNG EINER GUTEN VORBEREITUNG

Agilität wird häufig assoziiert mit Improvisation oder sogar Planlosigkeit. Das ist falsch. Insbesondere bezogen auf die Vorbereitung und den Start der agilen Transformation. Eine gründliche Vorbereitung ist erfolgskritisch. Hierbei geht es nicht um einen allumfassenden Masterplan oder eine ausgeklügelte Tribe-Taxonomie. Es geht um gewisse Startvoraussetzungen und Vorlaufzeiten für die ersten agilen Teams, die zentral geklärt und vereinbart werden sollten. Sonst blicken die Pioniere einem holprigen Start entgegen.

Das Buy-in des Managements und die Auswahl der richtigen Themen (später dazu mehr) sind elementar. Weitere, scheinbar banale und sehr operative Punkte sind:

Sind die wichtigsten Mitglieder für die agilen Teams benannt und auch verfügbar?
- Sind die Mitglieder frei von „Altlasten“ im Sinne von Linienaufgaben?
- Sind Rollen wie Agile Coach und Scrum Master besetzt und entsprechend ausgebildet?
- Gibt es intern Leute mit Erfahrungen? Oder Budget für externe Unterstützung?
- Ist der Betriebsrat informiert und eingebunden?
- Wo findet die cross-funktionale Zusammenarbeit physisch statt? Gibt es Räume?
- Welche digitalen Tools sollen für die Teamarbeit genutzt werden?
- Gibt es eine klare Zielsetzung, die mit den Stakeholdern abgestimmt ist?
- Wie messen wir den Erfolg?
- Wie sammeln wir Feedbacks und machen Erfahrungen für andere Teams verfügbar?

Diese Aufzählung ist sicher nicht abschließend und klingt an vielen Stellen auch profan. Dennoch kommen diese Punkte immer wieder zu kurz, weil man dann doch unmittelbar mit der Arbeit an vielen Themen in agilen Teams beginnen möchte, ohne sich ausreichend Zeit für die Vorbereitung zu nehmen. Gerade in der Startphase ist zu viel Improvisation schädlich und defokussiert die Teams. Und es ist sehr aufwändig, die Dinge später zu reparieren, wenn Vertrauen beim Betriebsrat verspielt oder die Teams eigene Tools ausgewählt und konfiguriert haben, aber plötzlich zusammenarbeiten sollen. Fehler machen ist Teil der Reise, es muss nicht alles 100% klar sein, aber ohne die oben genannten Vorbereitungen geht man schon mit einem schweren Rucksack vom Start los.


III. GROSSE ZIELE BRAUCHEN KLEINE SCHRITTE (UND EINEN LANGEN ATEM)

Warum nicht gleich einen „Big Bang“? Warum starten wir nur mit einer Handvoll Teams? Im anderen Ressort haben sie schon agile Teams, wir müssen jetzt auch welche los jagen! Die Frage nach der richtigen Geschwindigkeit, mit der agile Arbeitsweisen skaliert werden, stellt sich früher oder später. Nach einem gut vorbereiteten Start braucht es eine intensive Phase, in der gelernt, ausprobiert und adaptiert wird. Es braucht Erfahrung und Ausdauer, bis die ersten sichtbaren Erfolge und damit die Akzeptanz des Themas in der Breite der Organisation ankommen und wachsen kann. Diskussionen über Tribe-Architekturen helfen in der Startphase nicht wirklich, sondern lenken ab.

Wir halten bis zu 10 agile Teams im ersten Jahr und in einer Geschäftseinheit für eine gute Größenordnung. Dafür sollten keine Kompromisse bei Ausstattung, cross-funktionaler Besetzung, Ausbildung und Tools gemacht werden. Auch ist es wichtig, mit den richtigen Themen und Menschen zu starten: Die größten Probleme, die in den vergangenen Jahren nicht wirkungsvoll gelöst werden konnten, werden neu startende agile Teams heillos überfordern. Aufgaben mit vielfältigen Schnittstellen, zersplitterten Zuständigkeiten, viel Politik und komplexen Abhängigkeiten eignen sich ebenso wenig.

Die „Start-Themen“ müssen aber dennoch Relevanz und Sichtbarkeit für das Kerngeschäft haben. Sonst entfalten sie keine Leuchtturmwirkung und Teams werden schnell als „die Agilen da im Streichelzoo“ abgetan. Notwendig sind Relevanz und Bedeutung – aber auch eine realistische Chance auf Erfolg. Der Realisierungszeitraum sollte kurz- bis mittelfristig sein (< 1 Jahr) und es sollte in Etappen ausgeliefert werden können. Das scheint logisch, trifft aber in Konzernen auf viele Themen nicht zu. Die richtige und konkrete Themen- und Zielsetzung zum Start ist auch für Tribes, also der nächsthöheren Ordnungsebene, erfolgskritisch: Die Ressourcen und Teams müssen auf ein konkretes Ziel mit Relevanz für die Organisation ausgerichtet werden.

Beispiele für mögliche Themen zum Start sind: Der Aufbau eines Kundenportals, die Einführung einer App oder die Entwicklung eines Systems für den Innendienst. Und die Teams müssen wirklich konsequent cross-funktional aufgesetzt werden, damit die neue Art der Zusammenarbeit als Kern sichtbar wird. Zu oft werden einfach bestehende Teams in der IT oder in anderen Bereichen auf agil „umgestellt“ – ohne, dass sich echte Änderungen einstellen. Also: Klein, fokussiert aber richtig starten, statt zu schnell zu viel wollen.

Wenn wir Eines erlebt haben: Das Feuer der agilen Transformation wird in den Teams entfacht. Der Erfolg von agilen Teams, der kommuniziert und auch gefeiert wird, ist die wirkungsvollste Change-Maßnahme und entfaltet einen Sog in der Organisation. Die Skalierung und das sukzessive Wachstum kommen dann von ganz allein.


IV. CROSSFUNKTIONALE TEAMS MACHEN DEN UNTERSCHIED

In fast allen Unternehmen erfolgen die ersten Gehversuche in der IT. Und das ergibt aus vielerlei Sicht auch großen Sinn, denn SCRUM, als eine agile Kerndisziplin, hat die ursprüngliche Software-entwicklung dramatisch verbessert. Das ist insofern dringend erforderlich, da die klassische IT mit einem Wasserfallmodell mit Markt- und Kundenanforderungen häufig nicht mehr mithält. Zu teuer, zu spät, am Bedarf vorbei. Die IT-Organisationen stehen unter Druck und streben mit der agilen Transformation nach der Lösung.

Oft ist die IT den Fachbereichen daher zwei Schritte voraus. Es wird skaliert und weitere Teams aufgebaut. Wenn der Fachbereich keinen Product-Owner schickt? Egal, dann macht den Job ein IT-Kollege als „Proxy-PO“. Und wenn die Fachseite dabei ist, dann sitzen oft nicht die wirklichen operativen Mitarbeiter der Fachseiten drin. Es sind häufig „Demand-Management“ oder andere „Übersetzer“ zwischen Fachseite und IT, die in die neuen Rollen springen. Was dann unverändert fehlt sind Kundennähe, operatives Know-How und wirkliche Cross-Funktionalität.

Beim Setup der Teams ist es erfolgskritisch, dass beispielsweise Design-Kompetenzen wirklich im Team sind und nicht an eine Agentur ausgelagert sind. Wenn ein neues Vertriebssystem gebaut wird, dann muss der operative Vertrieb auch wirklich dabei sein und die Features priorisieren. Oder ein Mitarbeiter aus dem Kundenservice, wenn es um die Entwicklung eines Chat-Bots oder die Verbesserung von Serviceprozessen geht. Oft bringen diese Rollen die Teams wirklich weiter: Sie wissen was gebraucht wird. Und wenn sie dann noch klar mandatiert sind, können schnell Entscheidungen getroffen und Fortschritte gemacht werden.

Auf der anderen Seite gibt es auch „Agile Power Point Squads“ auf den Fachseiten. Eine agile Anforderungsphase kann ein sinnvoller Zwischenschritt sein, aber es darf nicht dazu führen, dass die Anforderungsphase in Dokumenten endet, die an andere agile IT-Teams weitergeschoben werden. Nur wenn IT und Fachseite gemeinsam in einem Team arbeiten und in die Verantwortung gehen, dann entsteht etwas Neues. Echte cross-funktionale Teams mit gemeinsamen Zielen und einer transparenten Erfolgsmessung sind der Kern der Transformation. Das bedeutet nicht, dass immer alle Bereiche vertreten sein müssen. Es gibt Aufgaben, die nur temporär anfallen. Die Teams so groß wie nötig und so klein wie möglich zu halten ist wichtig; ab 10 Personen wird es schwierig. Denn Abstimmungsaufwände und „Overhead“ steigen dann überproportional an.

Auch bei der Skalierung braucht es Cross-Funktionalität. Denn es kommt zu agilen Doppelstrukturen, wenn zu Beginn kein gemeinsames Zielbild entwickelt wurde, wie die Aktivitäten verzahnt werden sollen. Es muss eine Zielkongruenz geschaffen werden. Ansonsten gibt es Factories/Hubs in der IT und Tribes/Value Streams auf der Fachseite, die nicht Hand in Hand arbeiten und wieder umfangreicher Koordination und Abstimmung erfordern.

Der echte Test für die cross-funktionale Zusammenarbeit kommt übrigens dann, wenn es mal nicht gut läuft. Schlechtes Kundenfeedback, der Go-Live klappt nicht, die Zahlen stimmen nicht und viele weitere Gründe. In diesen Momenten ist es wichtig, nicht in alte Verhaltensmuster und Schuldzuweisungen zwischen Fachseite und IT zurück zu fallen. Sondern: ein Team, ein Auftrag, keine Schuldzuweisungen. Hier sind agile Coaches und auch Führungskräfte gefordert, dem Team aktiv zu helfen.


V. PLANUNG UND STEUERUNG: PRODUKTE STATT POWERPOINT

Steuerer und Planer blicken oft skeptisch auf die agile Transformation. Denn wie geht das in einem agilen Unternehmen? Was tritt an die Stelle von Lenkungsausschüssen und projektbezogenen, engmaschigen Freigabe- und Stage-Gate-Prozessen?

Zunächst lohnt sich ein Blick auf den „Erfolg“ der bisherigen Mechanismen. Warum kommt es trotz zahlloser Reportings und ausgeklügelter Excel-Templates mit 50 Ampeln und 4-wöchentlichem Rhythmus so oft kurz vor Projektende zu Mehrbedarfen, Verschiebungen oder Totalausfällen? Haben die Gremien wirklich ein inhaltliches Verständnis für die Maßnahmen, die sie freigeben und monitoren?

Aus unserer Erfahrung bieten neue, agile Formate eine weitaus höhere Transparenz, eine viel stärkere inhaltliche Auseinandersetzung und eine bessere unterjährige Möglichkeit der Einflussnahme. Und der Aufwand für den „Kontrollapparat“ sinkt deutlich. Wir haben mit der Nutzung von drei Instrumenten und Formaten, die die agile Transformation zu steuern helfen, gute Erfahrungen gemacht:

Tribe / Product Plannings (PIPs) dienen dazu, die inhaltliche Arbeit und die Kapazitäten der Teams für das kommende Quartal zu beplanen. Die Business Owner geben Inputs, welche Inhalte für sie in der anstehenden Periode wichtig sind. Aber auch die Teams bringen selber Anforderungen ein. Die Teams verpflichten sich auf Lieferobjekte, die sie mit den zur Verfügung stehenden Kapazitäten in der kommenden Periode abarbeiten wollen. Außerdem schafft das Planning die notwendige Transparenz über Abhängigkeiten sowie Liefer- und Leistungsbeziehungen mit anderen Teams und Tribes. Für das Management ist das Planning eine gute Gelegenheit, um die Teams mit einem „Business Update“ zu versorgen und in den Austausch zur Strategie und zum Fortschritt zu kommen. Leider wird vom Management (den Business Ownern) oft unterschätzt, wie wichtig es ist, sich im Planning „zu zeigen“ und in den Austausch mit den Teams zu kommen und die Richtung vor zu geben.

Quarterly Business Reviews (QBRs) finden zwischen dem Top / Executive Management und den Führungsteams der Tribes statt. In diesem persönlichen Austausch erfolgt eine fokussierte Diskussion über die gelieferten Ergebnisse des letzten Quartals und über die geplanten Aktivitäten für die kommende Periode. Beim Blick zurück geht es nicht um Vollständigkeit: Was war besonders gut und sollte ausgebaut werden, was hat nicht funktioniert und welche Schlüsse ziehen wir daraus? Wo braucht es Hilfe in den kommenden Monaten, um die Ziele zu erreichen? Für die Tribes geben die Diskussionen im QBR vor allem inhaltliche Orientierung und bieten die Möglichkeit, Widerstände, die durch das Top-Management gelöst werden müssen, offen zu adressieren. Dem Management gibt der regelmäßige Rhythmus des QBRs eine neue Transparenz und die Möglichkeit, wirklich Einfluss nehmen zu können.

Die Nutzung von Objectives and Key Results (OKRs) sind ein gutes Instrument, um die Aufgaben und Ziele der Teams und Tribes fokussiert und mit Blick auf die kommenden drei Monate transparent auszurichten. Die Vereinbarungen aus dem Planning finden hier gleichermaßen Eingang, wie auch Business-Ziele zur Steigerung von Transaktionen oder organisatorische und das Team betreffende Themen. Die OKRs werden bewusst sehr ambitioniert formuliert und eine vollständige Erreichung gelingt nur unter optimalen Rahmenbedingungen. Die Key Results sollen dabei konkret und messbar formuliert werden. Die OKRs dienen der monatlichen Fortschrittsüberprüfung im Team/Tribe und am Ende des Quartals auch der Diskussion mit dem Management (z.B. im QBR). Die OKRs sind dabei ein guter Indikator, wie der Veränderungsprozess fortschreitet, und sorgen für Transparenz in der Organisation.

Aus unserer Erfahrung ist es wichtig, dass agile Teams und Tribes relativ schnell über neue agile Formate begleitet werden und die klassischen Prozesse keine Anwendung mehr finden. Und auch hier gilt: Einfach mal mit einem ersten Tribe oder ein paar Teams ausprobieren und loslaufen. Denn agile Teams sind eigentlich der Traum eines jeden CFOs, da sie sich einer quasi Gewinn- und Verlustrechnung für ihr Produkt verpflichten und den Erfolg von Anfang bis Ende im Blick haben.


VI. TRANSFORMATION GIBT ES NICHT ZUM NULLTARIF

Die Agile Transformation ist keine klassische Re-Organisation. Es geht nicht darum, Organisationseinheiten neu zu strukturieren und durch die Optimierung von Führungsspannen kurzfristig Effizienzen zu heben. Wenn man sich solche Ziele setzt, dann wird das unserer Erfahrung nach nicht funktionieren. Es geht um die Ausrichtung auf den Kunden, eine andere Art der Zusammenarbeit mit neuen Methoden, eine neue Führung und ein anderes „Miteinander“.

Das kostet Zeit. Und Zeit ist nun mal Geld. Beim Geld werden die Diskussionen oft schwierig. „Muss kompensiert werden, muss in die bestehenden Budgets passen, darf nicht zu Lasten des Ergebnisses gehen“ sind die typischen Reflexe. Um es klar zu sagen: Es braucht Budget und es gibt keinen kurzfristigen, garantierten Payback. Die agile Transformation ist eine mittel- bis langfristige Investition in die Zukunft.

Worin bestehen die Mehraufwände?

- Es braucht Schulungen, um neue Methoden zu lernen – das kostet Zeit und erfordert Coaches.
- Es braucht neue Fähigkeiten (bspw. Scrum, CX, Python), die zunächst oft von extern eingekauft werden müssen. Wir reden hier nicht von Tagen sondern Monaten.
-Es braucht neue Tools, Systeme und Räumlichkeiten.
-Kundenzentriertes Arbeiten erfordert die systematische Befragung von Kunden und die Einführung maschineller Tests.
-Datengetriebene Entscheidungen brauchen Daten. Und die müssen gesammelt werden.
-Hinzu kommt natürlich noch der Umbau der IT-Architektur in Richtung APIs, CICD und Cloud.
-Es braucht Mitarbeiter, die in den neuen Teams arbeiten – ihre bisherigen Aufgaben bleiben aber teilweise in der Linienorganisation zurück. Die alte Organisation ist „ja auch noch da“.

Und auch wenn man diese Mehraufwände akzeptiert und auf sich genommen hat: Aus den ersten Teamsprints kommt oft wenig raus. Die Teams brauchen Zeit, um zu lernen und zu wachsen.

Erst nach 18-24 Monaten stellen sich die Erfolge ein: Produkte werden besser, Kundenzufriedenheit und Conversionrate steigen, IT-Releasezyklen werden engmaschiger, die time-to-market sinkt und die Mitarbeiterzufriedenheit steigt.

Unsere gemeinsame Erfahrung ist eindeutig: In den ersten beiden Jahren muss investiert werden. Es braucht Geduld und einen festen Kurs, wohin die Reise gehen soll. Wenn nur in agile Methoden und Werte-Workshops investiert wird, werden die Produkte nicht besser und die Delivery nicht schneller. Am Ende muss ein Wertbeitrag geleistet werden. Und hier muss die agile Transformation den Beweis antreten, dass dieser auch nachhaltig geliefert wird. In welcher Dimension auch immer (Kunde, Markt, Mitarbeiter…).


VII. PERFORMANCE AB DEM ERSTEN TAG

Zu Beginn der Transformation wird der Fokus oft allein auf Arbeitsweisen, Kultur und Werte gelegt. Workshops zu agilen Werten oder SCRUM-Schulungen sind Beispiele. Dies führt insbesondere im Top-Management oft zu Fragezeichen und kritischen Stimmen („Kommt da auch mal was raus?“) und die Teams richten sich manchmal in einer falsch verstandenen Wohlfühlumgebung („Wir sind hier niemandem Rechenschaft schuldig!“) ein.

Die Dimensionen „konsequente Kundenorientierung“, „Transparenz“, „Messbarkeit“ oder „kontinuierliche Verbesserung“ werden häufig erst spät fokussiert. Das ist ein großer Fehler, denn die agile Transformation wird dann einseitig in der Kultur-/Methoden-Ecke abgestellt und kann nicht funktionieren. Das Vertrauen des Managements schwindet schnell und ausbleibende messbare Ergebnisse gefährden den ganzen Prozess. Sehr oft werden Teams nach einer „Warmlaufphase“ mit ausbleibenden Ergebnissen, dem Wunsch nach agilen Metriken und Outcomes konfrontiert. Die Konflikte sind vorprogrammiert.s

Ein agiles Team braucht zum Start eine klare Aufgabe, echten Handlungsspielraum und nachvollziehbare Ziele, deren Erreichung es auch messen kann. Ein Team muss die Kosten kennen, die es in einem Sprint verursacht. Eine Retrospektive ist kein Selbstzweck. Werden wirklich Verbesserungen umgesetzt? Am Ende muss ein Team die Lust entwickeln, sich regelmäßig zu hinterfragen und zu wachsen. Oft wird die Frage nach Zahlen, Ergebnissen oder der Team-Performance als "nicht agil" abgetan und es wird auf die Team-Autonomie verweisen. Am Ende kann es Team-Autonomie aber nicht ohne konsequente Ergebnisorientierung und Transparenz geben. Dies braucht Begleitung und ist ein erfolgskritischer Andockpunkt für Stakeholder und Businessowner, damit die Teams nicht nur richtig im agilen Sinn, sondern auch an den richtigen Dingen arbeiten.

Die Teams brauchen hier Zeit und einen Vertrauensvorschuss. Und sie brauchen Impulse und Unterstützung durch das Management. Die ersten Monate sind in dieser Hinsicht oft "zäh" und müssen als bewusstes Investment in das Team und die Zusammenarbeit mit dem Management verstanden werden. Das gilt natürlich auch und insbesondere für die übergeordnete Ebene wie einen Tribe. Oder auf der Transformationsebene für das Top-Management, denn die Teams zahlen mit ihren Aktivitäten auf übergeordnete Wertströme ein.


VIII. METHODENKOMPETENZ JA / DOGMATISMUS NEIN

Agile Teamarbeit braucht Regeln und Strukturen. Ein Wertstrom oder ein Portfolio muss geplant und priorisiert werden. Abhängigkeiten zwischen Teams müssen transparent sein. SCRUM, LeSS und andere Methoden geben hierbei Sicherheit und Orientierung. Kurz: Ohne Methodenkompetenz geht es nicht.

Aber Großunternehmen sind meist gut darin, Prozesse zu standardisieren, einzuführen und die Einhaltung zu monitoren. Vermutlich ist dies auch der Grund, warum sich viele sofort auf großformatige Big-Room-Veranstaltungen und umfassende Frameworks wie SAFe stürzen, bevor die ersten Teams wirklich erfolgreich arbeiten. Man bekommt die Dinge so "unter Kontrolle" und Führungskräfte finden in Frameworks eine Menge Rollen, die Ihrer aktuellen Linienaufgabe entsprechen.

Natürlich müssen Grundlagen gelernt und Regeln vereinbart werden. Und Skalierung braucht eine vereinbarte Struktur, keine Frage. Wichtig ist aber auch, dass die Teams, nachdem sie Erfahrungen gemacht haben, ihren eigenen "Way of Working" entwickeln und wirklich auch Entscheidungen treffen können. Frameworks und Plannings dürfen nicht zum Selbstzweck überhöht werden und dürfen die Teams nicht in ein Korsett zwängen. Sie müssen pragmatisch an die eigenen Strukturen angepasst und nicht dogmatisch exekutiert werden.

In einigen Fällen bleibt die Ablieferung in einem "IT-Mini-Wasserfall" besser als die reine agile SCRUM-Lehre. Oft fehlen Pragmatismus und der Mut, Dinge einfach auszuprobieren. Stattdessen gibt es häufig dogmatische Diskussionen, ob das „richtig agil“ ist. Hier wird häufig viel Zeit und Energie investiert, die weder „Spirit“ noch Outcome der Teams und Tribes unterstützt. Der Factory-Lead eines großen Finanzdienstleisters sagte hierzu treffend: "Die agilen Skeptiker im Unternehmen sind das eine, die viel größere Herausforderung sind die agilen Dogmatiker."


IX. KULTUR – DER EISBERG

Wir haben viel über neue Methoden, Ziele, Strukturen und Prozesse geschrieben. Das ist alles notwendig. Die agile Transformation zielt aber ganz maßgeblich auf ein neues Miteinander und eine neue Qualität der Zusammenarbeit ab – auf die Kultur im Unternehmen.

Wie schafft man hier Veränderung? Auch vor dem Hintergrund, dass die bestehende Kultur im Unternehmen schwer zu „greifen“ und außerdem über viele Jahre gewachsen ist.

Starten wir damit, welche Kultur wir schaffen wollen. Einige Punkte, die für uns agile Kultur ausmachen:

- Den Kunden konsequent in den Fokus stellen.
- Die Bereitschaft, auszuprobieren, kontinuierlich zu lernen und Änderungen vorzunehmen.
- Persönliche Interaktionen höher werten als die Bedienung von Prozessen und Tools.
- Die Transparenz und Ehrlichkeit innerhalb der Teams und gegenüber den Stakeholdern.
- Das Verständnis, dass Fehler passieren und Teil der Lösung sind.
- Die hohe Wertschätzung und das Vertrauen in die Arbeit der selbstorganisierten Teams.
- Die Bereitschaft in den Teams, Verantwortung zu übernehmen und Entscheidungen zu treffen.

In den vergangenen Jahren und Jahrzehnten wurde in Großunternehmen und Konzernen aber in der Regel das Gegenteil verlangt: PowerPoint-Schlachten, Excel-Engineering, Storytelling in der Budgetplanung und Entscheidungen mit drei Kästchen zum Ankreuzen vorbereiten. Unternehmerisches Denken und Handeln muss gelernt und gefördert werden. Wenn Teams keinen Entscheidungsraum bekommen und sie ihn sich nicht schrittweise erweitern können, dann fehlt der Kern der Transformation – es fehlt an Raum, um zu wachsen.

Und wo Entscheidungen getroffen werden, da passieren auch Fehler. Wie weit ist es mit der neuen Fehlerkultur? Wird die Transparenz und Offenheit trotz eines Rückschlags ausdrücklich gelobt und es wird vereinbart, die Ursachen für die Situation zu verstehen? Oder trauen sich die Teams gar nicht erst, verharren im alten Modus und erklären aufwendig, dass das Ergebnis eigentlich gar nicht so schlecht ist. Hier reichen oft einzelne Entscheidungen nach altem Verhaltensmuster, um monatelange Veränderungen wieder über den Haufen zu werfen. Dann bekommt man wieder „Dog and Pony Shows“, statt den ungeschminkten Blick in den Maschinenraum.

Tritt das Management, wenn es darauf ankommt und das Scheitern droht, als Partner auf, wird es Teil der Lösung und unterstützt das Team aktiv? Oder eben nicht? Findet in diesen Momenten Kommunikation wirklich auf der viel zitierten Augenhöhe statt – inhaltlich, sachlich, wertschätzend und lösungsorientiert – oder eben doch top-down und belehrend, bevor die Teams ohne einen Mehrwert bei der Lösung des Themas wieder allein gelassen werden? Das sind die entscheidenden Wegpunkte. Im Erfolg ist Führung leicht und angenehm. Das Neue beginnt aus den kleinen und großen Krisen und Rückschlägen durch ein neues Miteinander. Eben durch persönliche Interaktionen von Individuen und nicht durch die Bedienung von Prozessen.

Die Mitarbeiter beobachten sehr genau und schauen „nach oben“, ob denn dort auch gelebt was gepredigt wird. Wenn im Management nicht wirklich zusammengearbeitet wird, wenn es kein Vertrauen in die Mitarbeiter und die Belegschaft gibt, den Weg der agilen Transformation erfolgreich bestreiten zu können („Da haben wir nicht die richtigen Mitarbeiter für“), dann sollte man ihn besser gar nicht erst beschreiten.

Insbesondere die kulturelle Veränderung braucht Zeit, Geduld, und muss erfahren werden. Sie braucht glaubwürdige und nachhaltige Vorbilder im Unternehmen. Am Ende gelingt die Transformation nur mit dem richtigen Mindset und einer neuen Kultur. Denn die Menschen machen den Unterschied.


EIN EHRLICHES (ZWISCHEN)-FAZIT

Die agile Transformation ist kein „Home Run“. Sie ist anstrengend und braucht Geduld. Mindestens das erste Jahr ist hart und muss als Investition verstanden werden. Und jeder muss durch dieses erste Jahr. Es gibt keine Abkürzungen.

Wir haben viele Teams und auch ganze Tribes gesehen, die nicht in den "Flow" gekommen sind und nach einem Jahr wenig oder nichts vorzuweisen hatten. Unserer Erfahrung nach tun sich 20-30 Prozent der Teams sehr schwer, verfehlen die Ziele deutlich oder scheitern im ersten Anlauf sogar komplett. In allen Transformationsprogrammen musste mehrfach umgeplant und teilweise neu gestartet werden. Trotzdem möchte keiner unserer Kolleginnen und Kollegen das Rad zurückdrehen.

Denn: Es lohnt sich!

Wenn die Teams als Motor der Transformation anfangen zu laufen, schneller werden und zu echten Teams zusammenwachsen, selbständig Entscheidungen treffen, selbstbewusst und transparent zu Fehlschlägen berichten, man den Stolz auf das eigene Team und ihr Produkt wirklich spüren kann, dann erlebt man die großen Chancen und Kraft der agilen Transformation. Dann sieht man Ergebnisse, die in der "alten Welt" schlicht nicht möglich waren.

Es kommt zu messbaren Verbesserungen bei der Durchlauf-Geschwindigkeit von der Idee bis zum Launch. Die Reaktionsgeschwindigkeit bei neuen Kunden- oder Marktanforderungen steigt. Auch erkennen wir Autoren alle eine höhere Qualität der Ergebnisse, denn es wird viel häufiger inhaltlich hinterfragt und mit Kunden, Mitarbeitern und Stakeholdern frühzeitig diskutiert.

Auch erkennen wir die positiven Veränderungen in der Kultur: Sie wird weniger hierarchisch und politisch, dafür stärker an Inhalten und Ergebnissen orientiert. Wenn die neue Kultur langsam wachsen kann und anfängt, über Team- und Tribe-Grenzen auszustrahlen, dann kann wirklich etwas Neues wachsen.

Wir hoffen, dass wir mit unseren 9 Erfolgsfaktoren zum Gelingen Eurer Transformationen einen kleinen Beitrag leisten können und Ihr von unseren guten und schlechten Erfahrungen lernen könnt. Wir glauben an die agile Transformation! Wie auch immer der Weg im Detail verlaufen wird.

Viel Erfolg!

Christin Zörner, TELEKOM DEUTSCHLAND | Head of Agile Transformation & Operating Office

Daniel Poelchau, ALLIANZ PKV | Chief Business Transformation Officer

Dominik Bauersch, AXA KONZERN | Tribe Leader and Head of Digital Interaction & Experience

Holger Neinhaus, SMP STRATEGY CONSULTING | Partner Transformation Practice

Kirsten Weisbender, COMMERZBANK | Head of Digital Culture, Strategy & Development

Kontakt zum Autoren-Team: team@agile-transformation-praxisbericht.de

Impressum

Verantwortlich im Sinne des Telemedienrechts für die Domain www.agile-transformation-praxisbericht.de

Stellvertretend für die Autoren

Holger Neinhaus
Wasserstrasse 8
40474 Düsseldorf
Telefon: 0211-130669-60
E-Mail: holger.neinhaus@smp-ag.de

Inhaltlich Verantwortlicher: Holger Neinhaus (Anschrift s. o.)

Datenschutzerklärung