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.

Donnerstag, 30. September 2021

Kommentierte Links (LXXVIV)

Grafik: Pixabay / The Digital Artist - CC0 1.0
Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Gergely Orosz: How Big Tech Runs Tech Projects and the Curious Absence of Scrum

Dieser Artikel ist auf mehreren Ebenen interessant. Zunächst deshalb weil er (allerdings basierend auf einer relativ kleinen empirischen Basis) belegt was immer wieder kolportiert wird: die grossen amerikanischen Tech-Firmen wie Google, Amazon und Netflix haben kaum Teams die nach einem der gängigen agilen Frameworks (v.a. Scrum) organisiert sind. Nicht etwa weil sie nicht agil arbeiten, ganz im Gegenteil. Die Agilität äussert sich hier aber anders - u.a. durch flache Hierarchien oberhalb der Teams, enge Verzahnung von IT und Business, Verzicht auf hauptberufliche Projektmanager, technische Exzellenz und hohen Automatisierungsgrad. Die zweite interessante Ebene ist eine drastische Fehlinterpretation von Scrum, in der man nur am Sprintende auf Produktion releasen darf, mit dem Product Owner als verlangsamendem Flaschenhals. Durch Kombination der beiden Aspekte erklärt sich die Scrum-Aversion im "Big Tech": wenn Scrum bürokratisch und schwergewichtig interpretiert wird und gleichzeitig eine Unternehmens- und Technologie-Struktur gegeben ist die auch "normalen" Teams Framework-unabhängige Agilität ermöglicht, dann ist es fast zwangsläufig, dass niemand nach Scrum arbeiten möchte. Spannend wäre es zu erfahren woher die Fehlinterpretation kommt.

Longqi Yang, David Holtz, Sonia Jaffe, Siddharth Suri, Shilpi Sinha, Jeffrey Weston, Connor Joyce, Neha Shah, Kevin Sherman, Brent Hecht & Jaime Teevan: The effects of remote work on collaboration among information workers

Weiter geht es mit einer Studie die eine etwas grössere empirische Basis hat. Dieser Artikel aus dem Magazin Nature Human Behaviour basiert auf der Auswertung der Arbeit von 61.000 Microsoft-Angestellten aus dem Jahr 2020 und zeichnet einmal mehr das Remote-Produktivitäts-Paradox nach. Durch den Wegfall von Pendelzeiten und Ablenkungen ging der Anteil der "persönlichen Produktivität" an der gesamten Arbeitszeit hoch, gleichzeitig führte das Fehlen der täglichen Begegnung (in Kantine, Aufzug, o.Ä.) aber dazu, dass sich die sozialen Netzwerke in der Firma zurückbildeten. Infolge dessen wurde es immer schwieriger zu erkennen an wen man sich bei Informationsbedarf oder Abhängigkeiten zu anderen Organisationseinheiten zu wenden hatte, die Kommunikation wurde ineffizient und ineffektiv, die Gesamtproduktivität der Firma ging zurück. Es ist zu hoffen, dass diese Untersuchung in eine langlaufende Vergleichsstudie zwischen Präsenz- und Remote-Teams überführt wird (und noch weitere stattfinden). Damit würde es möglich die bisher sehr stark von Vermutungen und Glaubenssätzen ausgehende Diskussion um die Folgen der Remote-Arbeit zu versachlichen.

Jurgen Appelo: Objectives and Key Results in Flow

Jurgen Appelo hat sich bereits einige Methoden-Mashups einfallen lassen, z.B. den Innovation Vortex oder den Change Dynamo. Seine neueste Schöpfung sind die "flOwKRs", in die er nicht nur Flow (Kanban) und Objectives and Key Results (OKRs) sondern auch Management by Objectives (MBO), Key Performance Indicators (KPIs), SMART-Kriterien, North Star Metric (NSM), Big Hairy Audacious Goals (BHAG), Evidence-Based Management (EBM) und Fitness for Purpose (F4P) integriert hat. Wie bei seinen anderen jüngeren Ideen ist auch hier eine Nacherzählung oder Zusammenfassung schwierig, nicht nur wegen der inhaltlichen Vielschichtigkeit sondern auch weil das Ganze einen Teil seines Charmes durch die im Text eingebetteten schreiend bunten Visualisierungen gewinnt. Es empfiehlt sich daher ein Blick auf den Originaltext, aus dem man reichlich Inspiration gewinnen kann.

Tim Theman: Warum viele Meetings nicht asynchron durchgeführt werden können – und wie es vielleicht doch geht

