On Lean and Agility

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?

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:

Flyvbjerg, Bent; Budzier, Alexander; Christodoulou, Maria: Explaining Superscaling, China's Greatest Innovation Yet

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.

Bernstein, Ethan S.; Turban, Stephen: The impact of the ‘open’ workspace on human collaboration

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. 

Patil, Rajeshwari; Raheja, Deepali K.; Nair, Lakshmi; Deshpande, Amruta; Mittal, Amit: The Power of Psychological Safety - Investigating its Impact on Team Learning, Team Efficacy, and Team Productivity

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.

Demirer, Mert; Musolff, Leon; Yang, Liyuan: Writing Code vs. Shipping Code - Productivity Effects Across Generations of AI Coding Tools

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.

Jané, Joan; Hill, Holly Anne: Agile Manufacturing

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.

Bild: Wikimedia Commons / Anton Heiz - CC BY-SA 4.0

Unter den vielen Berichten über sich verzögernde Infrastruktur-Projekte ist dieser hier kaum aufgefallen: der Bau des Fehmarnsundtunnels (Teil der Fehmarnbelt-Querung) dauert mindestens drei Jahre länger als geplant. Auffällig dabei ist, dass ein Grossteil dieser Verspätung nicht etwa durch Probleme beim eigentlichen Bauvorhaben entsteht (das hat noch gar nicht begonnen), sondern durch Bürokratie: Ausschreibungsprozesse, zu beachtende Fristen, Einspruchsverfahren, Klagemöglichkeiten, etc.

Der Fehmarnsundtunnel ist dabei kein Einzelfall: wer mit Bauträgern und Behördenvertretern spricht bekommt zahllose derartige Geschichten zu hören, bei denen das eigentliche Vorhaben mehr oder weniger im Plan liegt, bei denen aber bürokratische Vorgaben immer wieder zu verzögertem Start oder zwischenzeitlichen Unterbrechungen führen - und das nicht etwa durch Behördenwillkür, sondern nur weil auch die sich an Gesetze und Vorschriften halten müssen.

Wie sehr es tatsächlich die Verwaltungsbürokratie ist, die alles verlangsamt, kann man an einem anderen Beispiel sehen. den LNG-Flüssiggas-Terminals, die ab dem Jahr 2022 an der Nord- und Ostseeküste gebaut wurden. Für deutsche Verhältnisse sind sie in atemberaubender Geschwindigkeit fertig geworden, zum Teil lag zwischen dem Beschluss des Vorhabens und dem Ende der Bauarbeiten weniger als ein Jahr. Und man kann jetzt bereits ahnen, wie das gelungen ist.

Das für diesen Zweck erlassene "Gesetz zur Beschleunigung des Einsatzes verflüssigten Erdgases" (LNG-Beschleunigungsgesetz) macht fast ausschliesslich Eines: es setzt andere Gesetze und Vorschriften ausser Kraft. Formulierungen wie "Abweichend von § X ..." oder "§ Y des Gesetzes Z ist nicht anzuwenden" ziehen sich durch seinen gesamten Text und machen deutlich klar, dass hier ein subtraktiver Wandel stattfindet. Mit anderen Worten: Verbesserung durch Weglassen.

Natürlich heisst das nicht, dass alle bisherigen Gesetze und Vorschriften sinnlos sind und abgeschafft werden sollten, derartige Kettensägen-Methoden gehören (wenn überhaupt) in ganz bestimmte Sektoren der Privatwirtschaft, die entfesselnde Wirkung eines Regulierungs-Rückbaus ist aber an diesem Fall mehr als deutlich zu erkennen. Wenn der Staat wieder handlungsfähig werden soll, ist das temporäre oder dauerhafte Ausserkraftsetzen also ein durchaus gangbarer Weg.

Das hier gefällt mir wirklich: Barry O'Reilly versucht sich an einem philosophischen Blick auf das Konzept der Software-Architektur. Verkürzt gesagt - während sie häufig als ein logischer und konsistenter Ansatz zur Strukturierung von Software gesehen wird, ist sie in Wirklichkeit eine soziale Technik, mit der versucht wird, Ordnung in eine Welt zu bringen, die sich in einem Prozess der permanenten Unordnung befindet.

Alleine die oben genennten Gedanken hätten vermutlich schon für einen eigenen Vortrag gereicht, aber dieser geht deutlich weiter, und berührt unter anderem Essentialismus, Strukturalismus, Determinismus (und dessen Negierung), die Diskrepanz zwischen Sein und Werden, Positivismus, Interpretivismus, naive Kybernetik, Kausalität, Dekonstruktion und die philosophischen Grundlagen der Matrix-Filmreihe. Definitiv sehens- und hörenswert.

