Scrum Guide Expansion Pack

Bild: Unsplash / Olga Guryanova - Lizenz

Mit dem Scrum-Framework haben Jeff Sutherland und Ken Schwaber etwas Bemerkenswertes geleistet: es ist ihnen gelungen, das de facto-Standard-Vorgehen der globalen Software-Industrie zu entwickeln. Der Minimalismus, der die Stärke von Scrum bildet, ist dabei gleichzeitig seine Schwäche - es ist schnell zu verstehen, lässt dabei aber auch einen Freiraum, der mit komplizierten und umfangreichen Regelwerken gefüllt werden kann, von denen SAFe und Disciplined Agile (DA) die bekanntesten sein dürften.

Da ein Grossteil der agilen Community diese beiden Ansätze ablehnt, gibt es bereits seit langem den Wunsch, ihnen eine dem ursprünglichen Geist von Scrum eher entsprechende Erweiterung entgegenzusetzen, idealerweise beruhend auf bereits verbreiteten Praktiken. Large Scale Scrum (LeSS) ist vor diesem Hintergrund entstanden, hat aber nur einen eher inoffiziellen Status. Erst seit Juni 2025 gibt es eine quasi-offizielle Erweiterung, verfasst (u.a.) von Jeff Sutherland: das Scrum Guide Expansion Pack.

Dieses Expansion Pack (mit ca 50 Seiten deutlich umfangreicher als der 13-seitige Scrum Guide, aber auch deutlich schlanker als SAFe und DA) wurde neben Sutherland von John Coleman und Ralph Jocham mitverfasst und besteht aus vier Sektionen: der eigentlichen Erweiterung mit dem Namen Adaptation of: The original Scrum Guide und einem Appendix aus den drei Teilen MORE executive SUCCESS extract, Cynefin Framework Kind of Explanation unofficial & unauthorized und Emergent Strategy.

 

In die erste Sektion ist auch der eigentliche Scrum Guide eingebettet, um ihn zu ergänzen enthalten alle vier Sektionen weiterführende Erläuterungen, einige der erwähnten verbreiteten Praktiken und historische Hintergründe. Das ist zum Teil banal (etwa wenn erklärt wird, dass "self managing" ein von aussen kommendes Management ausschliesst) zum Teil aber auch durchaus aufschlussreich (z.B. dann wenn erklärt wird, welche Untergruppen die eher diffuse Gesamtgruppe der "Stakeholder" haben kann).

 

An einigen Stellen finden de facto Erweiterungen des Scrum Guides statt, so gibt es jetzt nicht mehr lediglich drei Artefakte (Product Backlog, Sprint Backlog und Increment) sondern mit dem Product ein viertes; aus der einen Definition of Done sind die Definition of Outcome Done und die Definition of Output Done geworden; zu den drei Rollen, bzw. Accountabilies (Developer, Product Owner, Scrum Master) kommt mit den Stakeholdern eine vierte.

 

Zu den aufgenommenen Praktiken gehören am prominentesten die Produkt Vision (die das Product Goal nicht ersetzt sondern ergänzt), die Akzeptanzkriterien (die nochmal aufgeteilt werden in die eigentlichen Akzeptanzkriterien und so genannte Outcome-Kriterien) und die häufigsten in Retrospektiven besprochenen Themen (u.a. Professionalität, Effektivität und Teamdynamiken), über den Text verstreut finden sich aber auch weitere, etwa Systems Thinking, (Product) Discovery und Beyond Budgeting.

 

Eher in den Berech der Nerd-Wissens gehören einige Exkurse zu historischen Begrifflichkeiten und Dokumenten. So werden die Scrum Werte Focus, Openness, Courage, Commitment und Respect aus dem amerikanischen Militär-Begriff OODA (Observe, Orient, Decide, Act) abgeleitet und gleich mehrere Absätze widmen sich dem wissenschaftlichen Paper The New New Product Development Game von 1986, das eine zentrale Inspirationsquelle für Sutherland und Schwaber war.

 

Im Gegenzug dazu gibt es mit einem eigenen Teil zum Thema der künstlichen Intelligenz (KI) auch etwas, das erkennbar von aktuellen Entwicklungen getrieben ist. Kurioserweise eingeordnet zwischen den Rollen, bzw. Accountabilies werden die damit verbundenen Möglichkeiten und Risiken herausgestrichen (und es wird hervorgehoben, dass der Scrum Master keine KI sein darf). Das ist nicht falsch, aber etwas willkürlich, mit gleicher Berechtigung hätte man z.B. auch Big Data oder Cloud mit aufnehmen können. 

Ob das Scrum Guide Expansion Pack weite Verbreitung finden und noch weiter modifiziert werden wird, wird sich zeigen, wahrscheinlich ist aber in Analogie zum eigentlichen Scrum Guide (den es nur ergänzt, aber nicht ersetzt) beides. Ob es sich als Ersatz oder Gegenmodell zu den kommerziell erfolgreichen und von professionellem Marketing unterstützen Ansätzen SAFe und DA durchsetzen wird ist dagegen weit weniger klar, das in den nächsten Jahren zu beobachten wird sicherlich spannend sein.

 

Auf jeden Fall wird man es aber gut nutzen können, um zu erkennen, wer sich wirklich für das Thema Scrum interessiert. Denn ganz sicher werden nus solche Personen bereit sein, die gesamten ca 50 Seiten durchzulesen. Alle anderen werden das vermutlich geflissentlich an ihren Scrum Master delegieren.

Agile Success Stories: ein wirklich crossfunktionales Team

Bild: Pexels / Ketut Subiyanto - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Am Anfang von dieser hier stand wie so oft ein Frustrationserlebnis. Eine grosse Firma, bei der ich im Einsatz war, hatte sich in einem Pilotprojekt auf die Idee crossfunktionaler Entwicklungsteams eingelassen, in der Hoffnung, dadurch die alles verzögernden Warte- und Übergabephasen zwischen den bisherigen Spezialistenteams deutlich verkürzen zu können. Bis zu einem gewissen Grad war das auch eingetreten, allerdings bei Weitem nicht in dem von allen erhofften Ausmass.

Eine Untersuchung der betroffenen Einheiten und Prozesse konnte dann klar aufzeigen, woran das lag: das Team war nur crossfunktional innterhalb der Softwareentwicklung (Frontend, Backend, Data Science, UX), was aber bei weitem nicht alle Arbeitsschritte abdeckte. Das Produkt (ein Kundenservice-Chatbot) musste nach der Entwicklung noch zur Fachabteilung, um von der mit Daten versorgt und trainiert zu werden, um dann von der Rechtsabteilung freigegeben zu werden. Hier entstanden weiter Wartezeiten.

 

Auch Mitglieder dieser beiden Abteilungen in das crossfunktionale Teams aufzunehmen war die offensichtliche Lösung, führte aber zu Beginn zu heftigen Abwehrreaktionen; dafür gäbe doch gar nicht genug Zeit, und es gäbe zu viel Anderes zu tun, das wichtig wäre. Auch hier führte eine Nachforschung schnell zu einer Identifikation des eigentlichen Problems: die betroffenen Kollegen waren stark überplant und hatten nur wenige Stunden pro Woche für das Pilotprojekt zur Verfügung - deutlich zu wenig.

 

Es brauchte mehrere Wochen und Eskalationen bis ins Top-Management um dieses Problem zu lösen, aber am Ende stand ein deutlich besseres Setup. Aus der Fachabteilung wurden mehrere Mitarbeiter für vier Tage pro Woche exklusiv für das Projekt freigestellt, aus der Rechtsabteilung immerhin ein Kollege für drei halbe Tage pro Woche. Damit konnten sie in das jetzt wirklich crossfunktionale Team eingegliedert werden, an dessen Meetings teilnehmen und eng mit den anderen Teammitgliedern zusammenarbeiten.

 

Durch diese Neuorganisation trat dann endlich die angestrebte Beschleunigung ein. Durch die täglichen Abstimmungen war jetzt jederzeit klar, wann die Übergaben zwischen den Teilteams stattfinden würden, und durch die realistischere Kapazitätsplanung konnten sie auch fast immer sofort stattfinden. Die Durchschnittlsdauer der Warte- und Übergabephasen sank von Tagen und Wochen auf Stunden (und als Nebeneffekt konnten die Meetings entfallen, in denen die zu übergebende Arbeit verwaltet wurde).

 

Natürlich gab es noch weitere positive Effekte dieses Vorgehens, z.B. die oben erwähnte Aufdeckung der strukturellen Überplanung vieler Mitarbeiter, da schnellere Durchlaufzeiten durch crossfunktionalere Teams aber das Hauptziel der Umstellung auf agiles Arbeiten waren, steht auch das hier im Focus dieser "agilen Erfolgsgeschichte". Und darüber hinaus ist es ein gutes Beispiel dafür, wie weit wirkliche Crossfunktionalität gehen kann.

Der Change-Prozess als bewusste Machtkampf-Arena

Eine häufige Beschwerde bei Veränderungsvorhaben in grossen Organisationen ist, dass unverhältnismässig viel Zeit in Meetings aller Art verloren geht. Workshop folgt auf Workshop, Steuerungskreis auf Steuerungskreis, Entscheidungsrunde auf Entscheidungsrunde - nur damit am Ende ein Ergebnis steht, für dessen Festlegung bereits ganz am Anfang alle Informationen zur Verfügung gestanden hätten. Warum tut man sich das an?

