On Lean and Agility

Bild: Wikimedia Commons / Roland Dobbins - CC BY-SA 2.0

Unter den vielen verschiedenen "Gesetzen", die mit der Zeit geschrieben wurden, um regelmässig auftretende Phänomene der Softwareentwicklung zu beschreiben, ist ein besonders schönes. Es handelt sich um Hofstadter's Law (also Hofstadters Gesetz), ist benannt nach dem amerikanischen Physiker, Informatiker und Kognitionswissenschaftler Douglas Hofstadter, und wurde von ihm erstmals 1979 beschrieben. Es lautet:

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

Ins Deutsche übersetzt: Hofstadters Gesetz: es dauert immer länger als man es erwarten würde, selbst wenn man dabei Hofstadters Gesetz berücksichtigt. Das klingt erstmal wie ein Scherz, es steckt aber durchaus mehr dahinter. Um dieses Gesetz zu verstehen muss man zuerst kurz das Buch erklären, in dem Hofstadter es veröffentlichte - es hat den Namen Gödel, Escher, Bach: an Eternal Golden Braid und es handelt (unter anderem) von Rekursionen.

Eine Rekursion (von lateinisch recurrere, ‚zurücklaufen‘) wird ein prinzipiell unendlicher Vorgang bezeichnet, der sich selbst als Teil enthält oder sich selbst immer wieder neu startet. Bei einem derartigen Vorgang kann es sich um ein Computerprogramm handeln (das man anhalten muss, wenn es nicht ewig weiterlaufen soll), es kann aber auch ein Denkvorgang (oder eine Verkettung von Denkvorgängen) sein, und genau darauf wollte Hofstadter hinaus.

Den Ausgangspunkt bildet eine bei der Planung komplexer Vorhaben häufige kognitive Verzerrung, der Optimism Bias, der dafür sorgt, dass man den für die Umsetzung nötigen Aufwand unrealistisch niedrig einschätzt. Wie alle derartigen Verzerrungen ist er dem Menschen, in dessen Kopf er stattfindet, aber in der Regel nicht bewusst - im Moment der unrealistisch niedrigen Aufwandsschätzung ist ihm daher nicht klar, dass sie unrealistisch niedrig ist.

Selbst wenn ein vom Optimism Bias betroffener Mensch versucht, den Erfahrungswert, dass er immer zu optimistisch geplant hat, in seine Aufwandsschätzungen einzubeziehen, löst dieser Gedankengang trotzdem erneut den Optimism Bias aus, wodurch die erwähnte Rekursion entsteht. Douglas Hofstadter versuchte diesen Teufelskreis offensichtlich zu machen, indem er in sein nach sich selbst benanntes Gesetz ebenfalls eine Rekursion einbaute: Hofstadters Gesetz löst sich selbst aus.

Die Parallelen zu rekursiven Computerprogrammen sind bis hierhin einleuchtend, an einer Stelle unterscheiden sich die durch Hofstadter's Law beschriebenen Denkvorgänge aber entscheidend von ihnen - mit der Zeit schwächt sich das Ausmass der Verzerrung ab. Das Beispiel an dem Hofstadter sein Gesetz erklärte, war die Entwicklung eines Schachcomputers, der einen Menschen schlagen kann. Und obwohl die Entwicklungzeit mehrfach falsch eingeschätzt wurde - irgendwann war er fertig.

Und damit kommen wir zu einer unerwarteten Verbindung zu einer in vielen agilen Teams verbreiteten Praktik: den Aufwandsschätzungen anhand von Fibonacci-Sequenzen. Dieser exponentielle Wachstums-Verlauf (0, 1, 2, 3, 5, 8, 13, 21, etc) war für Hofstadter beispielhaft für durch Rekursionen bedingte grösser werdende Schätzfehler. Umgekehrt wird in agilen Teams implizit davon ausgeggangen, dass es bei geringer Ungewissheit zu weniger Schätzungs-Rekursionen kommt und die Schätzungen genauer sind.¹

In den meisten Fällen dürfte den die Fibonacci-Sequenzen benutzenden agilen Teams dieser gedankliche Unterbau gar nicht klar sein (was auch nicht weiter schlimm ist). Für alle, die sich an geisteswissenschaftlichen Ausschweifungen erfreuen können, dürfte der Gedanke aber eine gewisse Faszination haben: immer dann, wenn die Scrum- und XP-Teams dieser Welt Planning Poker-Karten hochhalten arbeiten sie an der Widerlegung von Hochstädters Gesetz. Was der wohl dazu gesagt hätte?