Von Zeit zu Zeit lohnt es sich, Bücher heranzuziehen die zwar zu Zeiten des Aufschwungs der agilen Methoden verfasst wurden, sich aber nicht mit ihnen im engeren Sinn befassen, sondern breitere gesellschaftliche Trends zum Gegenstand haben. Da die agile Bewegung Teil der Gesellschaft ist, bietet diese Art der Betrachtung einen interessanten Blickwinkel: ist auch sie von diesen Trends beeinflusst worden, und wenn ja wie? Ein Buch mit dem man derartig vorgehen kann ist The Cult of the Amateur.

Verfasst wurde es im Jahr 2007 vom britisch-amerikanischen Unternehmer und Schriftsteller Andrew Keen. Vordergründig richtete es sich gegen das in dieser Zeit aufkommende partizipative Internet, damals Web 2.0 genannt (heute würde man von User generated Content sprechen). Auf einer grösseren Ebene handelte es sich aber gleichzeitig um eine harte Kritik an der zu dieser Zeit häufigen Verklärung unwissenschaftlicher und autodidaktischer, dafür aber meinungsstarker Diskussionsteilnehmer.

Zum Kontext: im ersten Jahrzehnt des dritten Jahrtausends ist es zu einer nie zuvor dagewesenen Demokratisierung des Zugangs einzelner Personen zur Öffentlichkeit gekommen. Services wie Wordpress, Youtube, Twitter, Facebook und Wikipedia erlaubten es jedem Menschen, Beiträge zu jedem beliebigen Thema zu veröffentlichen und damit potentiell den allgemeinen Diskurs zu diesem Thema mitzugestalten. Aus demokratietheoretischer Sicht eine grossartige Entwicklung.

Was Keen an dieser Entwicklung kritisierte, war, dass durch den Wegfall der bisherigen Verlags- und Sender-Oligopole nicht nur die Zugangsbarrieren wegfielen, sondern auch die mit ihnen verbundenen Qualitätssicherungs-Mechanismen. Während vorher vorwiegend Inhalte eine grosse Öffentlichkeit erreichten, die gut begründet, in sich konsistent und überprüfbar waren, verschob sich das plötzlich zu solchen, die auf starken Einzelmeinungen zu aktuellen Themen basierten.

Und an dieser Stelle kommen wir zurück zur agilen Bewegung. Selbst wenn viele der damals noch neuen agilen Frameworks basierend auf Praxiserfahrungen entstanden waren, waren die jeweiligen Entstehungsbedingungen so überschaubar und einzelfallspezifisch, dass sich nicht klar sagen liess, was Kausalität war und was Korrelation. Um ein bekanntes Beispiel zu nennen - Extreme Programming (XP) basierte ursprünglich auf den Erfahrungen eines einzigen Teams, das nur wenige Jahre lang bestand.¹

Dass dieser anfangs eher überschaubare Anwendungsfall es zeitweise schaffte, zum populärsten agilen Famework zu werden,² lag wesentlich an den zuvor erwähnten demokratisierten Zugängen zur Öffentlichkeit, im Fall von XP in Form von Wikis wie wiki.c2.com oder wiki.org, in denen Praktiker und Enthusiasten in selbst gewähltem Umfang und Detailgrad Inhalte veröffentlichen konnten, die weltweit von jedem Inhaber eines internetfähigen Computers gelesen werden konnten.³

In diesem Fall hat die Geschichte zwar ein Happy End, da sich XP mit der Zeit in der Praxis bewährte, in anderen Fällen war der Ausgang aber nicht ganz so gut - dass viele Versuche agile Arbeitsweisen einzuführen kläglich gescheitert sind, liegt ganz wesentlich daran, dass das dafür gewählte Vorgehen lediglich auf starken Meinungen und anekdotischer Evidenz beruhten, verfälscht durch Survivor Biases, Hindsight Biases und ähnliche Phänomene.

Zu den klassischen, immer wieder auftretenden Fehlern gehören dabei Über-Simplifizierung ("man muss nur alle Mitarbeiter schulen"), Personalisierung ("die Personen X, Y und Z wollen sich nicht ändern"), Blaupausen-Gläubigkeit ("Spotify hat das auch so gemacht"), Confirmation Bias ("ich habe schon immer gesagt: einfach machen! Endlich sehen das jetzt alle so.") und Ausblendung von Zusammenhängen ("warum reden wir hier über Budgetierung, wir wollten doch über die agile Transformation sprechen").