Eine interessante Erklärung dafür bietet der Soziologie-Professor Stefan Kühl im wie immer hörenswerten Podcast "Der ganz formale Wahnsinn". Ihm zufolge dienen derartiger Meetings nicht nur der rationalen Entscheidungsfindung, sondern auch dem Austragen von Machtkämpfen, deren Stattfinden zu derartigen Anlässen nicht nur möglich, sondern sogar gewünscht ist, die dort aber nach Möglichkeit auch abgeschlossen werden sollen - etwas, was ich mehrfach genau so erlebt habe.

Um das zu verstehen holen wir zunächst etwas aus: Veränderungen führen in sehr vielen Fällen dazu, dass es Gewinner und Verlierer gibt. Ein Abbau von Hierarchien reduziert Bürokratie, verknappt aber dafür die Karriereoptionen; die Schaffung von Spezialistenlaufbahnen ermöglicht individuellen Statusgewinn, das aber auf Kosten der Gleichbehandlung in Teams; etc. etc. Das ist meistens schon früh erkennbar und löst bei den negativ Betroffenen die erwartbaren Widerstände aus.

Werden Veränderungen jetzt (zu) schnell beschlossen, finden diese Widerstände im Rahmen der bereits neu geordneten Organisation statt, was diese von Beginn an lähmen kann. Gelingt es dagegen, die Widerstände (und die Anstrengungen zu ihrer Überwindung) vor die Entscheidung zur Neuordnung zu legen, und zwar so, dass die Gewinnerseite des dadurch entstehende Machtkampfes diese Entscheidung prägen darf, dann kann die Startphase der neuen Organisation weitgehend ungestört beginnen.

Die verschiedenen Workshops, Steuerungskreise und Entscheidungsrunden bilden in dieser Betrachtungsweise eine Arena, in der die verschiedenen Parteien vor den Augen der restlichen Organisation gegeneinander antreten, einzelne Auseinandersetzungen gewinnen, andere verlieren, nach und nach ermüden, neue Kraft schöpfen, Bündnisse schliessen und Rückzugsgefechte führen, bis letztendlich eindeutig klar ist, wer sich in welchem Bereich durchgesetzt hat.

Am Ende dieser Vorgänge stehen gleich mehrere Ergebnistypen: zum einen die Entscheidungen der Machtkämpfe, und mit ihnen auch die über das Ausmass und die Weiterführung der Veränderungen, zum anderen aber auch eine Legitimation und Delegitimation von Standpunkten. Die Gewinner können sich zukünftig auf den langen und ausführlichen Entscheidungsprozess berufen, den Verlierern kann vorgehalten werden, dass sie trotz ausreichender Zeit keine Mehrheiten für ihre Ideen finden konnten.

Was mit dieser Art einer Change-Herbeiführung verbunden ist, ist natürlich das Risiko einer hochemotionalen Konfliktaustragung, da jede Seite befürchten muss, nach einer Niederlage auf unabsehbare Zeit kein Gehör für Ihr Anliegen mehr zu finden. Schlimmstenfalls kann sogar das Gegenteil des Angestrebten erreicht werden, einer belasteter statt eines unbelasteten Neustarts, nur mit einer Belastung durch Verbitterung und Verletzungen statt durch weitergehende Widerstände.

Um das zu vermeiden kann es sich anbieten, Veränderungen nicht in seltenen, grossen Programmen durchzuführen, sondern in einer stetigen Reihe von kleineren Vorhaben. Der Arena-Effekt verschwindet dadurch zwar nicht, dadurch dass die Auseinandersetzungen kleiner und reversibler werden, gehen aber die zur Schau Stellung und die potentielle Emotionalität zurück. Und als ein Seiteneffekt sind in jedem einzelnen Fall auch weniger Meetings nötig, was wiederum zu weniger Beschwerden führt.

Digitales Working Out Loud als Alternative zum Daily

Bild: Pexels / Polina Tankilevitch - Lizenz

In den meisten agilen Teams sind die Daily Meetings (Daily Scrum, Daily Standup, Daily Symc, etc) ein fester Bestandteil ihrer Arbeitsweise. In einzelnen Fällen stösst dieses Konzept aber an Grenzen, etwa wegen nicht gegebener gleichzeitiger Verfügbarkeit, wegen Introvertiertheit oder (bei remote-Arbeit) wegen schlechter Internet-Verbindung. Um trotzdem im engen Austausch bleiben zu können, gibt es für solche Teams eine mögliche Alternaltive: digitales Working Out Loud (WOL).

Um Missverständnissen vorzubeugen: bei Working Out Loud handelt es sich in diesem Fall nicht um die seit 2015 entwickelte formalisierte Social Learning-Methode gleichen Namens, sondern um die dahinterstehende, 2010 von Bryce Williams entwickelte Grundidee, die lediglich aus zwei Prinzipien besteht: die eigene Arbeit sichtbar zu machen und sie in Erzählform zu vermitteln. Diese Prinzipien lassen sich auch in Team-interne Kommunikation übertragen.

Um das (in einer nicht-verbalen Form) zu tun braucht es zunächst einen gemeinsamen digitalen Kommunikationskanal. Das kann in der rudimentärsten Form eine Whatsapp-Gruppe sein. in den meisten Firmen sind aber professionelle Tools vorhanden (Teams, Slack, etc.), in denen sich eigene Kanäle für ein Team anlegen lassen. In diesen Chat kann man dann alles eintragen, woran man gerade arbeitet. Damit ist bereits das erste Prinzip erfüllt, die Sichtbarkeit.

Das zweite Prinzip, die Erzählform, ist nötig um die Information über die eigene Arbeit mit dem nötigen Kontext zu versehen. "Ich arbeite an Komponente XY" würde z.B. nicht klar machen, warum diese Arbeit stattfindet. "Ich arbeite wie besprochen an Komponente XY, damit unser Hauptkunde rechtzeitig die Exportfunktion bekommt die wir ihm bis Ende des Monats versprochen haben" macht dagegen den Hintergrund und die Prioritäten deutlich klarer.

Wichtig ist dabei, dass diese Information im Voraus stattfindet. Falls eines der anderen Teammitglieder Einwände, Fragen, Hinweise oder Verbesserungsvorschläge hat, können die dann noch eingebracht werden bevor die Arbeit begonnen wurde. Das Risiko, versehentlich unnötige oder in Relation unwichtige Arbeiten zu beginnen wird so minimiert. Und natürlich kann der Chat bei Unklarheiten auch für schnelle Klärungen und Abstimmungen genutzt werden.

Mit ein bisschen Übung kann diese Art des Working Out Loud einen Grossteil der Kommunikation ersetzen, die sonst in einem Daily Meeting stattfinden würde. Bei entsprechender Nutzung können die ausgetauschten Informationen sogar noch weiter angereichert werden, etwa durch Links zu Anforderungen oder Build Reports, durch angehängte Dateien oder in den Text eingebettete Screenshots und Diagramme. An diesen Stellen kann ein Chatt sogar besser sein als ein Meeting.

Schlechter als in einem Meeting lassen sich in einem Chat dagegen Stimmungen, Emotionen und sonstige soziale Aspekte sichtbar machen. Schlimmstenfalls kann es sogar zu Konflikten kommen, da Sorgen, Ungeduld oder Verärgerung nicht erkannt werden. Ein weiterer wichtiger Punkt ist, dass digitales WOL eine ständige Beachtung des Chats erfordert, was ggf. störend für Konzentration und Produktivität sein kann und zu Stress führen kann.

Digitales Working Out Loud kann also eine brauchbare Alternative zum klassischen Daily Meeting sein, es kommt aber mit einem Preis, dessen man sich bewusst sein sollte. Wenn nicht die oben genannten Gründe (oder ähnlich schwerwiegende) gegeben sind sollte man daher vor einer Umstellung die Vor- und Nachteile gegenüberstellen, und ggf. in einer Testphase erproben, wie der neue Modus funktioniert und mit welchen Effekten er verbunden ist.

Kommentierte Links (CXXVII)

Grafik: Pixabay / Brian Penny - Lizenz

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.

John Cutler: A Love Letter to Physical Boards (and What Comes Next)

Ich gestehe: diesen Liebesbrief von John Cutler an physische Task- und Kanban-Boards würde ich sofort unterschreiben. Tools wie Jira, Trello, Obsidian, Miro & Co haben zwar seit dem Corona-bedingten verstärkten Aufkommen von Remote-Arbeit massiv Funktionen und Nutzer dazugewonnen, sie haben die eigentlich einfache Idee visualisierter Arbeit aber auch massiv mit Regeln, Verlinkungen, Verschachtelungen und Formatierungen überladen. In diesem Fall war es tatsächlich früher besser.

Milan Milanović: How Google Measures and Manages Tech Debt

Die technischen Schulden gehören zu den Begriffen, die zwar weit verbreitet sind, unter denen sich aber auch jeder etwas anderes vorstellt. Milan Milanović teilt hier eine interessante Fallstudie, die der Firma Google die technische Schulden in 10 Kategorien unterteilt: Migration needed or in progress, Poor or missing documentation, Inadequate testing, Bad code quality, Dead code, Code degradation, Knowledge gaps, Problematic dependencies, Failed migrations und Outdated release processes.

