Montag, 18. Oktober 2021

Rage against the Machine

Bild: Wikimedia Commons / Eneas de la troya - CC BY 2.0

Zu dem "Food for Thought" das ich mir in letzter Zeit zugeführt habe gehört auch "Haben wir einen Konflikt oder hat der Konflikt uns?" von Markus Ingendahl. Aufbauend auf den Erkenntnissen des Konfliktforschers Friedrich Glasl fasst Markus in ihm zusammen wie Konflikte entstehen und eskalieren können. Alleine für sich genommen ist das bereits lesenswert, ich möchte es aber um einige weiterführende Gedanken ergänzen.


Zunächst zur Ausgangslage: laut Glasl entsteht ein Konflikt zunächst durch die individuell verschiedenen Wahrnehmungen von Beschaffenheit, Auswirkungen oder Bewertung eines Sachverhalts. Das liesse sich meistens noch auflösen, kann aber dadurch eskalieren, dass die Wahrnehmung der jeweils anderen Partei sich durch den Konflikt verändert: ihr werden negativ überzeichnete Motive und Charakterzüge zugeschrieben, wodurch der Umgang schärfer und die Konfliktlösung schwieriger wird.


Das alles ist zutreffend und kann jeden Tag zigfach beobachtet werden (mitunter am eigenen Beispiel), es gibt aber eine spezielle Kategorie von Konfliktfällen von denen ich glaube, dass man um sie zu verstehen über die gerade genannten Betrachtungen hinausdenken muss. Es handelt sich bei dieser Kategorie um Konflikte in grossen, formalen Organisationen. Sie nehmen häufig eine ungewöhnlich einseitige Form an, die in den meisten Definitionen übersehen wird.


Zum besseren Verständnis nochmal zur Konflikt-Eskalation bei Markus (bzw. bei Glasl). Was bei genauerer Betrachtung auffällt ist, dass sie durch eine Interaktion der beteiligten Parteien entsteht. Nicht nur wird die Gegenseite zunehmend dämonisiert, dadurch verändert sich auch das eigene Verhalten ihr gegenüber ins Negative, was wiederum die eigene Dämonisierung durch die Gegenseite befördert. Auf diese Weise schaukelt der Konflikt sich gegenseitig hoch.


Abweichend davon kann es in Grossorganisationen zu Konflikten kommen die nicht interaktiv sind. Das kann beispielsweise der Fall sein wenn durch gut gemeinte neue Vorschriften (oder deren Bürokratisierung durch Konzern-Trolle) die Arbeit auf den unteren Hierarchieebenen umständlicher, langwieriger oder anstrengender wird. Meistens ist ein zunehmend wütendes Protestieren der Betroffenen die Folge - wovon das Management aber erstaunlich oft gar nichts mitbekommt.


Die Gründe dafür können unterschiedlich sein. In vielen traditionellen Organisationen ist Unternehmenskommunikation eine Einbahnstrasse von oben nach unten, in anderen sind die höheren Hierarchie-Ebenen so überlastet, dass sie keine Zeit haben sich die Rückmeldungen anzuhören, in wieder anderen führt eine verbreitete Untertanenkultur zu der Annahme, dass dem Management alle Missstände bereits bekannt sein müssen, weshalb es sich erübrigt sie anzusprechen.


Wenn die oberen Hierarchie-Ebenen jetzt nicht auf die Missstände reagieren (was sie wie gesagt in dieser Konstellation nicht können, da sie ihnen nicht bewusst sind) kann das von den unteren Ebenen als Lösungs- oder Kommunikationsverweigerung wahrgenommen werden. Ist das der Fall greifen die oben erwähnten Eskalationsmechanismen wieder: "die da oben" werden zunehmend dämonisiert und ihnen werden zunehmend negative Beweggründe unterstellt. Es entsteht "Wut auf das System".


Im Extremfall kann das sogar dazu führen, dass weitere Verstärkereffekte entstehen: sobald diese "einseitige Eskalationsspirale" dazu führt, dass "die da unten" von aussen als zunehmend irrational wahrgenommen werden kann es dazu kommen, dass die Entscheidungsträger durch Vorzimmer, Mittelmanager, etc. nach unten abgeschirmt werden, da diese nicht mehr glauben, dass es in Begegnungen rational zugehen würde. Aus der gefühlten wird so eine reale Kommunikationsblockade.


