CAS Agile Organisation

making your organisation agile

Archive for the 'Agile Transformation' Category

Agile Transformation

Posted by Gils Glauser on 14th December 2019

Pit Zurkirchen hat uns im letzten Modul auf erfrischende Art viele Modelle und Methoden erläutert, welche ich immer noch am Verdauen bin. (NB : LC1 ist ein probiotisches Jogurt und kann während der Lektüre die Verdauung dieses Blogs unterstützen 😊).
Change in Organisationen erlebte ich bis jetzt nur als ein Herumschrauben an der Aufbauorganisation. Auf die Frage, wie die Ablauforganisation aussieht, hiess es “Da hat sich nichts geändert, jeder macht das, was er vorher gemacht hat”….?
Eine Überlebensstrategie auf Teamstufe war dann, herauszufinden wie es nun “wirklich” ist. Man hat aufgrund von Beobachtungen (Insights)  Annahmen getroffen (Hypothesen) und dann versucht aufgrund bestem Wissen und Gewissen U-Boote (Experimente) zu starten um zu sehen (Reflexion) welchen Impact das U-Boot hat. In dem Sinn habe ich bereits eine Art Lean Change Management betrieben. Ohne es zu wissen, einfach auf natürliche Art.
Ich denke das ist das, was Pit meint: Agil sein steckt schon als Kind in uns, wir haben es einfach verlernt so zu handeln. Mit dem nun erhaltenen Wissen, gehe ich bewusster und strukturierter an das nächste U-Boot …ich meine Experiment…heran. Im Hoffen, dass ich durch Reflexion und Analyse der Resultate gezielter einen Nutzen erlange kann.

Veränderung: Kann ich jemanden verändern?

Nein. Ich kann nur mich verändern. Pit hat anhand eines Beispiels gezeigt, wie man durch Anpassen der Verhältnisse eines Menschen, sein Verhalten beeinflussen kann und somit seine Haltung stimuliert. Dadurch ist die Hoffnung gross, dass der Betroffene seine Haltung in die gewünschte Richtung verändert. Ich nehme diesen Rat gerne in meinem agilen Rucksack mit und will bei der nächsten Irritation durch ein Individuum potentielle Baustellen seiner Verhältnisse abwägen.   

Veränderung steuern: Lean Change Management (LCM)?

LCM basiert auf einem nichtlinearen und iterativen Vorgehen. Bei diesem Modell geht es primär nicht darum die Veränderung zu steuern, sondern durch Feedbacks auf den Impact der Veränderung zu reagieren. Bei diesem Prinzip habe ich Parallelen zu anderen Methoden erkannt. Z.B dass der nichtlineare Prozess des LCM ähnlich wie beim Design Thinking den Menschen als Betroffenen einbezieht und mit Fragen stellen und durch Experimente resp Prototyping neue Erkenntnisse gewonnen werden.  Der Prozess gleicht einer liegenden Acht (Infinity=unendlich) und erinnert dabei auch stark an das Prinzip der Retrospektive und von Scrum. 

Der LCM-Zyklus (Bild aus den Kursunterlagen)

Insights: Hier geht es darum, über Feedbacks von Betroffenen Einsichten zu gewinnen. Erste Voraussetzung ist, dass die Mitarbeiter dazu bereit sind. Zweite Voraussetzung ist eine offene und ehrliche Feedback- und Lernkultur. Pit sagt zurecht, wenn niemand erscheint (z.B. bei einem offenen Austausch) kann das auch ein Feedback sein (kein Interesse, Information nicht erhalten, keine Bereitschaft für einen Austausch,… usw ).

Eine interessante Erfahrung für mich war die Übung mit der HotSeat-Methode. Ich war überrascht, wie viele wertvollen Einsichten dabei zu Tage kamen. Aus Erfahrung denke ich, dass auch mittels Retrospektiven viele Ideen gesammelt werden können.    