Dabei ist keiner dieser Fehler unvermeidbar, in der psychologischen und betriebswirtschaftlichen Forschung und Literatur werden sie seit über hundert Jahren behandelt, einschliesslich der Möglichkeiten sie zu erkennen und zu verhindern. Wer eine wissenschaftliche oder praktische Ausbildung im Produkt- oder Projektmanagement durchlaufen hat, wird sie mit grosser Wahrscheinlichkeit vermeiden oder abschwächen können.⁴

Dass eine Kenntnis dieser Forschungsergebnisse und Fachliteraturen in agilen Transitionenzu selten erwartet wird, liegt schliesslich an etwas, das man in Anlehnung an Keen als "Cult of the agile Amateur" bezeichnen könnte: der Verklärung unwissenschaftlicher und autodidaktischer, dafür aber meinungsstarker Scrum Master und Agile Coaches als "Organisationsrebellen" oder Inhaber eines "agilen Mindsets", deren Expertise keiner Validierung bedarf.

Um Missverständnisse zu vermeiden: dieser Cult of the agile Amateur ist nicht in den verschiedenen agilen Frameworks selbst verankert, sondern ist eher aus den oben erwähnten Besonderheiten der Entstehungszeit zu erklären. Und überall dort wo agile Transitionen langfristig erfolgreich gewesen sind, ist er entweder von Anfang an vermieden worden oder er wurde mit der Zeit erkannt und nach und nach eingedämmt und beseitigt.

Wie eine solche Gegenbewegung vor sich gehen kann ist dann wieder von Einzelfall zu Einzelfall unterschiedlich, so dass es dafür kein Patentrezept gibt (ein empirisch-analytisches Vorgehen ist aber ein guter Startpunkt). Lediglich eines lässt sich mit Sicherheit sagen: was nur in den allerseltensten Fällen helfen wird sind agile Zertifizierungen.

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 spiele gerade mit dem Gedanken, eine Beitragsreihe zu starten, in der ich jeweils einige von ihnen vorstelle. Ob es wirklich dazu kommt wird sich zeigen, für den Moment habe ich aber zumindest fünf, die mir erwähnenswert erscheinen. Sie gehen quer durch alle möglichen Themen durch und sind natürlich eine subjektive Auswahl, aber eine die ich empfehlen möchte. Hier sind sie:

Takeuchi, Hirotaka; Nonaka, Ikujiro: The New New Product Development Game

Eine der Initialzündungen dessen, was wir heute agile Produktentwicklung nennen. Vereinfacht gesagt haben Takeuchi und Nonaka Feldforschung betrieben um herauszufinden, warum manche Firmen effektiver Produkte entwickeln als andere. Ihre Forschungsergebnisse sind zwar schon 40 Jahre alt, haben aber nichts von ihrer Aktualität eingebüsst.

Verwijs, Christiaan; Overeem, Barry: The Double-Edged Sword Of Diversity In Teams

Manchmal tun Erkenntnisse weh. Verwijs und Overeem haben versucht, den in der agilen Bewegung verbreiteten Glaubenssatz zu validieren, dass Diversität in Entwicklungsteams etwas grundsätzlich Gutes ist. Ihre Erkenntnis - ganz so einfach ist es nicht. Zwar gibt es eindeutig positive Effekte, in einigen Dimensionen ist Diversität aber ohne Auswirkungen oder führt sogar zu Nachteilen.

Eilers, Karen; Peters, Christoph; Leimeister, Jan: Why the agile mindset matters

Diese Arbeit ist wirklich verdienstvoll. Zum ersten mal habe ich hier gesehen, wie versucht wird, den umstrittenen Begriff des "Agilen Mindset" neutral und sachlich einzuordnen und zu untersuchen. Ein wohltuender Kontrast zu dem eher esoterischen und zum Teil sogar übergriffigen Umgang, der sonst in der Beschäftigung mit diesem Begriff vorherrschend ist.

Flyvbjerg, Bent; Budzier, Alexander: Why Your IT Project May Be Riskier than You Think

Der bemerkenswerte Forschungsschwerpunkt von Bent Flyvbjerg sind (scheiternde) Grossprojekte. Dass die häufig ausser Kontrolle geraten ist zwar bekannt, er differenziert es aber entscheidend aus. Vereinfacht gesagt: es geht nicht immer schief, aber wenn es schiefgeht, dann richtig. Und: die Gründe dafür sind identifizierbar und es gibt erfolgsversprechende Gegenmassnahmen.

Kühl, Stefan: Das Scharlatanerieproblem – Zwischen Professionsbildung und Professionalisierung