It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.
Franklin D. Roosevelt
Was macht eine erfolgreiche Unternehmenstransformation aus? Diese etwas unsinnige Frage bekomme ich oft gestellt und eine klassische Antwort darauf würde wie folgt lauten: Auf der einen Seite braucht es eine klare Vision, was mit der Veränderung erreicht werden soll, ein „Warum?“, dass von allen verstanden wird, Management Commitment und messbare Ziele. Auf der anderen Seite einen Umsetzungsteil der Strategie, der Plan, wie diese Ziele erreicht werden sollen und natürlich das „make it happen“. Eine Antwort, die ich manchmal gebe, um zu sehen, wie die Gegenseite reagiert. Aus verschiedenen Gründen ist diese Antwort heutzutage vermutlich unzureichend:
- Der Plan, wie wir die Ziele erreicht werden sollen, sind in Wahrheit Hypothesen, die auf Annahmen beruhen
- Niemand kann im Voraus sagen, ob dieser Plan im konkreten Umfeld auch tatsächlich den gewünschten Effekt erzielt. Stattdessen sollten Hypothesen frühzeitig validiert werden, z.B. in Form von Piloten, um festzustellen, was funktioniert und was nicht um so den weiteren Weg ggf. anpassen können. „Best Practices“ funktionieren nur bei einfachen, aber nicht bei komplexen Fragestellungen.
- Transformation ist kein einmaliger Akt, kein Projekt, sondern eine Fähigkeit des Unternehmens, sich laufend an neue Zielsetzungen und Herausforderungen anzupassen. Dies erfordert eine Kultur der kontinuierlichen Verbesserung, die von innen kommen muss.
- „Fail Fast“ und kleine Schritte sind in diesem Kontext essentiell: Je später eine Erkenntnis kommt, das etwas nicht funktioniert und je später diese korrigierend einfliesst, desto kostspieliger.
- Die Veränderung wird nicht von den Mitarbeitern akzeptiert und dies führt zum berühmten „Culture eats Strategy for Breakfast“. Ich beobachte oft, dass Mitarbeiter eigentlich begeisterungsfähig sind für neue Ideen, sobald sie aber von aussen gedrungen fühlen, zeigt sich der Widerstand. Was aber, wenn die neuen Ideen von den Mitarbeitern selbst kommen?
Eine Kultur des kontinuierlichen Lernens und Experimentierens zu schaffen, ist der Schlüssel, diese Herausforderungen zu meistern.
Wie baue ich im Unternehmen die nötige Kultur und die nötigen Fähigkeiten auf?
Die „Unicorns“ wie Amazon, Netflix und Co machen es uns vor: Diese Unternehmen können sehr schnell auf Veränderungen reagieren und neue Produkte auf den Markt bringen. Diese sind dann meist zunächst ein Experiment, ein „Minimal Viable Produkt“ das laufend validiert und verbessert wird. Und manchmal auf verworfen. Der Punkt ist, dass diese Herangehensweise auch für die Veränderungen in der Organisation angewendet wird: Sollen wir jetzt wirklich dieses neue Gremium einführen? Ist Scrum oder Kanban für uns der richtige Startpunkt für uns? Die Hypothese und „Best Practice“ sagen vielleicht ja – aber der einzige Weg es herauszufinden, ist dies an der Realität zu validieren.
Das könnte dann wie folgt aussehen:
- Vision und „Why?“: Was wollen erreichen, warum ist beispielsweise Agilität in unserem konkreten Kontext wichtig? Etwa:
Unser nächster härtester Konkurrent könnte ein Unicorn mit einer disruptiven App sein.
Brüche, Handovers und zersiedelte Prozesse überall. „Not my responsibility“. Wo ist der Value Stream – end to end? So kann es nicht weiter gehen. - Verstehen, wo wir stehen, in Bezug auf Ziele. Wo besteht Handlungsbedarf? Wie messen wir eigentlich, ob wir uns verbessern?
- Roadmap in Form eines priorisierten Backlogs: Was gehen wir zuerst an und wie genau?
- Möglichst schnell Validierung der Top Prio Items: Funktioniert das für uns? Was haben wir daraus gelernt? Müssen wir unsere Strategie anpassen?
Aus einem Beispiel eines DevOps Kundenprojekts hat der Roadmap Backlog wie folgt ausgesehen:
- Mit ersten cross-functional Teams experimentieren, diese auf die Services/Produkte ausrichten und damit die Grundlage für eine Kultur mit gemeinsamen Zielen schaffen (statt Silo-Kultur)
- Die Grundlagen für Continuous Delivery schaffen, d.h.Entwicklungs- und Testplattformen sollen schnell zur Verfügung stehen, die Cloud (PaaS) ist die Grundlage dafür. Bis hin zu „Infrastructure as a Code“ und modularisierter Architektur
- Kontinuierlich Automatisierungspotential identifizieren und nutzen, z.B. Tests automatisieren, Deployments automatisieren
- Feedbackloops einbauen, um Fehler früh zu identifizieren
- Eine Continuous Delivery Pipeline schaffen
- Mit einer entsprechenden „Tool Chain“ entlang der Delivery-Pipeline schaffen, ohne Brüche (sonst kein Continuous Delivery)
- Eine agile Kultur schaffen, neu auch mit Leuten aus dem Betrieb (welche lange dagegen angekämpft haben). Als erster Schritt kann das auch einfach mal ein Kanban Board sein, und dann lernen es die Leute mögen (Denn: Culture eats Strategy for Breakfast)
- Kontinuierlich Value Stream Mappings durchführen. Wo sind unser Bottlenecks? Wo können wir uns verbessern?
- Und last but not least (eigentlich sogar als erstes) anhand weniger aussagekräftiger Metriken etablieren, um feststellen, ob wir uns verbessern. In diesem Fall: Time to Market, Deployment Frequency, Change Failure Rate, Recovery Time
Dies ist eine Reise in kleinen Schritten, die nie aufhört, die aber schon morgen sichtbaren Nutzen zeigen kann. Veränderung funktioniert natürlich nur, wenn wir dafür auch genügend Zeit einräumen. Arbeit ist wichtig, die Verbesserung der Arbeit aber genauso. Und was ist mit der Kulturveränderung? Dies braucht nach meiner Erfahrung Zeit. Indem neue Verhaltensweisen angewendet werden und der Einzelne den Nutzen sieht, werden diese irgendwann normal oder eben „the way we do things“, d.h. Kultur. Dazu gehört auch, dass Führungskräfte die Kultur des Experimentierens und Lernens vorleben – inklusive Scheitern (und etwas daraus lernen) – und ein Umfeld von psychologischer Sicherheit schaffen. In vielen Firmen noch ein langer Weg.
