Kommentierte Links (LXXXIII)

Bild: Pixabay / Buffik - Lizenz

Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" aber trotzdem lesenswerten Texte aus dem letzten Jahr.

Colin M. Fisher, Teresa M. Amabile, Julianna Pillemer: How to Help (Without Micromanaging)

"Ich wollte doch nur helfen" dürfte die häufigste Entschuldigung von Managern sein wenn ihre Untergebenen sich über übergriffiges Micromanagement beschweren. Man kann davon ausgehen, dass das in den meisten Fällen tatsächlich die zugrundeliegende Motivation ist, trotzdem liegt oft am Ende das Vertrauensverhältnis in Trümmern. Wie eine Konstellation aussieht in der eine Hilfestellung auch als eine solche empfunden wird arbeiten Colin M. Fisher, Teresa M. Amabile und Julianna Pillemer anhand von Fallstudien heraus: demjenigen dem geholfen wird muss klar sein, dass er alleine nicht weiterkommt, es muss bereits vor dem Hilfsangebot psychologische Sicherheit vorhanden sein und die Hilfe muss sich an der Verfügbarkeit und Aufnahmebereitschaft desjenigen dem geholfen wird ausrichten.

Emily Webber: Building a progression framework for a multidisciplinary organisation

Zu den grössten Herausforderungen vor denen agil arbeitende Organisationen stehen gehört die Entwicklung eines beruflichen Karriere-Modells. Klassische Karrierepfade stehen durch ihre Linearität und ihre Einbettung in organisatorische Silos im Widerspruch zum agilen Zielbild, die häufig anzutreffende "agile Alternative" einer Fachkarriere ohne feste Abteilungs-Zuordnung macht es dagegen schwer Weiterentwicklungen zu erkennen (und zu belohnen). Das von Emily Webber entwickelte Modell von Citizens Advice versucht beides möglich zu machen, mit einem Ansatz der die klassischen Junior/Mid-Weight/Senior-Pfade beibehält, es aber möglich macht mehrere parallel zu verfolgen und zwischen ihnen zu wechseln (hier ein Erfahrungsbericht der Einführung). Eine schöne Inspiration für ähnliche Versuche.

Simon Pitt: How IT Stopped Being Boring

In der allgemeinen Wahrnehmung ist die IT etwas noch immer Neues, Junges und Modernes. Was bei dieser (oberflächlichen) Betrachtung allerdings untergeht ist, dass auch dieser scheinbar moderne Zweig der Technik bereits mehr als ein halbes Jahrhundert alt ist. Diese lange Geschichte führt dazu, dass in den einstigen Pionier-Branchen (Telekommunikation, Banken, Versicherungen) mittlerweile Generationenkonflikte stattfinden, und zwar sowohl zwischen älteren und jüngeren Mitarbeitern als auch zwischen älteren und neueren Technologien. Am Beispiel eines fiktiven Systemadministrators erzählt Simon Pitt davon wie dieser Konflikt ausgetragen wird und die Arbeitswelt verändert.

Diana Kwon: Our Brain Typically Overlooks This Brilliant Problem-Solving Strategy

Es ist eine Erkenntnis die weitreichende Auswirkungen darauf hat wie Menschen Problemlösungen angehen sollten und darauf wie die Wirksamkeit dieser Lösungsbemühungen bewertet werden sollte: das menschliche Gehirn scheint eine natürliche Tendenz zu haben Problemlösungsstrategien darauf aufzubauen, dass dem problembehafteten Objekt etwas hinzugefügt wird - Features, Kontextinformationen, Restriktionen, Benutzergruppen, etc. Das findet selbst dann statt, wenn die gegenteilige Vorgehensweise, also das Weglassen sinvoller wäre. Diana Kwon fasst in diesem Text zusammen wie Forscher der Universität von Virginia diese Erkenntnis gewonnen haben, wer die Studie im Original lesen will findet sie hier.

Gaëtan Belbeoc'h: Tribal Leadership Techniques Through the Eyes of an Agilist

Seit Henrik Kniberg die Tribe-Organisation von Spotify bekannt gemacht hat ist die Wortwahl mit der über agile Skalierung gesprochen wird eine andere, bis zu dem Punkt, dass man das Gefühl haben kann mit einer Gruppe Ethnologen zu reden. Naheliegenderweise könnte man denken, dass auch einige echte Vertreter dieser Berufsgruppe in den Diskurs einbezogen werden sollten, doch das ist noch nicht passiert - bis jetzt. Gaëtan Belbeoc'h hat ein Jahr Feldforschung unter Eingeborenenvölkern am Amazonas betrieben und zusammengefasst welche Parallelen es zwischen ihrer Selbstorganisation und der in agilen Teams gibt. Spoiler: es sind einige.

Jessica Kerr: Those pesky pull request reviews

