Agile Enterprise Transition

... oder, die Transformation von Unternehmen in Richtung einer agilen Organisation.

Grundsätzlich

Ein Wandlungsprozess in einer Unternehmensorganisation kann durch unterschiedliche Umstände ausgelöst werden.  Zwei Gruppen von Auslösefaktoren, die extern oder die intern motivierten Faktoren, begegnen uns dabei.

Bei den extern motivierten Faktoren sind dies zumeist:

• Marktveränderungen (zB Kunden orientieren sich beispielhaft in Ihrer Kaufentscheidung bei Nahrungsmitteln immer öfter an der Nachvollziehbarkeit der Zulieferkette und lösen daher eine Änderung in Richtung des eigenen Einkaufsmanagements aus), 
• Veränderungen bedingt durch Regeländerungen (zB gesetzliche Rahmenbedingungen im Bereich der Automobilindustrie zwingen die OEMs zu Rückgewinnungsmassnahmen von Rohstoffen und lösen daher ebenso eine Änderung in Richtung des eigenen Einkaufsmanagements aus), 
• Technologieänderungen (zB hat die Firma Blackberry durch den grossen Erfolg des Apple Iphones mit einer massive Änderung ihres  Produktportfolios, gepaart mit einer Organisationsneugestaltung reagieren müssen), oder 
• Kundenvorgaben (zB verordnete das Unternehmen Redbull seinen Logistikpartnern vor wenigen Jahren kurzfristig eine neuer Art des Supply Chain Managements).

Von internen Auslösefaktoren sprechen wir bei:

• Restrukturierungsmassnahmen (zB Trennung oder Zusammenführung von Unternehmensteilen) ausgelöst durch operative bzw. strategische Aspekte (zB Kostendruck, Änderungen bedingt durch Beteiligungen), 
• Optimierungen in der Ablauf- und/oder Aufbauorganisation, oder aber auch durch das 
• Aufgreifen von Modeströmungen (zB externer Berater "verordnet" die Einführung eines CRM- Systems).

Startsituation und Zielsetzung

Als Zielsetzung jedes Änderungsprojektes muss es sein, das Unternehmen produktiver zu machen und die Menschen in den Mittelpunkt zu stellen, damit diese mit Spass und Stolz auf die eigene Arbeit ans Werk gehen. 

Der erste Aspekt steht in den Ergebniszielen und war auch immer Vorgabe in meinen Projekten. Der zweite Aspekt begegnete mir als Vorgabe jedoch selten, gehört aber in agilen Transition Projekten aus meiner Sicht zum "must have"!

Folgende drei unterschiedliche Startsituationen sind mir im Rahmen meiner Umsetzungsprojekte begegnet:

• Top-Down Einführung - das ist der Idealfall, denn dabei war stets von Beginn an der Rückhalt des Managements gesichert. Die Vorteile dabei sind und waren: Ein klarer Auftrag und eindeutiges Mandat, Ressourcenbeschaffung geht einfacher und schneller vonstatten, sowie die aktive Unterstützung in allen Belangen ist "vorprogrammiert".
• Bottom-up Einführung - die am häufigsten begegnete Situationen, dass Scrum von "unten aus" betrieben wird. Zumeist hat ein erfahrener Entwicklungsleiter die Initiative ergriffen, ein Pilotprojekt als Anlassfall gestartet und die Folgeprojekte unter Duldung des Topmanagements weitergeführt. Der Vorteil liegt in der breiten Akzeptanz und Motivation bei den Mitarbeitern. Der Nachteil liegt darin, dass sobald die Projekte über die Grenzen der eigenen Abteilung hinausgehen, Organisationsänderungen nur sehr schwer machbar sind. 
• Virale Einführung - Scrum wird unentdeckt in Abteilungen eingeführt und Dank des "Normativen durch das Faktische", schleichend und unerkannt im gesamten Unternehmen verbreitet. Da eine Entdeckung jedoch langfristig sicher, zumeist mit grossem Ärger verbunden ist und die Überlebenschancen einer solchen Einführung gering sind, sollten Sie von einer derartigen Implementierung Abstand nehmen.

Abb: 1: Orientierung in der Startsituation und Richtungsauswahl in einem Transitionsprojekt

Neben der Orientierung, welche Startsituation, den Wandlungsprozess ausgelöst hat, ist natürlich die Zielsetzung massgeblich. Folgende Ergebnis-Ziele können wir nach Wandlungsprozessen - im Kontext zu Scrum - grundsätzlich erreichen:

