12. November 2019

Agile Transformation – Kulturveränderung oder „normaler“ Einführungsprozess?

SMART DEVELOPMENT NEWS 04/2019

SDN 04/2019 - Agile Transformation – Kulturveränderung oder „normaler“ Einführungsprozess?
Avatar: Dirk Meißner
von Dirk Meißner, Geschäftsführender Gesellschafter

Die meisten Industrieunternehmen erproben agile Arbeitsweisen in mehreren Pilotprojekten. Sie wollen dadurch erste Erfahrungen sammeln, prüfen, ob agile Arbeitsweisen tatsächlich auch für die Entwicklung physischer Produkte geeignet sind, und die Vor- sowie eventuelle Nachteile kennenlernen. Verlaufen diese Pilotprojekte erfolgreich, entscheidet das Management sich für ein weiteres Ausrollen – den eigentlichen Beginn einer agilen Transformation des Unternehmens. Wie aber geht man eine solche Transformation an? Wie sehen Lösungsansätze für eine agile Organisation aus? Welche Herausforderungen kommen auf uns zu?

Schauen wir zunächst einmal, wo Unternehmen auf dem Weg der agilen Transformation heute stehen. Der Software-Anbieter CollabNet VersionOne führt jährlich die umfangreichste weltweite Befragung zum Status der agilen Transformation in Unternehmen durch. Im 13. „State of Agile“-Report werteten die US-Amerikaner die Antworten von 1.319 Unternehmen aus.

Erfahrung mit der Anwendung agiler Arbeitsweisen
Abbildung: Erfahrung mit der Anwendung agiler Arbeitsweisen

Erst 27 Prozent der Unternehmen haben mehr als fünf Jahre Erfahrung mit der agilen Transformation

Insgesamt haben nur 6 Prozent der befragten Unternehmen noch nicht mit der agilen Transformation begonnen. 10 Prozent starteten damit vor einem Jahr, 23 Prozent haben bereits ein bis zwei Jahre Erfahrung, 34 Prozent immerhin schon bis zu fünf Jahre Erfahrung und 27 Prozent mehr als fünf Jahre Erfahrung. Andere, weniger umfangreiche Studien (selbst bei einem Fokus auf Industrieunternehmen) kommen zu sehr ähnlichen Ergebnissen.

Nach dieser Zeit des Erfahrungsgewinns geben erst 12 Prozent der Unternehmen an, bereits eine hohe agile Kompetenz über die gesamte Organisation erreicht zu haben. 6 Prozent spüren eine größere Anpassungsfähigkeit an die Marktbedingungen. Die Transformation dauert also voraussichtlich, so auch unsere Erfahrung, drei bis fünf Jahre, bis die Potenziale agiler Arbeitsweisen organisationsweit und nicht nur in einzelnen Projekten gehoben werden.

Der Reifegrad der Anwendung agiler Arbeitsweisen in den Unternehmen
Abbildung: Der Reifegrad der Anwendung agiler Arbeitsweisen in den Unternehmen

Eine agile Transformation wird auch agil durchgeführt

Da es sich bei einer agilen Transformation um eine höchst-komplexe Veränderungsinitiative mit unbekanntem Ausgang handelt, spielt die empirische Prozesskontrolle mit ihrem Regelkreis aus Create-Inspect-Adapt alle Vorteile aus.

Zu Beginn der Transformation werden relevante Stakeholder einen „Transformation Owner“ finden und gemeinsam mit ihm oder ihr eine „Transformation Vision“ erarbeiten. Es folgen die Festlegung eines „Transformation Team“ mit einem Agile Coach sowie die gemeinsame Ausarbeitung eines initialen „Transformation Backlog“. Definierte Zwischenziele werden in Sprints erreicht und von den Stakeholdern in Reviews kommentiert. Der Transformation Backlog bleibt dynamisch und reagiertauf Stakeholder-Feedback und sich ändernde Bedingungen.

Eine agile Transformation wird auch agil durchgeführt
Abbildung: Eine agile Transformation wird auch agil durchgeführt

Für die Transformation Vision bietet sich das V2MOM Format an:

Vision: Was wollen wir erreichen?
Values: Welche Werte sind uns dabei wichtig?
Methods: Wie werden wir zusammenarbeiten?
Obstacles: Was könnte dabei im Weg stehen?
Measures: Wie ermitteln wir, ob wir das Gewünschte erreicht haben?

Aus dem V2MOM und den Erfahrungen aus den vorangegangenen Pilotprojekten leitet sich der Transformation Backlog ab. Er wird ähnlich einem Product Backlog erstellt. Nur adressieren die EPICs andere „Kundenanforderungen“ und berücksichtigen drei Ebenen:

1. Unternehmenskultur und Werte.
2. Strukturen, Regeln, Metriken.
3. Framework, Praktiken, Methoden.