Ein eher technisches Thema. Pull Requests (Anfragen an einen anderen Entwickler neuen Code zu begutachten und freizugeben) sind in vielen Firmen verpflichtender Teil des Software-Entwicklungsprozesses und werden oft als State of the Art angesehen. Jessica Kerr hat da eine andere Meinung. Tatsächlich kann man die Probleme die sie beschreibt häufig beobachten: (zu lange) auf Freigabe wartende Arbeitspakete, Kontext-Switching zwischen eigener Arbeit und dem Reviewen von anderem Code, dadurch gestörte Konzentration, zwischenmenschliche Konflikte und vieles mehr können zu Ineffizienz, nachlassendem Engagement und schlechterem Betriebsklima führen. Die von ihr vorgeschlagene Alternative ist ein Klassiker unter den agilen Praktiken: Pair- und Mob-Programming.

Makoto Shiraishi, Hironori Washizaki, Daisuke Saito, Yoshiaki Fukazawa: Comparing Participants’ Brainwaves During Solo, Pair, and Mob Programming

Apropos Pair Programming. Auch diese Praktiken sind mittlerweile zum Gegenstand wissenschaftlicher Untersuchungen geworden, in diesem Fall in der Psychologie. In einem leicht nach Science Fiction klingenden Experiment wurden Softwareentwickler während der Durchführung von Solo-, Pair- und Mob-Programming an ein Gerät zur Messung von Gehirnaktivitäten angeschlossen. Die Ergebnisse: während Ruhezustände vor allem im Solo-Programming vorkamen führten Pair- und Mob-Programming zu höherer Konzentration und geringerem Schwierigkeitsempfinden. Die durchführenden Forscher geben selbst an, dass die Ergebnisse vor allem ein Anstoss zu weiterer Forschung sind, interessant sind sie aber auf jeden Fall.

Ellen Cushing: Slackers of the World, Unite!

Obwohl sich dieser Artikel von Ellen Cushing vor allem auf Slack bezieht lassen sich seine zentralen Punkte auch auf vergleichbare Dienste übertragen, z.B. auf HipChat oder MS Teams. Neben einer Optik und Bedienbarkeit die sich stark an Social Networks anlehnt und damit für eine niedrige Eingangshürde sorgt nennt sie vor allem die Dezentralität, Hierarchiefreiheit und allgemeine Zugänglichkeit. Abgeleitet daraus erkennt sie eine sehr starke Demokratisierung und Egalisierung der Kommunikation in allen Unternehmen die diese Programme bei sich einsetzen. Ein klarer Fall von "Function follows Form", den jeder bestätigen kann der schon einmal mit Slack & Co gearbeitet hat.

Kommentierte Links (LXXXII)

Grafik: Pixabay / The Digital Artist - Lizenz

Leicht verfrüht: die Kommentierten Links des Dezembers zu interessanten, kontroversen, tiefgründigen oder aus anderen Gründen lesenswerten Artikeln. Am letzten Tag dieses Monats folgt wie in den letzten Jahren eine weitere Ausgabe, dann mit den Artikeln die es zu Unrecht nicht in die Kommentierten Links der vergangenen Monate geschafft haben.

Marty Cagan: Product Ops Overview

Dieser Artikel ist Fortsetzung von Marty Cagans Process People-Debattenbeitrag vom letzten Oktober, der wegen seiner sehr kritischen Ausrichtung gegenüber der Product Ops-Bewegung zu einem kleinen Sturm im Produktmanagement-Wasserglas geführt hat. Bereits damals hatte er angekündigt seine Aussagen auszudifferenzieren und aufzuzeigen, dass es sowohl hilfreiche als auch schädliche Varianten gibt, hier ist jetzt das Ergebnis. Welche dieser Varianten sich langfristig als (mehr oder weniger) verbindliche Definition von Product Ops durchsetzen wird bleibt abzuwarten, als Momentaufnahme ist seine Übersicht aber hochinteressant.

Tim Ottinger: Managing Interruptions

Das was Tim Ottinger hier festgehalten hat ist eine überraschend naheliegende aber trotzdem im Prozess- oder Projektmanagement eher seltene Begründung dafür, dass man parallele Arbeit vermeiden sollte: dadurch dass mit jeder weiteren parallel durchgeführten Arbeit die Zahl der am Fortschritt interessierten Stakeholder steigt, steigt auch die Zahl der Störungen und Unterbrechungen denen man ausgesetzt ist, da immer mehr Menschen sich nach Zwischenständen erkundigen. Da diese Unterbrechungen Zeit in Anspruch nehmen und die Konzentration stören verlangsamt der Fortschritt sich. Das kann eigentlich keiner wollen.

Bob Marshall: All Agilists Are Unethical