Thomas Germain: Still booting after all these years - The people stuck using ancient Windows computers

Dass uralte Windows-Systeme bis heute die Grundlage für viele Geschäftsprozesse und kritische Infrastrukturen bilden ist schon lange ein Thema, so umfassend wie hier bei Thomas Germain habe ich es aber noch nicht aufbereitet gesehen. Was man von ihm mitnehmen kann: es gibt handfeste betriebswirtschaftliche Gründe dafür, dass sie nicht schon längst überall abgelöst wurden. Das macht es zwar verständlicher, im Ergebnis aber nicht besser.

Barry O'Reilly: The Bootstrapped Revolution: How Small Teams Are Redefining Entrepreneurship

Ein bisschen Kontext vorweg: was Barry O'Reilly hier über kleine Business Einheiten schreibt, die mit weniger als 10 Mitgliedern ganze Märkte aufrollen, ist sehr spezifisch für das technische und soziale Ökosystem des Silicon Valley. Selbst wenn es aber nicht zur Gänze auf den stärker regulierten und von Grossunternehmen dominierten europäischen Markt übertragbar sein sollte - es zeigt deutlich, zu was kleine Einheiten in der Lage sein können, wenn man ihnen die passenden Rahmenbedingungen gibt.

Alex Ewerlöf: When a team is too big

Je nach Sichtweise die Ergänzung oder das Gegenstück zum letzten verlinkten Text. Ausgehend von der Frage, ab wann ein Team zu gross wird um unbürokratisch arbeiten zu können, ist Alex Ewerlöf der grosse Rundumschlag gelungen. Synchrone und asynchrone Kommunikation, Silos und Taskforces, Software-Architektur, Generalisten, Spezialisten, Mob Programming, Lean Management, Ownership und künstliche Intelligenz - alles zusammen in einem lesenswerten Text.

Ein Bild sagt mehr als 1000 Worte (XLVIII)

 Ein etwas anrüchiges Meme, aber eines, das seit Jahren immer wieder geteilt wird. Quelle unbekannt.

I Don't Need Another Scrum Master, Get Me a Technical Coach!

Das hier geht ein bisschen in die Richtung der klassischen Diskussion, wieviel technisches Verständnis ein Scrum Master haben sollte. Die These von Emily Bache in diesem Vortrag hier ist, dass Scrum Master ohne technischen Hintergrund zwar einen Mehrwert haben, dass es aber ebenfalls etwas braucht, was sie "technical Leadership" nennt - eine Rolle die dafür sorgt, dass die technischen Praktiken und Prinzipien genutzt werden, die agile Softwareentwicklung im eigentlichen Sinn überhaupt erst möglich machen.

Insgesamt schlägt sie einen grossen Bogen von Pull Requests über Testability, Code Reviews, Test Driven Development und Pair Programming bis hin zu vielen weiteren Themen. Insgesamt sehr sehenswert, selbst wenn zeitweise die Bewerbung ihrer eigenen Dienstleistungen als externer technical Coach doch sehr stark in den Mittelpunkt rückt.

Construct to deconstruct

Bild: Javier Alvarez / Picryl - Public Domain

In der agilen Softwareentwicklung sollte man sich stets eines Grundsatzes bewusst sein: alle Methoden, Frameworks, Meetings, Rollen, Werte und Prinzipien sind schön und gut, wenn die entstehende Software aber nicht schnell und mit vertretbarem Aufwand anpassbar ist, ist all das nur von bescchränktem Wert. Auch Entwicklungs-Praktiken und Architektur-Muster sind daher von Bedeutung, unter anderem eines, der leider ralativ unbekannt ist: Construct to deconstruct.

Die Grundidee dahinter ist einfach: zum agilen Entwicklen von Software gehört auch, dass vergangene Erweiterungen oder Modifikationen wieder rückgängig gemacht werden, sei es, weil es sich bei ihnen um Übergangslösungen oder MVPs gehandelt hat, oder seit es weil sich herausgestellt hat, dass bei den Anwendern keine Nutzungs- oder Bezahlbereitschaft besteht. In diesen und in anderen Fällen macht ein rückgängig Machen Sinn, um Umfang und Komplexität der Codebase zu reduzieren.

Dort wo das nicht schnell und einfach möglich ist, können verschiedene negative Auswirkungen auftreten - bestenfalls ist die Wiederherstellung eines früheren Zustandes einfach nur aufwändig und beansprucht Zeit und Ressourcen, schlimmstenfalls ist es nicht möglich und eine mit dem früheren Zustand vergleichbare Ersatzlösung muss gebaut werden, was nicht nur aufwändig ist, sondern ggf. auf Kosten von Konsistenz, Updatefähigkeit (bei Standardsoftware) oder Ähnlichem geht.

In der Umsetzung besteht die häufigste und offensichtlichste Form einer Construction for Deconstruction aus einer modularen Architektur der jeweiligen Software. Diese ist gegeben, wenn die Anwendung in selbstständige, voneinander unabhängige Einheiten gegliedert ist, die jeweils eine bestimmte (bestenfalls fachliche) Funktion erfüllen, mit anderen Einheiten nur über fest definierte Schnittstellen verbunden sind und einzeln angepasst werden können, ohne die jeweils anderen auch verändern zu müssen.

Ebenfalls offensichtlich ist, dass der vorherige Zustand bekannt bleiben muss, um wiederhergestellt werden zu können. Das kann ganz banal durch ein Abspeichern eines bestimmten Entwicklungsstandes des Codes stattfinden (und nicht nur der jeweils letzten Versionen), aber auch durch ein Sichern des entsprechenden Standes der dazugehörigen Dokumentation, idealerweise in einer Form, die nicht nur den Zustand beschreibt, sondern auch auch die Entscheidungen die ihm zugrundeliegen.

Etwas weniger offensichtlich aber nicht weniger bedeutsam ist, dass auch der zwischenzeitlich angepasste und jetzt wieder zu entfernende, bzw. auf den früheren Zustand zurückzusetzende Code verständlich und gut dokumentiert ist. Nur wenn sicher ist was er tut und welche Abhängigkeiten von ihm ausgehen kann er entfernt, bzw. zurückgesetzt werden, ohne dass es dabei zu überraschenden Seitenauswirkungen kommt, die wiederum ungeplante Verzögerungen und Aufwände mit sich bringen.

Und natürlich sind auch hier Testabsicherung / Testabdeckung und Monitoring von Bedeutung. Sowohl bei der Validierung ob der "neue alte Zustand" funktionsfähig ist, als auch bei der Sicherstellung, dass die Entfernung des "alten neuen Zustandes" keine unerwarteten Probleme mit sich bringt sind sie für eine schnelle und sichere Umsetzung unverzichtbar (bzw. wenn sie nicht gegeben sind ist mit hohen Aufwänden und verspätet erkannten Überraschungen zu rechnen).

Zuletzt noch eine nicht-technische Anmerkung: dass der Construct to deconstruct-Grundsatz nur verhältnismässig selten befolgt wird hat unter anderem einen sehr menschlichen Grund: es erscheint (bewusst und unterbewusst) naheliegender Veränderungen herbeizuführen, indem man etwas Bestehendem etwas Neues hinzufügt, und weniger naheliegend, dafür etwas Bestehendes zu entfernen. Mehr dazu hier, im Nature-Magazin.

Forward-deployed Engineers

Wer sich inspirieren lassen will, wie ein über Scrum und SAFe hinausgehendes individuelles agiles Framework aussehen könnte, der findet bei erfolgreichen Tech-Unternehmen eine Vielzahl von Beispielen, von Youtube über Amazon und Spotify bis hin zu Netflix und X/Twitter. Ohne nachzudenken kopieren sollte man nichts davon, aber Ideen zum Ausprobieren sind immer wieder dabei. Hier ist eine weitere: die forward-deployed Engineers (FDEs) der Firma Palantir.

Die an verschiedenen Stellen (z.B. hier, hier und hier) erklärte Idee ist einem Gründungsmythos zufolge nach dem Besuch in einem französischen Restaurant entstanden, in dem die Kellner viel Zeit mit den Gästen verbrachten, zusammen mit ihnen von der Karte abweichende Menüs erstellten und diese dann in Teilen selbst mit zubereiteten. In ähnlicher Form sollen zum Kunden entsandte (forward deployed) Teams von Palantir direkt mit den Anwendern Software-Features entwerfen und für sie erstellen.

Bewusst oder unbewusst scheint dieses Vorgehen eine (je nach Sichtweise) Weiterentwicklung oder Umdrehung der Rolle des Onsite Customers aus dem Extreme Programming zu sein. In beiden Fällen ist es das Ziel, Entwickler und Anwender möglichst nah zusammenzubringen. Während das im Extreme Programming aber dadurch stattfand, dass Kundenvertreter in die Entwicklungsteams integriert wurden, ist es bei den forward-deployed Engineers umgekehrt.

Die sich daraus ergebenden Vorteile (enger Zielgruppenkontakt, sofortige Erprobung neuer Ideen, unmittelbares Feedback) sind offensichtlich, allerdings sollte sich jeder bewusst sein, dass diese mit einem Preis kommen, und das ist in diesem Fall wörtlich zu nehmen. Bei Kunden eingesetzte FDEs werden dort lokale Lösungen entwickeln, die ggf. mit anderen lokalen Lösungen redundant oder inkompatibel sind, ihre Integration oder ihr parallel-Betrieb sind aufwändig, die Synergie-Effekte gering.