Options: Hier ist es zentral, die erhaltenen Einsichten genau zu analysieren. Wo ist für einen Change am meisten Potenzial vorhanden? Kann man ein Clustering der Themen bilden und welcher Gewinn ist zu erwarten.

Experiments: Wie starte ich ein Experiment?

Wie einleitend erkannt, kann man bei einem Menschen nicht seine Haltung ändern. Aber man kann versuchen, über die Verhältnisse das Verhalten zu beeinflussen. Aus dieser Einsicht (Insight) heraus möchte ich ein Experiment in meinem Team starten. Konkret: Aktuell ist wenig kreativer Output während unseren Meetings vorhanden. Ich generiere deshalb ganz spontan eine Hypothese anhand einer nützlichen Sprachschablone:

LCM Sprachschablone für Experimente (Bild aus den Kursunterlagen)

Dies würde dann etwa so lauten:
-Wenn wir die Sitzordnung und Bestuhlung im Projektraum ändern,
vermuten wir, dass der Austausch im Team viel natürlicher und inspirierender wird.
Wir stellen den Erfolg mit einem Feedback-Thermometer fest. (Achsen: Persönliche Zufriedenheit in Funktion der erarbeiteten Resultate)    

Um den Product Owner und den Scrum Master in das Experiment einzubeziehen, erstelle ich ein Plakat und präsentiere ihnen damit mein Vorhaben:

Das gemeinsame Auswerten des Feedback-Thermometers wird zeigen, ob die Hypothese eingetroffen ist.

SCARF-Modell (David Rock)

Es ist spannend, wenn Neurologen unser Verhalten im Alltag aufgrund von Hirnprozessen erklären. Je nach Typ Mensch reagieren wir in Stresssituationen mit Flucht, Kampf oder Erstarrung.
Nach der einführenden Theorie (Belohnung versus Bedrohung) hat Pit uns aufgefordert, jeder für sich eine Rangliste von Status, Certainty, Autonomy, Relatedness und Fairness zu erstellen. Welche dieser sozial wichtigen Domänen muss bei mir belohnt resp erhalten sein?  Oder anders ausgedrückt, welche Domäne darf am wenigsten bedroht oder in Konflikt stehen, damit ich handlungsfähig bleibe?

Ich habe erkannt, dass der Treiber Status für mich am meisten Gewicht hat. Bedrohung geschieht dann, wenn ich durch Worte in meiner Existenz als Mensch in Frage gestellt oder ausgeschlossen werde. Diese verbale Verletzung lässt mich in die Defensive gehen, hin bis zur Erstarrung. Gemäss den Hirnforschern wird die Region im Hirn aktiviert, welche auch bei körperlicher Verletzung aktiv wird. Wird man körperlich schwer verletzt, so kann man verbluten. Reagieren ist also lebenswichtig. Um nun in der Verletztheit richtig zu handeln und mein Gehirn wieder in die Leistungszone zu bringen, habe ich mir nun ein Konzept überlegt wie ich agieren kann: Muster erkennen, körperlich gerade Haltung einnehmen und dem Agressor mit sicherer und ruhiger Stimme antworten (Connecting Mindset lässt grüssen).     

Posted in Agile Transformation | No Comments »

Agile Transformation

Posted by Zehra Sirin on 5th January 2019

Die Zeit verging im Flug und schon schreibe ich meinen letzten Blog. Diesmal zum Thema Agile Transformation von Pit Zurkirchen.