An dieser Stelle folgt ein kurzer Exkurs in die Philosophie. Aufbauend auf den "Ethics of Belief" von William Kingdon Clifford ("It is wrong always, everywhere, and for anyone, to believe anything upon insufficient evidence") greift Bob Marshall einen der am häufigsten diskutierten Kritikpunkte an der agilen Produktentwicklung auf: es gibt kaum empirische Belege für ihre grundsätzliche Überlegenheit über die "klassischen Ansätze" (mehr dazu hier), weshalb man jeden Einzelfall gesondert betrachten muss. Diese Einzelfallbetrachtungen vermisst Marshall in den von ihm beobachteten agilen Transitionen, weshalb er ihnen (angelehnt an Clifford) unethische Beweggründe unterstellt. Ironischerweise wären auch seine eigenen Ausführungen bei konsequenter Anwendung der Ethics of Belief unethisch (da lediglich auf subjektiver Wahrnehmung beruhend), ein guter Denkanstoss sind sie aber trotzdem.

Karl Scotland: How to Measure the Predictability of Agile

Der Titel dieses Artikels ist leider etwas missverständlich. Anders als man ausgehend von ihm denken könnte beschreibt Karl Scotland hier nicht wie vorhersagbar Agilität ist (was alleine schon semantisch und grammatisch ein Ding der Unmöglichkeit ist) sondern welche Indikatoren Rückschlüsse darauf zulassen, dass die Anwendung agiler Praktiken und Frameworks zu Prozessverbesserungen geführt hat. Wichtig dabei ist, dass es sich bei den von ihm gesammelten Beispielen nicht um generalistisch anwendbare Regeln und Beweise handelt sondern eben um das was Indikatoren sind - hilfreiche Hinweise, die aber noch zusätzlicher Validierung bedürfen. Als solche verstanden können sie aber dazu beitragen den Erfolg agiler Transitionen überprüfbar zu machen.

Matt Philip: Kanban Myths

Dass Kanban als "Open Source-Methode" kein wirkliches Richtig und Falsch kennt hatte ich schon einmal aufgeschrieben, Auflistungen von "Kanban-Mythen" sollte man immer mit diesem Vorbehalt im Hinterkopf lesen. Trotzdem haben die von Matt Philip aufgeführten Punkte aber ihre Berechtigung, schliesslich sind sie so unsinnig, dass sie auch bei wohlwollender Betrachtung keinen Sinn ergeben. Um so bemerkenswerter ist ihre Verbreitung, jeder dieser Mythen ist auch mir bereits wiederholt begegnet.

An Agile Little Christmas

Lieder von Chad Beier habe ich schon zwei mal hier eingebunden, jeweils mit "agilen Coverversionen" von zeitlosen Pop/Rock-Klassikern. Auch dieses hier ist im Original zeitlos (Have Yourself a Merry Little Christmas von Judy Garland, bzw. von Frank Sinatra) in dieser Version aber wieder so umgedichtet, dass ein Bezug zur agilen Softwareentwicklung besteht.

Selbst wenn die Eingängigkeit ein bisschen dadurch verloren geht, dass die Ursprungsversion in Deutschland bei weitem nicht so bekannt ist wie in den USA, kann man sich das Ergebnis gut anhören. Und mit seinem Rauschebart wirkt Beier im Video auch sehr wie ein Weihnachtsmann.

North Star Metrics

Grafik: Pixabay / 5718714 - Lizenz

Die Idee sich auf ein einziges Ziel zu konzentrieren und focussiert daran zu arbeiten zieht sich durch zahlreiche Lean und Agile-Frameworks und findet sich u.a. in Sprint- und Produktzielen, im Single Piece-Flow, in OKRs oder in Work in Progress-Limits wieder. Wenn der Gegenstand dieser Focussierung ein schnell umsetzbares Arbeitspaket oder Nahziel ist kann man sich die Umsetzung auch gut vorstellen, aber wie würde das bei Fern- oder Dauerzielen gehen? Ein Ansatz sind die so genannten North Star Metrics.

Die dahinter stehende Idee ist es, eine einzige Messgrösse zu finden, die von so zentraler Bedeutung für die gesamte Organisation ist, dass ihre Optimierung Vorrang vor allem anderen hat. Das funktioniert natürlich nur dort, wo es ein klar umrissenes Geschäftsfeld gibt, das sich auf ein klar definertes Produkt (oder eine klar definierte Dienstleistung) ausrichtet, aber dort kann es ein interessanter Weg sein um focussiertes datengetriebenes Arbeiten zu ermöglichen.

