On Lean and Agility

Zu den vielen Herausforderungen des Change Managements gehört es, die herbeigeführten Veränderungen auch dauerhaft zu verankern. Idealerweise geschieht das dadurch, dass alle Beteiligten den Sinn in ihnen erkennen und sie von sich aus beibehalten wollen. Was kann man aber für die Beibehaltung tun, wenn das nicht der Fall ist, und die Betroffenen die Veränderung wieder loswerden wollen? Nun, ein Beispiel dafür kann man gerade in meiner Heimatstadt Bonn beobachten.

Für diese Anekdote muss man verstehen, dass hier seit einiger Zeit bei jeder Wahl die jeweilige Stadtregierung abgewählt wird und stattdessen die bisherige Opposition an die Macht kommt. Und da die beiden grossen Lager (die bürgerlichen und die linken Parteien) vor allem beim Verkehr diametral unterschiedlicher Meinung sind, wird jedesmal ein Teil der Massnahmen der jeweils letzten Stadtregierung wieder rückgängig gemacht.

Auch der zuletzt gewählte CDU-Oberbürgermeister ist vor allem mit dem Versprechen angetreten, die von seiner grünen Amtsvorgängerin eingeführten verkehrsbehindernden Massnahmen, mit denen verhindert werden solllte, dass die Menschen mit dem Auto in die Stadt fahren, wieder rückgängig zu machen. Dazu gehörte vor allem der Rückbau der neu angelegten extrem breiten Fahrradspuren, durch die mehrere Hauptstrassen für die Autos nur noch einspurig befahrbar waren.

Das erwies sich aber schwerer als gedacht - durch das Aufbringen von einer roten Schicht auf dem Asphalt waren die Radwege derartig markant von der eigentlichen Strasse abgehoben, dass die neue, wieder zweispurige Strassenführung mit schmalerem Radstreifen nicht gut erkennbar war. Wie man der Lokalzeitung entnehmen kann waren viele Autofahrer so irritiert, dass sie sich nicht trauten, ihre neuen Spuren zu nutzen - jetzt muss die rote Schicht abgefräst werden, was teuer wird und lange dauert.

Auch an anderen Stellen wurde durch gezielte Baumassnahmen verhindert, dass der ursprüngliche Verkehrsfluss einfach wiederhergestellt werden konnte. Neben dem Busbahnhof wurde beispielsweise ein Bürgersteig auf die bis dahin zweispurige Cityring-Strasse gebaut und genau auf diese Stelle eine überdachte Wartebank gesetzt. Ein Rückbau würde an dieser Stelle schweres Gerät erfordern und ebenfalls langwierig und teuer werden.

Was hier gemacht wurde entspricht wortwörtlich einem Vorgehen, das man umgangssprachlich das "Einbetonieren von Veränderungen" nennt. Es wird vor allem dort angewandt, wo die Treiber dieser Veränderungen befürchten müssen, die Entscheidungsgewalt zeitnah an Gruppen mit anderen Interessen zu verlieren. Durch Massnahmen, die eim Rückgängigmachen der Veränderungen verteuern, aufwändig machen und lange dauern lassen, wird dann versucht, dieses zu behindern.

Das Beispiel aus Bonn ist ein besonders offensichtliches für das Einbetonieren von Veränderungen, es gibt aber auch zahlreiche weitere, die man vor allem in grossen Organisationen und Behörden vorfinden kann. Ein Klassiker ist etwa das Verankern einer Veränderung in formalen Regeln wie z.B. einer Betriebsvereinbarung, wodurch sie sich nur noch im Rahmen eines formalisierten und langwierigen Prozesses gemeinsam von Management und Betriebsrat modifizieren lässt.

Auch das Zusammenlegen, Aufteilen, Neuschaffen, Auflösen oder Auslagern von Organisationseinheiten, die mit bestimmten Zwecken verbundenen sind, ist häufig anzutreffen. In solchen Fällen würde ein Rückgängigmachen Versetzungen, Entlassungen, (Wieder-)Einstellungen oder Arbeitsvertrags-Änderungen erfordern - der damit verbundene Aufwand wird von vielen Entscheidungsträgern so sehr gescheut, dass sie lieber nichts tun.