Apropos Mashups - die These die Tim Theman hier aufstellt ist eine die ich voll unterstützen kann: dass es gerade im Rahmen von Remote-Arbeit bei vielen Meetings extrem schwer zu entscheiden ist, ob sie wirklich als solche stattfinden oder in asynchrone (schriftliche) Kommunikation überführt werden sollten, liegt daran, dass sie meistens so verschiedene Themen umfassen, dass für diese auch verschiedene Durchführungsformen sinnvoll sind. Sobald das einmal als Problem erkannt ist liegt auch die Lösung auf der Hand - statt zu versuchen alle Inhalte in ein und das selbe Format zu pressen kann man sie auch aufteilen und unterschiedlich behandeln, z.B. mit Newslettern für allgemeine Informationen, Online-Foren für Verständnisfragen und Meetings (bzw. Video-Calls) für Diskussionen. Meine persönliche These ist, dass es ein noch tiefer liegendes Grundproblem gibt: durch die gut gemeinte Absicht möglichst viel Zeit für die "richtige Arbeit" zu haben richten viele Teams und Unternehmen nur wenige Sammeltermine für Meetings ein, z.B. eine einzige wöchentliche Team- oder Abteilungsrunde. Dass es in denen dann inhaltlich durcheinandergeht ist klar. Was in solchen Situationen als Lösung sinnvoll ist (und im hier verlinkten Artikel aufgegriffen wird) ist eine "Entklumpung" der Themen, ggf. verbunden mit den erwähnten jeweils angepassten Arten der Durchführung.

Nicolas M. Chaillan: It is time to say Goodbye!

Zum Abschluss ein Abschied. Selbst in der oft titelfixierten Welt der Grossorganisationen dürfte die Berufsbezeichnung von Nicolas Chaillan Aufsehen erregt haben - er ist "First U.S. Air Force and Space Force Chief Software Officer". Ebenfalls Aufsehen erregend ist der Grund für seinen Abschiedsbrief: es ist das permanente Ausbremsen und Kaputtsparen von agiler Softwareentwicklung in der amerikanischen Militär-IT. Selbst wenn dieses Umfeld einzigartig ist, die Probleme die er mit bemerkenswerter Offenheit anspricht sind es nicht. Eine lesenswerte Auflistung von Hindernissen mit denen sehr viele agile Transitionen zu kämpfen haben.

Montag, 27. September 2021

The Missing Link: Extreme Programming

Als Fan des Extreme Programming (XP) freut es mich jedesmal wieder wenn dieses Framework öffentlichkeitswirksam in den Mittelpunkt gerückt wird, gerade auch deshalb weil das mittlerweile nur noch relativ selten passiert. Den Vortrag "Putting the XP in Scrum" von Roy Osherove kann ich daher nur empfehlen.



Interessant ist bei seinen Ausführungen die Einordnung. Für ihn besteht agile Softwareentwicklung aus zwei Elementen: dem aus Scrum abgeleiteten iterativ-incrementellen Prozess und der aus DevOps übernommenen Nutzung automatisierter Build-Pipelines. Da Extreme Programming sowohl einen mit Scrum kompatiblen Prozess-Anteil als auch mit DevOps verwandte Entwicklungspraktiken hat ist es für Osherove der "missing Link", der die beiden anderen Ansätze miteinander verbindet.

Donnerstag, 23. September 2021

Worst Scrum ever!

Bild: Pexels / Karolina Grabowska - CC0 1.0

Nach über 10 Jahren als Scrum Master, Agile Coach und in anderen "agilen Rollen" ist so einiges an Erfahrungen zusammengekommen die ich mit der Zeit gemacht habe, sowohl im Guten als auch im Schlechten. Basierend darauf gibt es eine Frage die mir immer wieder gestellt wird: ob es eine erkennbar schlimmste Umsetzung von Scrum unter denen gegeben hat die ich erlebt habe. Und tatsächlich gibt es sie, die eine die so übel war, dass sie wirklich aus allem heraussticht. Haltet Euch fest.


Der Kunde war ein Mittelständler aus Süddeutschland. Scrum war dort ein Jahr zuvor von einer grossen, mit A beginnenden Unternehmensberatung eingeführt und als revolutionäre Prozess-Optimierung angekündigt worden. In der Wahrnehmung des oberen Managements liessen die sichtbaren Verbesserungen aber auf sich warten, weshalb ein externer Experte (ich) überprüfen sollte ob das Vorgehen tatsächlich so umgesetzt wurde wie gedacht. Ich begann entlang der Wertschöpfungskette.


Die erste Überraschung erwartete mich gleich zu Beginn, denn am Anfang der Wertschöpfungskette befand sich eine Fachabteilung die ein Lastenheft verfasste, also eines jener Telefonbuch-dicken Dokumente die alles an Wünschen enthalten was der beauftragenden Einheit sinnvoll erscheint. Nichts davon war durch Marktforschung oder Kundenfeedback validiert, nichts davon war durch eine Machbarkeitsanalyse oder eine Aufwandsschätzung gegangen.


Dieses Lastenheft ging im nächsten Schritt an das Anforderungsmanagement, das den Auftrag hatte es in User Stories herunterzubrechen. Die Unternehmensberatung mit A hatte dafür eine Anleitung hinterlassen, der zufolge alle User Stories mit "als User möchte ich" beginnen mussten (der Zwecksatz fehlte dagegegen) und klein genug sein mussten um von einem einzigen Entwickler in einem Tag umgesetzt werden zu können.