Um Beispiele zu nennen: in Vermittlungsplattformen wie AirBnB oder MyHammer, die an jedem zustandegekommenen Geschäft mitverdienen, ist die Anzahl zustandegekommener Vermittlungen entscheidend. Lieferdienste wie die von Picnic und Rewe haben dagegen ein Interesse an möglichst grossen Warenkörben, um die Logistikkosten gering zu halten. Und für Social Networks wie Instagram und Twitter ist entscheidend wie viele Nutzer täglich durch Likes oder Shares interagieren.

Dort, wo derartige Zahlen den Nordstern bilden, an dem sich alles ausrichtet, kann eine ganze Reihe von Vorteilen genutzt werden. Zunächst helfen sie bei Investitionsentscheidungen: wenn es darum geht, wo ein zur Verfügung stehendes Optimierungs-Budget am besten eingesetzt werden sollte, können z.B. alle Einheiten oder Systeme nachrangig behandelt werden, die diese zentralen Werte nicht beeinflussen können. Und bei denen die es können kann überlegt werden wo die grösste Wirkung möglich ist

Sie helfen offensichtlicherweise auch bei der Erfolgsmessung. Bei jedem der weiter oben genannten Beispiele kann jederzeit überprüft werden ob die Zahlen stabil bleiben, zunehmen oder abnehmen. Und dadurch, dass sie schnell (ggf. sogar in Echtzeit) erhebbar sind ist auch ein schnelles Inspect & Adapt möglich wenn sie sich nicht so entwickeln wie gewünscht oder geplant. Auch eine wirtschaftliche Betrachtung kann stattfinden, indem man prüft wieviel welche Verbesserung gekostet hat.

Zuletzt können North Star Metrics intern wesentlich dazu beitragen, dass die Mitarbeiter die Ausrichtung des eigenen Unternehmens verstehen und ihre eigene Tätigkeit darauf ausrichten. Vor allem dort wo mit autonomen und agilen Teams gearbeitet wird, ist es kaum noch möglich, zentral zu steuern, woran im Tagesgeschäft gearbeitet wird, mit Hilfe des über allem schwebenden Leitsterns können die Teams aber selbst erkennen wie zielführend ihre Arbeit gerade ist.

Wie dieser Ansatz im jeweiligen Einzelfall umgesetzt wird kann (und muss) je nach Fall unterschiedlich sein, da auch die jeweiligen Unternehmen und Produkte unterschiedlich sind. Eine naheliegende Variante ist aber die Kombination mit OKRs. Es gibt auch Versuche ein eigenständiges North Star Framework zu entwickeln, das aber noch in seinen Anfängen steckt und wenig verbreitet ist. Vielleicht entwickelt sich aber hier noch etwas. Man sollte es im Auge behalten.

The agile Bookshelf: The (Delicate) Art of Bureaucracy

Bild: Pexels / Vlada Karpovic - Lizenz

Wer mal wieder nach einem Geschenk für irgendeinen im Dunstkreis der Agilität arbeitenden Menschen sucht kann dieses Buch ins Auge fassen: The (Delicate) Art of Bureaucracy von Mark Schwartz bringt das Kunststück fertig das auf den ersten Einruck unspannenste aller Themen - die Bürokratie - so aufzubereiten, dass es nicht nur informativ sondern sogar unterhaltsam ist. Und zahlreiche Bezüge zu agiler Produktentwicklung und DevOps gibt es obendrauf.

Was Schwartz schon früh unmissverständlich festellt ist, dass die Bürokratie durchaus ihren Zweck hat. Spätestens bei Grossunternehmen und -behörden mit tausenden von Mitarbeitern ist es unumgänglich Rollen zu vergeben, Verantwortlichkeiten festzuleen, Abläufe zu definieren und Hierarchien aufzubauen. Würde das unterbleiben wären diese Organisationen (genau wie die meisten kleineren) von Anfang an nicht handlungsfähig.

Auch wie es zu der Entartung dieser eigentlich sinnvollen Strukturen in Regel- und Dienstweg-Fetischismus kommt beschreibt er anschaulich, u.a. am Beispiel von Scrum Teams, die um ihre Sprints zu schützen dafür sorgen, dass Stakeholder nur noch einmal alle zwei Wochen mit ihnen interagieren können, und auch das nur in einem stark formalisierten Meeting-Format, dem Sprint Review. Derartige "versehentliche Bürokratisierungen" sind zwar gut gemeint, in den Auswirkungen aber schädlich.

Neben dem Scrum Framework (mit dessen Klassifizierung als Bürokratie er bei den meisten Scrum Mastern einen mittelschweren Schock auslösen dürfte) konzentriert er sich aber in erster Linie auf das was auch im Allgemeinverständnis als Bürokratie verstanden wird: die Arbeitswirklichkeit in Grossorganisationen, und hier speziell in der amerikanischen Einwanderungsbehörde, deren CIO er für einige Jahre gewesen ist und gegen deren rigide Regeln und Prozesse er in dieser Zeit ankämpfte.

