Agile Transformation im Konzern | Case Study

Ein führender Telekommunikationskonzern stand vor einer typischen, aber anspruchsvollen Transformationsherausforderung: Die internationale Konzernmutter hatte den Übergang zu agilen Arbeitsweisen als strategische Richtung definiert. Ziel war es, schneller auf Marktveränderungen zu reagieren, Time-to-Market zu verkürzen und die Zusammenarbeit zwischen Business, IT und weiteren Unternehmensbereichen wirksamer zu gestalten.

Auf lokaler Ebene traf diese Vorgabe jedoch auf eine gewachsene Konzernrealität: komplexe Legacy-IT, etablierte Entscheidungswege, funktionale Silos, unterschiedliche agile Reifegrade und eine Rollenlandschaft, die historisch gewachsen war.

Die zentrale Frage war daher nicht:
„Wie führen wir agile Methoden ein?“

Sondern:
„Wie schaffen wir eine Arbeitsweise, die im Konzernalltag tatsächlich tragfähig ist und bessere Umsetzung ermöglicht?“

Customer Snapshot

Branche: Telekommunikation
Transformationsfokus: Agile Transition in einer gewachsenen Konzernstruktur
Rolle: Lead Agile Coach / Agile Transformation Lead
Schwerpunkte: Agile Transformation, Change Management, Rollenklarheit, Operating Model Design, Pilotierung
Ziel: Bessere Strategieumsetzung, klarere Verantwortlichkeiten, kürzere Entscheidungswege und skalierbare agile Zusammenarbeit

Situation: Eine klare Vorgabe trifft auf komplexe Realität

Die strategische Richtung war eindeutig: Die Organisation sollte agiler werden, schneller liefern und besser auf Markt- und Kundenbedürfnisse reagieren.

Auf lokaler Ebene zeigte sich jedoch schnell, dass diese Transformation nicht einfach nach einem zentralen Modell ausgerollt werden konnte. Viele Strukturen waren historisch gewachsen. Entscheidungswege waren etabliert, Verantwortlichkeiten stark funktional geschnitten und die Zusammenarbeit zwischen Business, IT, Produkt- und Projektrollen von vielen Schnittstellen geprägt.

Die Organisation war nicht grundsätzlich gegen Veränderung. Gleichzeitig war spürbar, dass eine agile Transformation nur dann erfolgreich sein würde, wenn sie zur realen Arbeitsweise, zur bestehenden Governance und zu den tatsächlichen Engpässen passte.

Key Insight

Agile Transformation scheitert selten daran, dass Menschen agile Methoden nicht verstehen. Sie scheitert häufiger daran, dass Strategie, Struktur, Entscheidungslogik, Rollen und tägliche Zusammenarbeit nicht sauber ineinandergreifen.

Herausforderung: Warum ein klassischer Rollout nicht funktioniert hätte

Ein Big-Bang-Rollout hätte die Organisation zu diesem Zeitpunkt überfordert. Zu unterschiedlich waren die Reifegrade, zu stark die bestehenden Abhängigkeiten und zu groß das Risiko, agile Rollen und Events nur formal einzuführen, ohne die eigentlichen Engpässe zu lösen.

Eine zentrale Herausforderung lag in der bestehenden Rollenvielfalt. Rollen wie Product Manager, Product Owner, Market Manager, Delivery Manager und IT Project Manager waren im Unternehmen etabliert, wurden im Alltag jedoch nicht durchgängig gleich verstanden.

Dadurch entstanden typische Spannungsfelder:

• Rollenvielfalt ohne gemeinsames Rollenverständnis führte dazu, dass Verantwortlichkeiten unterschiedlich interpretiert wurden.

• Überschneidungen zwischen Product-, Delivery- und Projektrollen verzögerten Entscheidungen oder führten zu mehrfachen Abstimmungen.

• Funktionale Silos erschwerten echte End-to-End-Verantwortung.

