Die Zeit ist um und schon schreibe ich den letzten Blog-Beitrag für das CAS ‹Agile Organisationen›.
Diesmal steht das Lean Change Management im Fokus meiner Betrachtung. Doch bevor es losgeht möchte ich an dieser Stelle innehalten und einen kurzen Rückblick auf das Erlebt, Erfahrene und Erlernte machen.
Review:
In den vergangenen Wochen und Monaten drehte sich alles um das Thema Agilität und ich bin in die verschiedensten Facetten der agilen Welt eingetaucht. Einiges war mir bereits bekannt und vertraut. Andere Aspekte hatte ich schon mal gehört und wieder vergessen. Doch ein grosser Teil des im CAS vermittelten Inhalts und Eindrücke war auch für mich, der seit über 10 Jahren in agilen Teams lebt und arbeitet, völliges Neuland. An meiner Grundeinstellung zum Thema Agilität hat sich auch heute nichts verändert und ich glaube immer noch fest daran, dass eine agile Denkweise und agile Methoden künftig unseren Arbeitsleben prägen und weiterentwickeln werden. Doch die Reise zum ‹agilen Nordstern› wird beschwerlich und übersät mit Stolpersteinen sein. Irgendwann jedoch haben auch die letzten verstanden das Hierarchien, Command & Control, reine Zielvorgaben, jährliche Mitarbeitergespräche und vieles mehr uns in der VUCA-Welt nicht weiterbringen.
Vielen Dank an alle Dozenten und Kommilitonen für diese lehrreiche Zeit, den Erfahrungsaustausch und die super Zusammenarbeit. Ich vermiss euch jetzt schon 😉
Lean Change Management:
Ein wichtiger Aspekt bei allen Agilitätsbestrebungen ist das Feedback. Denn ohne dieses sind wir «blind» in den Was und Wie wir etwas tun. Damit ist es auch nicht verwunderlich, dass wir Feedback-Loops überall in der agilen Zusammenarbeit wiederfinden. Sei es auf der persönlichen Ebene, der Team-Ebene oder innerhalb der gesamten Organisation. Menschen brauchen Feedback, um die unsichtbaren Flecken ihrer Wahrnehmung zu erkennen, zu lernen und um sich zu verbessern.
Der seit über 100 Jahren das Arbeitsleben beherrschende Taylorismus hat uns gelehrt, unsere Abläufe vorhersehbar zu machen, sie vorab detailliert zu planen, zu dokumentieren, umzusetzen und im besten Fall sogar abschliessend zu prüfen. Dieser Ablauf klingt einleuchtend und begegnet mir fast täglich in meiner Arbeit. Erst vor kurzen haben wir intern den Mini-Change «Kaffeemaschine zügeln» genau so geplant. Der Auslöser für dieses Vorhaben war eine Beschwerde unserer HR-Abteilung, welche in unmittelbarer Nähe zur Kaffeemaschine platziert war und sich durch die Geräusche des Mahlwerks und den an Kaffeemaschinen üblichen Mitarbeitergesprächen in ihrer Konzentration gestört gefühlt hat.
Das Leitungsteam hat sich daraufhin in mehreren Meetings zu diesem Problem Gedanken gemacht und beschlossen die Kaffeemaschine an einem anderen Ort im Gebäude zu zügeln und dieses Vorhaben akribisch geplant.
- #1 – Eruieren möglicher Standorte (Anschlussmöglichkeiten, Erreichbarkeit, usw.)
- #2 – Zeit- und Ressourcenplanung (Wann, Wer, Information an MA)
- #3 – Abschätzen der möglichen Mitarbeiterreaktionen und Vorbereitung einer Argumentationskette, die das Vorhaben plausibel rechtfertigt und positiv «verkauft»
- #4 – Planung des Abschluss-Meetings (Zusammenfassung der Mitarbeiterreaktionen und Validieren der Ergebnis)
Trotz dieser Spitzenleistung an Vorbereitung 😉 kam natürlich alles anders als erwartet. Schon nach der ersten Ankündigung, dass die Kaffeemaschine in ein anderes Stockwerk des Gebäudes verschoben wird, kam die ersten Reaktionen von Mitarbeiter. So meldete sich jemand und fragte, ob die Regelung : «Keine offenen Getränke im Treppenhaus» aufgehoben wird. Der Nächste hielt es für völlig unverhältnismässig und beschwerte sich über den Zeitverlust. Das Leitungsteam hielt natürlich an der Planung fest und die Kaffeemaschine wurde pünktlich durch den Abwart verschoben. Die weitere Story würde den Rahmen dieses Beitrags sprengen. Deswegen kürze ich an dieser Stelle etwas ab. Das Endergebnis des «kleinen» Veränderungsvorhabens war, dass neue Anschlüsse für die Kaffeemaschine durch den Elektriker verlegt werden mussten, der Schreiner entsprechende Möbel mit Entsorgungsmöglichkeiten anfertigen musste, Mitarbeiter ihren täglichen Kaffee in Thermoskannen mit an den Arbeitsplatz nehmen und sich daraus täglich lange Schlangen an der Kaffeemaschine bilden und auch Wochen später noch völliges Unverständnis darüber besteht was dieser Schritt an Mehrwert gebracht hat. Nur das HR, bestehend aus drei Personen, ist rundum zufrieden und holt den eigenen Kaffee aus der Kaffeemaschine, welche für Kundenbesuche auf dem Stockwerk verblieben ist.
Kurzum:
- Die Vorab-Planung zum Was, Wie und Wie schnell wurde weder im Change Prozess geprüft noch angepasst.
- Die Betroffenen wurden nicht mit einbezogen, fühlen sich übergangen und sind verärgert
- Alle vorab erwarteten positiven Effekte blieben aus
- Das Vorhaben wurde viel teurer als geplant
An diesem kleinen Beispiel wird deutlich warum klassisches Change Management so oft scheitert und eine Erfolgsrate von lediglich ca. 30%, wie verschiedene Studien zeigen, aufweist.
Organisationen und deren Bewohner sind komplexe adaptive Systeme, welche nicht vorhersehbar sind. Veränderungen können folglich nur mit Vermutungen und Annahmen darüber was passieren wird geplant werden. Genau hier setzt Lean Change Management an, indem es das Lean Startup-Prinzip auf Veränderungsmanagement überträgt.
Lean Startup:
Statt umfangreich mit theoretischen Wissen und Annahmen zu planen, setzt Lean Startup auf schnelle Iterationen. Ausgehend von Hypothesen soll gehandelt und aus dem Ergebnis gelernt werden, um das Erlernte in den nächsten Handlungsschritt einfliessen zu lassen.
(Start) Tue etwas. Schaue, was passiert. Ziehe Rückschlüsse daraus. Goto (Start)
Diese Idee des Lean Startups griff 2012 Jeff Anderson auf und übertrug es auf das klassische Change Management. Jason Little entwickelte den Ansatz von Anderson weiter und schuf einen eigenen offeneren Approach. Heute existieren verschiedene Ausprägungen des Lean-Change Management Ansatzes. (Quelle: Torsten Scheller auf agil-werden.de)
Wie auch beim Lean Startup finden beim Lean Change keine langwierigen Vorab-Planungen statt. Um zu starten bedarf es lediglich spezifisches internes Wissen aller am Veränderungsprozess Beteiligter in Form von Einsichten (Insights). Anhand dieser Einsichten können verschiedene Handlungsoptionen generiert und eine konkrete Veränderungsmassnahme selektiert werden. Die Umsetzung dieser Massnahme erfolgt experimentell und generiert neues Wissen, anhand dessen neue Einsichten entstehen, die ursprüngliche Option angepasst oder das Experiment beendet werden kann. Somit entsteht ein kontinuierlicher Kreislauf der Optimierung und Veränderung.
Auch wenn sich der Lean Change Cycle sehr strukturiert und linear präsentiert ist der Ablauf in der Praxis keineswegs so linear. Vielmehr kann das Vorgehen als «Dance with the System» betrachtet werden. Wie beim «echten» Tanzen auch, hängt der nächste Schritt von der Reaktion des Tanzpartners ab. Stolpert dieser, fange ich ihn auf. Dreht er sich in die falsche Richtung reagiere ich und korrigiere dies oder passe mich situativ der Bewegung an. Genau dies passiert im Lean Change Kreislauf. Die Reaktion des Systems in den einzelnen Schritten führt zu situativen Handlungen und einem neuen Vorgehen.
Anwendung in der Praxis:
Nachdem der ersten Halbtag im Lean Change Modul mit Pit absolviert war habe ich beschlossen das Erlernte in der Praxis anzuwenden.
Mein Teams bemängelte in verschiedenen Retrospektiven immer wieder, dass unsere Arbeitsweise nicht zielorientiert und fokussiert genug ist. Angespornt durch das CAS-Modul habe ich mein Team spontan zu einem gemeinsamen «Bier-Trinken» eingeladen und die Frage gestellt: Was müssen wir tun damit wir fokussierte werden und unser Sprintziel konsequent erreichen können?
Es entstand eine angeregte gemeinsame Diskussion, die uns zu verschiedenen Einsichten führte:
- Unser Sprintbacklog ist zu diffus
- Wir lassen uns von anderen betrieblichen Nebentätigkeiten zu sehr ablenken
- Scrum ist die falsche Methode für uns
- Wir sitzen zu verteilt (Grossraumbüro)
Mit diesen Insights haben wir an den darauffolgenden Tagen verschiedene Handlungsoptionen erarbeitet und gemeinsam bewertet, welche dieser Optionen wir als erstes umsetzen wollen und folgendes Experiment definiert:
Treiber:
Uns fehlt die Fokussierung um das Sprint-Ziel konsequent zu erreichen.
Hypothese:
Wenn wir unsere betrieblichen Aufgaben von unseren Projektaufgaben trennen und neben den Sprintbacklog ein Kanban-Board führen, sparen wir Zeit und können fokussierter und zielorientierte an der Erreichung des Sprintziels arbeiten.
Messen:
In jedem Daily Scrum beurteilt jeder die Wahrscheinlichkeit, dass wir das Sprintziel erreichen. (Diagnostik)
Über 3 Sprints hinweg messen wir, die Anzahl der offenen betriebliche Tickets im System und vergleichen dies mit den Vormonaten. (Metrik)
Ich bin gespannt wie dieses Experiment verläuft und welche neuen Erkenntnisse wir als Team für uns daraus ziehen können.
Quellen:
https://www.ionos.de/startupguide/gruendung/lean-startup/
https://www.lean-change.de/prinzip/
https://mindandmethods.com/lean-change-management/
Thx2Pit: it was amazing and exciting time