Hallo liebe Community,
es ist heute ausnahmsweise mal Dienstag und wir starten die Woche nach dem sonnigen Pfingstwochenende mit einer neuen Frage. Diesmal geht es um das Scheitern von agilen Transformationen.
Was sind eurer Erfahrung nach Gründe für das Scheitern einer agilen Transformation?
Habt ihr schon mal das Scheitern einer agilen Transformation erlebt und welche Faktoren haben dabei einen Einfluss gehabt?
Ich freue mich auf einen spannenden Austausch mit euch.
Liebe Grüße, Tim
Scheitern mit einem kompletten Rollback kenne ich nur aus zweiter Hand.
Dass eine Transformation Schwung verliert, dann irgendwann dahin dümpelt und in Teilen rückgängig gemacht wird, kenne ich allerdings gut.
Einer der Gründe ist meiner Meinung nach, dass die Einführung wie ein einmaliges Big-Bang-Change-Projekt gehandhabt wird. Nach den meisten Modellen wird hier mit einem “Sense of Urgency” begonnen. Den kann man aber nicht aufrecht erhalten und dann ist halt mal die Luft raus. Auch sind halt irgendwann die neuen Posten verteilt, das neue Territorium abgesteckt, und die Kollegen denen es mehr darum geht arbeiten nicht mehr so aktiv an der Veränderung mit. Management widmet sich ebenfalls der nächsten Initiative und die Erwartungen der Teams “dass alles anders wird” sind auch nicht erfüllt. Die Consultants sind irgendwann weg - schließlich ist das Budget verbraucht - und die Sachen die man nur wegen denen gemacht hat werden nicht mehr getan. Viele Versprechungen der Consultants (alles schneller z.B.) sind in Erfüllung gegangen.
Mein Vorschlag wäre Agilität in Unternehmen tendenziell mehr über Kaizen bzw. kleine Experimente und nicht Kaikaku einzuführen, dann hat man diese Probleme nicht.
Was bedeutet Kaikaku? Den Begriff höre ich gerade zum ersten Mal.
Viel Erfahrung habe noch nicht gemacht, wir befinden uns noch in einer Transformation.
An vielen Stellen hat er sehr gut funktioniert und läuft es auch gut, wenn auch teilweise Doing Agile anstelle von Being Agile gemacht wird.
NoGo = Big Bang Umstellung
besser Pilot im kleinen Bereich/Abteilung starten
Erfahrungen und Wissen in gesamter Organisation teilen und intensivieren
Mitstreiter finden, ausbilden oder ranholen, um die nächsten Schritte zu gehen
Schlimm wird es erst, wenn finanzielle Rahmenbedingungen, insbesondere bei Aktiengesellschaften, dazu führen, dass das Management eingreifen muss/will, und z.B. Teamgrößen, Anzahl Teams, etc. herumdoktort, so dass z.B. ein Scrum Master handlungsunfähig wird, weil Scrum mit 20 Leuten im Team nicht sinnvoll ist oder ein ScM 2 oder mehrere Team betreuen soll. Da werden dann Agile Coaches auch handlungsunfähig, weil die Argumente Kapitalmarkt und Kosten Totschlagargumente sind.
Just my two Cents 
Kaikaku ist der revolutionäre Wandel. Kaizen die permanente Verbesserung. Ich würde Agilität über Kaizen fördern, sprich kurze Feedback Zyklen an vielen Stellen im Unternehmen implementieren. Das Ergebnis ist nachhaltiger, auch wenn man damit nicht so gut angeben kann
Danke. Das sehe ich genauso. Das, was ich immer wieder erlebe, sind
Veränderungen entstehen dadurch, dass man drüber redet und mit kleinen Dingen anfängt, z.B. Meetingkultur, Entscheidungsfindung usw.
Meiner Wahrnehmung nach scheitern die meisten agilen Transformationen nicht, sie verlaufen im Sande. Offiziell scheitern tun sie nur dann, wenn ein neues Management übernimmt und ein Scheitern erklärt. Man beachte die Feinheiten Eine nachhaltige Transformation ist weiterhin unwahrscheinlicher als ein Auslaufen der Bemühungen.
Hier meine Favoriten der Gründe:
• Es gibt oft ein Problem mit Werten (falsche Werte, falsch verstandene Werte und nicht gelebte Werte)
• ungenügende Kommunikation der Vorteile (insbesondere für die Mitarbeiter – “Was habe ich davon?”)
• Statt ganzheitlichem und durchgängigem Denken in Systemen die Beschränkung auf Methoden
• kein Anpassen an den Kontext im Unternehmen (schlimmstenfalls One-fits-all Blödsinn)
• Agilität wird als Projekt verstanden
Hier ein paar Beispiele dazu…
Fangen wir oben an. “Eat your own dog food” ist überwiegend nichts fürs oberste und obere Management.
• Agilität wird nicht vorgelebt. Fehlanzeige, selbst agilen Werten zu folgen und agile Methoden zu verwenden.
• Die Transformation wird an Projektteams oder externe Berater delegiert.
• Die Transformation wird als klassisches Projekt aufgesetzt und genauso abgearbeitet.
Was ich auch oft erlebe, ist die Umkehrung, insbesondere von zwei Werten des agilen Manifestes:
• Statt “Individuals and interactions over processes and tools” werden dann in ersten Linie Prozesse und Methoden wichtiger als alles andere. Schnell tauchen agile Methoden und Frameworks auf, auf die sich dann festgelegt wird und die möglichst flächendeckend ausgerollt und durchgesetzt werden (Scrum, SAFe und Co. lassen grüßen).
• Sobald es einen Plan gibt, ist “Responding to change over following a plan” nicht mehr so wichtig wie den Plan auszuführen. Unversehens finden sich entsprechende Unterstützer, die sich schon lange mit der Umsetzung von Plänen auskennen. Ups, was könnte hier schieflaufen?
Beim Management wird durch Jeff Sutherland’s Scrum The Art of Doing Twice the Work in Half the Time gern die Erwartung geschürt, dass es um höhere Effizienz und mehr nutzbarer Kapazität geht.
Viele Mitarbeiter können darin aber keinen Vorteil für sich erkennen. Es führt eher zu mehr Stress, weil sie das Gefühl haben, dass sie jetzt noch mehr leisten müssen. Oft ist keinem klar, dass es hier um mehr Kundennutzen geht, der überwiegend durch Reduzierung und Vermeidung von Verschwendung (“Waste”) geschaffen wird. Durch Verringerung von Wartezeiten, höhere eingebaute Qualität und schnellere Anpassung an die Kundenbedürfnisse ist der Kundennutzen größer.
Prinzipien wie “Simplicity–the art of maximizing the amount of work not done–is essential.” geraten in Vergessenheit, wenn der ehemalige Kapazitätsoptimierer seine Chance sieht und mehr Arbeit ins System drückt (The resource utilization trap - YouTube). Sehr beliebt in diesem Zusammenhang auch die kontraproduktive Vergrößerung von Teams, damit mit mehr Kapazität mehr geschafft wird. Hat auch schon beim konventionellen Projektmanagement nicht funktioniert, aber wurde da auch immer wieder vergessen.
Schön auch, wenn das Agile neben der Linienorganisation als eigene Organisation aufgebaut wird (SAFe verkauft dies oft als Vorteil, dass das mit dem SAFe Framework möglich ist). Regelmäßig bleibt dadurch die klassische Linie vollständig und dauerhaft erhalten und behindert nicht selten die Agilität. Das Beharrungsvermögen der Linie kann eigentlich nie unterschätzt werden. Eine verbesserte Kommunikation im Gesamtsystem ist so meist unwahrscheinlich, wenn man hier nicht weitermacht. Vielleicht reden sich ja viele ein, dass das Gesetz von Conway nur bei anderen Unternehmen gilt, nicht aber bei der eigenen Organisation – Dream on! “The Empire strikes back” z.B. mit: “Wir haben viel erreicht, für uns reicht der Status quo der Transformation. Wir müssen jetzt konsolidieren”. Höchstwahrscheinlich der Anfang vom Ende einer kontinuierlichen Verbesserung.
Ein Indikator, wie ernsthaft sich die Unternehmung verändert hat, ist oft die Fehlerkultur. Agiles Vorgehen propagiert Experimente, um möglichst früh/schnell zu scheitern, um falsches früh zu erkennen. Fehler werden im Unternehmen dagegen aber weiterhin als negativ angesehen und führen ggf. zu Sanktionen (offen oder versteckt). Also sollte der Mitarbeiter weiterhin besser keine Fehler machen oder mit Fehlern in Verbindung gebracht werden. Sehr “vorteilhaft” für Faktoren wie die psychologische Sicherheit.
Fragt ihr die Mitarbeiter regelmäßig, mit denen ihr Kontakt habt, was ihnen persönlich die Transformation konkret bringt? High-Level VUCA-Gequatsche etc. ist dabei keine valide Antwort. Stelle ich diese Frage erstmals bei einer laufenden Transformation, bei der ich dazukomme, dann bekomme ich mit Mühe noch eine Antwort, was es dem Einzelnen bringen sollte. Die Nachfrage, ob es tatsächlich auch so ist, wird dann praktisch immer verneint. Scrum Team Mitarbeiter erzählen dann gern von mehr Meetings, weil andere Meetings deswegen nicht weggefallen sind und auch, dass die Anforderungen für die Dauer des Sprints fixiert sind, können viele nicht bestätigen. Kognitive Dissonanz bei den Mitarbeitenden sollte dann niemanden überraschen.
Spannend finde ich auch, wenn bei der Diskussion über eine Transformation nach Best Practices gefragt wird. Ein Blick ins Cynefin Framework (Cynefin framework - Wikipedia) zeigt, dass der Einsatz von Best Practices zur Domäne Clear (vormals Simple) gehört. Wer möchte, der kann es gern mit mir diskutieren, aber aus meiner Sicht gehören Unternehmen und deren Mitarbeiter mindestens zu den komplexen Systemen. Wie wahrscheinlich ist es, dass man da mit einfachen Antworten der Best Practices Erfolg haben wird? Ist es einem Berater gelungen, dies einem Unternehmen zu verkaufen, dann singt er bestimmt: Dire Straits - Money For Nothing (Official Music Video) - YouTube
Ich bitte um Entschuldigung, wenn meine Art Humor in diesem Fall nicht allen Werten und jedem Geschmack, sowie einer maximalen Meinungsvielfalt entspricht, aber bitte “assume positive intent”. Danke liebe Kollegen.
Kaikaku ist genau wie Kaizen oder Hansei ein Begriff aus dem Japanischen und aus dem Bereich des Lean Managements.
Wie Dirk schon schrieb, steht Kaikaku dabei für einen revolutionären Wandel und wird deshalb häufig Top-Down angewendet. Die Veränderung erfolgt dabei zunächst auf strategischer Ebene und weitet sich dann auf produktive Ebenen aus. Durch dieses Learning by Doing wird dann letztlich auch Einfluss auf die Unternehmenskultur genommen.
Kaizen steht für evolutionären Wandel und beginnt im Gegensatz zu Kaikaku mit dem Wandel der Kultur. Das wohl bekannteste Beispiel für Kaizen ist das berühmte “Stop-the-line”-Event bei Toyota. D.h. sobald es in der Produktion zu einem Problem kam, wurde die Produktionslinie gestoppt, das Problem angesprochen, analysiert und einer sofortigen Verbesserung zugeführt. Im Anschluss wurde die Produktionslinie dann wieder hochgefahren. Damit ist Kaizen eigentlich in jedem agilen Team ein sehr effektives, weil anlassgetriebenes Mittel der Verbesserung.
Hansei sei der Vollständigkeit noch ergänzt. Der Begriff steht für Selbstreflexion und ist ebenfalls von Toyota geprägt. Hansei entspricht quasi dem Scrum-Event der Retrospektive und bietet anlassunabhängig wiederkehrend die Möglichkeit der Verbesserung, in dem es für ein Bewusstsein der eigenen Schwächen sorgt.
Es ist natürlich absolut traumhaft, wenn man eine agile Transformation einmal Top-Down durch das Top-Management und Bottom-Up durch Teams der Willigen initiiert. Beide Ebenen werden im Prozess meist begleitet, entweder durch Berater (Top-Management) oder Scrum Master / Agile Coaches (operative Ebene).
Nur leider gibt es dazwischen eine ziemlich einflussreiche Ebene, nämlich die des Mittelmanagements. Diese Führungskräfte sind es gewohnt, massiv in operative Aufgaben involviert zu sein, Dinge zu initiieren, zu steuern, zu entscheiden. Kurz sie haben Macht.
Nun kommt aber dieser Change in Form der agilen Transformation, stellt das alles auf den Kopf und nach und nach verlieren diese Führungskräfte ihren Einfluss, die Initiative, die Übersicht, die Entscheidungen, die Macht, wenn sie sich denn nicht anpassen.
Unabhängig davon, dass ich der festen Überzeugung bin, dass Führungskräfte sich eh mehr darauf konzentrieren sollten, ein für die operative Ebene optimales Umfeld, also eine förderliche Kultur zu schaffen, löst diese Entwicklung in der agilen Transformation natürlich Fragen und Verlustängste beim Mittelmanagement auf.
Die häufige Reaktion dieser Führungskräfte ist dann meist der Kampf um den Erhalt dessen, was vor Beginn der Transformation war. Das geht teilweise sogar so weit, dass der Prozess aktiv sabotiert wird, indem Unterstützung ausbleibt und dem “Schwarm” in schwerwiegenden Fällen sogar wichtige Informationen vorenthalten werden, damit die Führungskraft so später als Retter in der Not auftreten und aufzeigen kann, dass das mit der Agilität doch eh nicht funktioniert (Hero Culture at its finest!).
Daher ist für mich das Ausbleiben einer aktiven Begleitung des Mittelmanagements im Change-Prozess der agilen Transformation der Grund schlecht hin für das Scheitern agiler Transformationen. Es heißt nicht grundlos 90% aller agilen Transformationen scheitern am Mittelmanagement.
Habt ihr das auch schon erlebt?
Ja, da sprichst du einen ganz wichtigen Punkt an, Tim. Wer den Widerstand des Mittelmanagements noch nicht erlebt hat, sollte bei so viel Glück dringend Lotto spielen.
Meinem Verständnis nach muss eine Transformation das Umfeld bzw. das System ändern. Es ist merkwürdig, wenn man Berater “oben” und SMs/ACs “unten” findet, aber es dazwischen nichts gibt, obwohl dort ein grosser Teil des Systems massgeblich definiert, gelebt und missbraucht wird.
Hier zwei Punkte, die mich insbesondere in den Anfängen der Transformation alarmieren
Viele Dinge, die den Teams Probleme bereiten und auch zu Problemen/Konflikten in den Teams führen, können die Teams nicht aus sich selbst herauslösen.
Ich war in meinen ersten agilen Jahren auch “pragmatisch” auf die Dinge konzentriert, die die Teams selbst ändern können. Es ist für das Team weiterhin sinnvoll, sich auf die Lösung von Problemen zu konzentrieren, die in der eigenen Einflusssphäre liegen. Der SM als “true leader” muss aber nicht nur den Blick nach innen haben, sondern die Probleme identifizieren, die das Team insgesamt behindern. Für ACs gilt das erst recht.
Ein Grossteil meiner Zeit geht daher heutzutage in die “Bearbeitung” (meist professionelles Coaching) des Managements, welches mit den Teams auf verschiedenen Ebenen und aus unterschiedlichen Bereichen verbunden ist. Ich bin mittlerweile schmerzfrei einen Manager über alle Hierarchien hinweg anzugehen, egal welchen wunderbaren Titel jemand in der Linienorganisation hat, wenn dieser die Macht hat ein Problem zu lösen. Viele SMs tun sich damit eher schwer, wenn sie z.B. demselben Manager unterstellt sind, wie die Entwickler der Teams, sprich ganz unten in der Hierarchie stehen. Damit haben wir den Übergang zum nächsten Punkt.
Natürlich ist es grob vereinfacht, aber in einer hierarchischen Linienorganisation gilt “Ober sticht Unter”. Man muss es nicht gut finden, aber man muss sich der Realität stellen, dass viele der Linienmanager über Jahre, wenn nicht sogar Jahrzehnte auf die Mechanismen der Hierarchie konditioniert sind. Nicht alle schalten von jetzt auf gleich auf Augenhöhe um. Es sollte also bei einer Transformation dringend überlegt werden, ob es den agilen Rollen unnötig schwer gemacht werden sollte. Eine geeignete hierarchische Positionierung kann hier hilfreich sein, um Gehör zu finden und einen Austausch auf Augenhöhe zu erleichtern. Ein Muss bleibt, das entsprechende Vertrauen aufzubauen und die verständlichen Ängste des Mittelmanagements zu adressieren.
Ein weiterer Nebeneffekt einer geeigneten hierarchischen Positionierung kann sich qualitativ bei der Einstellung von neuen Mitarbeitern in agilen Rollen ergeben. Ein Manager, der nach maximal einem “Agile for Dummies”-Zweitageskurs beispielsweise Scrum Master einstellen soll, läuft Gefahr nach nicht ganz idealen Auswahlkriterien (sondern eher nach den “guten alten Kriterien”) zu entscheiden.
Die Transformation bestehender Mitarbeiter aus althergebrachten Rollen (z.B. Produktmanager → Product Owner, Projekt Manager → Scrum Master, RTE etc.) dürfte bei den meisten Transformationen bereits im Blick von Senior Scrum Mastern und ACs sein.
Von beidem kann ich absolut ein Lied singen! Leider…
Ich habe SMs/ACs erlebt, die sich an der Organsiationsentwicklung (dein Pkt 1) abgekämpft, letztlich die Zähne ausgebissen und gekündigt haben. Nachfolger sind aufgrund der Erfahrung ihrer Vorgänger gar nicht erst in die Hölle der Organisationsentwicklung herabgestiegen, haben versucht, die Teams zu verbessern. Als diese Teams aber aufgrund des unbetreuten Mittelmanagements ihre Grenzen erlebten und echte Verbesserungen nicht mehr möglich waren, ging erst der SM / AC und dann nach und nach 6 von 10 Devs…
Dieser personelle Aderlass führt dann logischer Weise zum Versuch der Neueinstellungen, der aus den in Pkt 2 von dir genannten Gründen scheiterte. In meinem Fall traf das “Thomas-Prinzip” voll zu (gleich und gleich gesellt sich gern). Obwohl wir von 4 SM-Kandidaten 3 nicht perfekte aber definitiv qualifizierte, ausbaubare / formbare Bewerber(innen) hatten, wurden alle vom Mittelmanagement abgelehnt. Ich behaupte, Grundlage dieser Entscheidungen war das von diesen Kandidaten für das Mittelmanagement selbst ausgehende Gefahrenpotential.
Spätestens als ein Bewerberin abgelehnt wurde, die BWL und Psychologie studiert hatte und es locker mit dem Mittelmanagement hätte aufnehmen können, dämmerte es mir, zumal auch das Top-Management aufgrund der vielen Reibung mit den agilen Teams, die Unterstützung der Transformation aufgegeben hatte.
Eine auch für mich als PO aussichtslose Situation, denn dieses lange Zeit unbemerkt stattfindende Abdriften des Managements (Weg vom agilen Mindest, zurück zum Management 0.0 - wie ich immer sage) war aufgrund von Lerneffekten unumkehrbar. Es sei denn man stellt neues Mittelmanagement ein. Aber eine Krähe sticht einer anderen Krähe kein Auge aus! Die Gesamtsituation ließ nur eine Reaktion zu. Gehen oder wie eine vorherige Kollegin von mir zu sagen pflegt “Lauf , lauf so schnell du kannst!”
Meine These: Hätte man das Mittelmanagement von Anfang an an die Hand genommen und in stattfindenden Change der Transformation “betreut”, wäre es anders gekommen…
Diese Regression ins Management 0.0 klingt so schlimm,
dass da womöglich nicht mal ein Punkt reingehört und es
in diesen Fällen besser Management 00 heissen sollte.
Böser Stuart! Aus! Mach Sitz! 
Du sollst doch das Management nicht immer beissen.