• Komplexe Governance führte dazu, dass Entscheidungen lange dauerten oder eskaliert werden mussten.

• Unterschiedliche agile Reifegrade machten deutlich, dass Teams und Führungskräfte unterschiedliche Formen der Begleitung benötigten.

• Unklare Schnittstellen führten dazu, dass neue Arbeitsweisen teilweise durch alte Muster überlagert wurden.

Der entscheidende Punkt war: Die Transformation musste nicht nur geplant, sondern zuerst organisatorisch geklärt werden.

Ohne ein gemeinsames Verständnis von Rollen, Verantwortlichkeiten und Entscheidungswegen wäre jede agile Skalierung instabil geblieben.

Key Insight

Rollenunklarheit ist einer der größten versteckten Bremsfaktoren in agilen Transformationen. Wenn Product, Delivery, Projekt und Marktverantwortung nicht sauber zusammenspielen, entstehen Wartezeiten, Doppelarbeit und Entscheidungsstaus, selbst dann, wenn Teams formal agil arbeiten.

Vorgehen: Transformation als iteratives Lernsystem

Statt die gesamte Organisation auf einmal zu verändern, wurde die Transformation bewusst iterativ aufgebaut.

Der Ansatz folgte einem einfachen Prinzip:

Dort starten, wo Wirkung sichtbar werden kann — und parallel ein skalierbares Fundament für die Zukunft schaffen.

Die Umsetzung bestand aus sechs miteinander verbundenen Bausteinen:

1. Systemische Analyse der bestehenden Arbeitsweise

2. Initiale Rollendefinition zur Klärung des Ist-Stands

3. Gezielte Pilotierung statt flächendeckender Einführung

4. Coaching im Arbeitsfluss

5. Target Operating Model als strukturelles Fundament

6. Agile Employee Journey für Orientierung und Beteiligung

1. Systemische Analyse der bestehenden Arbeitsweise

Zu Beginn wurde die reale Arbeitsweise systematisch analysiert. Der Fokus lag nicht darauf, einzelne Teams oder Personen zu bewerten. Ziel war es, die strukturellen Ursachen für Verzögerung, Reibung und fehlende Wirksamkeit sichtbar zu machen.

Untersucht wurden unter anderem:

• Entscheidungswege und Governance-Routinen

• Übergaben zwischen Bereichen

• Wartezeiten im Arbeitsfluss

• Rollen- und Verantwortungsunklarheiten

• Priorisierungsmechanismen

• Schnittstellen zwischen Business, IT und Produktverantwortung

• Abhängigkeiten zwischen Teams, Linienorganisation und Projekten

Die Ergebnisse wurden faktenbasiert und lösungsorientiert aufbereitet. Dadurch entstand ein gemeinsames Verständnis dafür, wo die größten Hebel für Veränderung lagen.

Der Fokus lag nicht auf Agilität als Selbstzweck. Der Fokus lag auf besserer Umsetzung.

Key Insight

Eine gute Transformation beginnt nicht mit der Frage:
„Welches Framework nutzen wir?“

Sie beginnt mit der Frage:
„Welche Strukturen verhindern heute wirksame Umsetzung?“

2. Initiale Rollendefinition zur Klärung des Ist-Stands

Auf Basis der systemischen Analyse wurde eine initiale Rollendefinition durchgeführt. Ziel war es, die bestehende Rollenlandschaft transparent zu machen und ein gemeinsames Verständnis über Verantwortlichkeiten, Entscheidungsrechte und Schnittstellen zu schaffen.

In der Organisation existierte eine Vielzahl produkt-, markt-, delivery- und projektbezogener Rollen. Dazu gehörten unter anderem:

• Product Manager

• Product Owner

• Market Manager

• Delivery Manager

• IT Project Manager

• weitere fachliche und technische Schnittstellenrollen

Diese Rollen waren nicht per se falsch. Die Herausforderung lag darin, dass sie im Alltag unterschiedlich verstanden und teilweise überlappend gelebt wurden.