Zuletzt ist auch die Einführung prozessbegleitender Software ein probater "Beton", vor allem dann, wenn es sich bei genauerer Betrachtung um eine Prozess-erzwingende oder -verhindernde Software handelt. "Dafür gibt es in SAP kein Feld" oder "das kann Jira nicht darstellen" sind verblüffend mächtige Argumente, wenn begründet werden muss, warum Vorschriften und Abläufe nicht wieder auf einen früheren Zustand zurückgesetzt werden können.

Um Missverständnissen vorzubeugen: ich sympathisiere nicht mit dem Einbetonieren von Veränderungen, und ich würde es auch niemandem raten - selbst dann nicht, wenn damit etwas "geschützt" werden soll, das ich für richtig halte. Da es aber eine weit verbreitete Praktik ist, macht es Sinn, sie beim Namen zu nennen. Und sei es auch nur um einen Aufhänger für ein Gespräch darüber zu bekommen, was man stattdessen tun könnte um Veränderungen dauerhaft zu verankern.

Nachtrag:

Eigentlich geht es mir hier um ein Antipattern im Change Management und nicht um die Spezifika des Fahrradspurenbaus. Da mir mittlerweile aber mehrfach gesagt wurde, diese Spuren müssten immer Rot sein, oder stadtweit einheitlich sein - das kann nicht stimmen, auch in Bonn gibt es einige, die nur mit den leicht zu entfernenden weissen Streifen markiert sind. Übrigens auch von der grünen Oberbürgermeisterin gebaut, wie hier an der Oxfordstrasse:

Es ist gerade wieder die Zeit des Jahres, in der ich mich über den Umgang mit der staatlichen Bürokratie freuen kann, denn die Verlängerung der Arbeitnehmerüberlassungs-Lizenz steht an. Was das ist und warum es Unternehmensberatungen wie meiner aufgezwungen wird wäre nochmal ein eigenes Thema, was mir bei der Durchführung jedesmal ins Auge springt ist aber, dass es sich um ein extremes Beispiel von Conway's Law handelt.

Unter diesem Gesetz versteht man das immer wieder anzutreffende Muster, dass Organisationen ihre Software spiegelbildlich zu ihren Organisationsstrukturen oder Kommunikationsflüssen aufbauen. Mit anderen Worten: zu jeder Teilorganisation gehört auch ein spezifischer Teil der Gesamt-Software, und da jede Teilorganisation ihren Softwareteil vor allem für sich selbst optimiert, wird die Benutzererfahrung uneinheitlich und dadurch kompliziert und verwirrend.

Bei der Arbeitnehmerüberlassungslizenzverlängerung kann man das in Reinform beobachten. Man beginnt auf einer Seite der Bundesagentur für Arbeit und wird von dort für das Einloggen zum Behörden-Identifikationsdienst Bund ID weitergeleitet. Auch der leitet aber weiter, und zwar zur deutschen Ausweis-App, bei der der Login endlich stattfindet. Alle drei Dienste (Arbeitsagentur-Seite, Bund ID und Ausweis-App) haben völlig unterschiedliche Aussehen und Abläufe.

Als jemand der sein Geld in der Software-Industrie verdient bekomme ich das zwar jedesmal hin, ob ein normaler Benutzer das auch schaffen würde, habe ich aber immer bezweifelt. Mittlerweile hat sich gezeigt, dass diese Zweifel berechtigt sind. Eine Studie des Vereins NExT, in dem Digitalexperten der öffentlichen Verwaltung zusammengeschlossen sind, zeigt, dass beim Versuch verschiedene "digitale Behördengänge" durchzuführen, bis zu 90 Prozent (!) der Menschen frustriert aufgeben.