Das Fazit vorgezogen kann ich sagen, dass ich dieses Modul am Spannendsten erlebt habe. Lean Change, dachte ich mir. Die Aspekte von Change ändern sich kaum, nur weil ein Projekt agil umgesetzt wird. Doch Pit Zurkirchen holte früher aus, d.h. was Menschen zu Veränderungen bewegt, was es auslöst bzw. was es mit ihnen macht. Erst dann brachte er die mir bekannten Aspekte aus Change. Und ich lernte über das SCARF Modell, Veränderungsmodelle wie das 3-Phasen Modell (Lewin), die emotionale Veränderungskurve (Kübler-Ross) oder das psychologische Satir-Modell (Satir). Diese zahlreichen Inhalte und Themen aus der Kommunikations-, Psychologie-, Qualitätsmanagement-Toolbox wurden nun kombiniert. Die Kombination machte es letztlich lehrreich für mich und ich freue mich, in einem meiner nächsten Projekte das Erlernte anzuwenden.

 

Um meine nachstehenden Überlegungen und Interpretationen zum in diesem Modul neu Erlernten zu begründen, möchte ich die Arbeitswelt umschreiben, denen ich in Changeprojekten nach wie vor begegne. Dies gilt selbstverständlich nicht als Pauschalisierung, doch weitestgehend so oder ähnlich verlaufende Gegebenheiten. Mit Pit Zurkirchen vermittelten Inhalte jedoch lernte ich, dass meine Erwartung nach mehr Sinnhaftig-, Handhabbar- und Verstehbarkeit in einem Changeprojekt offenbar doch mit Systematik existiert, einen Namen hat und der Aspekt «Lean» nicht nur ein Märchen von morgen ist. Doch nun zu meinem Arbeitsalltag als Unternehmungsberaterin:

 

Wie oft in meinem Arbeitsalltag bezüglich Change-Projekten denke ich mir «schon wieder wird eine Organisation nach dem «budgetierten» oder «politisch verträglichen» Fahrplan umgesetzt. So werden nicht selten – und abhängig von den Erfahrungen des Projektleiters – die 8 Stufen (Kotter) des Changes mehr oder weniger gleichmässig und linear in den Projektplan eingebettet. D.h. wieviel Zeit, welche Phase in der Organisation benötigen «darf» wird im Voraus phasenweise verteilt. Zwar spricht man von Wirksamkeit der Massnahmen, erfolgskritische Faktoren wie die Beteiligung der Mitarbeitenden. Doch blicke ich auf meine Statussitzungen mit Auftraggebenden, bzw. sog. Steering Committee Meetings, so wird wenig Zeit für die Überprüfung und Anpassung der Insights oder Changezustand besprochen. Meist geht es um schnelle Meilensteinerreichung – um möglichst schlank «durch zu kommen». Die Projektnamen besiegeln förmlich die Projektpriorität mit Bezeichnungen wie «Fast Track», «Speed-Up» oder «RC», das für «Reduce Complexity» stand und statt Komplexität als Rahmenbedingung zu nehmen und damit zu arbeiten, versucht wurde, in der Organisation zu glätten bis hin aufzuheben. Die Besiegelung all dieser weniger optimalen Vorgehensweisen erfolgt dann noch mit Erfolgsboni sowie Halteprämien. Damit wird den Entscheidungsträgern und Projektleiter der Anreiz für die Einhaltung des Projektplanes und quantitative Projektziele geschaffen oder für sog. Key-Player-Mitarbeitende Prämien angeboten, damit sie das Unternehmen währendes Changes «trotzdem» nicht verlassen.

 

 

Der Lean Change Management Cycle (LCM)

Summary

Betrachte ich den obigen Zyklus von LCM, so sind sie mir nicht ganz fremd. Ob RADAR aus EFQM, DMAIC aus SixSigma oder PDCA (Deming/QM), es geht hauptsächlich um die konsequente Einhaltung der Systematik. Hier sehe ich auch den wesentlichen Unterschied zwischen LCM und meinen (plangetriebenen/klassischen) Vorgehensweisen. Die hohe Gewichtung von Zusammenarbeit, Qualität, Werte, die Erlaubnis von einer «fail fast and better»-Kultur sind bei LCM handlungsleitender und verankern viel stärker die Changemassnahmen. Auf einzelne möchte ich nachstehend vertiefter eingehen.

 