Dass dieser Weg für Palantir trotzdem der richtige ist, hat mit der Kundenstruktur dieser Firma zu tun. Sie ist im Rüstungssektor tätig und hat darum wenige, dafür aber potentiell riesige Kunden (v.a. die Armeen verschiedener Länder und grosse Rüstungskonzerne, wie z.B. Airbus). Diese Grosskunden sind problemlos in der Lage, die mit diesem Vorgehen verbundenen Kosten zu stemmen, gleichzeitig ist ihre Anzahl so überschaubar, dass die Varianz der entstehenden Lösungen handhabbar bleibt.

Von Bedeutung ist ausserdem, dass es sich bei den in diesem Kundensegment erstellten Palantir-Produkten um Individualsoftware handelt, die zum Grossteil bewusst nicht an andere Kunden verkauft werden soll (und zum Teil aufgrund von Geheimhaltungs- und Exklusivitätsvereinbarungen auch gar nicht verkauft werden darf). Die bei der Erstellung von Standardsoftware normalen und sinnvollen Vereinheitlichungs- und Effizienz-Bestebungen spielen daher hier keine Rolle.

Die forward-deployed Engineers sind daher in gleich doppelter Hinsicht ein interessanter Anschauungsfall. Zum einen weil sie einen Weg zu extrem effektiver und intensiver Kunden- und Nutzer-Interaktion darstellen, zum anderen weil es bei ihnen sehr deutlich erkennbar ist, wie kontextspezifisch ihr Einsatz ist und wie wenig übertragbar er auf die meisten anderen Unternehmen wäre. Daher, wie oben gesagt - eine Inspiration können sie sein, einfach kopieren sollte man sie aber nicht.

120. Scrumtisch Bonn

Jubiläum, Jubiläum! Der bonner Scrumtisch wird 10 Jahre alt, und da er monatlich ausgerichtet wird bedeutet das folgerichtig, dass er heute Abend zum 120sten mal stattfindet. Selbst wenn ich es natürlich nicht jedes mal geschafft habe an ihm teilzunehmen, biin ich von Anfang an dabei gewesen, in den ersten Monaten noch als normaler Teilnehmer, später dann als Teil des Organisationsteams, und das bis heute. Darum an dieser Stelle ein kleiner Blick zurück.

Was den Scrumtisch in Bonn von Anfang an ausgemacht hat, ist zunächst sein Format gewesen. Mit einer einzigen Ausnahme hat er jedes mal als Open Space oder Lean Coffee stattgefunden. Wie genau dieses Format abläuft habe ich hier beschrieben, der zentrale Punkt dabei ist aber, dass es keine vorbereitete Agenda, Themenliste oder Redner-Auswahl gibt. Stattdessen kann jeder das Thema mitbringen, dass ihn gerade bewegt und zusammen mit den anderen diskutieren.

Ein weiterer Punkt der für diese Veranstaltungsreihe prägend gewesen ist, sind seine ständig welchselnden Gastgeber. Anders als es der Name vermuten lässt findet der Scrumtisch nicht in einer Kneipe statt, sondern in Unternehmen die selbst nach Scrum (oder einem anderen agilen Framework) arbeiten. Dadurch kommen immer wieder neue Impulse auf, da die Gastgeber in der Regel bereit sind, Einblicke in die jeweils eigene Art des agilen Arbeitens zu gewähren.

Der mit Sicherheit wichtigste unter den Faktoren, die dafür gesorgt haben, dass es den bonner Scrumtisch nach 10 Jahren noch gibt, ist die lokale Community aus Frenden und Anwendern von Scrum, Kanban, DevOps & Co, die wiederum dadurch bedingt ist, dass es in Bonn eine wesentlich grössere Digital-Wirtschaft gibt als man von Aussen vermuten würde. Von der Regierungs-IT und die Staatsunternehmen über Mittelstand, und Versicherungen bis hin zu Startups ist alles dabei.

Natürlich gäbe es noch viel mehr zu erzählen, von den Anfängen als Spinnoff des Scrumtisch in Köln über das langsame Wächstum der nächsten Jahre und die virtuelle Durchführung während der Corona Lockdowns bis hin zu den negativen und positiven Auswirkungen der aktuellen Wirtschaftskrise. Aber das ist viel besser in Gespräch und Diskussion möglich, weshalb es sich anbietet, das heute Abend auf dem 120. bonner Scrumtisch selbst zu machen. Vielleicht sehen wir uns da?

Deine Muda: Inspect ohne Adapt

Bild: Unsplash / Glenn Carstens-Peters - Lizenz

Elfter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: Inspect ohne Adapt.

In gewisserweise handelt es sich bei dieser speziellen Ausprägung um eine (wenn nicht sogar die) "agile Muda", da sie vor allem im Umfeld von (schlecht laufender) agiler Produktentwicklung anzutreffen ist. Sie liegt vor, wenn zwar regelmässig nach Verbesserungspotentialen oder Dysfunktionen gesucht wird, ein Auffinden einer solchen aber keine Schritte zur Folge hat, die den Zustand verbessern sollen. Ein klassisches Beispiel dafür wären Retrospektiven ohne Action Items.

Der Verschwendungs-Charakter dieses (Nicht-)Vorgehens ist offensichtlich: für das Suchen, Identifizieren, Beschreiben und Besprechen schlecht laufender Dinge ist Arbeitszeit nötig, und Zeit ist im Unternehmenskontext gleich Geld. Das ist in gewisser Weise gleich doppelt fällig - zum einen für die gerade genannten Tätigkeiten, zum anderen für das Nachholen anderer Aktivitäten, die wegen der so bereits vergebenen Arbeitskapazitäten in die Zukunft verschoben werden mussten.

Ein weniger offensichtlicher aber in seinen Auswirkungen nicht zu unterschätzender Effekt ist der in diesem Rahmen eintretende Motivationsverlust der Mitarbeiter, die erkennen, dass ihnen mit ihren Problemen nicht geholfen wird. Zum einen kann die daraus entstehende Frustration zu nachlassender Arbeitsleistung führen, zum anderen dazu, dass neu auftretende Probleme gar nicht mehr addressiert und bearbeitet werden, da mit ihrer Lösung gar nicht mehr gerechnet wird.

Im schlimmsten Fall entsteht zusätzlich zu diesen Effekten nochmal ein weiterer Verwaltungsaufwand, nämlich dadurch, dass die identifizierten aber nicht gelösten Verbesserungspotentiale und Dysfunktionen ggf. aufbewahrt und aktuell gehalten werden müssen. Die damit verbundenen Untersuchungs-, Informations-, Aktualisierungs- und Repriorisierungs-Aufwände überfrachten das ohnehin schon sinnlose Inspect ohne Adapt nochmal mit einer weiteren Muda, der Lagerhaltung.

Ein derartiges Verhalten abzustellen sollte aus diesen Gründen für jedes agile Team (aber auch für jedes andere Team bei dem es auftritt) eine hohe Priorität haben. Notwendig dafür ist es allerdings, den Teufelskreis einmal initial zu durchbrechen und dem Inspect auch ein tatsächliches Adapt folgen zu lassen, in diesem Fall eine Verhaltensänderung. Ist das aber einmal gelungen, kann in dem so gestarteten Verbesserungszyklus kontinuierlich an Fortschritten gearbeitet werden.

The Future of Agile Isn’t Sh*t

So wie es aussieht, hat Scott Ambler, der Erfinder von Disciplined Agile, seine beiden viralen Linkedin-Posts The Agile Community Shat The Bed und How Agilists Can Move Forward After Shatting the Bed zu einem Vortrag ausgebaut. Die Wortwahl ist noch immer grenzwertig, seine Analyse der Fehlentwicklungen in der agilen Community bleiben aber richtig. Und immerhin gibt er dem Ganzen noch einen positiven Ausblick.

Abseits von der Inhaltlichen Ebene ist die Bildsprache seiner Präsentation noch bemerkenswert. Man muss Memes mögen, um an ihr Gefallen zu finden, dann ist die aber großartig. Daher: ein Vortrag den man auch sehen sollte, nicht nur hören.

Kommentierte Links (CXXVI)

Grafik: Pixabay / Brian Penny - Lizenz

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.

John Cutler: The 4 Framework Jobs (And Why It Matters)

Vorgehensmodelle jeglicher Art sind in praktisch allen grösseren und mittleren Organisationen weit verbreitet, von klassischem Projekt und Prozessmanagement über Lean Six Sigma und Total Quality Management bis hin zu Kanban, Scrum und SAFe. Was John Cutler zurecht anmerkt ist aber, dass zu selten darüber nachgedacht wird, warum diese Modelle ursprünglich ausgewählt wurden, was mit ihnen erreicht werden sollte und ob sie noch immer der beste Weg zu diesen Zielen sind.

Sjoerd Nijland: How to Say “It Depends” with Data