• Bedarfsfall-Scrum - Scrum wird jeweils im Bedarfsfall eingesetzt, jedoch ohne eine entsprechende Unterstützung wie zB durch ein Scrum-Office (oder Scrum Software Studio) 
• Oberflächen-Scrum - Scrum wird vom Management verordnet, jedoch ohne tiegreifende Änderungen auslösen zu wollen. Es werden dabei oftmals nur Teilaspekte von Scrum verwendet (zB Daily Scrum) und  die Projekte grossteils noch in der traditionellen Methode abgewickelt.
• Scrum Office - dabei werden in einem eigenen Unternehmensbereich (Scrum Office) Methodenwissen rund um Scrum gebündelt und Metriken aufgebaut die zur ständigen Verbesserung von Scrum im Unternehmen führen.  Alle Projekte im Unternehmen werden im Scrum Office aus gestartet und geschlossen. Bei der Etablierung eines Scrum Office ist es nicht das Ziel eine tiefgreifende Änderung in Richtung einer Agilisierung des gesamten Unternehmens zu erzeugen.
• Full-Scrum - ist ein Wandlungsprozess, an dem am Ende die gesamte Unternehmensorganisation erfasst wird. Scrum wird auf breiter Front im gesamten Unternehmen etabliert und nachhaltig verankert. Scrum durchdringt alle Prozesse des Unternehmens.

Abb. 2: Zielsetzung von Transitionsprojekten 

Organisation des Änderungsprojektes

Egal wie der Weg des Wandlungsprozesses aussieht und ausgesehen hat, ich habe mich inhaltlich stets am "8-Stufen Modell für Organisationsveränderungen nach Kotter" orientiert und als zeitlichen Rahmen, Scrum verwendet. 

Jede dieser Phasen im "Kotter-Modell" müssen linear durchlaufen werden, um ein Änderungsprojekt nachhaltig erfolgreich abschliessen zu können. Das bedeutet, dass Sie zB nicht die achte Phase vor der ersten abschliessen können. Meist sind jedoch mehrere Phasen gleichzeitig aktiv. Das sollte Sie auch nicht irritieren. Als Überblick habe ich das „Kotter-Modell“ nachfolgend kurz skizziert und aufgelistet:

1. „Establishing a sense of urgency“ (Ein Gefühl für die Dringlichkeit erzeugen)

• Untersuchen von aktuellen und zukünftigen Marktchancen.
• Identifizierung potenzieller Krisen um diese auch anzusprechen.
• Daraus resultierende Chancen erkennen und diskutieren.
• Dringlichkeit für alle Beteiligten spürbar machen.
• Sorgen dafür, dass das Führungsteam die Dringlichkeit verspürt und danach handelt. Ansonsten sind alle nachgelagerten Kommunikationsmassnahmen wertlos.
• Klärung der Fragen: Warum soll das Unternehmen agil gestaltet werden oder warum soll Scrum eingeführt werden? Was geschieht, wen nichts passiert?

2. „Creating the guiding Coalition“ (Aufbauen eines Führungsteams)