Um dieses Anforderungsmanagement zu Höchstleitungen anzuspornen wurde seine Leistung an der Menge der geschriebenen User Stories gemessen. Um möglichst viele erzeugen zu können wurden diese folgerichtig noch kleiner als gefordert, zwei an die ich mich erinnern kann waren "Als User möchte ich, dass sich das Dropdown-Menue öffnet wenn man es anklickt" und "Als User möchte ich, dass das geöffnete Dropdown-Menue anklickbare Items enthält". Insgesamt waren es tausende.


Die so verfassten User Stories gingen als nächstes in das so genannte "Planning I", in dem der IT-Chef und die Architekten sie auf einen Zeitstrahl verteilten, der bis weit in das nächste Jahr hineinreichte. Aufgrund der schieren Masse (nochmal: tausende) wurden dabei nicht alle genau angeschaut, das Hauptkriterium war, dass ungefähr gleich viele in jedem Monat landeten. "Langfristig mittelt sich das", wurde als Begründung für dieses Vorgehen genannt.


Kurz vor Beginn eines Monats (der hier einem Sprint entsprach) folgte jeweils das "Planning II". Die Architekten und der in diesem Moment erstmals beteiligte Product Owner schätzten für jede der für diesen Monat eingeplanten User Stories den Aufwand und entschieden welchem Entwickler sie zugewiesen werden würden. Zusätzlich dazu verfassten sie neue User Stories für dringende Bugs ("Als PO möchte ich, dass Bugticket XY im nächsten Sprint gefixt wird") und wiesen auch die zu.


Am ersten Arbeitstag des Monats, bzw. Sprints folgte schliesslich das "Planning III". In dem wurde nacheinander jeder Entwickler in einen Raum gebeten in dem er von dem PO, den Architekten und seinem Abteilungsleiter (diese Rolle war in Personalunion auch Scrum Master) erwartet wurde. Dieses Kommittee erklärte dem einzeln vor ihm stehenden Entwickler welche Arbeit für ihn eingeplant war, erlaubte es ihm Verständnisfragen zu stellen und forderte ihn auf die Lieferung zuzusagen.


Dass diese Zusage auch eingehalten wurde, wurde im Sprint in den Daily Scrums sichergestellt. Die Scrum Teams (jeweils 15 bis 25 Entwickler) versammelten sich in einem Raum, der Abteilungsleiter/Scrum Master filterte das digitale Sprint Backlog nach Bearbeitern und forderte nacheinander jeden auf vorzutreten und einen Statusbericht abzugeben. Da dieser Termin länger als eine Stunde war konnte jeder direkt nach seinem Bericht zurück an die Arbeit, um so produktiver zu sein.


Erfahrungsgemäss zeigte sich in den meisten Sprints etwa in ihrer Mitte, dass sie zu optimistisch geplant waren. Um das auszugleichen forderten die Abteilungsleiter/Scrum Master die Entwickler zu Überstunden auf oder verschoben User Stories zu anderen die noch nicht im Rückstand waren. Neu entdeckte Bugs wurden in das "Bug Backlog" verschoben, aus dem alle die nicht dringend waren in einem der halbjährlich stattfinden "Bugfixing-Sprints" eingeplant wurden.


Im am Ende des Sprints stattfindenden Review Meeting überprüften die Architekten, die Product Owner und die Abteilungsleiter/Scrum Master ob alle User Stories wie geplant fertiggestellt worden waren, falls das nicht der Fall war konnten einzelne Entwickler in dem Raum geholt werden um ihren Rückstand zu erklären. Die Ergebnisse des Reviews wurden im Anschluss schriftlich dem Steuerungskommittee mitgeteilt, in dem u.a. der IT-Chef und die beauftragende Fachabteilung sassen.


Retrospektiven gab es keine. Sie hatten wohl früher stattgefunden, waren aber wegen Ineffektivität wieder abgeschafft worden.


Wie man sich denken kann konnte ich bereits nach wenigen Tagen mit einer umfangreichen Liste an identifizierten Missständen und konkreten Handlungsempfehlungen aufwarten. Ich hatte schon geahnt, dass sie keine Begeisterung auslösen würden, und genau so kam es. Ich sollte doch stattdessen bitte "pragmatische Lösungen" erarbeiten, die ohne grundlegendes Infragestellen der bestehenden Prozesse umsetzbar wären. Das wollte ich nicht, und als Folge dessen beendete die Firma unsere Zusammenarbeit.


Und das ist sie, die Geschichte der schlimmsten Umsetzung von Scrum die ich jemals erlebt habe. Ich habe später noch mitbekommen, dass in den folgenden Monaten über die Hälfte der Angestellten aus der IT gekündigt hat und dass weitere Unternehmensberatungen beauftragt wurden. Ob es eine Moral gibt die man daraus ziehen kann weiss ich nicht, vielleicht ist es diese hier: egal wie vermurkst Dir Deine agile Transformation erscheinen mag - irgendwo ist es schlimmer.