Ohne den Begriff Conway's Law zu benutzen, erklären die Verfasser, dass genau das ein Hauptgrund für die hohen Abbruchquoten ist. In ihren Worten: "Die Kernursache ist, dass Digitale Identitäten in Deutschland primär als isolierte, technische Basiskomponenten entwickelt wurden, anstatt sie konsequent Ende-zu-Ende (E2E) aus der Perspektive der Nutzenden in die Verwaltungsservices zu integrieren." Auch eine passende Visualisierung gibt es:

Grafik: NExT - CC BY-NC 4.0

Was aus der Studie noch hervorgeht, ist, dass Conway's Law keineswegs der einzige Frustrationsfaktor ist, es werden also nicht alle Abbrüche ausschliesslich darauf zurückgehen. Da die dadurch bedingten Systembrüche und das Springen zwischen völlig unterschiedlichen Anwendungen als die "Kernursache" identifiziert werden, kann man bei bis zu 90 Prozent Abbrüchen aber davon ausgehen, dass über die Hälfte der Nutzungsversuche den Auswirkungen dieses Gesetzes zum Opfer fallen.

Ich muss gestehen, dass ich diesen Text gerne mit einem optimistischen Ausblick beenden würde, mich aber nicht ganz traue. Auf der einen Seite hört man erfreulich viel Positives über die Arbeit des neuen Digitalministeriums, das sich auch gerade des oben genannten Problems annehmen will, auf der anderen Seite gibt es einen Bericht des Bundesrechnungshofs, der bemängelt, dass ausgerechnet das (noch) nicht geschafft wird. Wir müssen also abwarten, wie sich alles entwickelt.

Bild: Unsplash / Charanjeet Dhiman - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Arbeitswelt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich 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.

Eine die ich vor einigen Jahren erleben durfte, trug sich in "der goldenen Zeit der agilen Transitionsprogramme" zu, als das agile Arbeiten noch neuer und aufregender war als heute und in der Unternehmen zeitweise praktisch alles nach Scrum organisieren wollten. Vieles davon war eher wenig sinnvoll, mitunter waren die Ergebnisse aber auch überraschend gut. In einem derartigen Fall wurde Scrum in einer Einheit eingeführt, auf die man nicht sofort kommen würde: im Kundenservice.

In besagtem Kundeservice hatte die Firma ein nicht unwesentliches Problem - er wurde in fast allen Kundenbefragungen als unterdurchschnittlich schlecht bewertet, allerdings ohne dass dafür ein klarer und sich wiederholender Grund angegeben wurde. Stattdessen waren die Begründungen stark uneinheitlich oder so abstrakt, dass sich aus ihnen nicht eine einzige grosse Massnahme ableiten liess. Es brauchte also ein anderes Vorgehen. Und zufällig war gerade erst eines vorgestellt worden.

Wie alle anderen Mittelmanager in diesem Unternehmen hatte auch die Kundenservice-Abteilungsleitung kurz vorher an einer Scrum-Schulung teilgenommen, mit deren Durchführung ich beauftragt war. Und die Idee von kurzen Sprints, in denen alle Beteiligten gemeinsam auf ein kurzfristig erreichbares Ziel hinarbeiteten, war hängengeblieben. Nach diesem Muster den Service schrittweise zu verbessern schien allen eine gute Idee zu sein, also wurde die Abteilung als Scrum Team neu organisiert.

Ab diesem Punkt wurde alle drei Wochen ein neues Sprintziel gesetzt. Das konnte eine einfachere Formulierung der versandten Briefe sein, die erstmalige Verwendung von Grafiken und Icons in ihnen, ein veränderter Aufbau von Selfservice-Seiten, angepasste Uhrzeiten zu denen das Callcenter erreichbar war, die schriftliche Anrede der Kunden mit Du statt mit Sie, oder vieles mehr. Jede dieser Massnahmen sollte innerhalb eines Sprints umgesetzt werden.¹

Die für diese Einheit umfasste Definition of Done umfasste allerdings nicht nur die Umsetzung, sondern auch die Erfolgsmessung. Alle Kunden, die mit angepassten Service-Vorgängen Kontakt hatten, wurden im Anschluss nach ihrer Bewertung gefragt, so dass in den Sprint Reviews nicht nur die Umsetzung der für das Sprintziel notwendigen Massnahmen vorgestellt wurde, sondern auch das dazugehörende Kundenfeedback. Damit wurde die Diskussion bewusst versachlicht und von Annahmen befreit.