Dadurch war nicht immer klar, wer für Priorisierung, fachliche Entscheidungen, Umsetzung, Stakeholder-Abstimmung oder Lieferverantwortung zuständig war.

Die initiale Rollendefinition half dabei, den tatsächlichen Ist-Stand sichtbar zu machen und eine belastbare Grundlage für die weitere Transformation zu schaffen.

Im Fokus standen vier Leitfragen:

1. Welche Rollen existieren heute?
   Ziel war es, Transparenz über die aktuelle Rollenlandschaft zu schaffen.

2. Welche Verantwortung wird tatsächlich gelebt?
   Dabei wurde der Unterschied zwischen formaler und realer Rolle sichtbar gemacht.

3. Wo überschneiden sich Verantwortlichkeiten?
   So konnten Reibung, Doppelarbeit und Entscheidungsstaus identifiziert werden.

4. Welche Rollenlogik braucht die Zielorganisation?
   Diese Frage schuf die Grundlage für Pilotierung und Operating Model.

Diese Klärung war ein wichtiger Zwischenschritt zwischen Analyse und Pilotierung. Sie verhinderte, dass agile Begriffe einfach auf bestehende Strukturen gelegt wurden, ohne die dahinterliegenden Verantwortlichkeiten zu klären.

Gleichzeitig wurde sichtbar, welche Rollenkonflikte kurzfristig durch Coaching bearbeitet werden konnten und welche strukturell im Target Operating Model gelöst werden mussten.

3. Gezielte Pilotierung statt flächendeckender Einführung

Da eine großflächige Transformation zu diesem Zeitpunkt nicht realistisch war, wurde der Fokus auf ausgewählte Pilotbereiche gelegt. Diese Piloten dienten als geschützte Lernräume, in denen neue Arbeitsweisen unter realen Bedingungen erprobt werden konnten.

In den Pilotbereichen wurden konkrete Verbesserungen im Arbeitsalltag aufgebaut:

• klarere Rollen und Verantwortlichkeiten

• strukturierte Backlogs

• transparente Visualisierung von Arbeit

• regelmäßige Planungs- und Priorisierungsroutinen

• Reviews zur gemeinsamen Bewertung von Fortschritt

• Retrospektiven zur kontinuierlichen Verbesserung

• stärkere End-to-End-Verantwortung für Ergebnisse

Die Piloten hatten eine doppelte Funktion: Sie verbesserten die Zusammenarbeit in den jeweiligen Bereichen und lieferten gleichzeitig praktische Erkenntnisse für die spätere Skalierung.

So entstand Veränderung nicht durch abstrakte Kommunikation, sondern durch konkrete Erfahrung.

Key Insight

In komplexen Organisationen entsteht Vertrauen nicht durch Konzepte. Vertrauen entsteht durch erlebbare Beispiele, die zeigen: Es funktioniert auch unter unseren Bedingungen.

4. Coaching im Arbeitsfluss

Trainings und Grundlagenformate waren wichtig, aber nicht ausreichend. Die eigentliche Veränderung entstand dort, wo neue Arbeitsweisen auf reale Prioritäten, Abhängigkeiten, Meetings, Konflikte und Entscheidungslogiken trafen.

Deshalb wurden Teams, Product Owner, Scrum Master, Führungskräfte und weitere Schlüsselrollen direkt im Arbeitsfluss begleitet.

Im Fokus standen unter anderem:

• Rollenklärung, um Verantwortlichkeiten verständlich und wirksam zu schneiden

• Backlog-Arbeit, um Arbeit strukturieren, priorisieren und steuerbar machen zu können

• Reviews, um Fortschritt sichtbar zu machen und Feedback zu ermöglichen

• Retrospektiven, um kontinuierliche Verbesserung im Alltag zu verankern

• Abhängigkeitsmanagement, um Schnittstellen zwischen Bereichen aktiv zu gestalten