• Zusammenstellung eines Führungsteams (maximal 9 Personen) mit entsprechender Durchsetzungskraft im Wandlungsprozess (Geschäftsführer oder sonstige Führungskraft mit hierarchischer Macht, Experten für die Kernprozese, Scrum-Veteran, alle Personen die sie im Änderungsprojekt unterstützen können.
• Aufbau einer gemeinsamen Sichtweise der aktuellen Situation (Starten Sie mit der Erstellung des Transition Backlogs).

3. „Development a vision and strategy“ (Entwicklung einer Vision der Veränderung und Entwicklung einer Veränderungsstrategie)

• Schaffung einer richtungsweisenden Vision.
• Verwendungen von jeglichen Visualisierungswerkzeugen (Brownpaper, Flipcharts, Pinwänden) helfen in der Visionsarbeit.
• Entwicklung einer Strategie für die Umsetzung der Vision (spätestens hier sind das sind schon die ersten Epics und Stories im Transition Backlog)
• Die Vision muss maximal in fünf Minuten kommunizierbar sein.

4. „Communicating the change vision“ (Kommunikation der Vison auf breiter Basis)

• Nutzung jeder Möglichkeit und jedes Anlasses um die Vision und die Strategie zu kommunizieren, ständig, bestmöglich täglich kommunizieren.
• Einfachheit in der Kommunikation (keine Fremdwörter verwenden).
• Verwendung von sprachlichen und wirklichen Bildern.
• Vor-BILD-haftes Rollenverhalten, des Führungsteams, dass der Mitarbeitererwartung in dieser neuen Situation entspricht.

5. „Empowering broad-based action“ (Befähigung zur Initierung großräumiger Aktivitäten)

• Veränderung von Strukturen, die die Veränderungsvision beinträchtigen könnte (speziell mögliche Hemmnisse bei den Vorgesetzten abbauen).
• Beseitigung von Hindernissen (Misstrauen abbauen, mangelnde Fähigkeiten mit Schulungen kompensieren, an der Einstellungen und der Motivation der Mitarbeiter arbeiten).
• Förderung von „konfliktfähiger“ Kultur.
• Ermutigung zu ungewöhnlichen Ideen, Aktivitäten und Handlungen.

6. „Generating short-term wins“ (Sicherstellung von kurzfristigen Gewinnen)

• Planen von kleinen sichtbaren Erfolgen (zB ein kleines bis mittleres Scrum Pilotprojekt).
• Sichtbarmachung und Kommunikation dieser „quick wins“ (nach spätestens 6 Monaten sollten Sie einen Erfolg vorweisen können)
• Anerkennung und Auszeichung der involvieren Führungskräfte und Mitarbeiter.

7. „Consolidating gains and producing more change“ (Sicherung der erreichten Ziele und Schaffung weiterer Veränderung) 

• Die wachsende Akzeptanz für weitere Veränderungsprojekte nutzen.
• Förderung von Mitarbeitern, die eine Veränderung vorantreiben.
• Die Verantwortung und das Engagement der Veränderung verlagert sich immer mehr von den Führungskräften zu den Mitarbeitern.

8. „Anchoring new aproaches in the culture“ (Verankerung der erreichten Veränderung)

• Dauerhafte Fixierung der Veränderungen in der Organisation (Kultur, Normen, Werte), die am Ende des Wandlungsprozesses erreicht wurden.

Der Wandlungsprozess, als Scrum Projekt gestartet, verwendet in diesen Fällen als Product Backlog ein sogenanntes „Transition Backlog“. Jeder Sprint liefert dabei etwas "Fertiges" aus. Zumeist sind aus dem Tranistion Projekt heraus neue Teilprojekte (zb ein Scrum Pilotprojekt, oder ein Schulungsprojekt) gestartet worden. Ein Beispiel für ein Tranistion Backlog Items ist: "Die Arbeitsfähigkeit für Scrum Projekte ist im gesamten Unternehmen vorhanden". 

Als Product Owner habe ich zumeist jene Personen rekrutieren können, die das grösste Interesse an der Einführung von Scrum sowie die grösste Motivation dazu hatten. 

Als Scrummaster wurde ein erfahrener Scrummaster des eigenen Unternehmens ausgesucht. Öfters war dies auch ein zukünftiger Scrummaster, der von mir in seiner Rolle in den ersten Sprints begleitet wurde. Das Team bestehend aus 3-9 intern anerkannten und gut vernetzten Personen  wurde aus allen wichtigen Personengruppen des Unternehmens rekrutiert (siehe dazu Stufe 1 bis 2 nach Kotter). 

Abb. 3: Transiation Projekt als Scrum Projekt organisiert

Fallbeispiel

Nachfolgend sind die Lernpunkte eines Änderungsprojektes am Beispiel eines   Dienstleistungsanbieter im Bereich Telekommunikation kurz und knapp beschrieben.

Die Ausgangssituation

Ausgelöst wurde der Change - intern motiviert - durch das Bedürfnis, die Vielzahl der überwiegend erfolgreich abgeschlossenen Scrum-Projekte als Beispiel für die Gestaltung einer neue Projektorganisation im gesamten Unternehmen zu nehmen und Scrum als unternehmensweite Methode zu etablieren. Andererseits sollte der Change dazu dienen, das gesamte Unternehmen flexibler und agiler zu organisieren. 

Scrum wurde als Projektmanagement Methode im Jahre 2008 gestartet, und schrittweise durch die unterschiedlichen Software Abteilungen ins Unternehmen eingebracht. Die Ausgangssituation war 2012 daher ein Bottom-up Ansatz, kombiniert mit einer empfohlenen Top-Down Einführungsstrategie, vom Führungskreis des Unternehmens vorgegeben. 

Als Zielsetzung dieses Wandlungsprojektes war eine Full-Scrum Einführung in die gesamte Organisation geplant. Das Zwischenziel war die Etablierung eines Scrum-Office im Bereich der Service- und Software Entwicklung und des Produktmanagements. Das Zwischenziel wurde nach ca. 9 Monaten Projektdauer erfolgreich erreicht und gefeiert. 

Momentan wird an der schrittweisen Etablierung von Scrum in allen Unternehmensbereichen und der Durchdringung in alle Kernprozesse des Telekommunikationsanbieters gearbeitet. Am Ende des Projektes sollte jeder Unternehmensbereich, im strategischen sowie im operativen Bereich der Unternehmensführung, Scrum und weitere agile Werkzeuge  verwenden, Metriken für sich entwickeln und sich daran selbstständig weiter verbessern können. Das Scrum Office als zentrale Institution wird in dieser Situation dann nicht mehr notwendig sein und wird mit einer hohen Wahrscheinlichkeit wieder aufgelöst werden.

Die Lernpunkte

Als Lernpunkte aus dem Fallbeispiel sind die Do´s und die Dont´s in Bezug auf Gesamtorganisation sowie betroffene Abteilungen aufgelistet und sollen damit die Erfolgs- bzw. Misserfolgsfaktoren der abgeschlossenen Projektphase kurz veranschaulichen.

1) Gesamte Organisation