Dass die allgemeine Verfügbarkeit von KI-Anwendungen (KI = künstliche Intelligenz) die Arbeitswelt in kurzer Zeit stark verändert hat, ist ein Allgemeinplatz, welche Veränderungen das sind, ist im Einzelfall aber doch immer wieder überraschend. So gehört anscheinend zu ihnen, dass die Nutzung von KI zu einem verstärkten Auftreten des Dunning-Kruger Effektes führen kann, also zu einer unrealistisch guten Selbsteinschätzung, gerade dann wenn eigentlich das Gegenteil der Fall ist.

Nachlesen kann man das aktuell in einer Studie des IT-Sicherheits-Providers Snyk, die auf Interviews mit 500 Entwicklern beruht, schon etwas älter (von 2022) ist eine Meta-Studie der Stanford University, die die Forschungsergebnisse mehrerer amerikanischer und kanadischer Wissenschaftler zusammenfasst. Ohne David Dunning, Justin Kruger oder ihr Paper Unskilled and unaware of it beim Namen zu nennen, beschreiben sie genau das, was den nach ihnen benannten Effekt ausmacht.

Zum Hintergrund: es gibt systemische Gründe, wegen denen der von KI-Tools generierte Code oft schlecht ist. Anders als von Laien angenommen lernen diese Programme nicht selbst, sondern werden von Menschen trainiert, und zwar aus Kostengründen von Billigkräften aus Afrika oder Asien. Bei einfachen Wissensfragen oder Bildgenerierungen funktioniert das auch gut, beim Überprüfen von Quellcode kommen Menschen dieses Gehalts- (und damit Bildungs-)Niveaus aber schnell an Grenzen.

Die Grundlage dieser Trainings ist (vereinfacht gesagt) aller im Internet stehender Code, der natürlich in weiten Teilen schon älter ist. Der auf dieser Basis generierte neue Code ist daher nicht in dem Sinn schlecht, dass er nicht funktioniert (das würde dann doch auffallen), er ist es in dem Sinn, dass er an veralteten Architektur- und Sicherheitsstandards ausgerichtet ist und die so erzeugten Programme aus diesem Grund schwerer verständlich, aufwändiger in der Wartung oder einfacher zu hacken sind.

Statt sich dessen bewusst zu sein, herrschte bei den an den Untersuchungen teilnehmenden Entwicklern aber mehrheitlich die genau gegenteilige Meinung vor: sie waren davon überzeugt, dass der Code, den sie sich von ihrer KI (z.B. von Github Copilot oder Facebook InCoder) hatten generieren lassen, modern, gut lesbar und sicher wäre. Und genau das, die unrealistisch hohe Meinung über die Qualität eher dürftiger eigener  Arbeitsergebnisse, ist der Dunning Kruger Effekt.

Die genauen Gründe, aus denen dieser Effekt in genau diesem Kontext auftritt, sind in den genannten Studien nicht erforscht (und es ist auch fraglich, ob ihre Identifizierung so einfach möglich wäre), einen vermutlich nicht unwichtigen Faktor hat aber Rebecca Parsons, der CTO von Thoughtworks, beschrieben: die Antworten der Chatbots sind immer so formuliert, dass sie den Eindruck zweifelloser Richtigkeit erwecken. Das kann dazu führen, dass diese dann auch vom Anwender angenommen wird.

Die Lehre die man daraus ziehen kann ist, dass gerade KI-generierter Code mit grosser Vorsicht behandelt und möglichst sorgfältig reviewt werden sollte, bevor er irgendwo integriert und deployed wird. Das führt zwar dazu, dass die Menge der Arbeit, die man an eine künstliche Intelligenz delegieren kann gefühlt weniger wird, dafür ist das Ergebnis aber auch besser und sicherer. Und auch das gehört zu Dunning Kruger dazu - wenn man gemerkt hat, dass man betroffen ist, geht der Effekt zurück.

Nachtrag 29.05.2025

Es kam wie es kommen musste: The hottest new vibe coding startup may be a sitting duck for hackers