Für eine Befreiung aus dieser speziellen Konfliktsituation ist es wichtig zu verstehen, dass sie systemisch entstanden ist und nur systemisch gelöst werden kann. Ein auf einzelne Personen oder Gruppen zielendes Konflikt- oder Anger-Management-Training bringt hier z.B. nur eingeschränkt weiter, stattdessen muss herausgearbeitet werden wo Feedback-Schleifen fehlen oder beschädigt sind und wie dadurch Frustrationserlebnisse entstehen. Basierend darauf kann man das System anpassen.


Das heisst leider nicht, dass es danach keine Konflikte mehr gibt, so schön es auch wäre. Es heisst aber, dass jetzt wieder eine Situation hergestellt ist in der man Konfliktdynamiken mit Hilfe der Erkenntnisse von Friedrich Glasl analysieren und auflösen kann. Das allein ist schon viel.

Donnerstag, 14. Oktober 2021

Deutungshoheit

Bild: Pexels / Tima Miroshnichenko - CC0 1.0

Dass Change-Projekte in deren Rahmen agile Frameworks und agile Produktentwicklung eingeführt werden nicht immer so verlaufen wie das dafür verantwortliche Management es sich wünscht ist ein erstaunlich häufig zu beobachtendes Phänomen. Die Gründe dafür sind vielfältig und reichen von der Zielsetzung bis zur Ergebniskommunikation. Ein weiterer, der häufig unterschätzt wird, ist eine bestimmte Art des Kontrollverlustes: das sich verändernde Unternehmen beitzt keine Deutungshoheit über den neuen Arbeitsmodus mehr.


Um zu verstehen warum es sich dabei um einen Ausnahmefall handelt hilft ein Blick auf den Normalfall. In ihm werden methodische Veränderungen dadurch eingeleitet, dass das von Unternehmensberatern unterstützte Management sich in ein Tagungshotel zurückzieht um dort in Ruhe neue Strukturen und Abläufe zu konzipieren. Diese werden dann nur noch verkündet, und zwar so, dass die betroffenen Mitarbeiter kaum noch widersprechen können.


Dabei ist eines wichtig: dass Widerspruch kaum möglich ist liegt meistens nicht daran, dass er nicht erlaubt wäre. Deutlich schwerer wirkt eine Informations-Asymetrie: egal ob es sich um Synergieeffekte und Sparpotentiale handelt oder um erfolgversprechende "Best Practices" und Industrie-Standards, den meisten Menschen fehlen sowohl die Erfahrungs- und Vergleichswerte um mitreden zu können als auch Zeit und Informationszugang für eigene Recherchen.


Bedingt dadurch befindet sich in diesem Szenario die Deutungshoheit über das angestrebte Vorgehen nahezu ausschliesslich auf der Seite von Management und Beratern. Nur sie haben den vollständigen Blick darauf wie der methodische Ansatz gedacht ist, er umgesetzt wird, sein Erfolg gemessen wird, etc. Verstärkt wird das oft noch dadurch, dass die Dokumentation des angestrebten Vorgehens nicht für alle zugänglich ist (wofür es sowohl gute als auch schlechte Gründe geben kann).


Im Fall agiler Transitionen ist diese Asymetrie aufgehoben. Das Manifest für agile Softwareentwicklung und die Grundlagen-Dokumente von Exteme Programming, Scrum und (IT-)Kanban stehen frei verfügbar im Internet und dank der Soft Power der agilen Bewegung findet ihre Verbreitung nicht nur durch (teure) Konferenzen und Bücher statt sondern auch durch zahllose, grösstenteils kostenlose Meetups und Online-Publikationen.


Durch diesen gleichen Informationszugang verschiebt sich die Deutungshoheit, und das in mehrfacher Hinsicht. Zum Einen kann sie nicht mehr (bewusst oder unbewusst) monopolisiert werden, wodurch in der Einführungsphase plötzlich eine Situation der Augenhöhe entsteht die für viele Organisationen höchst ungewohnt ist. Man kann es sich vorstellen - ein Sachbearbeiter oder Tester der einem Manager sagen kann ob dieser Scrum richtig verstanden hat oder nicht kann für ganz neue Dynamiken sorgen.