• Führung, um neue Entscheidungs- und Steuerungslogiken zu ermöglichen

So wurde Agilität nicht als abstraktes Konzept vermittelt, sondern Schritt für Schritt in tragfähige Routinen übersetzt.

Teams lernten nicht nur, agile Meetings durchzuführen. Sie lernten, ihre Arbeit anders zu steuern, Abhängigkeiten aktiver sichtbar zu machen und Entscheidungen bewusster vorzubereiten.

Key Insight

Seminare schaffen Verständnis. Coaching im Arbeitsfluss schafft Verhaltensänderung. Für echte Transformation braucht es beides.

5. Target Operating Model als strukturelles Fundament

Parallel zur Pilotierung wurde ein Target Operating Model für die zukünftige Arbeitsweise entwickelt. Dieses Zielbild beschrieb, wie agile Zusammenarbeit im Konzernkontext dauerhaft funktionieren kann.

Das Operating Model umfasste unter anderem:

• Rollen und Verantwortlichkeiten

• Entscheidungs- und Governance-Logiken

• Zusammenarbeit zwischen Business, IT und Produkt

• Portfolio- und Priorisierungsmechanismen

• Skalierungsprinzipien für agile Teams

• Feedback- und Steuerungsroutinen

• Leitplanken für kontinuierliche Verbesserung

Der Vorteil dieses parallelen Vorgehens: Die Organisation musste nicht sofort vollständig umgebaut werden. Gleichzeitig entstand ein belastbares Fundament für spätere Skalierungsschritte.

Die Piloten lieferten praktische Lernerfahrung. Das Operating Model übersetzte diese Lernerfahrung in eine skalierbare Zielarchitektur.

Key Insight

Team-Coaching ohne Operating Model bleibt lokal begrenzt.
Ein Operating Model ohne praktische Verankerung bleibt Theorie.
Wirkung entsteht, wenn beides verbunden wird.

6. Agile Employee Journey für Orientierung und Beteiligung

Neben der Arbeit an Piloten und Operating Model wurde eine Agile Employee Journey entwickelt und moderiert. Ziel war es, Agilität für Mitarbeitende verständlich, konkret und anschlussfähig zu machen.

Transformation erzeugt Unsicherheit, besonders wenn neue Rollen, Verantwortlichkeiten und Entscheidungswege entstehen. Deshalb war es wichtig, nicht nur Strukturen zu verändern, sondern auch Orientierung zu geben.

Die Agile Employee Journey half dabei,

• ein gemeinsames Verständnis von Agilität zu schaffen

• Unsicherheiten und Vorbehalte abzubauen

• Rollen und Erwartungen zu klären

• konkrete Beispiele aus dem Arbeitsalltag sichtbar zu machen

• Mitarbeitende aktiv einzubinden

• interne Multiplikator für den Wandel zu stärken

Damit wurde die Transformation nicht nur über Prozesse und Strukturen, sondern auch über Kommunikation, Beteiligung und gemeinsame Lernerfahrung verankert.

[Visual einfügen: Agile Employee Journey]

Ergebnisse: Wirkung durch sichtbare Veränderung

Der iterative Ansatz ermöglichte Veränderung trotz komplexer Rahmenbedingungen. Statt die Transformation über ein großes Rollout-Versprechen zu legitimieren, wurde Vertrauen durch konkrete Wirkung aufgebaut.

Die Pilotbereiche zeigten, dass agile Zusammenarbeit auch in einem gewachsenen Konzernumfeld funktionieren kann, wenn sie kontextgerecht eingeführt und eng begleitet wird.

Teams gewannen mehr Transparenz über ihre Arbeit. Prioritäten wurden klarer. Abstimmungen wurden strukturierter. Rollen und Verantwortlichkeiten wurden greifbarer. Blockaden im Arbeitsfluss wurden sichtbar und bearbeitbar.

Gleichzeitig entstand mit dem Target Operating Model eine strukturelle Grundlage für weitere Entwicklungsschritte.