Wie sinnvoll das war, konnte man an einem Sprintziel sehen, das auf den ersten Blick eines der am einfachsten umzusetzenden gewesen war: das Duzen der Kunden. Fast zwei Wochen vergingen mit Diskussionen, Eskalationen, rechtlichen Bewertungen, Focusgruppen-Befragungen und ähnlichen vorbereitenden und absichernden Tätigkeiten. Auch im Sprint Review erschienen einige Stakeholder mit sehr gefestigten Meinungen - die erst von dem durchweg positiven Kundenfeedback widerlegt wurden.

Am Ende des Projekts hatte es sowohl erfolgreiche als auch weniger erfolgreiche Sprints gegeben (und sogar einige, die die Kundenzufriedenheit eher verschlechtert hatten), insgesamt waren die Bewertungen des Kundenservice allerdings deutlich besser geworden als zuvor. Das Vorgehen wurde danach wieder in einen eher kontinuierlichen Arbeitsmodus überführt, in den bei Bedarf allerdings weitere Sprints eingeschoben werden konnten.

Was bei mir hängengeblieben ist, war neben diesem Erfolg der geradezu vorbildliche Umgang mit den Sprintzielen, die immer zu Beginn formuliert wurden, und die durchgängig als Alignment- und Erfolgsmessungs-Werkzeug genutzt worden waren. Hätte mir jemand vorher gesagt, dass ich ausgerechnet ausserhalb der IT im Kundenservice erleben würde, hätte ich es bezweifelt. So habe am Ende auch ich dazugelernt. Ein weiterer Grund warum ich gerne an dieses Projekt zurückdenke.

Ich gebe es zu, KI-generierte Songs sind eines meiner Guilty Peasures. Aber ohne diese versteckte Neigung würde ich nicht auf derartig grossartig bekloppte Kunstwerke stossen wie das hier.

Irgendwann werde ich mal eine Party veranstalten, auf der nur solche Musik gespielt wird. Mal sehen, ob ich danach noch Freunde habe.

Von dieser Grafik gibt es gerade verschiedenste Varianten auf X und in Linkedin. Welche die ursprüngliche ist, lässt sich nicht mehr rekonstruieren, also nehmen wir diese hier.

Als Bonus: ein inhaltlich sehr ähnliches Meme.

New devs in 2026 be like... pic.twitter.com/6BfkRqV4wb

— yash.jsx (@yashmp2004) September 6, 2026

Eine steile These: die immer weiter um sich greifende Integration von KI-Agenten in die Softwareentwicklung führt dazu, dass gerade aus DevOps ein neues Vorgehendmodell entsteht, das zwar grundsätzlich die selben Tätigkeiten und Ideen umfasst, sie allerdings in der Schwerpunktsetzung so stark vertauscht, dass dadurch etwas Neues entsteht. Einen "offiziellen" Namen dafür gibt es noch nicht, naheliegend wäre aber "OpsDev".

Um kurz zu erklären, wie ich zu dieser These komme: unter DevOps verstehe ich nicht nur die Zusammenfassung von Development und Operations in einer Einheit, sondern auch eine dazugehörende Gewichtung. Entwicklung/Development macht darin den Grossteil der Arbeit aus, da sie nicht automatisierbar ist (bzw. bisher war). Damit das so bleiben kann, wird versucht, Betrieb/Operations weitgehend zu automatisieren, entweder durch die Entwickler selbst oder durch Plattform-Teams.

Gleichzeitig wird in DevOps das Releasen, Deployen, Betreiben und ggf. Reparieren der Software einfacher und schneller, da diejenigen die dafür zuständig sind auch die sind, die die Software ursprünglich geschrieben haben. Während reine Operations-Mitarbeiter oft rätseln müssen, warum sich der für sie fremde Code in bestimmter Weise verhält, fällt dem ursprünglichen Erzeuger eine Analyse und Fehlerbehebung meistens leichter.