Der Hauptunterschied besteht also in der Fähigkeit, das Projekt einerseits voranzutreiben, das Spektrum jedoch auf die Entwicklungen, Feedback, Bedarf und Ideen zu erweitern. Erst auf dieser Grundlage können Changeprojekte das volle Potenzial entfalten. Die Erkenntnisse pro Iteration dienen demnach als Wegbeschreibung, von der aus stimmig und erfolgreicher gehandelt werden kann.

Aus meiner Sicht ein deutlich anspruchsvolleres Vorgehen. Raum, Zeit und Individualität zuzulassen und trotzdem das Projektziel zu «beherrschen», erfordert sehr viel mehr Empathie und Kompetenzen von allen Beteiligten. Sicherlich ist dieses agile Vorgehen kein Garant für das Gelingen eines Changes, doch die typischen Widerstände werden sicherlich gemindert, gemildert und Akzeptanz durch Beteiligung über alle acht Phasen des Changes, gekürzt.

 

 

Iteratives Vorgehen

Anders als beim oben beschriebenen Fall, wird in LCM schrittweise und teilweise iterativ vorgegangen. Ziel ist pro Schritt möglichst viel richtungsweisende Erkenntnisse und Feedback aus der Organisation zu erhalten, um den Change bedarfsgerechter weiter zu steuern und entwickeln. Der Change-Verlauf wird demnach kontinuierlich geprüft und darauf basierend die Planung der nächsten Massnahmen angepasst.

 

Insights

Zu Beginn ist es erforderlich, das zu lösende Problem zu verstehen, um daraus die richtigen Massnahmen und Hypothesen aufzustellen. Eine Aufgabe, mit der sich meine Auftraggebenden kaum aufhalten (möchten). Viel eher liegt ihr Fokus auf dem Ziel und dem Massnahmenplan dahin. Doch zurück zum Erlernten. Eine systematische Ursachenanalyse mit beispielsweise Ishikawa oder 5W hilft nicht nur die Vielschichtigkeit der zu verändernden Thematik zu erkennen und verstehen. Darauf basierend werden Hypothesen gebildet, was zur Folge hat, dass in einer so frühen Phase schon entscheidende Weichen richtig oder falsch gestellt werden können.

 

Options

Anders als in meiner Praxis, wo der Weg vorgängig weitestgehend statisch geplant und höchstens Pufferzeiten für Unvorhergesehenes eingebaut werden, werden hier basierend auf die identifizierten Ursachen mehrere Hypothesen beziehungsweise Lösungsoptionen gebildet. Das bedeutet, mehrere Massnahmen und Szenarien werden so formuliert, dass dabei die Frage beantwortet werden kann, wie eine zu verändernde Situation oder das Problem möglicherweise (auch) gelöst werden kann. Diese Optionen können verschiedenen Rahmenbedingungen Rechnung tragen und sich deshalb auch voneinander unterscheiden.

 

Experiments

Hier werden zu den Hypothesen Experimente gefahren, die nun die Hypothese bestätigen oder widerlegen. Der Unterschied zur eingangs erwähnter Vorgehensweise ist, dass durch das Ziel, möglichst viele Erkenntnisse zu sammeln, diejenigen, die sich als falsche Hypothese ergeben, mindestens so wichtig sind, wie diejenigen, die sich bestätigen lassen. Und selbstverständlich experimentiert man nicht ins Blaue hinaus. Diese Optionen werden wie in allen Investitionsthemen und das Aufwand-/Nutzenverhältnis gegenseitig erwogen. Je nach Firmenkultur sehe ich hier dieselben Hürden, wie in jedem anderen Projekt mit Investitionen. Die Wozu-Frage leidet nicht selten unter der Wieviel- oder Wie-Lange-Frage.