Wirkung auf einen Blick

Rollenklarheit
Verantwortlichkeiten, Schnittstellen und Entscheidungslogiken wurden transparenter.

Transparenz
Arbeit, Prioritäten und Abhängigkeiten wurden sichtbarer.

Zusammenarbeit
Die Abstimmung zwischen Product-, Delivery-, Projekt- und Business-Rollen wurde strukturierter.

Entscheidungsfähigkeit
Verantwortlichkeiten und Entscheidungswege wurden klarer.

Lernfähigkeit
Retrospektiven und Feedbackzyklen wurden im Alltag verankert.

Skalierbarkeit
Ein Target Operating Model schuf die Grundlage für weitere Entwicklung.

Veränderungsbereitschaft
Vertrauen entstand durch praktische Erfahrung statt durch reine Kommunikation.

Ergebnisformulierung

In ausgewählten Pilotbereichen konnten zentrale Blockaden im Arbeitsfluss sichtbar gemacht, Rollen und Verantwortlichkeiten geklärt, Priorisierungs- und Entscheidungsroutinen verbessert und agile Arbeitsweisen nachhaltig im Alltag verankert werden.

Gleichzeitig entstand ein skalierbares Operating Model als Grundlage für weitere Transformationsschritte.

Key Insight

Der wichtigste Fortschritt war nicht nur, dass einzelne Teams agiler arbeiteten. Entscheidend war, dass die Organisation begann, ihre eigenen Engpässe besser zu erkennen und gezielter zu bearbeiten.

Zentrale Learnings

1. Transformation braucht Anschlussfähigkeit

Eine globale Vorgabe kann Richtung geben. Wirksam wird sie aber erst, wenn sie in lokale Strukturen, Entscheidungswege und Arbeitsrealitäten übersetzt wird.

2. Agilität lässt sich nicht ausrollen wie ein Tool

Agile Arbeitsweisen entstehen nicht durch Frameworks allein. Sie entstehen durch Rollenklärung, bessere Entscheidungsroutinen, transparente Arbeit und kontinuierliche Verbesserung.

3. Rollenklarheit ist Voraussetzung für Skalierung

Agile Skalierung funktioniert nicht, wenn bestehende Rollen nur umbenannt oder mit neuen Framework-Begriffen überlagert werden. Zuerst braucht es Klarheit darüber, welche Verantwortung heute tatsächlich gelebt wird, wo Überschneidungen bestehen und welche Entscheidungslogik die Zielorganisation benötigt.

4. Pilotierung schafft Vertrauen

Gerade in komplexen Organisationen entsteht Veränderungsbereitschaft nicht durch Überzeugung allein, sondern durch konkrete Erfahrung. Gut begleitete Piloten machen Wirkung erlebbar.

5. Operating Model und Coaching gehören zusammen

Team-Coaching ohne strukturelles Zielbild bleibt lokal begrenzt. Ein Operating Model ohne praktische Verankerung bleibt Theorie. Nachhaltige Wirkung entsteht, wenn beides verbunden wird.

6. Gute Transformation ist selbst iterativ

Ein starrer Masterplan hätte in diesem Umfeld zusätzliche Reibung erzeugt. Erfolgreicher war ein Vorgehen, das selbst agil war: beobachten, lernen, anpassen und gezielt skalieren.

Fazit

Diese Case Study zeigt, dass agile Transformation in einem Konzernumfeld kein linearer Rollout ist. Sie ist ein iterativer Veränderungsprozess, der Strategie, Struktur, Führung und operative Zusammenarbeit miteinander verbindet.

Der entscheidende Hebel lag darin, die Transformation nicht gegen die Organisation durchzusetzen, sondern sie an die Realität der Organisation anzuschließen: mit systemischer Analyse, initialer Rollendefinition, gezielter Pilotierung, Coaching im Arbeitsfluss, einer klaren Agile Employee Journey und einem skalierbaren Target Operating Model.