 |
| Original-Grafik: XKCD.com - CC BY-NC 2.5 |
Wir erleben bei diesem Bild die Magie der Creative Commons: jemand hat die unter der CC BY-NC 2.5-Lizenz veröffentlichte ursprüngliche Grafik von XKCD genommen, um einen dritten Teil ergänzt und sie damit um eine weitere Dimension bereichert (gefunden in irgendeinem Forum).
|
| Bild: Pexels / Ekam Juneja - Lizenz |
Durch die Einführung von künstlicher Intelligenz (KI) in die Softwareentwicklung durchläuft dieser Beruf gerade einen grundsätzlichen Wandel. Im Mittelpunkt der öffentlichen Berichterstattung steht dabei der enorme Zuwachs an Geschwindigkeit und Output, gleichzeitig werden aber auch Veränderungen auf der persönlichen Ebene sichtbar. Immer mehr Softwareentwickler berichten von einem Gefühl der Entfremdung von ihrem Beruf.
Da dieser Begriff mehrdeutig ist, zuerst eine kleine Differenzierung: mit Entfremdung ist hier nicht gemeint, dass durch die Auslagerung der Entwicklung an die KI Übung und damit auch Wissen verlorengehen (selbst wenn auch das immer wieder berichtet wird), sondern, dass der Beruf nicht mehr als etwas Vertrautes und in allen Aspekten Verständliches empfunden wird, sondern als etwas zunehmend Fremdes. Ein Phänomen das in anderen Berufen schon vor langer Zeit beobachtet wurde.
Der Gegenstand, den die Arbeit produziert, ihr Produkt, tritt ihn als ein fremdes Wesen, als eine von dem Produzenten unabhängige Macht gegenüber. [...] Ja, die Arbeit selbst wird zu einem Gegenstand, dessen er nur mit der größten Anstrengung und mit den unregelmäßigsten Unterbrechungen sich bemächtigen kann.
Was hier von keinem geringeren als Karl Marx formuliert wird ist das Schicksal aller Menschen, deren Arbeit sich durch Aufgabenteilung und Automatisierung verändert. Der eigene Anteil wird immer fragmentierter und immer abstrakter, und das Interesse am Arbeitsgegenstand, das in der Regel ja die Ursache der Berufswahl war, wird immer weniger befriedigt. Selbst wenn es faktisch zu Steigerungen der Produktivität kommt, der Grad der Erfüllung sinkt.
In der Softwareentwicklung ist dieser Phänomen noch einmal ausgeprägter. Bereits vor der Einführung von KI war er durch einen hohen Grad an Abstraktion und eine geringe Fassbarkeit vieler Ergebnisse geprägt, so dass es Entfremdungs-Phänomene auf einem niedrigeren Niveau schon lange gegeben hat. Mit den neuen Arbeitsweisen, die im Wesentlichen daraus bestehen, einem Chatbot Arbeitsaufträge zu geben, steigert sich das noch einmal deutlich.
Wie auch in anderen Berufen ist das bedauerlich, wird sich aber nicht wieder vollständig zurückdrehen lassen, dafür sind die Vorteile der KI-gestützten Softwareentwicklung zu offensichtlich. Was sich aber immer wieder beachten lässt ist der Versuch, sich einen direkteren Zugang zu bewahren, in dem in bestimmten Zeitfenstern oder für einen Bestimmten Anteil der Arbeit wieder selbst entwickelt wird (was nebenbei auch einem schleichenden Verlernen von Praktiken und Techniken entgegenwirkt).
Da es sich um eine relativ neue Entwicklung handelt, ist noch nicht absehbar in welchem Ausmass sie langfristig zu einem Problem werden wird, als Pointe kann man aber bereits jetzt festhalten, dass die Nutzung künstlicher Intelligenz beim jeweiligen Anwender auch emotionale Intelligenz erfordert, wenn er nicht von den Entfremdungsphänomenen frustriert und demotiviert werden will. Wer (ausser Karl Marx) hätte das gedacht?
Genau wie bei den etwas älteren agilen Frameworks stellt sich auch beim relativ neuen AI-Driven Development Lifecycle (AI-DLC) die Frage: wie lässt es sich in die umgebende Organisation so integrieren, dass Risikomanagement, Kostenmanagement, Wissensmanagement, etc. weiterhin funktionieren? Dieser Erfahrungsbericht von Shilpa Nagavara ist einer der ersten, die dieses Thema öffentlich beleuchten.
Spannend an ihren Ausführungen ist, dass bei der Umsetzung sowohl soziale als auch technische Probleme auftreten und ineinandergreifen, von der Notwendigkeit nonverbale Kommunikation gegenüber der KI explizit zu machen bis hin zur Token-Ökonomie. Und was Shilpa Nagavara zu Recht hervorhebt: es ist noch alles im Work in Progress-Zustand, im wohnt also noch der Anfangszauber inne.
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.1
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 |
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?
 |