Im Umfeld von KI-getriebener Softwareentwicklung ist es dagegen auf einmal die Entwicklung, die weitgehend automatisiert ist, oder zumindest teilautomatisiert (je nachdem ob bereits Agentic Development stattfindet oder ob nur gepromptet wird). Für diesen Tätigkeitsbereich den Grossteil der Arbeitszeit freizuhalten ist damit nicht mehr nötig, stattdessen bleibt mehr Zeit für andere Tätigkeiten übrig. Und damit kommen wir zum Betrieb.

Betrieb/Operations kann in der KI-getriebenen Softwareentwicklung auf einmal unerwartet aufwändig werden, da die Entwickler plötzlich vor dem selben Problem stehen wie früher die reinen Operations-Mitarbeiter. Die Anwendungen die deployt, released, betrieben, gewartet und repariert werden müssen, bestehen wieder aus fremdem Code, nur mit dem Unterschied, dass der "fremde Erzeuger" jetzt nicht mehr ein anderer Mensch ist, sondern ein KI Agent, also ein Computerprogramm.

Durch diese beiden Verschiebungen verändern sich auch die Anteile der beiden Tätigkeitsgebiete an der Arbeitszeit. Nicht mehr die Entwicklung steht im Vordergrund und der Betrieb im Hintergrund, sondern umgekehrt: im Vordergrund steht der Betrieb, im Hintergrund die nur noch in Teilen selbst durchgeführte Entwicklung. Und diese Umkehrung kann man auch in der Benennung deutlich machen, daher der Name OpsDev anstelle von DevOps.

Angesichts der Geschwindigkeit und der Tiefgreifenden Natur des aktuellen Umbruchs kann es natürlich sein, dass die These der Bewegung von DevOps zu OpsDev nur eine temporäre Gültigkeit hat und die Situation sich schon bald ganz anders darstellt, für den Moment entspricht sie aber dem, was ich gerade in verschiedenen Firmen wahrnehmen kann. Wenn des diese Seite in ein paar Jahren noch gibt kann ich ja überprüfen, wie die Entwicklung weitergegangen ist.

Bild: Pexels / Ekam Juneja - Lizenz

Nigel Thurlow: Why High Utilization Slows Knowledge Work

John Cutler: Tokens, Hours, Points, and Other Curious Proxies

Marty Cagan: A Fresh Definition of The Product Role

Roman Pichler: Product Operating Model - The Crucial Enabler for AI Success

Relativ schnell habe ich diesen Vortrag von Matt Dailey mit der Neurasthenie oder "amerikanischen Kankheit" assoziiert, die um das Jahr 1900 bei vielen Menschen diagnostiziert wurde, die glaubten, dass sie mit dem technischen und sozialen Wandel nicht mithalten könnten. Die Velocity Sickness hat ähnliche Ursprünge, manifestiert sich aber anders: in höherer Arbeits- und Informationsdichte durch gesteigerter Anwendung künstlicher Intelligenz - ohne nennenswerte Steigerung der Ergebnismenge oder Qualität.

Die Lösung, die Dailey vorschlägt, ist passenderweise von den aktuellen Trends der KI-getriebenen Softwareentwicklung geprägt. Zur Stabilisierung und Rationalisierung der oft halluzinierenden und erratischen KI-Agenten (die für ihn die Ursache der  Velocity Sickness sind) empfiehlt er, den Focus weniger auf die unmittelbare (und flüchtige) Interaktion mit den Agenten zu legen, und sich stattdessen auf grosse, langlebige und einordnende Dokumente zu konzentrieren, die den Agenten dann gemeinsam mit dem jeweiligen Prompt vermittelt werden.

Während ich bei seiner Initialen Problembeschreibung spannende Anstösse (und eine überfällige Thematisierung einer unterschätzten Gesundheitsgefahr) sehe, bin ich bei seiner Lösungsfindung nicht ganz sicher: selbst wenn das funktionieren sollte - ist das am Ende nicht nur Context Engineering?