Eine agile Transformation beginnt bei der Unternehmenskultur

Bei mehr als 50 Prozent der Unternehmen steht laut CollabNet-Studie die eigene Unternehmenskultur im Widerspruch zu den agilen Werten und Prinzipien. Die Transformation muss deshalb „inside-out“ beginnen.

Die Ebenen der agilen Transformation
Abbildung: Die Ebenen der agilen Transformation

Das Transformation Team kümmert sich zuallererst darum, bestehende Differenzen zwischen der aktuellen Unternehmenskultur und -werte in Bezug auf die agilen Werte und Prinzipien zu identifizieren. Hier kommen auch die Werte und Menschenbilder der Führungskräfte auf den Prüfstand. Der „Expert-Leader“, der seine Fachkompetenz immer über die seiner Mitarbeiter stellt, ihnen daher nichts zutraut, mikro-managed und kontrolliert, wird keine selbstorganisierten Teams fördern. Genauso wenig wird er Mitarbeiter wachsen lassen und sich aus dem „wie“ heraushalten.

Für eine systematische Kulturanalyse eignet sich z. B. das Competing Values Framework von Kim Cameron und Robert Quinn. Es unterscheidet vier verschiedene Kulturtypen:

  • Collaborate
  • Create
  • Compete
  • Control

Durch eine Befragung der Führungskräfte und Mitarbeiter, z. B. differenziert nach Standorten, Hierachieebenen, Funktionen, Rollen etc., können Ist- und Soll-Profile erarbeitet und konkrete Maßnahmen abgeleitet werden.

Das Competing Values Framework von Cameron und Quinn
Abbildung: Das Competing Values Framework von Cameron und Quinn

Diese Differenzen zu überbrücken und eine hohe Übereinstimmung der eigenen Unternehmenskultur mit den agilen Werten und Prinzipien zu erreichen, ist der kritische Erfolgsfaktor der Transformation.

Der Inside-out-Ansatz wird begleitet von einem parallelen Outside-in-Vorgehen

Basierend auf den Erfahrungen aus den Pilotprojekten arbeitet das Transformation Team parallel zur Kulturarbeit an einem unternehmensspezifischen agilen Framework und der Anpassung bestehender Prozesse an die agile Arbeitsweise. Vielleicht schafft man es im ersten Ansatz noch nicht, die Rolle des Product Owners mit nur einem Mitarbeiter zu besetzen, der Markt und Produkt gleichermaßen gut kennt. Dann wird man Product-Owner-Duos oder -Teams zulassen. Oder es gelingt aufgrund einer hohen Arbeitsteilung und damit verbundener hoher Spezialisierungsgrade nicht, kleine agile Teams zu bilden, die das jeweilige Ergebnis alleine erzeugen können. Dann wird man Scrum-Teams definieren, die von einem erweiterten Expertenteam punktuell unterstützt werden.

Hier gilt es den eigenen Weg für erfolgreiche agile Arbeitsweisen zu finden, die nicht dogmatisch an den theoretischen Frameworks festhalten – gleichzeitig aber nicht unverzichtbare Elemente aufgeben und im Ergebnis ein einheitliches Verständnis sowie eine gemeinsame Sprache in der Organisation herstellen. Auch die zugrundeliegenden Produktentstehungsprozesse müssen modifiziert werden.

Bei Strukturen, Leitlinien und Metriken kommt es zum Schwur

Das parallele Inside-out und Outside-in trifft sich früher oder später auf der mittleren und entscheidenden Ebene. Nur wenn das Unternehmen auch aufbauorganisatorische Strukturen, Leitlinien und Metriken so anpasst, dass sie agile Werte, Prinzipien und Arbeitsweisen unterstützen, wird die Transformation erfolgreich und unumkehrbar sein.

Was kommt bei der Aufbauorganisation auf uns zu?

Die Grundbausteine der Organisation sind agile Teams und Communities of Practice. Diese bilden eine Matrix. Eine Person wird also in der Regel einem agilen Team und mindestens einer Community of Practice angehören. Die Herausforderung wird darin bestehen, die agilen Teams dauerhaft stabil, das heißt personell möglicht unverändert, zu implementieren. Skalierte, agile Organisationsformen werden aufgrund der Größe und Komplexität der meisten Vorhaben Einzug halten. Auch auf der Portfoliomanagement-Ebene werden sich agile Arbeitsweisen und Praktiken etablieren. SAFe hat heute in der Softwareentwicklung bereits einen großen Vorsprung und wird sich wohl auch für die skalierte Entwicklung mechatronischer Produkte durchsetzen.

Bei der Gestaltung der Aufbauorganisation gehen wir von der Prämisse aus, Führung künftig nach vier Dimensionen aufzuteilen:

  • Produktverantwortung
  • Technologieverantwortung
  • Personalverantwortung
  • Leistungsverantwortung