Wenn es einen Begriff gibt, der von fast jedem Agile Coach oder Scrum Master regelmässig benutzt wird, dann ist es VUCA (volatility, uncertainty, complexity, ambiguity), bzw. dessen deutsche Übersetzung VUKA (Volatilität, Unsicherheit, Komplexität, Ambiguität). Meistens verwendet um zu zeigen, aufgrund welcher Faktoren Agilität nötig ist, verbirgt sich hinter ihm oft eine interessante Wahrnehmungs-Schere: die Selbsteinschätzungen der Betroffenheit durch VUCA gehen z.T. weit auseinander.

Aus einer abstrakten Beobachterposition heraus ist die Sache klar: sich ändernde Rahmenbedingungen, Marktdynamiken und unerwartete Ergebnisse von Hypothesen-Validierungen setzen praktisch jedem Entwicklungsteam permanent zu, so dass regelmässiges Innehalten, Abgleichen des Ist-Standes mit dem Ziel und ein Abgleichen des Ziels mit der möglicherweise veränderten Realität zwingend notwendig ist, wenn man nicht am Bedarf vorbeiarbeiten und so die eigene Firma gefährden will.

Umgekehrt gibt es aber interessanterweise aus vielen Teams und Management-Runden die genau entgegengesetzte Wahrnehmung. Die Existenz von Volatilität, Unsicherheit, Komplexität und Ambiguität im eigenen Umfeld wird hinterfragt oder sogar negiert, oft mit dem Hinweis, dass die Umgebungsfaktoren seit Jahren oder sogar Jahrzehnten unverändert und stabil wären. Oft treffen diese unterschiedlichen Einschätzungen (Vuca und Nicht-Vuca) sogar im selben Kontext auf - wie kann das sein?

Um den weniger wahrscheinlichen Fall zuerst zu betrachten: es kann tatsächlich vorkommen, dass es im Umfeld von Entwicklungsteams über längere Zeiträume zu keinen unerwarteten Entwicklungen kommt. Ein Fall der mir einmal untergekommen ist war z.B. ein Intranet, das nur mit einem selbstentwickelten Browser aufrufbar war. Es wurde zwar weiterentwickelt, war aber von den Überraschungen und Neuerungen der "Aussenwelt" komplett abgekoppelt. Wie gesagt, möglich aber selten.¹

Wesentlich wahrscheinlicher ist eine andere Erklärung: die Existenz der VUCA-Dynamiken wird nicht erkannt oder (ggf. unbewusst) ignoriert. Wer schon einmal in grösseren Organisationen unterwegs war, wird mit etwas Nachdenken sicher auf einige derartige Fälle kommen, die er selbst miterlebt hat. Wichtig für Ihr Verständnis ist dabei, dass diese "Betriebsblindheit" in den meisten Fällen nicht aus individuellen Schwächen entsteht, sondern systemische Gründe hat.

Einer davon kann ein Organisationsdesign sein, das die Entwicklungsteams durch ein zwischengelagertes Anforderungs- oder Produktmanagement weitgehend von Kunden, Anwendern und externen Faktoren abschirmt. Die äusseren Dynamiken finden in solchen Fällen zwar statt, die Teams sind sich ihrer aber nicht bewusst. Die Konsequenz ist ein irgendwann stattfindendes unschönes Erwachen, z.B. dadurch, dass man im Jahr 2020 herausfindet, dass COBOL nicht mehr zeitgemäss ist.²

Ein zweiter Fall wäre der, den man despektierlich als "kollektive Betriebsblindheit" bezeichnen könnte. Er liegt vor, wenn auf allen Hierarchie-Ebenen und in allen Organisationseinheiten die bestehenden Veränderungsdynamiken nicht erkannt oder als zu unwichtig eingeschätzt werden. Beispiele dafür wären die Mobiltelefon-Sparten von Siemens und Nokia, die das Potential der Smartphones nicht erkannt haben. Ihr Schicksal zeigt auch auf, welche Folgen solche Verkennungen haben können.