"Es kommt darauf an" ist die klassische Antwort aller Produkt- und Projektmanager, wenn sie nach Fortschritten und Fertigstellungsdaten gefragt werden. Dass diese Antwort ohne Kontext und Begründung nicht zufriedenstellend ist, ist offensichtlich, weshalb Sjoerd Nijland eine entscheidende Erweiterung vornimmt: er nennt eine entscheidende Variable auf die es ankommt, nämlich das Ausmass der messbaren Volatilität des Backlogs. Je höher diese ist, desto unklarer die Fortschritts-Prognosen.

Hunter Schwarz: This 3D-printed train station in Japan took less than 6 hours to build

Dass CAD und 3D-Druck agiles Arbeiten auch in Bauprojekten möglich macht, ist eine der spannenden Entwicklungen der letzten Jahre. Welche Umsetzungs-Geschwindigkeiten damit erreicht werden können beschreibt Hunter Schwarz anhand des Neubaus des japanischen Bahnhofs in Arida, der in unglaublichen sechs Stunden abgeschlossen werden konnte, also in nur einer einzigen Nacht. Zum vergleich: vergleichbare Arbeiten in Deutschland dauern Monate.

Maarten Dalmijn: The Explosive Nature of 'Big Bang' Rewrites

Dass Big Bang-Releases neu entwickelten problematisch sind, sollte mittlerweile allgemeines Verständnis sein. Maarten Dalmijn fügt dieser Erkenntnis noch eine weitere Dimension hinzu: auch das komplette Umschreiben einer bestehenden Anwendung mit anschliessender Big Bang-Ablösung des Bestandssystems ist riskant. Zwar sind die Nutzerbedürfnisse (hoffentlich) bekannt, das Wissen um die inneren Zusammenhänge ist aber schon schnell zu gross um sich noch verlässlich planen zu lassen.

Luís Gonçalves: Scaling Startups - The Ultimate Guide For Founders

Wo würden agile Vorgehensweisen Sinn machen, wenn nicht in einem Startup? Und wodurch zeichnet sich ein Startup aus, wenn nicht durch starkes Wachstum? Dass es aber auch hier Differenzierungen gibt kann man bei Luís Gonçalves nachlesen, der vor allem den Unterschied zwischen Start Up und Scale Up hervorhebt. Der ist gravierender als man denken könnte (selbst wenn es eine Übergangsphase dazwischen gibt), so dass es sich lohnt, die beiden Typen zu kennen.