| Bild: Wikimedia Commons / Matthias Mullie - CC BY-SA 4.0 |
Es ist nicht mehr ganz nachvollziehbar wann die agile Community zum ersten mal mit der Idee der Monte Carlo-Simulation in Berührung gekommen ist, aber mit der Zeit hat sie sich zu einem Trend entwickelt, und wird immer wieder als alternative (oder sogar als bessere) Prognose-Methode im Vergleich zur Velocity genannt. Bei einer neutralen Betrachtung ist sich auch erstmal ein weiteres interessantes Werkzeug, nur bei der normativen Bewertung sollte man vorsichtig sein.
Um zuerst zu verstehen worum es geht: in agilen Teams wird mit der Monte Carlo-Simulation versucht die wahrscheinliche Umsetzungsdauer zukünftiger Arbeitspakete vorherzusagen, indem mit ähnlichen Arbeitspaketen der Vergangenheit Simulationen durchgeführt werden. Z.B. wird 1000 mal die durchschnittliche Umsetzungsdauer aus zehn jeweils zufällig ausgewählten bereits abgeschlossenen Arbeitspaketen ermittelt (mehr dazu hier). Das Ergebnis sieht dann etwa so aus.
Auf der X-Achse sieht man hier die Menge fertiger Arbeitspakete pro Woche, auf der Y-Achse die Häufigkeit in der so ein Ergebnis aufgetreten ist. Aus diesen Daten lassen sich Prozentzahlen ableiten: in über 80% der Simulationen wurden mindestens 50 Arbeitspakete geschafft, in 50% mindestens 60 Arbeitspakete, etc. Und daraus werden dann Prognosen abgeleitet: mit 80% Wahrscheinlichkeit werden wir 50 Arbeitspakete pro Woche schaffen, mit 50% Wahrscheinlichkeit 60, usw.
Diese Prognosen sind zwar etwas kompliziert formuliert, basieren dafür aber nicht auf Bauchgefühl sondern Empirie. Gleichzeitig gibt es aber auch Kritik: der Lean Experte Nigel Thurlow kritisierte etwa, dass Wartezeiten und Übergaben der Arbeitspakete in diesem Vorgehen nicht erfasst werden. Ein weiterer Kritikpunkt ist, dass es nur dann gut funktioniert, wenn die einzelnen Arbeitspakete ähnlich geartet sind, während bei Unterschieden zwischen ihnen die Aussagekraft schwindet.
Ein zusätzlicher Kritikpunkt kommt ausserdem von dem hier schon mehrfach erwähnten Oxford-Professor Bent Flyvbjerg, und in ihm wird die Monte Carlo-basierte Prognose für agile Teams gewissermassen mit ihren eigenen Waffen geschlagen: mit Statistiken, die auf historischen Daten beruhen. In einem Paper, das er zusammen mit anderen dänischen und englischen Wissenschaftlern verfasst hat, macht er auf ein unterschätztes Risiko aufmerksam - die dicken Enden (Fat Tails).
Hinter diesem Begriff verbirgt sich die Auffälligkeit, dass in komplexen Umgebungen (IT-Projekten, grossen Bauprojekten, etc.) das Risiko extremer Ausschläge an den Rändern extrem steigt. Um ein Beispiel in der Sprache der Monte Carlo-Prognosen zu nehmen: in nur 10% Prozent aller Fälle werden weniger als 20 Arbeitspakete pro Woche geschafft, aber in fast allen dieser Fälle sind es nur eines oder zwei oder Null - oder eine negative Zahl (d.h. bereits geschlossene müssen erneut bearbeitet werden).
Diese auf zahlreichen statistischen Daten echter Projekte beruhende Erkenntnis relativiert die Aussagekraft der Monte Carlo-Simulationen sehr stark. Denn wenn man mit 80-prozentiger Wahrscheinlichkeit einen stabilen Arbeitsdurchsatz prognostizieren kann, in den restlichen 20 % aber ein Risiko mit hoher Eintrittswahrscheinlichkeit steckt, das den gesamten Umsetzungsplan über den Haufen werfen kann, dann ist die versprochene Prognostizierbarkeit nicht wirklich gegeben.
Bevor Missverständnisse aufkommen: die Alternative zu Monte Carlo-Simulationen ist in komplexen Umfeldern nicht etwa eine andere Prognosemethode, sondern ein Vorgehen, das extreme Ausschläge früh zu entdecken versucht, und genug Zeit und Ressourcen hat um auf sie zu reagieren: Product Discovery, Lean Startup, Chaos Engineering, Extreme Programming oder Rapid Prototyping. Aber für das Arbeiten "zwischen den Ausschlägen" ist Monte Carlo natürlich geeignet (genau wie die Velocity auch).
Bücher zum Thema Unternehmenskultur gibt es mittlerweile unübersehbar viele, und wer einige davon gelesen hat wird gemerkt haben, dass auch die Vorstellungen davon, was Kultur eigentlich ist, ebenfalls unübersehbar vielfältig sind. Das Schöne daran: es gibt immer wieder interessante neue Sichtweisen, so wie in- dem Buch Making Organizational Culture Great - Moving Beyond Popular Beliefs, geschrieben von den amerikanischen Wirtschaftswissenschaftlern Jennifer A. Chatman and Glenn R. Carroll.
Passend zum von ihnen gewählten Untertitel ist es das Ziel der beiden Autoren, die Diskussion über Unternehmenskulturen zu versachlichen, weshalb der Aufbau um fünf populäre Annahmen kreist, die anhand realer und bekannter Beispiele validiert und in diesem Rahmen bestätig oder widerlegt werden (oder differenziert betrachtet, wenn das Ergebnis nicht eindeutig ist). Bei diesen fünf untersuchten Annahmen handelt es sich um die folgenden:
Diese Annahme ist in den Augen von Chatman und Carroll nicht völlig falsch, aber auch nicht zwangsläufig richtig. Während z.B. bei Kodak und PanAm ein Kulturwandel scheiterte war er bei Ford und Roche erfolgreich. Und bei Apple scheiterte er zunächst, um unter später unter neuer Führung (der von Steve Jobs) zu gelingen. Entscheidend ist jeweils der Kontext.
Auch hier ist die Antwort differenziert. Auf der einen Seite wird an Beispielen wie dem Southwest Airlines-CEO Herb Kelleher gezeigt, wie gross die Gestaltungsmöglichkeiten hoher Manager sein können, auf der anderen Seite wird an Firmen wie Boeing (vor der Fusion mit McDonnell Douglas) gezeigt, dass Kultur (in diesem Fall Ingenieur-Kultur) auch dezentral entstehen kann.
Vermutlich das kontroverseste Kapitel des Buches. In ihm wir klar davon ausgegangen, dass Kultur konkretisierbar und messbar ist, und dass nicht nur qualitativ (etwa durch Zufriedenheits-Erhebungen) sondern auch quantitativ (etwa durch Umfang und Geschwindigkeit der Aneignung von Insider-Sprache). Praxisbelege gibt es auch hier, über deren Repräsentativität kann man aber diskutieren.
Für Chatman und Carroll ist das zu einfach gedacht. Zum einen erfordern viele Unternehmenskulturen (z.B. in innovativen Umfeldern) eine gewisse Nonkonformität, was im Widerspruch zum angepasst Sein steht, zum anderen ist Kultur oft implizit oder dynamisch, was Anpassungen erschwert. Sehr deutliche Kulturunterschiede sind aber meistens nachteilig, wie anhand von Disney und Netflix gezeigt wird.
Diese Annahme drehen die beiden Autoren zunächst um. Was eine (schlechte) Unternehmenskultur definitiv bewirken kann, ist ein wirtschaftlicher Schaden, wie sie u.a. am Beispiel Volkswagen zeigen. Darüber hinaus können eine Leistungs- oder Innovationskultur erkennbar zu wirtschaftlichem Erfolg beitragen, wofür Walmart und SpaceX als Belege genannt werden.
Nach diesen zentralen Kapiteln endet Making Organizational Culture Great mit einem weiteren, in dem konkrete Ratschläge zur Kulturgestaltung gegeben werden, auch hier wieder basierend auf vielen Praxisbeispielen. Vieles davon ist naheliegend, etwa die gezielte Personalauswahl oder Weiterbildung. Andere, wie das Verfassen von kulturellen Leitbildern oder das oben genannte Messen von Kultur sind kontrovers. Und einige, wie das Feuern kulturell unpassender Mitarbeiter, wären in Deutschland illegal.
Am Ende spiegelt sich aber in dieser Mischung, warum das Buch lesenswert ist. Es verbindet das Hinterfragen scheinbarer Gewissheiten mit konkreten Praxiserfahrungen und -anleitungen sowie kontroversen Standpunkten, an denen man sich Reiben kann. Das regt an zum Nachdenken, Hinterfragen und Ausprobieren - was passenderweise auch ein erfolgsversprechender Ansatz für die Erforschung und Gestaltung von Unternehmenskulturen ist.
 |