Ebenfalls anzutreffen ist der unschöne Fall, dass Monopolstellungen ausgenutzt werden, um Anwenderwünsche und technische Neuerungen bewusst zu ignorieren. Das wird z.B. einem grossen ERP-Entwickler immer wieder unterstellt, die meisten derartigen Fälle finden aber im Rahmen interner Anwendungsentwicklungen statt, vor allem dort, wo Konzerne ihre eigene Individualsoftware herstellen. Die Konsequenz daraus ist meistens eine zurückgehende Mitarbeiter-Loyalität, ggf. Kündigungen.³

Welche Variante es auch ist, mit den zu Beginn genannten wenigen Ausnahmen handelt es sich bei fast allen Fällen, in denen Produktentwicklungs-Einheiten glauben, nicht von den VUCA-Faktoren betroffen zu sein, um Verkennungen der Realität, die sich früher oder später rächen werden.  Zumindest in einem techniknahen Umfeld sollte man sich daher besser mit ihnen beschäftigen, und zwar auch und gerade dann wenn man das Gefühl hat, ihnen gar nicht ausgesetzt zu sein.

Cognitive Biases, zu deutsch verzerrte Wahrnehmungen, sind häufiger, als wir es uns eingestehen wollen. Nahezu alle Aspekte unseres Lebens sind davon betroffen, dass wir die Realität nicht immer so wahrnehmen wie sie ist, sondern so wie wir sie uns vorstellen. Auch in der Produktentwicklung kommen derartige Verzerrungen vor, und zwei von ihnen können besonders unschöne Auswirkungen haben: die Empathie-Lücke und die subjektive Validierung.

Empathie-Lücken liegen vor, wenn wir nicht in der Lage sind, uns in die Situation anderer Menschen hineinzuversetzen. Die Ursache dafür sind in der Regel Unterschiede in Herkunft, Alter, Geschlecht, Ethnie oder anderen Faktoren. Warum das in der Produktentwicklung ein Problem ist, dürfte offensichtlich sein - schlimmstenfalls entwickeln wir Produkte an den Bedürfnissen oder Vorlieben der Zielgruppe vorbei, mit der Folge, dass sie am Markt nicht erfolgreich sind.

Eine subjektive Validierung bedeutet, dass wir uns selbst unbewusst zum Massstab für andere machen. Unsere eigenen Wahrnehmungen, Gefühle und Vorlieben kommen uns so selbstverständlich vor, dass wir gar nicht auf den Gedanken kommen, dass andere sie nicht teilen können. In der Produktentwicklung bedeutet das, dass wir schlimmstenfalls nur das entwickeln, was wir selbst verstehen und gut finden und nicht das was auch die Zielgruppe verstehen und brauchen würde.

Ein Beispiel, mit dem man das plastischer machen kann, sind die Schlüsselkarten-Lichtschalter in Hotelzimmern. Sir wurden um das Jahr 2000 herum entwickelt und beruhen auf einer simplen Idee: das Licht im Zimmer lässt sich nur einschalten, wenn die Karte, mit der man auch die Zimmertür öffnet, in einen Schlitz an einem Hauptschalter steckt. Verlässt man das Zimmer, nimmt man die Schlüsselkarte mit, das Licht geht wieder aus und das Hotel spart Strom.

Wir können jetzt versuchen uns vorzustellen, wie wir reagiert hätten, wenn man uns damals diese Idee vorgestellt hätte. Vermutlich positiv. Die Idee klingt gut, man versteht sofort worum es geht, sie ist relativ einfach umzusetzen und mit dem Stromsparen dient sie einem Zweck, der Wirtschaftlichkeit und Umweltschutz vereint. Auch die Manager der Hotelketten waren damals sofort überzeugt, Schlüsselkarten-Lichtschalter sind heute der fast überall anzutreffende Standard.

Das Problem an dieser eigentlich schönen Geschichte: die Idee hat in der Realität nicht gut funktioniert. Viele Hotelgäste verstanden die Funktionsweise nicht und hielten das Licht für kaputt, andere fanden im Dunkeln den Schlitz nicht, wieder andere waren es gewohnt, die Schlüsselkarte im Portemonnaie mit sich zu tragen und vergassen sie ständig im Zimmer. Die Folgen waren schlechte Bewertungen und hoher Arbeitsaufwand für das ständig  zur Hilfe gerufene Personal.