Zum Anderen (und das ist sogar noch weitergehend) verlagert sich die Deutungshoheit aus der Organisation heraus. Die Verfasser des agilen Manifests sind fast alle noch am Leben und sehr auskunftsfreudig, und die oben verlinkten Regelwerke der einzelnen Frameworks sind zwar minimalistisch, aber dafür ein vielen Stellen von unmissverständlicher Klarheit. Und keine Firma der Welt (egal wie gross sie ist) hat einen Einfluss auf das was darin steht.


Das hat Folgen. Natürlich kommt es in vielen Organisationen während der Change-Projekte zu Kompromissen, Missverständnissen oder halbgaren Lösungen. Aber anders als in den meisten klassischen Veränderungsvorhaben ist das jetzt für alle offensichtlich. "Wenn man agil arbeitet macht man das so" funktioniert nicht mehr als Universalbegründung wenn alle wissen dass das nicht stimmt. Und beim Scheitern alles auf die angeblich unpassende Methodik zu schieben geht auch nicht mehr.


Für viele Entscheidungsträger mag das zunächst bedrohlich klingen, man kann aber auch das Positive darin sehen. Dadurch dass die agilen Frameworks ausserhalb der eigenen Deutungshoheit liegen kann man sie als Leitstern benutzen, der alle (im Zweifel gut gemeinten) Kompromisse oder Minimalkonsense unverfälscht übersteht, so dass es immer wieder von neuem möglich ist zu refocussieren und sich erneut an ihm zu orientieren. Es kann sogar befreiend sein, keine eigene Methodik erarbeiten zu müssen.


Natürlich kollidiert ein solches Vorgehen mit vielen eingeübten Change-Routinen, die Veränderungen eher schnell beenden als durch regelmässige Refocussierungen immer wieder neu starten wollen. Genau das ist der zu Beginn genannte Verlauf den sich das verantwortliche Management häufig anders wünschen würde. Aber genau das ist eben auch - agil.

Montag, 11. Oktober 2021

Ein Bild sagt mehr als 1000 Worte (XXXII)

Bild: Comic Agile - CC BY-NC 4.0

Für alle die zu diesem Bild etwas Kontext brauchen: "Agile Release Tains" (ART) sind ein Elemement von SAFe und bestehen aus mehreren, aneinander gekoppelten Teams, die in Intervallen von acht bis zwölf Wochen ein Produkt entwickeln.

Donnerstag, 7. Oktober 2021

Do not automate all the things

Es ist der Schlachtruf der DevOps-Bewegung: Automate all the Things!, ein Anspruch der in seiner radikalen Absolutheit oft von dem Hyperbole and Half-Meme unterstrichen wird. Nicht nur in Bezug auf DevOps sondern mittlerweile auch für die Agilität im Allgemeinen ist diese Haltung zu einem der zentralen Distinktionsmerkmale geworden, ohne sie wäre es vermutlich nicht zu der damit verbundenen Erfolgsgeschichte gekommen. Und doch - mittlerweile sollte man  das Ganze kritisch hinterfragen.


Zur Erinnerung, eigentlich ist Automatisierung in der agilen Produktentwicklung etwas Gutes. Manuelle Release-, (Regressions-)Test-, Dokumentations- und ähnliche Prozesse können schnell absurde Umfänge annehmen, in der Durchführung ewig dauern und gigantische Kontroll- und Koordinierungs-Bürokratien erzeugen. Da das jegliche Beweglichkeit und Reaktionsfähigkeit ersticken würde bleibt nur eines - automatisieren, im Wettlauf gegen die Zeit.


Was im Rahmen dieses Vorgehens aus dem Blick geraten kann ist aber, dass die Automatisierung auch im wahrsten Sinn des Wortes Schattenseiten hat. Nicht umsonst wird sie im Deutschen auch als Dunkelverarbeitung bezeichnet, sobald Prozesse einmal selbstständig ablaufen sind sie vor dem menschlichen Auge verborgen (zumindest in der IT, wo Automatisierung fast immer Digitalisierung bedeutet, unter Umständen sogar irgendwo in der Cloud statt in den eigenen Systemen).