Die Hintergründe für diese Auseinandersetzung dürften jedem der Politik und IT kennt bekannt vorkommen: auf der anderen Seite ein stetiger, durch äussere Umstände verursachter Handlungsdruck, auf der anderen Seite der verständliche Wunsch nach Sicherheit und Berechenbarkeit, der aber schnell zu Überregulierung führte. Um dieser zu entkommen entwickelte Schwartz drei Ansätze, den des Affen, den des Rasierers und den des Sumo-Ringers.

Der "Weg des Affen" ist inspieriert vom Chaos Monkey aus dem Chaos Engineering, einem Computer-Programm das ununterbrochen andere Programme Belastungsproben aussetzt um so Schwachstellen zu finden. In Analogie dazu besteht das Ziel darin, in den bürokratischen Regelungen Ausnahmen oder Regulierungslücken zu finden in denen man sich freier bewegen kann. Dass das nicht nur gegen sondern auch zusammen mit den Regelhütern stattfinden kann ergibt sich für ihn aus dem nächsten Ansatz.

Der "Weg des Rasierers" ist abgeleitet von Hanlon's Razor, einem Erkenntnismodell das von dem Grundsatz ausgeht nicht mit Bosheit erklären zu wollen was sich auch damit erklären lässt, dass dem Urheber die Konsequenzen seines Tuns nicht bewusst waren. Die daraus abgeleitete Prämisse ist, dass die Verfasser und Überwacher strikter Regeln gar kein Interesse daran haben andere zu behindern, man also durchaus vertrauensvoll mit ihnen zusammenarbeiten kann.

Der "Weg des Sumo-Ringers" basiert schliesslich auf einer Grundtechnik asiatischer Kampfsportarten, die daraus besteht die kinetische Energie eines stärkeren Gegners gegen ihn selbst zu verwenden. Auf die Bürokratiebekämpfung kann das übertragen werden indem man die Regulierung bestimmter Bereiche explizit untersagt und das zum Gegenstand regelmässiger Überprüfungen macht. Die Bürokratie richtet sich so gegen sich selbst und dämmt sich selbst ein.

Alleine diese Inhalte würden das Buch bereits lesenswert machen, es gibt aber noch eine zweite Ebene wegen der sich der Kauf lohnt, die erzählerische. Schwartz ist sehr gut darin trockene Sachverhalte durch Anekdoten und Analogien unterhaltsam zu machen, ausserdem zieht sich ein Feuerwerk an Zitaten und Referenzen durch das ganze Buch, von Franz Kafka und Herrman Melville über Napoleon, Georg Hegel, Karl Marx, Max Weber, Frederick Taylor und Peter Drucker bis hin zu Jeff Sutherland.

Wer diese grossen Denker und ihre Werke kennt wird übrigens schon ahnen auf welchen von ihnen ganz am Anfang und ganz am Ende verwiesen wird: auf Kafka, der mit "Der Prozess" den Bürokratie-Roman schlechthin geschrieben hat. Mark Schwartz hätte sich keine bessere Klammer für seine Ausführungen suchen können.

Langfristige Retrospektiven

Bild: Wikemedia Commons / Louis Moeller - Public Domain

Es ist eines der grossen Verdienste der agilen Frameworks (und im Besonderen von Scrum), dass sie mit den Retrospektiven einen regelmässig stattfindenden Rückblick-Termin auf die unmittelbar zurückliegende Vergangenheit etabliert haben. Erst durch sie wird Agilität im Sinn eines kontinuierlichen Inspect & Adapt möglich. Was in diesem Arbeitsmodus dagegen seltener stattfindet sind langfristigere Rückblicke. Schade eigentlich, denn langfristige Retrospektiven können in vielen Kontexten von Mehrwert sein. Hier sind einige von ihnen:

Zum Jahresende

Dieser Rhythmus macht vor allem da Sinn wo noch mit Jahresplanungen gearbeitet wird, deren Ergebnisse man gemeinsam unter die Lupe nehmen kann. Auch dort wo das nicht der Fall ist bietet es sich aber an, schliesslich ist der Jahreswechsel mit seinen Feiertagen eine Zäsur die sich für einen gemeinsamen Blick zurück anbietet. Im Normalfall sorgen diese Feiertage auch dafür, dass solche Retrospektiven nicht genau am Jahresende stattfinden sondern eher Mitte Dezember.

(Ungefähr) Halbjährlich

Der nächstkürzere Zeitraum, und direkt einer der etwas Anpassung und Erklärung benötigt. Auch im Sommer gibt es mit den Sommerferien, in denen die meisten Menschen in den Urlaub fahren, eine grosse Zäsur - allerdings liegen diese in der Regel bereits im dritten Quartal. In Kombination mit dem de facto-Ende des Arbeitsjahres vor Weihnachten ergibt sich so ein längerer Retrospektiv-Zeitraum im ersten Halbjahr und ein kürzerer im zweiten.