Heute steckt in fast allen Hotels eine zweite Karte dauerhaft in den Schlitzen der Hauptschalter, die dadurch ständig angeschaltet sind. Es gibt zwar meistens den Hinweis, dass man durch das Herausziehen Strom sparen kann (wie oben auf dem Bild), wer sich erkundigt wird aber erfahren, dass das nur selten passiert. Am Ende hat die eigentlich gute Idee also nur dazu geführt, dass in allen Zimmern ein zusätzlicher, kaum genutzer und unnötig komplizierter Lichtschalter eingebaut wurde.

Um wieder zum eigentlichen Thema zurückzukommen - wenn es uns schon bei so einfachen Einrichtungen wie Lichtschaltern und Schlüsselkarten schwer fällt uns in die Anwender hineinzuversetzen, wieviel schwieriger ist es dann bei komplizierten Geräten oder Software-Anwendungen? Das Risiko, dass wir an Bedürfnissen und Vorlieben vorbeientwickeln ist immens, auch (und gerade dann) wenn wir das Gefühl haben, das alles einfach und offensichtlich wäre.

Als Mittel gegen Empathie-Lücken und subjektive Validierungen bleibt am Ende nur eine Möglichkeit: Vertreter der Zielgruppe müssen möglichst früh als Tester und Feedback-Geber in den Entwicklungsprozess eingebunden werden. Onsite Custumer in XP, MVPs in Lean Startup, Sprint Reviews in Scrum und viele ähnliche Konzepte wurden aus genau diesem Grund erfunden. Nur so lässt sich feststellen, ob die eigenen Annahmen stimmen oder nicht.

Bild: Wikimedia Commons / Erwin Soo - CC BY 2.0

"Grau ist alle Theorie, nur im Praxiseinsatz sieht man ob etwas funktioniert." Aufgrund von Überzeugungen wie dieser ist eine ganze Berater- und Erfahrungsbericht-Industrie um ehemalige Angestellte von vorbildhaft agil arbeitenden Firmen wie Google, Facebook, Netflix und Amazon entstanden, die Ratschläge zum agil werden geben. Das ist auch grundsätzlich nachvollziehbar, führt aber leider regelmässig in die Sackgasse. An einem Beispiel möchte ich erklären warum.¹

In den letzten Wochen wurde in meinem Bekanntenkreis wiederholt ein Interview einer ehemaligen Amazon-Managerin herumgereicht,² in dem diese betont, dass das Geheimnis der Agilität in dieser Firma darin liege, keine grossen, jahrelang dauernden Veränderungsprogramme zu starten sondern nur einzelne kleine, und auch die vor allem mit Focus auf Mindset und Achtsamkeit. Das klingt gut und bedient auch ein in der agilen Community beliebtes Narrativ, es ist aber leider inhaltlich falsch.

Wer sich mit der Geschichte von Amazon beschäftigt (z.B. hier und hier) wird das genaue Gegenteil entdecken. Um das Jahr 2000 herum war das Unternehmen durch schnelles Wachstum gross und eher träge geworden, weshalb es (Surprise!) ein grosses, mehrere Jahre dauerndes Veränderungsprogramm startete. Vieles von dem was heute seine Agilität ausmacht (kleine, empowerte Teams mit Verantwortung über klar abgegrenzte Services mit klar definierten Schnittstellen zu anderen Teams) entstand damals.

Die Frage die sich jetzt stellt: wie konnte es angesichts dieser Vergangenheit zu einer derartigen Falsch-Einschätzung der besagten Amazon-Managerin kommen? Die vermutliche Antwort: sie war Opfer einer Wahrnehmungs-Verzerrung die man "Post-Transformation Bias" nennen könnte. Als sie Amazon kennenlernte wird Change Management dort durch viele kleine Massnahmen üblich gewesen sein, dass das aber nur aufgrund eines früheren Grossprogramms möglich war wurde ihr aber nicht erzählt.

Dieses Muster kann man bei Unternehmen mit gut funktionierenden Prozessen immer wieder antreffen. In Unkenntnis der Existenz oder der Tragweite vergangener Umorganisationen wird der durch sie möglich gewordene leichtgewichtige und flexible Arbeitsmodus selbst für das Erfolgsgeheimnis gehalten, selbst wenn die vorgelagerten Weichenstellungen viel wichtiger und entscheidender gewesen sind. Schlimmstenfalls kann diese Fehlannahme sogar ins kollektive Gedächtnis der Firma übergehen.