Der Unterbau von OKRs

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) erstmal einfach. Man setzt ein abstraktes, mittelfristiges Ziel (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen konkreten, messbaren Ergebnissen (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Die Herausforderung, die dadurch entsteht ist aber: wie lässt sich das mit dem Alltagsgeschäft verbinden?

Die erste und naheliegende Antwort ist es, in kurzen Abständen (z.B. wöchentlich) zu überprüfen, ob Forschritt in der gewünschten Richtung stattfindet und ggf. Anpassungsmassnahmen zu beschiessen, falls die bisherigen Ergebnisse zu wünschen übriglassen. Auch hier bleibt aber offen, was genau es ist, das da begutachtet wird. Natürlich kann man sich immer wieder die OKRs selbst vorlegen, die Verbindung zum Alltagsgeschäft wäre damit aber noch immer nicht gegeben.

Ein häufig anzutreffender Ansatz zum Schliessen dieser Lücke ist, für die jeweiligen Key Results einen weiteren Work Breakdown durchzuführen und die Umsetzung der sich so ergebenden Arbeitspakete mit Hilfe eines Backlogs oder einer Roadmap zu planen.¹ Damit wird nicht nur die Umsetzungslücke geschlossen, es ist darüber hinaus möglich, die OKR-Aufwände und die sonstigen Tätigkeiten in einer gemeinsamen Planungssicht zusammenzufassen und so Redundanzen und Überplanung zu vermeiden.

Die Art der jeweiligen Arbeitspakete kann schliesslich variieren. Sie können die Bereitstellung der (Infra-)Strukturen zum Gegenstand haben, die für die Erbringung von Leistungen Voraussetzung sind, sie können aus der Fertig- und Bereitstellung von neuen Produkten, Features oder Services bestehen, sie können aber auch die Form von Business-Experimenten haben, durch die erforscht wird, auf welche Art und Weise sich Nutzergewohnheiten ändern oder Kaufanreize setzen lassen.

Wichtig bei der Definition dieses Unterbaus unterhalb der OKRs ist dabei weniger, um was für Arbeitspakete es sich genau handelt, sondern eher ob sie zur Erreichung der übergeordneten messbaren Ergebnisse, der Key Results, beitragen. Stellt sich heraus, dass sie einen Beitrag leisten, sollten sie ggf. wiederholt und intensiviert werden können, leisten sie keinen erkennbaren Beitrag muss es möglich sein, sie unbürokratisch zu variieren oder zu verwerfen. Auf keinen Fall dürfen sie zum Selbstzweck werden.

Der Vollständigkeit halber sei noch erwähnt, dass diese Art mit Objectives and Key Results zu arbeiten weder die einzige ist, noch eine die per Definition besser als andere Vorgehensweisen wäre. Es ist aber eine, mit der sich die Verbindung zwischen OKRs und Alltagsgeschäft gut herstellen lässt. Wer in diesem Bereich Verbesserungspotential sieht, kann daher einen Versuch wagen und überprüfen, wie gut dieser Ansatz für ihn funktioniert - idealerweise anhand von im voraus definierten Erfolgskriterien.

¹Ein naheliegender Ansatz ist die Nutzung der Key Results als Sprintziele in Scrum

Ein Bild sagt mehr als 1000 Worte (XLVII)

Grafik: Manu Cornet / Bonkersworld.net - CC BY-NC-ND 3.0

Das wirklich Bemerkenswerte an dieser Darstellung ist ihr Alter - sie ist aus dem Jahr 2011, hat aber bis heute nichts von ihrer Aktualität eingebüsst. Ein zeitloser Klassiker.

Change Management (II)

Grafik: Pixabay / Mohammed Hassan - Lizenz

Change Management ist einer dieser Begriffe, die je nach Betrachtungsweise unterschiedliche Bedeutungen haben können - von denen aber keine einzige die "offiziell richtige" ist. Das kann Gespräche und Vorhaben zu diesem Thema leicht in Missverständnisse führen. Um das zu vermeiden hilft es, sich die verschiedenen möglichen Bedeutungen bewusst zu machen, um auf dieser Basis gemeinsam explizit zu machen, welche man gerade meint.

Eine Möglichkeit sich dem zu nähern ist die Frage, was genau im Change Management eigentlich "gemanaged" wird, denn das ist tatsächlich keineswegs so eindeutig wie es auf den ersten Blick scheinen mag (der Grund dafür ist die Vieldeutigkeit des englischen Wortes "Management", der nicht-Muttersprachlern zum Teil nicht bewusst ist). Gegenstand des Change Managements können nämlich sowohl die Veränderungen selbst sein, als auch der Umgang mit ihnen.

Die erste Variante dürfte auch die eingängigere sein. In ihr ist Change Management die Summe aller Tätigkeiten, durch die Veränderungen auf Organisationsebene (Team, Abteilung, Firma, etc.) ausgelöst, verhindert, begleitet, durchgeführt, verstärkt, abgeschwächt, beendet oder verstetigt werden sollen. Diese Art von Tätigkeiten ist im klassischen Projektmanagement häufig Teil eines Change Management Plans, dessen Einhaltung Gegenstand von Controlling und Reporting ist.

Die zweite Variante ist in gewisser Weise eine Äquivalenzklasse zu Konzepten wie Stress Management und Anger Management und kann sich ggf. mit diesen überschneiden. In ihr ist Change Management ein auf individueller Ebene stattfindender (und ggf. professionell begleiteter) Prozess, in dem es darum geht, zu erkennen, ob und wie man von Veränderungen betroffen ist, welche persönlichen Konsequenzen sich daraus ergeben und wie man mit ihnen stress- und frustrationsvermeidend umgehen kann.

Je nach Art der Veränderung kann die zweite Variante auch eine soziale Dimension haben, also ganze Gruppen betreffen, die dann gemeinsam einen Weg finden müssen, damit umzugehen. Das ist vor allem dann der Fall, wenn gemeinsame identitätsstiftende Elemente sich ändern oder ändern sollen, zum Beispiel (organisatorische) Zugehörigkeiten, Ziele und Aufgaben, aber auch Überzeugungen, Identitäten, Gewohnheiten oder Erwartungen.

Man kann schnell erkennen, dass diese beiden Varianten des Change Managements vollkommen unterschiedliche Notwendigkeiten, Herausforderungen und Rahmenbedingungen mit sich bringen, und ggf. sogar gegenläufig zueinander sein können, etwa dann, wenn auf organisations-Ebene Veränderungen schnell vorangetrieben werden sollen, während auf Personen- oder Gruppenebene der Wunsch vorherrscht, diese zu verlangsamen, um sich besser auf sie einstellen zu können.

Wenn Veränderungsvorhaben auf den Weg gebracht werden, kann es daher eine gute Idee sein, zu Beginn ein gemeinsames Verständnis darüber herzustellen, was in diesem Fall unter dem Begriff Change Management verstanden wird. Das mag zwar etwas abstrakt und theoretisch wirken, auf lange Sicht kann man sich dadurch aber einiges an Missverständnissen und Konflikten ersparen, wodurch die Veränderungsarbeit dann einfacher und tendenziell auch erfolgreicher wird.

Agile ≠ Improvement

Bild: Unsplash / Jessica Gale - Lizenz

Ich kann es nicht mehr genau nachvollziehen, aber mittlerweile dürfte ich über hundert Job-Interviews mit Scrum Mastern, Agile Coaches und Inhabern ähnlicher Rollen geführt haben, sowohl für meine eigene Firma als auch für verschiedene Kunden. Und selbst wenn es die eine entscheidende Antwort auf sie nicht gibt, mit der Zeit habe ich eine Frage gefunden, mit der sich gut feststellen lässt, ob mein aktueller Gegenüber wirklich verstanden hat, was es mit dem Konzept der Agilität auf sich hat.

Sie ist relativ einfach: "Gibt es irgendeinen Kontext, in dem es nicht sinnvoll ist, agil zu arbeiten?" Erstaunlich viele Bewerber verneinen das und versteifen sich darauf, dass es immer sinnvoll wäre, agil vorzugehen. Und wenn man darum bittet, das zu erklären, erfolgt fast immer die selbe Erläuterung: "Es gibt immer irgendetwas, was man besser machen kann. Deshalb ist es grundsätzlich in jeder Situation eine gute Idee, agil vorzugehen".

Der grundsätzliche Denkfehler, der dieser Argumentation zu Grunde liegt (und durch den man zeigt, die Idee der Agilität noch nicht zur Gänze verstanden zu haben) ist die Gleichsetzung von agilem Arbeiten mit der Suche nach Verbesserungspotential. Dabei handelt es sich allerdings um eine Verwechselung der notwendigen und der hinreichenden Bedingung. Wer agil arbeiten will, muss zwar nach Verbesserungen suchen, aber nicht jeder der nach Verbesserungen sucht, arbeitet agil.

Um das zu erläutern: eine agile Vorgehensweise unterscheidet sich von der blossen Suche nach Verbesserungspotential durch zwei Eigenschaften: sie findet kontinuierlich statt und sie ist potentiell disruptiv. Und auch die lassen sich nochmal besser erläutern, angefangen mit der ersten. Eine Suche nach Verbesserungen könnte auch jährlich oder quartalsweise stattfinden. Um das agil-typische ständige Inspect & Adapt zu erfüllen reicht das aber nicht - kontinuierlich bedeutet hier eher monatlich.¹

Jetzt zur zweiten, etwas schwerer zu erklärenden Eigenschaft: die blosse Suche nach Verbesserungen kann auch lediglich auf Effizienzsteigerungen ausgerichtet sein, also darauf, einfach schneller und reibungsloser zu arbeiten. Agiles Arbeiten ist dagegen auf Effektivitätssteigerung ausgerichtet, also auf die Frage, ob überhaupt noch am richtigen Thema gearbeitet wird, oder ob sich Rahmenbedingungen oder Ziele inzwischen so geändert haben, dass man eine grundsätzlich andere Richtung einschlagen solllte.

Diese Möglichkeit, die bisher verfolgten Zielsetzungen anzupassen, ist das, was agiles Arbeiten disruptiv macht. Und da diese Richtungsanpassung nichts ist, was man bei jeder Verbesserungsbemühung zwangsläufig machen sollte, sondern nur dann, wenn man darin einen Sinn erkennt, ist Agilität nicht zwangsläufig disruptiv sondern lediglich potentiell disruptiv. Es kann zu einer grundsätzlichen Anpassung kommen, es muss aber nicht. Notwendige und der hinreichende Bedingung.

Um auch die anderen Vorgehensmodelle beim Namen zu nennen - seltene (bzw. nicht-kontinuierliche) Veränderungen entsprechen dem klassischen Verbesserungsmanagement, dessen explizites oder implizites Ziel die (Wieder-)Herbeiführung eines stabilen Zustandes ist. Und kontinuierliche, aber nicht disruptive Optimierungen finden sich im Lean Management, das einen gleich bleibenden Ablauf nach und nach immer effizienter machen will.

Diese drei Typen (agiles Arbeiten, klassisches Verbesserungsmanagement und Lean Management) unterscheiden zu können ist etwas, das jeder Scrum Master oder Agile Coach eigentlich beherrschen sollte - zumindest dann, wenn er in einer beratenden Funktion arbeitet, sei es extern (wie in meiner Firma) oder intern (als Change Agent innerhalb einer Organisation). Kann man das noch nicht ist das zwar kein Drama, aber ein deutlicher Hinweis darauf, wo noch dazugelernt werden muss.

¹Wenn sich gerade jemand fragt, woher diese Festlegung kommt - aus dem Manifest für agile Softwareentwicklung, dem Gründungsdokument der agilen Bewegung.

Working on Software in the Desert and the Forest

Zu den wichtigsten Praktiken des Extreme Programming gehört der Einsatz von Metaphern, mit deren Hilfe man komplexe Sachverhalte einfach erklären kann. Zu den prominenteren Beispielen der letzten Zeit gehören dabei the Desert and the Forest von Kent Beck und Beth Andres-Beck. Der Wald (Forest) steht dabei für eine Umgebung, in der moderne Software-Entwicklungspraktiken möglich sind, während sie in der Wüste (Desert) nicht angewandt werden können. In diesem Konferenz-Vortrag erklären sie, was sich hinter diesen Metaphern verbirgt.

Erwähnenswert ist dabei ihre Einordnung ihres Konzepts in die Realitäten der Softwareentwicklung in vielen Firmen. Die Wüste gilt bei ihnen nicht als etwas per se Schlechtes, sondern als etwas was historisch gewachsen ist, durchaus Ergebnisse bringen kann (wenn auch relativ langsam) und durch die richtigen Entscheidungen nach und nach zu einem Wald werden kann.

Bürokratisierung der Entbürokratisierung

Vor einiger Zeit reifte in einer Behörde, deren IT-Projekte ich begleiten durfte, die Einsicht, dass die eigenen Prozesse zu starr und zu langwierig waren. Um dem zu begegnen wurde ein neues "Referat für den Abbau von Bürokratie" geschaffen, das dem entgegenwirken sollte. Seine erste Amtshandlung bestand darin, alle anderen Referate anzuweisen, alle ihre Arbeitsabläufe detailliert zu dokumentieren. Auf Basis dieser Dokumente sollte dann entschieden werden, wo Bürokratie abgebaut werden könnte.

Dieses widersinnige Vorhaben (das nicht zu weniger sondern zu mehr Verwaltungsaufwand führte) gehört zu einem Trend, den der Soziologie-Professor Stefan Kühl treffend als "Bürokratisierung der Entbürokratisierung" beschrieben hat. Hinter ihm verbergen sich die zunehmend verbreiteten Massnahmen, Bürokratieabbau, Digitalisierung, Effizienzzsteigerung und ähnliche Dinge dezidierten Organisationseinheiten zuzuordnen - und damit versehentlich alles nur noch schlimmer zu machen.

Diese Verschlimmerung ergibt sich aus verschiedenen, mit grosser Wahrscheinlichkeit eintretenden Dynamiken. Zunächst gibt es für die neue Zentraleinheit starke Anreize, Informierungs-, Beteiligungs- und sonstige Pflichten anzuordnen, wodurch es wie im Fall des oben genannten Bürokratieabbau-Referats dazu kommen kann, dass alleine der dadurch notwendige Kommunikationsaufwand zu der perversen Konsequenz führt, dass alles ineffizienter wird statt effizienter.

Wenn es darüber hinaus dazu kommt, dass nicht nur über die eigenen Prozesse berichtet werden muss, sondern Änderungen an ihnen zentral begutachtet und ggf sogar genehmigt werden müssen, wird die dafür zuständige Einheit zu einem verlangsamenden Flaschenhals für alle anderen. Schlimmstenfalls kann es dazu kommen, dass selbst dringende und von allen gewollte Änderungen lange verzögert werden, weil die für die Freigabe zuständigen Personen überlastet sind.

Als Folge dessen kann es sogar zu nochmals weiteren Verschlechterungen kommen: um eine eigene Überlastung zu verhindern oder abzubauen neigen viele Zentraleinheiten dazu, der restlichen Organisation einheitliche Vorgehensmodelle oder Berichtsformate vorgeben zu wollen, um deren Lage einfacher verstehen und vergleichen zu können. Diese Vereinheitlichung kann oft nur auf Kosten der optimalen Bedienung der lokalen Bedürfnisse erreicht werden.

Gleichzeitig entstehen demotivierende Auswirkungen für die dezentralen Einheiten. Wenn plötzlich alle eigenen Verbesserungsbemühungen zu Dokumentations- und Kommunikationsmehraufwand führen und darüber hinaus befürchtet werden muss, dass von aussen gut gemeinte Verschmlimmbesserungen stattfinden, dann ist das ein Anreiz, solche Bemühungen gar nicht mehr (oder nur lokal, unangekündigt, unabgestimmt und intransparent) durchzuführen.

Zuletzt stehen Bürokratieabbau-Einheiten aufgrund der mit ihnen verbundenen Erwartungen und Aufwände unter hohem Erfolgsdruck, der (vor allem dann wenn die Erfolge Voraussetzung für Gehalts-, Karriere- und Statusverbesserungen sind) dazu führen kann, dass Fortschritte aufgebauscht und voreilig oder wahrheitswidrig verkündet werden, mit der Folge, dass vordergründig Verbesserungen stattzufinden scheinen, während in Wahrheit Verspätung, Stillstand und Verschlechterungen vorherrschen.

Die Zuordnung von Bürokratieabbau, Digitalisierung, Effizienzzsteigerung, etc. zu dezidierten Organisationseinheiten ist aus all diesen Gründen mit dem hohen Risiko verbunden, das Gegenteil des Angestrebten zu erreichen. Ein wesentlich besserer Weg kann es sein, dezentrale Freiräume für Verbesserungsbemühungen (incl. Zeit und Budget) zu schaffen, alleine verbunden mit der Bedingung einer transparenten Durchführung, um auf versehentliche Fehlentwicklungen hinweisen zu können.

Und um Missverständnissen vorzubeugen - Referate die den Abbau von Bürokratie bürokratisieren gibt es nicht nur in der staatlichen Verwaltung, sondern auch in der freien Wirtschaft. Sie tragen dort nur andere Namen, z.B. Prozessmanagement, Inhouse Consulting, Betriebsorganisation oder Agiles Transitionsteam.

Nachtrag 24.04.2025:

Stefan Kühl hat seine Gedanken zur Bürokratisierung der Entbürokratisierung im Sozialtheoristen-Blog präzisiert.

Business Owner (BO)

Bild: Wikimedia Commons / JCS - CC BY 3.0

Sobald agiles Arbeiten über die Teamebene hinaus in einem Unternehmen etabliert werden soll, stossen praktisch alle agilen Frameworks auf das immer gleiche Problem: oberhalb der Teams und um die Teams herum gibt es vor allem in grösseren Firmen eine unberschaubare Zahl von Management-Rollen. Teilprojekt-, Projekt- und Programmleiter, Test-, Release- und Security Manager, Heads of Legal, Product und Sales, Team- Abteilungs- und Bereichsleiter und viele, viele mehr. Was macht man jetzt mit denen?

In den meisten Fällen gibt es darauf keine klaren Antworten; Scrum, Kanban, DevOps und fast alle weiteren agilen Vorgehensmodelle befassen sich einfach nicht mit diesem Thema, was Unklarheit und Unsicherheit zur Folge hat. Schlimmstenfalls erwächst aus dieser Unklarheit sogar ein Konflikt - wenn den verschiedenen Managern gesagt wird, dass sie im Umfeld selbstorganisierter Teams bald nicht mehr benötigt werden, werden die meisten von ihnen natürlich um ihren Status und ihre Karriere kämpfen.

Und auch das gehört dazu: viele der bisherigen Management-Aufgaben können nicht so einfach dezentral in alle Teams delegiert werden. Irgendjemand muss die grossen strategischen Entscheidungen treffen, irgendjemand muss Ansprechpartner für Gehaltsverhandlungen, Beförderungen, Versetzungen und Eskalationen sein, und irgendjemand muss letzten Endes die Verantwortung tragen, wenn es um zivilrechtliche Haftungsfragen geht, etwa wegen Verstössen gegen Arbeitsschutz oder Compliance.

Das meines Wissens nach einzige agile Framework, dass diese Umstände in seinem Regelwerk berücksichtigt (wenn man von einigen offensichtlich nur halb-ernst gemeinten Management-Rollen in Extreme Programming absieht) ist das Scaled Agile Framework/SAFe, in dem eine Rolle enthalten ist, die einen Grossteil der oben genannten Verantwortungen enthalten kann - wenn auch nicht in jedem Fall enthalten muss. Die Rede ist von dem Business Owner (BO).

Auf der entsprechenden Website beschreibt SAFe fünf Aufgabenbereiche, die ein BO haben kann: Leading by Example, Engaging in Lean Portfolio Management, Aligning Priorities & PI Planning, Realizing Business Outcomes und Sponsoring Relentless Improvement. Wie vieles andere in diesem Framework ist das im Folgenden gleichzeitig hinreichend unkonkret um individuell ausgestaltet zu werden und spezifisch genug um "agile Puristen" zu provozieren.

Zu den hinreichend unkonkreten Formulierungen, mit denen die fünf Aufgabenbereiche beschrieben werden, gehören beispielsweise mehrere, in denen davon die Rede ist, durch eigenes Verhalten ein Vorbild zu sein, Visionen zu kommunizieren, anderen Führungsrollen zu helfen, den Geschäftskontext zu vermitteln, den Teams Feedback zu geben und andere zu motivieren. Dahinter kann sich alles Mögliche verbergen, von der Sonntagsrede bis zur Hands On-Unterstützung.

Provozierend für agile Puristen sind weitere Formulierungen, die implizieren, dass die Business Owner Aufgaben übernehmen können, die auch von selbstorganisierten Teams direkt übernommen werden könnten. Das Vermitteln bei internen Konflikten und Widerständen gehört dazu, das Organisieren teamübergreifender Communities of Practice, Stakeholdermanagement, Abhängigkeitsmanagement, die Beseitigung von Impediments, die Definition von KPIs und die Optimierung von Arbeitsflüssen.

Während diese beiden Aufgabenbereiche diskutierbar und ggf. verzichtbar sind, gibt es aber einen dritten, der unverzichtbar und entscheidend ist - das Schaffen optimaler Rahmenbedingungen: Business Owner sind zuständig für die Bereitstellung von ausreichend Budget, Personal und Ressourcen, für das Setzen und Anpassen strategischer Ziele sowie für das Beseitigen demotivierender Vorschriften und Prozesse. Das sind Schlüsseltätigkeiten, auf deren Basis Selbstorganisation überhaupt erst möglich ist.

Insgesamt ergibt sich so ein für SAFe typisches Bild: mit der BO-Rolle werden Dinge thematisiert und formalisiert die wichtig sind, in anderen agilen Frameworks aber nicht erwähnt werden. Gleichzeitig sind sie aber eingebettet in eine Menge weiterer derartig unscharf formulierter Vorgaben, dass auf deren Basis praktisch alles möglich ist, unterstützender von Hilfe zur Selbstorganisation bis hin zu übergriffigem Hineinregieren in die Teams.

Um das Positive darin zu sehen - wenn man im Unternehmen ein Management mit einer (aus einer "agilen Perspektive") "richtigen" Einstellung hat, kann man seine Mitglieder als Business Owner auf passende, hilfreiche und sinnstiftende Weise einbinden. Wenn auf der anderen Seite eine eher "falsche" Einstellung vorherrscht, würde auch ein methodischer Rahmen ohne diese Rolle nur in begrenztem Ausmass für Verbesserung sogen. In diesem Sinn: gebt den BOs eine Chance.

Vibe Coding

Es kommt nicht mehr oft vor, dass eine neue Art der Software-Programmierung erfunden wird, aber es kommt vor, zuletzt im Februar 2025 durch Andrej Karpathy, einen slowakisch-kanadischen Software-Entwickler und ehemaligen Manager von Tesla und OpenAI. Der neue Programmier-Stil wurde von ihm in einem Posting im Social Nework X zum ersten mal beschrieben und Vibe Coding genannt. In kurzer Zeit erreichte er weitgehende Bekanntheit. Hier ist seine Beschreibung:

Zu Deutsch: Vibe Coding benötigt eine künstliche Intelligenz mit Spracherkennung. In der Interaktion mit dieser gibt man sich ganz seiner gegenwärtigen Stimmung (den Vibes) hin, äussert Wünsche und Vorstellungen und und lässt die KI auf diese Weise fast ausschliesslich durch Spracheingabe ein Stück Software erstellen, das dann irgendwann mehr oder weniger fertig und lauffähig ist. Mit Karpathys eigenen Worten: "just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works".

Aufbauend auf diesen Beitrag kam es in kurzer Zeit zu zahlreichen Artikeln in Medien wie Fortune, Forbes, TechCrunch und New York Times, die grossteils den selben Tenor hatten: Programmieren lernen ist nicht mehr nötig, auch als Laie kann man jetzt Software erstellen. Viele dieser Beiträge waren ausserdem verbunden mit marktschreierischen Verheissungen (jeder kann jetzt ein Startup gründen und reich werden) oder Untergangsszenarien (alle Entwickler werden bald arbeitslos sein).

Dass all das erkennbar an der Realität vorbeigeht hätte man dabei bei einem sorgfältigeren Lesen von Karpathys Post leicht erkennen können. Wie er selbst schreibt und wie kritische Stimmen bald anmerkten führt Vibe Coding dazu, dass selbst der "Urheber" nicht mehr genau sagen kann, wie sein Code entstanden ist und was er im Detail tut. Im besten Fall führt dieser Blindflug zu vielen kleinen Bugs, im schlechtesten Fall zu schweren Fehlfunktionen. Zum Herumspielen ist das gut, zu mehr aber nicht.

In diesem Herumspielen steckt allerdings auch eine Potential, das man nicht verachten sollte: mit Vibe Coding erstellte Anwendungen taugen zwar nicht für echte Markt- oder Produktions-Anwendungen, was sie aber sein können sind erstaunlich realitätsnahe Prototypen, mit denen man in Product Discovery oder Lean Startup Nutzerbedürfnisse und Nutzungsbereitschaft evaluieren kann, um sich dann schnell dem Bedarf anzupassen - frühe Entwicklungsphasen lassen sich so deutlich beschleunigen.

Und was ebenfalls oft nicht ausreichend beachtet wird: das "Programmieren" mit Hilfe gesprochener Prompts führt dazu, dass Anforderungen wesentlich klarer und präziser formuliert werden müssen als das in den meisten klassischen Anforderungs-Dokumenten der Fall ist, die oft eher kryptisch, verschachtelt und inkonsistent sind. Am Ende hat man im Vibe Coding also gleich zwei Ergebnisse - einen vorführbaren Prototyp und klarer formulierte Wünsche und Anforderungen.

Natürlich entspricht das bei weitem nicht den oben genannten, durch marktschreierische Berichterstattung hervorgerufenen Erwartungen oder Befürchtungen. Es ist aber in mehrfacher Hinsicht eine deutliche mögliche Verbesserung im Vergleich zum Ist-Zustand. Um eine Prognose zu wagen: als Buzzword wird Vibe Coding wieder verschwinden, die möglichen Mehrwerte werden aber bleiben und auf einem geringeren Aufmerksamkeits- und Verheissungsniveau zu deutlichen Verbesserungen führen.

Kommentierte Links (CXXV)

Grafik: Pixabay / Brian Penny - Lizenz

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.

Lavaneesh Gautam: Behind the Bottlenecks - The Root Causes of Dependencies in Teams

In komplexen Umgebungen ist es sehr häufig so, dass sich hinter scheinbar einfachen Begriffen erstaunlich vielschichtige Sachverhalte verbergen. Dass das auch im Fall der Abhängigkeiten so ist arbeitet Lavaneesh Gautam sehr schön heraus: je nachdem ob sie durch berufliche Spezialisierung, geteilte Verantwortlichkeiten, Architektur-Muster oder Organisationsdesign verursacht werden, können sie sehr unterschiedliche Formen annehmen und unterschiedliche Behandlung erfordern.

Roman Pichler: Setting up Product Teams for Success

Seit einigen Jahren haben die Konzepte von agiler Entwicklung und Product Thinking begonnen sich mehr und mehr zu überlagern. Dieser Artikel von Roman Pichler könnte daher auch "Setting up agile Teams for Success" heissen, die relevanten Parameter sind die gleichen. Wie immer sollte man das Ganze nicht unreflektiert als Blaupause benutzen, es ist aber einguter Denkanstoss.

Militarnyi: Saab Develops Anti-Aircraft System in Record 84 Days

Ich bin schon lange überzeugt, dass agiles Arbeiten überall möglich ist, wenn der Sense of Urgency gross genug ist. Ein (drohender) Krieg ist leider gerade der unter diesen Treibern, der stark zunimmt. Als Ergebnis sehen wir plötzlich auch bei hochkomplexen Produkten Entwicklungsgeschwindigkeiten, die wir noch vor wenigen Jahren für unmöglich gehalten hätten. Und die Erfolgsmechanismen sind die bekannten: Modularität, Einfachheit des Designs und Entscheidungsspielraum der Umsetzungsmannschaft.

Pawel Rola: Product Backlog Management with Upstream Kanban – From Chaos to Clarity

Mal wieder ein Klassiker. Pawel Rola erklärt sehr gut nachvollziehbar, wie die Nutzung von Kanban-Praktiken dafür sorgen kann, dass der Anforderungsmanagement-Prozess eines agilen Teams transparenter, expliziter und flüssiger werden kann. Und das sogar in Übereinstimmung mit den Vorgaben, die Scrum für ein Product Backlog macht - man muss es einfach nur horizontal abbilden statt vertikal, und alles passt wunderbar zusammen.

John Ward: Agile marketing - The source of enterprise agility

Als Letztes etwas zum Nachdenken. John Wards Idee, dass Enterprise Agility (also die Fähigkeit einer Gesamtorganisation, sich schnell an Veränderungen anzupassen) nur unter Einbezierung des Marketings möglich ist, ist naheliegend. Das Marketing dabei als treibende Einheit zu sehen ist aber eher selten, diese Rolle haben meistens eher IT oder HR. Ein interessanter Ansatz.

The Law of unintended Consequences

Bild: Flickr / McKinney75402 - CC BY 2.0

Unter den verschiedenen "Gesetzmässigkeiten", die in Projektmanagement-Kreisen gerne zitiert werden, nimmt das Gesetz der unbeabsichtigten Konsequenzen eine Sonderstellung ein. Anders als fast alle anderen (Conway's Law, Gall's Law, Goodhart's Law, etc) ist es nicht nach einer Person benannt, die es erfunden und popularisiert hat, sondern ist nach und nach in den Wirtschafts- und Sozialwissenschaften entwickelt worden, u.a. von John Locke, Adam Smith und Friedrich Hayek.

Sie alle hatten unabhängig voneinander die folgende Einsicht: wer in komplexen, vernetzten oder volatilen Systemen Veränderungen vornimmt, der wird nicht nur den Effekt erzielen den er beabsichtigt,¹ sondern auch andere, unbeabsichtigte. Zu einem "Gesetz" wird es dadurch, dass diese ungewollt eintretenden Konsequenzen praktisch unvermeidbar sind, einzig ihre Art und Intensität kann von Fall zu Fall anders sein. Vereinfacht gesagt sind mindestens sechs verschiedene Varianten möglich:

Unerwartete positive Konsequenzen

Der beste Fall der eintreten kann, in ihm treten positive Effekte auf, mit denen man gar nicht gerechnet hatte. Ein Beispiel wäre ein Sparkurs, durch den ein Grossprojekt auf nur noch wenige Teams zusammenschrumpft. Da diese jetzt jeweils mehr Themengebiete abdecken müssen, werden sie crossfunktionaler und weniger arbeitsteilig, wodurch nicht nur die Personalkosten sinken, sondern auch der bisherige Koordinationsaufwand und mit ihm weitere Kosten.

Unerwartete negative Konsequenzen

Das Gegenteil des ersten Falls. Ein Beispiel dafür wäre die Neueinführung gehaltsrelevanter Ziele für einzelne Mitarbeiter. Die arbeiten dann zwar mit gesteigerter Motivation an diesen Zielen, aber das im Zweifel auch auf Kosten der gemeinsamen Team- oder Unternehmensziele. Ein Sicherheitsbeauftragter, der für jeden gefundenen Regelverstoss belohnt wird, hat etwa einen starken Anreiz, seine Kollegen mit einer lähmenden und demotivierenden Kontroll-Bürokratie zu überziehen.

Unerwartete perverse Konsequenzen

Eine derartige Übersteigerung der negativen Konsequenzen, dass es sogar zu einer Verschlechterung in dem Bereich kommt, der eigentlich verbessert werden sollte. Ein bekannter Fall der Versuch, durch die Einführung von gemeinsamen Grossraumbüros die Kommunikationsbarrieren zwischen Mitatarbeitern abzubauen. Forschungsergebnisse zeigen, dass das Gegenteil der Fall ist - um den Geräuschpegel auszublenden werden Headsets aufgesetzt, wodurch die Kommunikation sogar zurückgeht.

Unerwartete positive Seitenauswirkungen

In diesem Fall treten unbeabsichtigte positive Effekte auf, die ihre Auswirkungen in einem anderen Bereich entfalten als dem, in dem die Veränderungen stattgefunden haben. So können Programme zur Förderung von Achtsamkeit und Sorgfalt nicht nur zu geringeren Fehlerquoten bei der Arbeit führen, sondern auch zu einem generell bewussteren und verantwortungsvolleren Konsumverhalten, wodurch im Privatleben der Beteiligten weniger Haushaltsmüll erzeugt wird.

Unerwartete negative Seitenauswirkungen

Wieder das Gegenteil des letzten Falls, hier tretennegative Effekte in einem anderen Bereich auf als dem, in dem die Veränderungen stattgefunden haben. Wenn eine Firma beispielsweise Kosten senken will indem sie von externen Mitarbeitern Gebühren für die Nutzung des eigenen Parkhauses verlangt, wird sie dadurch die Verkehrs- und Parkplatz-Situation in der Nachbarschaft verschlechtern, da auf die hier befindlichen Pakkplätze ausgewichen wird.

Sonstige unerwartete Seitenauswirkungen

Auch das gibt es - unbeabsichtigte Auswirkungen auf andere Bereiche als den, in dem die Veränderungen stattgefunden haben, die weder positiv noch negativ sind. Ein anschaulicher Fall dafür wäre eine Firma, die im Rahmen eines Corporate Design-Relaunch die Farbe ihrer Dienstwagen von Gelb zu Grün ändert. Das Strassenbild der Umgebung wird das zwar verändern, allerdings nicht zum Besseren oder Schlechteren, es sieht einfach nur anders aus.

Welche auch immer es sind, die Gemeinsamkeit der verschiedenen unbeabsichtigten Konsequenzen ist, dass sich weder ihre Art noch die Schwere ihrer Auswirkungen vorhersagen lassen. Dort wo in komplexen, vernetzten oder volatilen Systemen Veränderungen vorgenommen werden, ist es daher eine gute Idee, regelmässig zu überprüfen, ob derartige Effekte auftreten. Nur dann ist es möglich ggf. schnell Gegenmassnahmen zu ergreifen. Auch hier gilt also wieder: Inspect & Adapt.

¹Falls der überhaupt eintritt