| Bild: Unsplash / Chase Chappell - 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.
Diese hier hat auf den ersten Blick kein besonders agiles Ergebnis gehabt, schliesslich handelte es sich bei ihm um die Einführung von Quartalsplanungen. Eine Quartalsplanung - wie soll das mit den kurzen Lieferzyklen zusammenpassen, die Erkennungsmerkmal der agilen Arbeitsweisen sind? Um das zu erklären muss ich etwas ausholen, denn wie immer steckt auch hinter dieser Geschichte eine Entstehungsgeschichte, die man kennen sollte.
In der Vergangenheit hatte das Unternehmen mit dem ich zu dieser Zeit zusammengearbeitet habe einen eher klassischen Planungsansatz. Am Anfang stand die so genannte "Mifri" (die mittelfristige Finanzplanung), die jeweils für die nächsten drei Jahre die vorgesehenen Budgets festlegte, und das z.T. auf erstaunlich detailliertem Niveau. Den Budgets wurden dann für jeweils das nächste Jahr Ressourcen (also Mitarbeiter) zugeordnet. Für die ganzen zwölf Monate, ebenfalls in hohem Detailgrad.
Ob es jemals den Fall gegeben hatte, dass ein solcher Plan aufgegangen war, konnte keiner sagen. In den letzten zehn Jahren war das aber nicht der Fall gewesen, ständig liefen Plan und Realität auseinander. Zu Beginn eines Jahres wurde das versucht mit Mehrarbeit zu kompensieren, in der Mitte des Jahres gab es bürokratische Plananpassungen, ab Herbst floss ein Grossteil der Arbeit dann in Rechtfertigungen dafür, dass die Planziele nicht erreicht worden waren. So lief es jedes Jahr.
Irgendwann war der durch dieses Vorgehen erzeugte Schmerz zu gross geworden, und das Vorgehen wurde angepasst. Die mittelfristige Finanzplanung gab es zwar noch, sie wurde aber wesentlich weniger kleinteilig durchgeführt. Statt für einzelne Features waren die Budgets jetzt für Systeme oder Services vorgesehen, wodurch der Handlungsspielraum deutlich grösser wurde. In gleicher Art wurden auch die Jahresplanungen abstrahiert und vereinfacht.
Die eigentliche Planung fand ab diesem Zeitpunkt auf Quartalsbasis statt, also immer für drei Monate im Voraus. Und um zu verhindern, dass Überläufer-Themen des letzten Quartals de facto zu einer Verlängerung der Planungszyklen führten, wurden alle Aktivitäten und Prioritäten vor Planungsbeginn auf Null zurückgesetzt, so dass Restaufwände ggf. nicht mehr umgesetzt wurden. Mit der Zeit erwies sich das als wirkungsvolles Mittel gegen die bis dahin weit verbreiteten überoptimistischen Pläne.
Der so entstehende Kontrast zwischen dem alten und dem neuen Vorgehen war drastisch: vorher hatten die Pläne ab Frühling kaum noch Realitätsbezug, stattdessen flossen bemerkenswerte Aufwände in Eskalationen, bürokratische Umplanungen und Rechtfertigungen. Nach der Umstellung führten die kürzeren Planungszeiträume dazu, dass Plan und Realität ständig nah beieinanderlagen, wodurch die gerade genannten Aufwände unnötig (oder zumindest stark reduziert) wurden.
Als zusätzlichen Effekt konnte man eine deutliche Zunahme der Produktivität beobachten. Die gesamte bisher notwendige Eskalations, Umplanungs und Rechtfertigungszeit konnte jetzt für die eigentliche Arbeit verwendet werden, was zu deutlich schnelleren Umsetzungen führte. Und wenn Annahmen oder Planungen sich als unrealistisch erwiesen, belastete das nicht mehr das ganze Jahr, sondern nur die Zeit bis zur nächsten Quartalsplanung, bei der alle Pläne zurückgesetzt wurden.
Eine tatsächliche Erfolgsgeschichte also. Aber auch eine agile Erfolgsgeschichte? Wie oben gesagt, sind dafür drei Monate nicht zu lang? Statt einer eigenen Antwort darauf möchte ich die Primärquelle zitieren, das Manifest für agile Softwareentwicklung, bzw. dessen zweite Seite, die Principles behind the Agile Manifesto. Zu denen gehört nämlich auch eines, dass sich mit den anzustrebenden Umsetzungszeiträumen befasst, und das liest sich so:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Die Hervorhebung ist von mir, den Rest kann man für sich sprechen lassen.
Das was Randy Shoup hier abliefert ist ein bemerkenswerter Einblick in die Welt grosser (IT-)Organisationen. Seine zentrale Botschaft, die er mit zahlreichen Beispielen aus seiner Zeit bei Ebay unterlegt: wenn ein Unternehmen eine dysfunktionale Unternehmenskultur hat, dann wird eine Modernisierung der Prozesse, Tools und IT-Systeme nur in begrenztem Ausmass zu Verbesserungen führen. Keine neue Erkenntnis, aber sehr anschaulich an einem bekannten Beispiel erklärt.
Eine zweite von ihm erzählte Geschichte, die in der oben genannten Enthalten ist, ist die der bei Ebay vorgenommenen Prozess-, Tool- und System-Modernisierungen, die trotz des letztendlichen Scheiterns an kulturellen Mustern zwischenzeitlich zu deutlichen Verbesserungen geführt haben. Shoup zufolge ist das mit einem geradezu minimalistischen Vorgehensmodell gelungen: der kontinuierlichen Identifikation von verlangsamenden Faktoren und deren sequentieller Abarbeitung durch ein die Entwicklungsteams unterstützendes Plattform-Team. Geradezu das Gegenmodell zu SAFe & Co.
Es gibt für Retrospektiven kein kategorisch richtiges oder für alle Situationen passendes Format, jedes Team kann seine eigene Variante entwickeln. Umgekehrt gibt es aber Verhaltensmuster, die besser zu vermeiden sind. Ein leider immer wieder anzutreffendes besteht daraus, Probleme nur zu identifizieren, für ihre Lösung aber später stattfindende Folgetermine einzurichten (oder noch schlimmer: sich lediglich vorzunehmen, derartige Termine zu planen).
Dabei ist es natürlich nicht so, dass es gar keine Konstellationen gäbe, in denen dieses Vorgehen Sinn macht. Wenn für eine Problemlösung z.B. Fachexperten oder Kooperationspartner anwesend sein müssen, die nicht zum Team gehören, dann muss man selbstverständlich vorher deren Verfügbarkeit und Bereitschaft in Erfahrung bringen. Aber bei Team-internen Themen, wie z.B. der Überarbeitung der eigenen Definition of Done, ist diese Sinnhaftigkeit nicht gegeben.
Dass trotzdem immer wieder so vorgegangen wird hat verschiedene Gründe. Ein häufiger ist der, dass auf diese Weise (scheinbar) mehr Themen erledigt werden können: nur Fünf Folgetermine zu planen geht schneller als Fünf Themen zu besprechen und zu Ergebnissen zu kommen. Auch dass das Thema für einen Teil der Anwesenden von nur wenig Interesse ist, ist ein häufiger Grund. Und ein ebenfalls häufiger (wenn auch keineswegs Guter) ist der, dass man schon immer so vorgegangen ist.
Die Folgen dieser Vorgehensweise sind zum einen, dass die Kalender immer voller werden, und zum anderen, dass die angestrebten Lösungen und Ergebnisse immer später entstehen. Diese Phänomene stehen sogar in Beziehung zueinander. Weil für zusätzliche Meeting nicht unbegrenzt Zeit (und Lust) vorhanden sind, kann nur eine begrenzte Zahl zeitnah stattfinden. Schlimmstenfalls können sie sogar erst so weit in der Zukunft stattfinden, dass bis dahin schon die nächste Retrospektive stattgefunden hat.1
Ein deutlich besseres Vorgehen ist es, die aufgekommenen Themen direkt in dem Termin zu behandeln, in dem sie zum ersten Mal thematisiert wurden. Um beim oben genannten Beispiel zu bleiben: wenn eine Überarbeitung der eigenen Definition of Done nötig ist, dann ist das etwas, was sofort angegangen und erledigt werden kann. Das Gleiche gilt auch für zahlreiche weitere Themen, von Coding Standards über zwischenmenschliche Unstimmigkeiten bis zur Planung des nächsten Team-Events.
Bleiben noch die gerade genannten Einwände. Einfach zu entkräften ist der Erste: mehrere Themen nur kurz anzudiskutieren und dann Folgetermine zu vereinbaren, sorgt eben nicht dafür, dass insgesamt mehr erledigt werden können. Es führt nur dazu, dass die Arbeit an mehreren parallel begonnen wird (ein wichtiger Unterschied). Nur an wenigen zu arbeiten, dafür aber richtig, lässt natürlich andere Themen unbehandelt - aber wenn sie wichtig bleiben, können sie nächstes Mal erneut eingebracht werden.
Dass bei manchen Themen nicht alle Mitglieder eines Teams nicht alle bei allen Themen in gleicher Tiefe mitreden können ist schon ein besseres Argument, aber auch kein wirklich Gutes. Zum einen bietet ein sofortiges und gemeinsames Angehen die Möglichkeit, neue Themen kennenzulernen und in ihnen besser zu werden. Und sollte der Extremfall zweier extrem unterschiedlicher Teilteams gegeben sein, lassen sich ggf. auch zwei Arbeitsgruppen bilden, von denen jede an jeweils einem Thema arbeitet.
So oder so sollten die Vorteile einer sofortigen Problembehandlung durch eine Workshop-artige Retrospektive klar sein. Schnelle Ergebnisse, kein Aufschieben der Lösungsfindung auf zukünftige Zeitpunkte, keine zusätzlichen Meetings, kein paralleles Herumwerkeln an mehreren Themen. Warum nicht alle Teams das so sehen ist mir schleierhaft, aber immerhin ist es meine Erfahrung, dass die meisten sich darauf hinweisen lassen und diesen Impuls dann auch verstehen und annehmen.
Wenn die Aussenwahrnehmung eines Arbeitgebers sehr stark durch einen einzigen HR-Aspekt geprägt ist, dann muss das schon ein ganz besonderer sein. Dementsprechend sind solche Fälle zwar selten, aber es gibt sie immer wieder. Die Side Project Time bei Google ist ein bekanntes Beispiel oder die freie Vorgesetzten-Wahl bei Uber. Das vermutlich kontroverseste dieser Beispiele dürfte aber der so genannte "Keeper Test" von Netflix sein.
Besagter Test wurde in dieser Firma bereits 2001 als Praktik eingeführt, 2009 im so genannten Culture Deck offiziell gemacht und 2020 im Buch No Rules Rules einer breiteren Öffentlichkeit vorgestellt. Es gibt ihn in verschiedenen (inhaltlich gleichen) Varianten, die im besagten Buch vorgestellte ist diese hier:
If a person in your team were to quit tomorrow, would you try to change their mind? Or would you accept their resignation, perhaps with a little relief? If the latter, you should give them a severance package now, and look for a star, someone you would fight to keep.
Zu Deutsch: jeder Manager sollte sich bei jedem seiner Untergebenen fragen, ob er ihm eine Kündigung ausreden würde - und wenn nicht, dann soll er ihm eine Abfindung zahlen, damit er geht, und sich einen besseren Ersatz suchen. Das klingt zunächst einmal extrem hart und hat tatsächlich auch dazu geführt, dass Netflix in den Medien das Schaffen einer Angstkultur vorgeworfen wurde. Aber wie so oft in derartigen Fällen: ganz so einfach ist es nicht.
Zunächst muss man die wichtige Kontext-Information kennen, dass in der IT-Industrie im Allgemeinen und im Silicon Valley im Besonderen kurze Firmenzugehörigkeiten von jeweils wenige Jahren nichts Ungewöhnliches sind, bei vielen Unternehmen sind sie sogar der Normalfall. Den Menschen, die den Keeper Test nicht bestanden haben, wird also keine Job weggenommen den sie bis zur Rente behalten wollten, es fällt lediglich eine von vielen Stationen etwas kürzer aus.
Ebenfalls wichtig ist, dass die Angestellten von Netflix keineswegs in ständiger Ungewissheit über die Meinung ihrer Vorgesetzten leben müssen. Es gibt sogar ein fest definiertes Auskunftsverfahren, den so genannten "Keeper Test Prompt", mit dem man sein aktuelles Ergebnis erfragen kann. Und da dieses Ergebnis nicht nur aus den Extremwerten Bleiben und Gehen besteht, sondern auch aus vielen Zwischenstufen, hat jeder die Gelegenheit, an sich zu arbeiten um das Testergebnis wieder zu ändern.
Auch ist in der Realität auch das Scheitern an einem Keeper-Test nicht automatisch mit einer Kündigung verbunden (selbst wenn auch das natürlich oft genug vorkommt). In No Rules Rules werden auch Fälle beschrieben, in denen stattdessen eine Versetzung in andere Abteilungen stattfand, in denen die Betroffenen für sie passendere Rahmenbedingungen vorfanden. In Einzelfällen kann die Überlegung, wo der durch den Test gefallene Kollege einen Mehrwert stiften kann, sogar zu Beförderungen führen.
Zuletzt sollte man nicht aus den Augen verlieren, dass der Keeper-Test auch eine sehr positive Seite haben kann. Elizabeth Stone, der Chief Product and Technology Officer (CPTO) von Netflix, hat beispielsweise in einem Podcast erzählt, dass sie in den Personalgesprächen mit ihren Untergebenen regelmässig hervorhebt, was diese so gut machen, dass sie darum kämpfen würde, sie in jedem Fall bei sich zu behalten. Denn auch das gehört dazu: in vielen Einheiten bestehen alle den Test.
Trotz allem bleibt aber die Kernaussage aber natürlich bestehen - die Mitarbeiter, um die man nicht kämpfen würde, sollen bitte gehen. Auch das wird in No Rules Rules detaillierter erklärt: zu denen, von denen man sich trennt, gehören nicht nur die, die schlechte Arbeit leisten, sondern auch die, die sich technischen Innovationen verweigern, die strategische Entscheidungen und organisatorische Veränderungen nicht mittragen wollen, oder die einfach ständig für schlechte Stimmung sorgen.
Aber führt das am Ende nicht doch zu einer Angst- und Ellenbogen-Kultur? Nicht unbedingt. Das Buch zitiert Forschungsergebnisse der amerikanischen Business School-Professorin Erin Meyer, die folgende Zahlen ermittelt hat: Netflix kündigt jährlich im Schnitt 8% seiner Angestellten, und liegt damit nur leicht über dem Branchenschnitt von 6% - gleichzeitig liegt aber die Kündigungsrate der Mitarbeiter bei nur 4%, während diese im Branchenschnitt bei 12% liegt. Eine Angstkultur sähe anders aus.
Was hinter diesen Zahlen steckt ist die Erkenntnis, dass mit den Angestellten, die den Keeper Test nicht bestehen, nicht nur menschlich geschätzte Kollegen die Firma verlassen, sondern vor allem solche, die durch konstant schlechte Arbeitsergebnisse oder durchgehend grenzwertige Verhaltensweisen auf alle anderen demotivierend wirken. Vielleicht ist das der eigentlich kontroverse Gedanke - dass das humane Verhalten gegenüber denen, die die Erwartungen nicht erfüllen, inhuman gegenüber allen anderen ist.
The new development cycle in one image. pic.twitter.com/18bBgKPQF2
— Kr$na (@krishdotdev) July 16, 2026
Der Vollständigkeit halber sollte man sagen: die neue Form eines schlechten Softwareentwicklungs-Zyklus. Leider trotzdem eine Häufige.
|
|
| Bild: Pexels / Ekam Juneja - Lizenz |
Selten in der Geschichte der organisierten Arbeit haben angestellte Menschen ein solches Ausmass an Freiheit und Mitbestimmung gehabt wie in agilen (Software-)Entwicklungsteams. Sie können selbst entscheiden wie viel Arbeit sie in nächster Zeit beginnen wollen, wie viel Beschreibungsumfang die Anforderungen haben müssen, wie sie sich die Arbeit intern aufteilen und noch Vieles mehr. Aber paradoxerweise sind viele von ihnen hochgradig unzufrieden.
Wie immer in komplexen Konstellationen gibt es nicht einen einzigen Grund, der das abschliessend erklärt, und auch keinen (Teil-)Grund der in allen Fällen vorliegt, meiner Erfahrung nach gibt es aber einen der in sehr vielen Fällen zu beobachten ist. Es ist die so genannte hedonistische Tretmühle, womit das Phänomen beschrieben wird, dass Menschen auch nach deutlichen Verbesserungen ihrer Situation mittelfristig wieder auf ihr vorheriges Zufriedenheits-Niveau zurückkehren.
Um es an einem konkreten und häufig zu beobachtenden Beispiel festzumachen: wenn einem Team nicht mehr die Aufwandsschätzungen und Umsetzungswege der Anforderungen von Aussen vorgegeben werden, führt das kurzzeitig zu Erleichterung, Aufbruchsstimmung und ähnlichen positiven Emotionen. Mittelfristig entstehen aber neue Demotivations-Ursachen, z.B. Unzufriedenheit mit der Anforderungs-Priorisierung oder der Feedback-Frequenz. Am Ende ist die schlechte Stimmung wieder da.
Die Erklärung, die in verschiedenen psychologischen Studien postuliert wurde, ist die, dass ein Grossteil der Menschen (viele, aber nicht alle) ein stabiles Niveau an Zufriedenheit und Glück hat, von dem zwar situationsbedingt Abweichungen nach unten oder oben möglich sind, zu dem aber immer wieder zurückgekehrt wird. Unwissenschaftlich formuliert: manche Menschen sind halt Miesepeter, während andere durchgehend gute Laune haben.
In der Aussenbetrachtung werden Teams, die auch bei spürbaren Verbesserungen ihrer Situation immer wieder auf ihr ursprüngliches Zufriedenheitslevel zurückfallen, in der Regel kritisch gesehen, oft mit Urteilen oder Vorwürfen wie Undankbarkeit und Destruktivität bedacht, und in Extremfällen sogar mit "Diagnosen" wie Dysphorie pathologisiert. Sich des Phänomens der hedonistischen Tretmühle bewusst zu sein, kann dabei helfen, derartigen (in der Regel vorschnellen) Annahmen nicht zu verfallen.
Eine konstruktive Möglichkeit des Umgangs mit derartigen Situationen ist es, den Teams kontinuierlich Erfolgserlebnisse zu ermöglichen, wodurch eine Gegendynamik gegen das Zurückfallen auf das ursprüngliche Zufriedenheitslevel entstehen kann. Die Schaffung derartiger Erlebnisse ist einer der Hintergründe für Sprint Reviews, Kaizen Boards und ähnliche Events und Tools, in denen Verbesserungen und Erfolge sichtbar gemacht werden.
Idealerweise geschieht das übrigens nicht mit verdeckter und manipulativer Absicht (selbst dann nicht wenn es gut gemeint ist), sondern den Teams gegenüber offen und transparent, um ihnen diesen zusätzlichen Mehrwert der jeweiligen Events und Tools bewusst zu machen. Natürlich kann das dann zu einer Ablehnung führen, aber letztendlich ist auch das Selbstorganisation: wer dauerhaft unzufrieden sein will, den kann man nicht abhalten - aber zum Glück ist das eher selten der Fall.
Der Begriff der Ungewissheit (Uncertainty) wird mit grosser Zuverlässigkeit immer wieder herangezogen wenn es zu begründen gilt, warum agile Vorgehensweisen Sinn machen. Was dabei in der Regel stattfindet ist allerdings eine Verengung dieses Begriffs - fast immer geht es lediglich um die Unsicherheit in Bezug auf die Planbarkeit von (wirtschaftlichen) Vorhaben. Dabei gibt es noch eine weitere Dimension der Ungewissheit: die psychologische.
Wer mehr darüber erfahren möchte, kann das in dem Buch Uncertain - The Wisdom and Wonder of Being Unsure tun, verfasst von der amerikanischen Wissenschafts- und Tech-Journalistin Maggie Jackson. Genau wie einige ihrer vorherigen Werke befasst es sich mit der Frage, was es mit dem menschlichen Geist macht, einer nicht enden wollenden Abfolge von technischen Innovationen, sozialen Umbrüchen und wirtschaftlichen Disruptionen ausgesetzt zu sein.
Die überraschende zentrale Botschaft ist dabei, dass Ungewissheit für die Menschen keineswegs etwas Schlechtes ist. Tatsächlich kann umgekehrt eine (scheinbare) Gewissheit ein wesentlich grösserer Risikofaktor sein, da sie zu der Annahme verleitet, Antworten und Lösungen bereits parat zu haben, so dass eine genauere Beschäftigung mit anliegenden Fragen und Problemen vernachlässigbar erscheint. Mit eher schlechten Ergebnissen als Folge.
Ungewissheit dagegen führt meistens zu genaueren Ursachen- und Einfluss-Analysen, zu einer Erwägung verschiedener Lösungsoptionen und in vielen Fällen (wenn keine von ihnen die offensichtlich Richtige zu sein scheint) zu einer parallelen Erprobung und einem Vergleich der Ergebnisse. Die dadurch gewonnenen Erkenntnisse tragen deutlich mehr zu Innovationen und Entdeckungen bei als die auf Gewissheiten begründeten schnellen Massnahmen.
Und auch auf das zwischenmenschliche Miteinander hat Ungewissheit positive Auswirkungen. Während die Überzeugung, Gewissheit über die Richtigkeit der eigenen Ansichten zu haben, zu Abwertung anderer Ansichten und damit zu gesellschaftlicher Polarisierung führen kann, führt die Ungewissheit eher dazu, dass auch andere Standpunkte als potentiell zutreffend akzeptiert werden, wodurch Konflikte seltener und Diskussionen fruchtbarer werden.
Letzteres zeigt sich auch in einem speziellen Teilbereich des zwischenmenschlichen Miteinanders - der Arbeitswelt. Maggie Jackson nennt in ihrem Buch zahlreiche Beispiele von Teams, die von der Auseinandersetzung mit Ungewissheiten stärker profitieren konnten als von den aus scheinbaren Gewissheiten abgeleiteten Best Practices, von Operations-Teams in Krankenhäusern über Bergsteiger, Wissenschaftler und Astronauten bis hin zu Gerichts-Jurys und Erziehern.
Was in diesem Buch nicht geschrieben steht, sich aber aus ihm ableiten lässt, ist deshalb ein Leitprinzip für das Change Management. Anders als oft behauptet ist es weder notwendig noch zielführend, den von Veränderungsvorhaben betroffenen Personen Ungewissheiten zu ersparen. Ganz unabhängig von der Frage ob das überhaupt möglich ist, zeigt Uncertain auf, dass Menschen Ungewissheit nicht nur ertragen, sondern sogar von ihr profitieren können.
Zu den neuen Rollen, die in den letzten Jahren in der Softwareentwicklung entstanden sind, gehört die des so genannten Forward-deployed Engineers (FDE), eines Softwareentwicklers, der zusammen mit Mitarbeitern der Kunden seines Unternehmens in deren Systemen arbeitet, häufig auch vor Ort in deren Büros. Wie das konkret aussehen kann beschreibt Pauline Brunet hier am Beispiel der FDEs ihrer eigenen Firma Cursor.
Zu den verschiedenen interessanten Punkten ihrer Ausführungen gehören nicht nur die Aufgaben-Beschreibung, das Skill-Profil und das Persönlichkeitsprofil der Forward-deployed Engineers bei Cursor, sondern auch die Beschreibung des Kontextes in denen ihr Einsatz überhaupt Sinn macht. Denn wie so oft gilt auch hier: es ist keine Universallösung für alle Situationen, sondern nur eine für bestimmte Herausforderungen.
Was wäre die Welt ohne unsinnige Metriken, bzw. die missbräuchliche Verwendung von Kennzahlen? Sicher, ein besserer Ort. Aber auch einer mit weniger sarkastischen Cartoons. Es ist also nicht alles daran schlecht.
Noch einmal zurück zum Estuarine Mapping. Dieser Prozess kategorisiert Elemente eines Veränderungsvorhabens anhand von zwei Dimensionen: der voraussichtlich zu investierenden Zeit und der voraussichtlich zu investierenden Energie (im Sinn von Stress und persönlicher Anstrengung). Je nachdem wie die Einordnung erfolgt, können die Vorhaben einfach und schnell, anstrengend und schnell, einfach und langsam oder anstrengend und langsam sein (oder etwas dazwischen).
Über diese auf den ersten Blick einfache Zuordnung hinaus gibt es aber noch weitere Kategorien, in denen eine Einordnung möglich ist: im Bereich des negativen Energieaufwands, oder anders formuliert dort, wo Veränderungen keine Energie binden, sondern freisetzen. Um sie abbilden zu können wird die Energie-Achse der Estuarine Map nach unten verlängert (sie Abbildung oben). Da das nicht intuitiv verständlich ist, eine kurze Erklärung.
In der Change Management-Praxis bedeutet Veränderung in einem Grossteil der Fälle, dass Prozesse oder Strukturen eingeführt, erweitert, modifiziert oder stabilisiert werden. Das bringt sowohl einen kurzfristigen Energieaufwand für Konzeption und Implementierung mit sich, daneben aber häufig auch einen dauerhaften Energieaufwand für die Überwachung der Einhaltung und die Sanktionierung von Abweichungen. Die häufige Folge: Change Fatigue (Veränderungs-Ermüdung).
Was seltener zu sehen, aber ebenfalls möglich ist, ist Veränderung durch das Weglassen von etwas, etwa von Vorschriften oder Berechtigungen. Ggf. kann der kurzfristige Energieaufwand für Konzeption und Implementierung auch hier auftreten, der bis zu diesem Punkt dauerhaft aufzubringende Energieaufwand für Überwachung und Sanktionierung entfällt für die weitere Zukunft aber. Diese "Nicht mehr-Bindung" von Energie lässt das Veränderungs-Element auf der Estuarine Map nach unten rutschen.
Dass im Rahmen des Estuarine Mapping überhaupt sichtbar gemacht wird, dass bestimmte Veränderungen Energie nicht etwa binden, sondern freisetzen, ist bereits für sich genommen ein Mehrwert. Alleine durch diese Visualisierung können Widerstände reduziert und Unterstützung erzeugt werden. Darüber hinaus kann diese Information auch in die Priorisierung der anstehenden Vorhaben einfliessen - mit dem zu beginnen, was Energie freisetzt, kann hochgradig sinnvoll sein.
Wenn man Aussagen sucht, auf die die agile Bewegung sich einigen kann, dann wird man schnell auf die stossen, dass agiles Arbeiten Empirie- und Evidenz-getrieben sein sollte, oder mit anderen Worten: wissenschaftlich. Ernst genommen bedeutet das zum Einen, dass man im Kleinen selbst versuchen sollte, so vorzugehen, zum Anderen aber auch, dass man sich für wissenschaftliche Erkenntnisse interessieren sollte, die das eigene Arbeitsfeld betreffen - und wer danach sucht, findet Einiges.
Ich bin mit der Zeit auf eine ganzen Reihe wissenschaftlicher Papers gestossen und habe irgendwann mal angefangen, einige davon vorzustellen. Hier sind die nächsten fünf, die mir erwähnenswert erscheinen (und sollte ich das noch ein drittes mal machen, wäre es eine Serie). Sie gehen quer durch alle möglichen Themen durch und sind natürlich eine subjektive Auswahl, aber eine, die ich jedem empfehlen möchte, der bereit ist, sich auf wissenschaftliche Publikationen einzulassen. Hier sind sie:
Wer Bent Flyvbjergs Bestseller How Big Things get Done gelesen hat wird wissen, dass er Modularität als einen zentralen Erfolgsfaktor für Grossvorhaben identifiziert hat. Aufbauend auf Forschung zu derartigen Vorhaben in China formuliert und validiert er zusammen mit anderen Forschern die Theory of Modular Natives, die das weiter untermauert. Als kurze Erklärung: ein "Modular Native" ist ein immer identisches Bauteil (z.B. ein Solar Panel), das aber in verschiedenen Kontexten eingebaut werden kann.
Dieses Forschungsvorhaben wäre in Europa wohl an den Datenschutzvorschriften gescheitert. Die Interaktions-Frequenz von Büroarbeitern wurde gemessen, und zwar sowohl die digitale, als auch (über Sensoren) die direkte Kommunikation. Die Ergebnisse widerlegen eine häufige Annahme: das Zusammensitzen in Grossraumbüros führt nicht zu mehr direktem Austausch unter den Mitarbeitern, sondern lässt ihn sogar deutlich zurückgehen.
Dazu, dass Psychologische Sicherheit ein zentraler Faktor für die Produktivität von Team ist, gibt es bereits umfassende Forschungsergebnisse, am bekanntesten aus dem Aristotle-Projekt von Google. Eine häufige Frage dazu ist aber, ob diese Ergebnisse universal reproduzierbar sind, oder vor allem auf den europäisch/nordamerikanischen Kulturraum zutreffen (oder noch spitzer - vor allem auf dessen Tech-Industrie). Dieses Paper der Universität Pune in Indien zeigt: sie sind reproduzierbar.
Nicht nur die emotionale Intelligenz, auch die künstliche Intelligenz ist ein Produktivitätsfaktor. Dass dabei allerdings eine massive Diskrepanz zwischen Output und Outcome entstehen kann zeigt diese Studie. Einer Steigerung der erzeugten Code-Menge um bis zu 741 % (!) steht nur eine Steigerung der Feature Releases um 20% gegenüber. Die Schluss-Pointe: ein Grossteil der neuen, schnell erzeugten Programme hatte keinen Product-Market-Fit. Es wurde mit Vollgas am Markt vorbei gebaut.
Eines der grossen Kuriosa der agilen Bewegung ist, dass sie sich irgendwann in zwei Varianten aufgespalten hat, die kaum noch verbunden sind, Agile Produktentwicklung und Agile Manufacturing. Zwei Wissenschaftler der Universität von Navarra haben sich mit Agile Manufacturing der weniger bekannten Variante angenommen und erforscht, wie ihr aktueller Anwendungsstand in Europa ist.