Umso wichtiger ist die Wozu-Frage gegenwärtig zu halten, welches Problem lösen wir damit und was benötigt es nun dafür? Die vorgängige Festlegung von Kennzahlen und Indikatoren, die eine Hypothese Zahlen-Daten-Fakten basiert bestätigen oder widerlegen sind eine weitere Massnahme zur Zielorientierung und Qualitätssicherung. Und auch hier sehe ich eine weitere Herausforderung. In der Praxis stelle ich fest, dass das Verständnis für Kennzahlen und Indikatoren sehr unterschiedlich ist und je nach Ergebnis (u/o Politik) sie einfach weggelassen werden.

Diese Experimente werden so lange durchgeführt bis alle Hypothesen bzw. Massnahmen abgearbeitet sind – vergleichbar mit dem PDCA-Regelkreis (Deming) nur mit einer zusätzlichen Iteration in der Iteration. Vergleichbar mit der Scrum-Iteration, bestehen die Experimente aus einer eigenen Sub-Iteration mit folgenden Teilleistungen:

  • Prepare– Vorbereitung der Option zur Umsetzung inkl. Bestimmung Messgrössen, KPIs, Indikatoren.
  • Introduce– Umsetzung der Optionen und Gewinnung der Erkenntnisse und Feedbacks.
  • Review– Validierung der Ergebnisse, Erkenntnisse auf das zu lösende Problem bezogen und diesbezüglich vorgängig geplanten KPIs/Indikatoren. Insbesondere dieser Punkt wird in meiner Praxis zu wenig konsequent bis gar nicht durchgeführt, zumindest was die Erfahrungen betrifft, wie auch die Qualität der Zusammenarbeit ist.

 

Der LCM-Cycle ist eingebettet in einen Kontext und Rahmenbedingungen und prägen massgeblich die oben beschriebenen Hypothesen in ihrer diesbezüglichen Ursache. Teile davon werden nachstehend mit Vergleichen zu meinen Projekt-Rahmenbedingungen in Changeprojekten zusammengefasst. Ausserdem werde auf den ebenfalls in der Grafik abgebildete Canvas eingehen.

 

People

Auch Beteiligte werden stark eingebunden und in ihrem Standpunkt sozusagen typisiert. Diese Typisierung nach Movers, Movables, Immovables klingt zunächst missverständlich. Doch basiert die Kategorisierung auf Aspekte, wie sie einleitend mit SCARF etc. beschrieben, bzw. systematisch identifiziert wurden. Ausserdem wird nicht nur anfänglich, sondern kontinuierlich der Entwicklungsstand der Beteiligten und ihrem Mind-Set erwogen und ermöglicht auch bedürfnis- und bedarfsgerechtere Massnahmen. Zumal die Betroffenen sich auch selbst einschätzen können. Dies verschafft die Möglichkeit, dass der Stand der Veränderung realistischer eingeschätzt werden kann.

Auch die Dauer der Change-Phasen relativiert und individualisiert sich bezüglich Handlungsbedarfes und auf Basis der gewonnen Einschätzung. Zwar besagt Kotters Modell, dass Beteiligte in unterschiedlichen Phasen des Changes abzuholen sind. Von LCM erfuhr ich nun jedoch, wie weiter damit umgegangen werden soll.

 

Selbstverständlich sehe ich auch die Gefahren dieser Typisierung. Zu schnell können voreilige Schlüsse darüber gezogen werden, wie sich jemand verhält und wie mit ihm umgegangen oder gar ignoriert wird. Doch diese Gefahr besteht in jeder Form der Vorgehensweise. Diese Gefahr mache ich auch vom Reifegrad und Kultur der Organisation abhängig, wobei ich mir gut vorstellen kann, dass auch hier agilere Vorgehensweisen diese Gefahr weniger bieten, weil der Mindset schon eine ganz andere ist.

 

Lean Change Canvas