Bedingt dadurch kann es vorkommen, dass Informationen gar nicht mehr auffallen (oder erst dann wenn es zu spät ist). Eines der häufigsten Beispiele dafür sind Burndown-Charts. Dort wo sie manuell an der Wand erstellt werden ist es für ein Team schon früh sichtbar ob es Fortschritte macht oder ob es sich festgefahren hat, dort wo sie automatisiert erstellt werden (z.B. auf einer versteckten Web-Seite in Jira) werden sie oft nur zum Sprintende angeschaut, schlimmstenfalls nie.


Selbst wenn sie sichtbar angezeigt werden, können wichtige Informationen aber übersehen werden. Auch hier gibt es ein häufiges Beispiel: die Summe der Punkte auf den Tickets, die anzeigen seit wann sich hier nichts mehr bewegt hat. Dort wo sie automatisiert hochgezählt werden treten oft schnell Abstumpfungs-Effekte ein, dort wo sie manuell hinzugefügt werden entsteht eine bewusstere Beschäftigung mit dem Thema, die häufiger zu Korrekturmassnahmen führt.



Nicht zu unterschätzen ist auch der Effekt der eintritt wenn die Beschäftigung mit den eigenen Prozessen zu einem Standard-Bestandteil von Regelmeetings wird. Das kann etwa im Rahmen von Reviews oder Retrospektiven stattfinden, es können aber auch eigene Termine dafür geschaffen werden, z.B. solche in denen man gemeinsam die eigenen technischen und organisatorischen Schulden begutachtet. Das Ergebnis ist eine Verankerung der Themen im kollektiven Gedächtnis der Organisation.


Um langsam zum Schluss zu kommen - heisst das, dass man die Prozessautomatisierung doch wieder seinlassen soll? Natürlich nicht, und die bisher genannten Beispiele verleiten auch nicht dazu. Repetitive Tätigkeiten sollen (bzw. müssen) weiterhin automatisiert werden wenn Agilität das Ziel ist, das bleibt unverändert. Eine "Ent-Automatisierung" lohnt sich aber trotzdem, vor allem bei vielen Datenerhebungen, um so Probleme offensichtlich zu machen und Lösungsfindungen anzustossen.


Genau so ist es zu verstehen wenn "Automate all the Things!" hinterfragt wird. Nicht als Generalkritik sondern als Aufruf dieses Mittel nur bewusst einzusetzen - oder dort wo es weniger Sinn macht eben nicht. Schliesslich ergeben sich Beweglichkeit und Reaktionsfähigkeit nicht nur durch Geschwindigkeit sondern auch regelmässige Entschleunigung an den zur Reflektion vorgesehenen Punkten.

Montag, 4. Oktober 2021

Stacey Matrix (II)

Noch einmal ein paar Worte zur Stacey Matrix, jenem Analyse-Werkzeug des Organisationsforschers Ralph D. Stacey, mit dessen Hilfe meistens versucht wird Sachverhalte als einfach, kompliziert, komplex oder chaotisch einzuordnen. Wie an anderer Stelle geschrieben sind die meisten Anwender in einem Irrtum gefangen - was sie nutzen ist nicht die eigentliche Stacey Matrix sondern nur ihre vereinfachte Version, die Stacey-Zimmermann-Matrix. Das Original ist weitgehend unbekannt.


Der Grund für diese relative Unbekanntheit dürfte sein, dass Stacey's Orginalversion (zu finden u.a. bei Dave Snowden) wesentlich detaillierter und differenzierter ist und damit auch schwerer zu erklären und zu verstehen. Der grobe Aufbau ist zwar ähnlich, je nachdem wo in der Matrix man sich befindet kann die Analyse aber eine andere sein als in der Zimmermann-Ableitung. Selbst die Bezeichnung der Achsen ist eine etwas andere, um Stacey's Orginal zu verstehen sollte man daher nochmal neu beginnen.