Do´s

• Klares Ziel: Warum mache ich/wir das?
• Langer Atem (Derartige Projekte sind eher Programme und dauern oftmals länger als 12 Monate)
• Rahmen schaffen (inhaltlich, zeitlich, organisatorisch, kostenmässig) kleine Schritte gehen, Selbstorganisation einführen und fördern
• Transparenz zur Verbesserung nutzen
• Es wurden gesamte Abteilung(en) umgestellt
• Die gesamte Organisation (im Moment nur der Teilbereich Produktentwicklung und Produktmanagement) wurde mit Scrum „agilisiert“
• Das Management-Commitment ist von Beginn bis zum Ende des Prozesses vorhanden gewesen
• Geduld in allen Phasen des Prozesses
• die Bilder der Änderungsvision „von oben“ vorleben
• Lernen wichtiger als Abstrafen
• Play-2-win
• Kulturwandel oftmals (aber nicht immer) nötig
• Selbstorganisation braucht Feedback in beide Richtungen
• Evolutionär (always run a changing system)
• Selbstorganisation des Teams fördern und dies auch beachten
• klaren Rahmen erarbeiten (einfache Regeln, inkl. eigenes Budget für zB Incentives)
• Kommunikation fördern (zB Kaffee Ecken ausbauen, Spielecken mit zB Tischfussball aufbauen)
• Unschärfen und Differenzen fördern

Dont´s 

• Das Management kommt nur zum „kritisieren“ in/nach schwierigen Situationen
• Technische Defizite sind hoch (aber keiner will es frühzeitig einsehen)
• Transparenz schafft Angst
• Schaffung von agilen Inseln
• Desinteresse des Managements kann für das Projekt „tödlich“ sein
• Assoziationen: Agilität bedeutet nur „Teamkram“; mit Agilität löst man alle Probleme schlagartig
• Klassisches Change Management (Ziele, Stufen, Deadlines). Die Gefahr dabei ist, das die 2. und 3. Führungsebene sich auf das Management der KPI´s (Key Performance Indikatoren) zurückzieht
• Lineares Denken
• Ressourcen managen wollen
• Bedeutung, Macht, Kontrolle (Auswirkung: Beschneidung der Änderungskommunikation)
• Einführung von Oberflächen-Scrum („Wasch mir den Pelz, aber mach mich nicht nass“)

2) Produktmanagement

Do´s

• Gutes Produktmanagement aufbauen und stärken
• Klare Produktvision bei jedem Produkt erzeugen
• Entscheidungen/Prioritäten in der Produktentwicklung werden nach dem jeweiligen Wert für den Kunden UND der Firma getroffen
• Realistische Ziele

Dont´s 

• Verwalter von Produkten und Produktideen anstatt Product Owner
• Ein Druck von allen Seiten (innen und aussen) auf das Produktmanagement
• Druck wird unreflektiert auf Produktentwicklung weitergegeben
• Schwäche in der Organisation zu Prioritäten und Umpriorisierungen
• Agilität ist das „Spielzeug der Software Entwicklung“