Quartalsweise

Nicht nur der wiederum nächstkürzere Zeitraum, sondern auch einer der sich (halboffiziell) in zwei agilen Frameworks wiederfindet. In den meisten Implementierungen des Scaled Agile Framework (SAFe) sind die mehrere Sprints umfassenden Pogramm Incremente drei Monate lang, genau wie die Zyklen in denen in der Regel mit Objectives and Key Results (OKRs) gearbeitet wird. Quartals-Retrospektiven können aber natürlich auch Framework-unabhängig sein.

Nach Ende eines (Teil-)Projekts

Die vermutlich älteste Variante langfristiger Retrospektiven, denn es handelt sich hier im Grunde um nichts anderes als um das im klassischen Projektmanagement schon seit langem übliche so genannte "Post Mortem". Aus diesem Namen ergibt sich auch das grösste Problem dieses Vorgehens: Erkenntnisse werden erst generiert wenn alles vorbei ist, womit eine Optimierung des laufenden Vorhabens nicht mehr möglich ist. Stattdessen lernt man hier für zukünftige Vorhaben.

Nach einem Go Live

Egal ob in der Produkt- oder in der Organisationsentwicklung, viele Unternehmen scheuen sich (aus guten und schlechten Gründen) davor regelmässige Veränderungen an einem laufenden System vorzunehmen. Verkaufsbeginne oder Umstrukturierungen finden dort erst statt wenn sich eine relevante oder kritische Menge angesammelt hat. Die dafür nötige Zeit kann immer wieder anders sein, weshalb es für solche Retrospektiven keinen festen Rhythmus gibt.

Zeitlich versetzt nach einem Go Live

Ähnlich, aber nicht ganz das gleiche. Der entscheidende Unterschied dieser Variante ist, dass auf etwas anderes zurückgeblickt wird. Im zuvor genannten Fall steht der Erstellungs-Zeitraum im Focus des Rückblicks, in diesem Fall sind es Erfolg und Akzeptanz der Ergebnisse bei Kunden und anderen Betroffenen. Es kann daher Sinn machen auch Vertreter dieser Gruppen einzuladen, falls mit Onsite Customern gearbeitet wurde ist das sogar sehr naheliegend.

Nach Übergabe eines Liefergegenstandes

Vor allem in Grossprojekten kommt es vor, dass Gewerke, Teilumfänge oder andere Arten von Liefergegenständen separat ausgeschrieben werden. Da diese Ausschreibungen während der gesamten Projektlaufzeit immer wieder stattfinden und in der Regel auch die selben Bieter an ihnen teilnehmen kann es hilfreich sein nach Übergabe eines Liefergegenstandes gemeinsam zu überlegen wie die Ausschreibung und Erbringung des nächsten Leistungspakets verbessert werden könnten.

Bei Bedarf

Anlässe für bedarfsgetriebene Retrospektiven gibt es viele, vom schlechter werdenden Betriebsklima über das Aufstauen technischer Schulden bis zu nachlassendem Erfolg am Markt. Erscheint einer von ihnen wichtig genug kann eine Retrospektive bei der Ursachenanalyse und Verbesserungsmassnahmen helfen. Ähnlich wie bei den Jenga-getriebenen Retrospektiven kann es auch Sinn machen zu warten bis genug Themen zusammengekommen sind, wenn die einzelnen für sich genommen zu unwichtig sind.

---

Natürlich ist diese Aufzählung nicht abschliessend, im Zweifel werden sich noch viele andere Möglichkeiten finden langfristige Retrospektiven zu planen und durchzuführen. Wichtig ist dabei vor allem, dass überhaupt Überlegungen dazu stattfinden ob und wenn ja auf welche Weise sie stattfinden sollten. Sobald sie erstmal etabliert sind kann man sie schliesslich so lange bedarfsgerecht anpassen bis sie ihren Zweck erfüllen. Mit kontinuierlichem Inspect & Adapt, wie eben in Retrospektiven üblich.

Die Gemeinsamkeiten von Softwareentwicklung und Politik

Bilder: Flickr / OSCEPA - CC BY-SA 2.0 + Pexels / Christina Morillo - Lizenz

Dass die Berufe des (agilen) Softwareentwicklers und des Politikers mehr Verbindendes haben als man auf den ersten Blick denken sollte hatte ich am Beispiel des "agilen Redens" schon einmal erwähnt, die Parallelen gehen aber weit über derartige Einzel-Aspekte hinaus. Sobald man diese beiden Tätigkeiten abstrahiert betrachtet zeigen sich grosse Gemeinsamkeiten in Herausforderungen, Rahmenbedingungen und Lösungsansätzen - sogar so grosse, dass der eine Beruf eine Analogie des anderen sein kann.