Um auch direkt mit den Achsen zu anzufangen - statt "Was" und "Wie" wie in der vereinfachten Version heissen sie ursprünglich Agreement (gemeinsames Verständnis des Sachverhalts) und Certainty (Sicherheit darüber welche Handlungsoptionen gegeben sind). Beide Variablen sind in der unteren linken Ecke am höchsten, sinken aber mit zunehmendem Abstand zu diesem Punkt kontinuierlich ab, bis sie am Ende der jeweiligen Linien nicht mehr gegeben sind.


In der Anwendung folgt daraus, dass dort wo sich die Variablen mit hohen Werten überschneiden (links unten) eine technisch-rationale Entscheidungsfindung und technisch-rationale Kontrollmechanismen möglich sind. Die (nähere) Zukunft ist hier prognostizierbar und planbar, der Umsetzungsfortschritt ist messbar. Zu finden sind solche Situationen dort wo es standardisierte Abläufe und nur wenige Störungen und Änderungen gibt, etwa in der Serienfertigung oder in Call-Centern.


Komplizierter wird es dort wo die Variablen auseinandergehen. Eine hohe Sicherheit über die möglichen Handlungsoptionen bei geringerem Verständnis darüber welche richtig sind führt zu politischem Verhalten (Mitte links). Es wird nötig Bündnisse mit den Vertretern ähnlicher und kompatibler Standpunkte einzugehen, meistens mit der Folge, dass das weitere Vorgehen auf einem Kompromiss beruht, der schlimmstenfalls halbherzige oder unvollständige Umsetzungen nach sich zieht.


Umgekehrt führen eine geringere Sicherheit über die möglichen Handlungsoptionen bei hohem gemeinsamen Verständnis über über das richtige Ziel zu eher subjektiver Entscheidungsfindung (untere Mitte). Die Auswahl der nächsten Schritte beruht in solchen Kontexten auf Glaubenssätzen und Methodismus, überprüft wird eher die Methodentreue als die Sinnhaftigkeit. Schlimmstenfallskann so eine "Entsachlichung" und Emotionalisierung der Diskussionen stattfinden.


Jenseits dieser beiden nebeneinanderliegenden Sektoren liegt die Komplexitätszone, die sich von links oben nach rechts unten durch die Matrix zieht. Auch in ihr gebt es Unterschiede: geringe Übereinstimmung bei hoher Sicherheit verleitet zu Bauchentscheidungen und sprunghaftem Verhalten, hohe Sicherheit bei geringer Übereinstimmung ermöglicht kontrollierte Überprüf- und Lernprozesse, mit dem Ziel auf diesem Weg die beste Lösung zu finden.


Oben rechts befindet sich schliesslich die chaotische Zone, in der ein strukturiertes Vorgehen nicht mehr möglich ist. Selbst hier gibt es aber noch Unterschiede - ein Rest an Sicherheit über mögliche Handlungsoptionen bei gleichzeitiger völliger Uneinigkeit lässt Systeme zerfallen, ein Rest an Übereinstimmungen bei gleichzeitigem Fehlen von Handlungssicherheit ermöglicht zumindest eine letzte gemeinsame Kraftanstrengung mit dem Ziel dem Chaos irgendwie zu entkommen.


Was bei dieser Betrachtung der ursprünglichen Stacey Matrix klar wird ist das Ausmass der Vereinfachung, dass die Umwandlung in die Zimmermann-Variante mit sich gebracht hat. Weder sind im Original Einfach, Kompliziert und Komplex als einheitliche Blöcke zu finden, noch lassen sich methodische Ansätze grossflächig zuordnen. Die agilen Frameworks machen beispielsweise nur unten rechts Sinn, nicht im gesamten mittleren Bereich.


Damit soll nicht gesagt werden, dass die Zimmermann-Variante schlecht ist, aufgrund ihrer Einfachheit und Übersichtlichkeit eignet sie sich gut als Einstieg in eine Beschäftigung mit den Themen Kompliziertheit und Komplexität. Sobald diese Beschäftigung vertieft werden soll ist es aber sinnvoll dazu die Original-Matrix zu nehmen, so wie sie von Ralph D. Stacey erfunden wurde.