3) Produktentwicklung

Do´s

• Wenn überhaupt, Gruppenincentives (Zielsetzung immer eine Ebene höher als persönlich oder alleine erreichbar)
• Kennzahlen abschaffen/ersetzen (Planeinhaltung ist kein sinnvolles Ziel, Wert und Nutzen erzeugen jedoch schon)
• Zufriedenheitsindex erstellen

Dont´s 

• Lineares Kontrolldenken
• Effizienz mit Effektivität verwechseln
• Planeinhaltung um jeden Preis
• Incentives auf metrische Ziele 
• Management und Verwaltung by KPI´s

Für weiterführende Fragen stehe ich Ihnen gerne zur Verfügung und freue mich über Ihre Kommentare zu diesem Artikel.

Weiterführende Literatur

Brandstätter, M./ Gölzner/H., Siems, F. (2006): Diversifizierte Kommunikation auf Basis des Event Life Cycle. Eine interdisziplinäre Betrachtung für die Stakeholder Netzwerkpartner, Mitarbeiter und Kunden. In: Proceedings of VI. Interdisziplinäres Symposium „Europäische Kulturen in der Wirtschaftskommunikation (EUKO 2006)”, Turku, S. 24-25.

Capra, F. (2002): Verborgene Zusammenhänge, Bern.

Doppler, K./Lauterburg, C. (2005): Change Management. Den Unternehmenswandel gestalten, 11. Aufl., Frankfurt a. Main.

Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, München.

Kostka, C./Mönch, A. (2001): Change Management. 7 Methoden für die Gestaltung von Veränderungsprozessen, München.

Kotter, J., P. (1996): Leading Change, Boston.

Laube, T./Schwandner, O. (2006): Technologie-Roadmapping-basierte Vorgehensweise zur Unterstützung des Technologietransfers in kmU. In Gausemeier, J. (Hrsg.): Vorschau und Technologieplanung. 2. Symposium für Vorschau und Technologieplanung Heinz Nixdorf Institut, 9. und 10. Nov. 2006, Schloss Neuhardenberg, Paderborn.

McK Wissen 08 (2008): Von der Amöbe lernen, http://www.brandeins-wissen.de/Downloads/McK/mck08_10.pdf, (Abfrage: 18.03.2008).

Morgan, G. (2002): Bilder der Organisation, 3. Aufl., Stuttgart.

Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.

Peters, T., J./Waterman, R., H. (2003): Auf der Suche nach Spitzenleistungen. Was man von den bestgeführten US-Unternehmen lernen kann, Heidelberg. 

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Preissing, W. (2008): Visual Thinking. Probleme lösen mit der Faktorenfeldmethode, München.

Project Management Institute (2004): A Guide of the Project Management Body of Knowledge, 3. Aufl., Washington.

Pugh, D., S. (1981): The Aston Program of Research. Retrospect and Prospect, in Van de Ven A., H./Joyce, W., F. (Hrsg.), Perspectives on Organization Design and Behavior, New York, S. 135-166.

Reiß, M. (1997): Optimierung des Wandels, in Reiß, M. (Hrsg.): Handbuch für Change Management. Programme, Projekte und Prozesse, Stuttgart, S. 123-144.

Robbins, P. (2001): Organisation der Unternehmung, 9. Aufl., München.

Scholl, W. (2004): Grundkonzepte der Organisation,  in H. Schuler (Hrsg.), Lehrbuch der Organisationspsychologie, 3. Aufl., Bern, S. 515-556.

Stolzenberg, K./Heberle, K. (2006): Change Management. Veränderungsprozesse erfolgreich gestalten - Mitarbeiter mobilisieren, Heidelberg.

Senge, P. (2003): Die fünfte Disziplin, 9. Aufl., Stuttgart.

Takeuchi, H./Nonaka, I. (1986): The New Product Development Game. Stop running the race and start rugby. In: Harvard Business Review. Jan-Feb 1986, Harvard, S. 137-146.

Von Rosenstiel, L./Dierkes, M./Steger, U. (1993): Unternehmenskultur in Theorie und Praxis: Konzepte Aus Ökonomie, Psychologie und Ethnologie, Frankfurt a. Main.

Von Rosenstiel, L. (2003): Grundlagen der Organisationspsychologie, Stuttgart.

Weick, K. (1995): Der Prozess des Organisierens, Frankfurt a. Main.