Zunächst finden beide in einem Umfeld statt das bestenfalls komplex und oft genug sogar chaotisch ist. In beiden Fällen müssen Systeme verändert werden die hochgradig unübersichtlich, vernetzt und durch schwer vorhersehbare Dynamiken geprägt sind, was in beiden Fällen dazu führt, dass die Folgen der eigenen Handlungen nur eingeschränkt absehbar sind. Um sicherzugehen, dass die eigenen Ziele erreicht werden ist daher eine kontinuierliche Validierung und Anpassung des Vorgehens nötig.

Sowohl die Politik als auch die Softwareentwicklung erfordern weitgehende Spezialisierungen, z.B. in Wirtschafts-, Innen- und Finanzpolitik oder in Frontend-, Backend- und Middleware-Entwicklung. Zwar gibt es Idealvorstellungen wie den in allen Fachgebieten bewanderten Politiker oder den Fullstack-Developer, in der Realität sind es aber praktisch immer Teams von mehr oder weniger ausgeprägten Spezialisten, die nur gemeinsam Ergebnisse liefern können.

Darüber hinaus haben beide Berufe ein Problem mit Legacy Code. Sowohl der Quelltext (englisch Source Code) in der IT als auch die Gesetzestexte (englisch: Law Code) in der Politik sind in einer z.T. weit zurückligenden Vergangenheit von Personen geschrieben worden die sich mittlerweile in Rente befinden oder den Job gewechselt haben. Sowohl die ursprüngliche Intention als auch die Lesbarkeit, die Ausführung oder die Verknüpfung zu anderen Code-Stellen sind häufig eine Herausforderung.

Die vielleicht grösste Gemeinsamkeit der beiden Berufswelten ergibt sich aber in ihrer Aussenwahrnehmeng. Beide werden kontinuierlich umlagert von einer Vielzahl an unterschiedlichsten Interessenvertretern, die mit nicht nachlassender Vehemenz darauf bestehen, dass ihr jeweils aktuelles Problem das wichtigste von allen wäre und sofort gelöst werden müsste. Und bekommen sie nicht ihren Willen sind sie im Zweifel schnell bereit zur Eskalation.

In meinen fünf Jahren in der politischen Verwaltung und meinen über 10 Jahren in der Softwareentwicklung ist mir im Rahmen dieser regelmässig stattfindenden Eskalationen eine weitere Übereinstimmung immer wieder aufgefallen: wenn Interessenvertreter ihre Wünsche nicht sofort erfüllt bekommen neigen viele dazu, den Grund dafür in einer Unfähigkeit des anderen zu sehen - "die Politik" oder "die IT" werden dann beschuldigt ihren Job nicht machen zu können oder zu wollen.

An dieser Stelle ist es dann Zeit für die finale Pointe: sobald Politiker (als Auftraggeber) ein Anliegen an eine Softwareentwicklungs-Abteilung haben oder Softwareentwickler (als Wähler) Wünsche an eine politische Institution, werden sie regelmässig selbst zu den ungeduldigen Interessenvertretern, die der jeweils anderen Seite Unvermögen unterstellen. Vermutlich würde es beiden Berufsgruppen sehr helfen ihre Gemeinsamkeiten wahrzunehmen um hier eine entspanntere Sicht zu entwickeln.

Speed trumps perfection

Eigentlich hätte ich ja gehofft, dass das Covid19-Virus zwei Jahre nach seinem Auftreten nicht mehr als aktuelles Beispiel dafür herhalten muss wie man mit einer unberechenbaren und riskanten Situation umgeht, aber naja - hier sind wir nun einmal. Dementsprechend hat dieses Video von Mike Ryan, dem Executive Director des WHO Health Emergencies Programm, nichts von seiner Aktualität eingebüsst.

Die von ihm genannten Punkte sind von ihm zwar aus der Perspektive der Pandemiebekämpfung vorgebracht, treffen aber auch auf andere komplexe Change-Vorhaben zu: man muss aus der Vergangenheit lernen, versuchen so gut wie es geht vorbereitet zu sein, in der Lage sein schnell zu reagieren (auch um den Preis sich manchmal zu irren), man muss Systemzusammenhänge erkennen können und die von den Massnahmen Betroffenen möglichst früh mit einbeziehen.

Hanlon's Razor, Stein's Razor und die Prime Directive

Bild: Wikimedia Commons / Frank Schulenburg - CC BY-SA 3.0

Selbst wenn sich nicht mehr genau rekonstruieren lässt ob sich das Sprichwort "Hanlon's Razor" auf Robert J. Hanlon oder (versehentlich falsch geschrieben) auf Robert A. Heinlein zurückzuführen ist (siehe Wikipedia für mehr Details), es hat mittlerweile eine weite Verbreitung erreicht und wird immer wieder zitiert wenn Streit darüber entsteht warum etwas schiefgelaufen ist. Für alle die es nicht kennen sind hier sein Hintergrund, seine gute Seite, seine Problematik und eine bessere Alternative.