Der Canvas ist eine einfachste Form der Planung, Umsetzung und Transparenz und stellt die Aufgaben und ihren aktuellen Stand dar. Der Fortschritt kann dann durch Heftnotizen-Umplatzierungen verwaltet werden und visualisiert den Projektstatus at a Glace. Auf dieser Grundlage können Diskussionen einfacher geführt werden, wenn die Konversion nicht im gewünschten Masse vorangeht oder Anpassungen im Vorgehen erforderlich werden.

 

Unter den zahlreichen Canvas arbeitete ich bisher mit dem Business Canvas Modell von Osterwalder/Pigneur. Je nach Detaillierungsstufe des Abzubildenden, können die Inhalte von strategischer bis Einzeltätigkeitsstufe kaskadiert werden und unterscheiden sich dementsprechend in den Feldbezeichnungen. Beim Lean Canvas geht es um die Umsetzung des Projektes, weswegen folgende Inhalte grundsätzlich thematisiert werden sollten:

  • Wozu: Ziel-/Sinnfrage
  • Was: Experimente
  • Wie: Umsetzung
  • Wer: Beteiligte/Bereich
  • Wann: Friste, Termine

 

Die Sichtbarmachung der Aufgaben und ihre Stati ist in agilen Projekten deutlich wichtiger, als in meinen bisherigen Changeprojekten. Die Visualisierung ist allerdings sehr einfach und kreativ gehalten. D.h. während für meine bisherigen Status-Meetings zeitintensive Folien für die Führung erstellt werden, die den Stand des Fortschrittes in Management-Folien wiedergeben, wird hier wahrscheinlich ein Foto des Canvas-Boards gemacht und diese in einer Managementpräsentation abgebildet. Ich würde – nach all dem Gelernten- sogar einen Schritt weitergehen und bei einfacheren Fällen die oberste Führung dazu einladen, den Projektstatus direkt vor dem Board durchzuführen. Zum einen, weil es Teamergebnisse zum Projekt nichts Vertrauliches sind, und zum anderen, um den Bezug und Committment hoch zu halten.

 

Zu Praxistipp LCM: «Are failed experiments really failing, or is the organization not ready for change?»

Nebst den oben aufgeführten Insights nehme ich diese Aussage mit.

 

Sie erinnerte mich unweigerlich an einen vor langen Jahren gelernten Ansatz: «Können – Wollen – Dürfen». Dieser besagt, dass eine gute Leistung – im vorliegenden Fall ist die Leistung der Change – nur möglich ist, wenn die drei Komponenten im Gleichgewicht sind. Ist dem nicht so, werden Ziele nicht oder nur teilweise erreicht, die Motivation sinkt und das fach- und firmenspezifische Wissen geht verloren. Die Konsequenz in Changeprojekten daraus sind schlechte Ergebnisse, Frustration der Beteiligten bis hin zu Abbruch u/o Neustart von Change-Rollouts.

 

Beispiel:

  • Nur weil eine Organisation den Change will
    (weil z.B. Markt Anpassung und damit Change erfordert) und
  • die Führung den Change als Massnahme erkennt und genehmigt (Dürfen),
  • ist die Organisation für die Transformation und Change nicht zwingend bereit und fähig (Können);

 

Denn oft dachte ich mir, dass der Kern mancher meiner Projekte der ist, dass die Organisation für den Change gar nicht bereit ist. Ein Dilemma für jede Unternehmungsberaterin. Da einerseits eine Optimierung und Wertschöpfung durch mich angestrebt wird, und andererseits diesbezüglich bei der Führung (Auftraggeber) diesbezüglich auf taube Ohren stosse wird.

 

Hilfreich wäre hier ein Tipp gewesen, wie mit solchen Organisationen umgegangen werden kann. Selber versuche ich diese Herausforderung mit der Wozu-Frage in Erinnerung zu rufen und lasse die Führung ausarbeiten, welche Voraussetzungen für das Projekt wichtig bis hin zu kritische Erfolgsfaktoren sind.

 

Posted in Agile Transformation | No Comments »