Die Produktverantwortung – und damit auch die geschäftliche Verantwortung – übernehmen Portfolio Manager, Chief Product Owner und Product Owner. Die Technologieverantwortung nehmen Experten wahr. Sie bringen sich maßgeblich in die Communities of Practice ein. Die Personalverantwortung liegt bei „People Managern“. Sie sind nicht mehr für die Arbeitsorganisation und Kontrolle der dann selbstorganisierten Mitglieder agiler Teams verantwortlich. Stattdessen investieren sie deutlich mehr Zeit in die Weiterentwicklung der Menschen und Rahmenbedingungen. Als Konsequenz wird ihre Führungsspanne im Vergleich zu heutigen Disziplinarvorgesetzten deutlich steigen. Agile Coaches, Scrum und Kanban-Master tragen die Leistungsverantwortung, d. h. die Aufgabe die Leistungsfähigkeit der Organisation und der agilen Teams zu steigern.

Auf jeden Fall werden sich Führungsspannen im unteren und mittleren Management drastisch verändern. Ein Teil der heutigen Teamleiter wird seine disziplinarische Führungsrolle abgeben und in der Rolle eines Product Owners, Agile Coaches oder Senior Expert aufgehen. Andere Führungskräfte werden deutlich größere Führungsspannen übernehmen.

Wie verändern sich Leitlinien?

Einfachere, prinzipienorientierte Richtlinien werden umfangreiche, detaillierte und unflexible Regelwerke ersetzen. Lokale Autonomie wird wichtiger als globale Vorschriften. Eine positive Fehlerkultur ersetzt heutige Absicherungsstrategien. Vertrauen wird wichtiger als Kontrolle, Teamerfolge bedeutender als Einzelergebnisse. Eine gute Zusammenarbeit mit externen Partnern ist wichtiger als die kurzfristige Gewinnoptimierung. Eine schnelle, fokussierte Reaktion auf Kundenbedarfe geht vor Overengineering.

Und Metriken?

Metriken spielen eine wichtige Rolle für das Verhalten der Führungskräfte und Mitarbeiter. Divergierende Ziele können ein wesentliches Hindernis für kollaborative Teamarbeit darstellen. Metriken müssen Werte und Leitlinien unterstützen. Wir brauchen also Metriken für das „Outcome“, die sich stärker auf das langfristige Unternehmensergebnis und nicht auf die Optimierung einzelner Unternehmensbereiche beziehen. Und wir brauchen Metriken, die uns helfen, die Leistungsfähigkeit durch kontinuierliche Verbesserung weiter zu steigern.

Zurück zum Transformation Backlog

Das Transformation Team wird all diese Anforderungen an neue Lösungsbausteine für die Organisation in den Transformation Backlog überführen und wie bei einer Produktentwicklung als User Stories mit konkreten Akzeptanzkriterien beschreiben. So entsteht eine Story Map.

Das Transformation Team startet mit einem initialen Transformations-Backlog
Abbildung: Das Transformation Team startet mit einem initialen Transformations-Backlog

Auch der Transformation Backlog ist dynamisch, wachsend, priorisiert, geschätzt. Eine wichtige Stakeholdergruppe für das Transformation Team sind die Agile Coaches oder Scrum Master der Organisation. Sie erarbeiten in ihren Retrospektiven mit den Teams die Themen, die in der agilen Transformation ausgeräumt werden müssen. All die Themen, die als übergreifende und nicht teamspezifische Hindernisse identifiziert werden, gelangen in den Transformation Backlog.

Wie machen wir es bei CO-Improve?

Um die Vorteile agiler Führung und Arbeitsweisen für uns selbst zu nutzen und Erfahrungen nicht nur in unseren Kundenprojekten, sondern im eigenen Unternehmen zu sammeln, haben auch wir bei CO-Improve uns im Dezember 2017 auf den Weg der agilen Transformation begeben. Unsere eigene Transformation gestalten auch wir nach der beschriebenen Vorgehensweise.

Fazit

Eine agile Transformation ist eine hochkomplexe, das ganze Unternehmen betreffende Veränderungsinitiative. Daher wird auch eine agile Transformation agil durchgeführt. Die größte Herausforderung besteht darin, eventuell bestehende Widersprüche der eigenen Unternehmenskultur zu den agilen Werten und Prinzipien aufzulösen.

Eine agile Transformation setzt daher am besten zuerst mit einer Diagnose der Unternehmenskultur an, um daraus die richtigen kulturverändernden Maßnahmen abzuleiten. Der Transformation Backlog initiiert und priorisiert die Veränderungen von Unternehmenskultur und Werten; Strukturen, Leitlinien und Metriken; Framework, Praktiken und Methoden.