Zunächst zum Namen. Als "Razor" (Rasiermesser) kann im Englischen ein Vorgehensmodell des Erkenntnisgewinns bezeichnet werden, bei dem man überflüssige oder verwirrende Elemente von einer Überlegung "abrasiert". Das was danach übrigbleibt soll klarer und verständlicher sein als der Ausgangszustand. Der Bekannteste ist vermutlich Occam's Razor ("The simplest explanation is usually the best one."), der zweitbekannteste der nach Hanlon oder Heinlein benannte, um den es hier geht.

Never attribute to malice that which can be adequately explained by stupidity.

Hanlon's Razor

Ins Deutsche übersetzt: "Erkläre nicht mit Bosheit was sich auch mit Dummheit erklären liesse." Das klingt zunächst eher passiv-agressiv, hat aber bei näherer Betrachtung einen fast schon humanistischen Hintergrund - statt dem Verursacher eines Fehlers oder Schadens niedere Beweggründe zu unterstellen wird davon ausgegangen, dass er die Konsequenzen seines Handelns einfach nicht überblicken konnte und sie nur darum nicht unterlassen hat.

Das Schwierige an dieser Betrachtungsweise ist allerdings, dass der Betrachtete doch wieder herabgesetzt wird, nur auf eine andere Art. Er wird zwar nicht mehr als bösartig bezeichnet, dafür aber als geistig minderbemittelt, worin implizit mitschwingt, dass jeder durchschnittlich intelligente Mensch sich anders verhalten hätte. Das ist zum einen eine sehr anmassende Haltung, zum anderen hat es aber auch Folgen die den Folgen der Zuschreibung von Bösartigkeit sehr ähnlich sind.

Beide Erklärungsansätze führen dazu, dass im Nachgang eines Fehlers oder Schadens eher nach Schuldigen als nach Lösungen gesucht werden wird. Dass das geschieht ergibt sich zwingend daraus, dass in beiden Fällen das Problem in der geistigen Verfassung des Verursachers gesehen wird. Dieser Logik folgend muss man nur alle als böse oder dumm wahrgenommenen Menschen aus Entscheidungspositionen entfernen um zu verhindern, dass der Vorgang sich wiederholt.

Die Realität ist aber meistens vielschichtiger. In einer komplexen Umgebung liegen so viele verschiedene Faktoren vor (die sich dazu auch noch gegenseitig beeinflussen), dass es kaum möglich ist sie alle im Blick zu behalten. Und selbst dann wenn das noch irgendwie möglich wäre wird das in der Regel dadurch erschwert, dass zeitgleich andere, ähnlich komplexe Sachverhalte ebenfalls beobachtet werden müssten um sicherzugehen, dass nicht dort gerade etwas aus dem Ruder läuft.

Die Erkenntnis, dass derartige Zusammenhänge nicht vollständig beherrschbar sind hat in den agilen Frameworks dazu geführt, dass versucht wird die Aufarbeitung von Zwischenfällen möglichst ohne Schuldzuweisungen durchzuführen (man spricht hier von "Blame-free Retrospectives"). Bekannt geworden ist in diesem Zusammenhang die sogenannte "Prime Directive", also die oberste Verhaltensregel die in derartigen Situationen zu beachten ist:

Regardless of what we discover, we must understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

the Prime Directive

Und damit kommen wir zum kreativen Teil. Abgeleitet von der obersten Verhaltensregel für agile Retrospektiven ist es möglich Hanlon's Razor so umzuformulieren, dass er nicht mehr dazu führt einen Schuldigen zu suchen sondern stattdessen die Unbeherrschbarkeit einer komplexen Welt anerkennt. Das soll jetzt passieren. Und da das Ergebnis einen neuen Namen braucht möchte ich für einen Moment unbescheiden sein und es nach mir benennen. Hier ist "Stein's Razor":

Erkläre nichts durch Bosheit oder Dummheit was auch durch fehlende Informationen oder gestörte Konzentration erklärbar ist.

Stein's Razor

Ob sich dieser Name durchsetzt und mich berühmt werden lässt wird sich zeigen, aber unabhängig von der Benennung lege ich diese Richtlinie allen ans Herz die an der Aufarbeitung von Fehlern oder Schadensfällen beteiligt sind. Sie zu befolgen führt in der Regel zu konstruktiveren Diskussionen, lösungsfokussierteren Verbesserungsprozessen und bereitwilligerer Beteiligung, also zu eigentlich allem was in solchen Situationen nötig und wünschenswert ist.