On Lean and Agility

Mit sichtbarer Zufriedenheit stellte sich der Geschäftsführer Wirtsrat vor seine Belegschaft. Viele Themen wollte er anlässlich der Frühjahrstagung seiner Organisation ansprechen, aber eines ganz besonders und zuerst: seine Freude darüber, dass die Sachbearbeiter jetzt endlich die Vorteile des im letzten Jahr angeschafften teuren neuen CRM-System akzeptierten und seine intelligenten Funktionen benutzten. Er hatte keine Ahnung, wie es sich in Wirklichkeit verhielt.

Ich habe den Geschäftsführer Wirtsrat (der in Wirklichkeit anders hiess) vor langer Zeit in einem meiner ersten Jobs kennengelernt. Er war ein eher klassisch sozialisierter und denkender Vorgesetzter, der überzeugt war, dass zu viel Transparenz und Mitsprache Entscheidungen nur verzögern würden. Aus diesem Grund hatte er das besagte CRM-System auch alleine ausgewählt und gekauft, ohne vorher mit denen zu reden, die es später benutzen würden. Er wusste schliesslich, was gut war.

Die Anwender hatten eine ganz andere Meinung. An sich fanden sie das System ähnlich gut wie das alte, nur eine Funktion fanden sie extrem nervtötend: beim Öffnen jeder einzelnen Ebene des zentralen Ordnerbaums erfolgte ein Ladevorgang von mehreren Sekunden, während denen die "intelligenten Funktionen" geladen wurden - Hilfs- und Hinweis-Funktionen, die sich alle etwa auf dem Niveau von Karl Klammer bewegten: gut gemeint, aber schon nach Kurzem sehr nervig.

Der eigentliche schlimme Nervfaktor war aber ein anderer: es waren die Ladevorgänge, die sich bei tieferen Ordnerbäumen auf bis zu einer halben Minute summieren konnten. Ständig hörte man im Büro fluchende Mitarbeiter, die ewig darauf warteten, endlich bei der Zielebene anzukommen. Der Geschäftsführer Wirtsrat hielt allerdings starr an seiner Meinung fest: die intelligenten Funktionen wären eine wertvolle Hilfe und das neue CRM wäre deswegen gut.

Auch ich war schon nach kurzem von den langen Ladezeiten genervt, und besonders an einem Morgen dauerte alles gefühlt doppelt so lange wie sonst. Ohne gross darüber nachzudenken überbrückte ich die Zeit durch schnelles, ununterbrochenes Klicken auf den Apply-Button, als auf einmal etwas Unerwartetes geschah - eine Systemmeldung tauchte auf und zeigte an, dass das System wegen zu vieler Eingaben überlastet war, weswegen die intelligenten Funktionen temporär ausgeschaltet würden.

Auf einmal waren die Ladezeiten weg. Mit ihnen zwar auch die Hilfsfunktionen, aber die waren wie gesagt ohnehin verzichtbar. Nach dem Neustart war zwar alles wieder da, aber nach kurzem Ausprobieren stellte sich heraus, dass man mit erneuten Dauerklicken die Hilfsfunktionen wieder vorübergehend deaktivieren konnte. Schon nach kurzem hatte sich der Trick herumgesprochen, und der Arbeitstag fast aller Kollegen begann mit schnellem Klicken, gefolgt von zufriedenen Seufzern.

Dem Geschäftsführer Wirtsrat hat während meiner Zeit in seiner Organisation niemand gesagt, dass praktisch jeder Mitarbeiter an jedem Morgen als erstes die intelligenten Funktionen deaktivierte, um während des restlichen Tages produktiv arbeiten zu können. Er hielt die plötzlich stark zurückgehenden Beschwerden für ein Zeichen von Akzeptanz, weshalb es diese auch stolz auf der zu Beginn erwähnten Frühjahrstagung vor allen Mitarbeitern erwähnte. Die Mitarbeiter grinsten und schwiegen.

Natürlich war das ein Extremfall, in verschiedenen Abwandlungen findet man derartige Funktionen und Manager aber in vielen, vielen Organisationen. Und für mich ist dieses Erlebnis, bei dem für viel Geld ein neues System angeschafft wurde, das praktisch alle Mitarbeiter so nervte, dass sie es täglich durch destruktives Nutzerverhalten deaktivierten, ein prägendes gewesen. Davon, ein neues System zwangsweise, ohne Einbeziehung der Nutzer einzuführen, habe ich seitdem immer abgeraten.

Viel zu häufig werden in Projektmanagement und Organisationsdesign Entscheidungen aufgrund von Bauchgefühl, anekdotischer Evidenz oder unvalidierten Annahmen getroffen. Die Gegenbewegung dazu ist das evidenz- oder empiriebasierte Arbeiten, das entweder auf selbst erhobenen Zahlen oder auf wissenschaftlichen Erkenntnissen beruht. Besonders das Zweite kann aber erneut zu einem Problem werden, denn nicht Alles, was auf den ersten Blick wissenschaftlich erscheint, ist es auch.

Die offensichtlichste Form derartiger unwissenschaftlicher Annahmen sind solche, die oft mit Aussagen wie "es ist allgemein bekannt" begründet werden, bei denen es sich aber eher um Truthinesses handelt, also um Aussagen von eher geringer Richtigkeit, die man aber als so naheliegend empfindet, dass man es für unnötig hält, sie zu überprüfen. "Bei großen und komplexen Aufgaben muss man mehr und detaillierter planen, damit alles funktioniert" wäre ein Beispiel dafür.

Wesentlich schwerer zu erkennen sind Behauptungen, die zwar auf echten wissenschaftlichen Erkenntnissen beruhen, diese aber aus ihrem ursprünglichen Kontext herausreissen, sinnentstellend zitieren oder selektiv verkürzen. Eine flüchtige Recherche kann in solchen Fällen den Eindruck einer soliden wissenschaftlichen Fundierung hervorbringen, ein genaueres Betrachten der Quellen findet nur selten statt. Hier sind einige der häufigsten derartigen Fälle

Der Ringelmann-Effekt

Der Ringelmann-Effekt unterstellt, dass Mitglieder einer Gruppe an gemeinsamen Aufgaben nicht mit ganzer Kraft mitarbeiten, und so versuchen, Arbeit auf ihre Kollegen abzuwälzen (was häufig als Rechtfertigung für Arbeits- und Leistungskontrollen dient). Seinen Ursprung hatte er 1913 in der Forschung zu körperlicher Arbeit in der Landwirtschaft und "bewiesen" wurde er in Tauzieh-Wettbewerben. Eine Übertragbarkeit auf die moderne Arbeitswelt ist hochgradig fraglich.

Die Sieben als ideale Teamgrösse

Die häufig zu hörende Aussage, dass die ideale Grösse eines Teams Sieben Mitglieder wäre, wird meistens mit der Psychologie-Studie The Magical Number Seven, Plus or Minus Two von 1956 belegt. Macht man sich die Mühe diese zu lesen, findet man aber heraus, dass es in ihr um etwas völlig anderes geht - um die Anzahl der Informationsquellen nämlich, deren Input ein Mensch gleichzeitig verarbeiten kann. Daraus eine Teamgrösse abzuleiten ist gewagt (Mensch ≠ Informationsquelle).

Die Dunbar-Zahl

Wenn man so will ist die Dunbar-Zahl die grössere Variante der magischen Sieben, es ist die maximale Anzahl an Menschen, mit denen man soziale Beziehungen unterhalten können soll. Auch hier ist der Ursprung bemerkenswert: es ist die Forschung aus den 90ern an Affen, Naturvölkern und vorindustriellen Gesellschaften, welche die in den letzten 200 Jahren erzielten technischen und sozialen Optimierungen zwischenmenschlicher Kommunikation und Zusammenarbeit weitgehend ausblendet.

Die Tuckman-Phasen

Auch als das Forming–Storming–Norming–Performing-Modell bekannt, geht das Tuckman-Entwicklungsmodell von 1965 davon aus, dass Teams nacheinander die vier genannten Phasen durchlaufen. Der wissenschaftliche Unterbau ist dünn, da es sich nur um eine Meta-Studie von Arbeiten aus verschiedenen, nur schwer miteinander vergleichbaren Fachgebieten handelt. Und: in einer Folge-Studie von 2007 durchliefen nur zwei Prozent (!) von 321 Teams die Tuckman-Phasen.

Man könnte die Liste noch länger machen, bereits jetzt dürfte aber klar sein, wie wenig viele der scheinbar gesichert wissenschaftlichen Erkenntnisse auf die moderne Arbeitswelt übertragbar sind. Bereits durch ein einfaches Querlesen der Originalquellen wird schnell klar, dass deren Forschungs-Gegenstand ein völlig anderer war und er kaum Rückschlüsse auf in Projektmanagement und Organisationsdesign zu beachtende Regelmässigkeiten zulässt.

Das soll übrigens nicht heissen, dass evidenz- oder empiriebasiertes Arbeiten eine schlechte Idee wäre, ganz im Gegenteil. Es heisst aber, dass man die "wissenschaftlichen Erkenntnisse", auf die man sich beruft, zumindest bis zu einem gewissen Grad verstanden haben sollte. Wenn das nicht der Fall ist, ist der Übergang zur Truthiness fliessend.

Ich bitte um Entschuldigung, aber hier wird jetzt geflucht. Genauer gesagt wird es um Bullshit gehen, die englische (und wesentlich obszönere) Übersetzung des deutschen Wortes Bockmist, und dabei um ein Phänomen, das viel zu selten beachtet wird - das der Bullshit-Artefakte. Gemeint sind damit Hinterlassenschaften und Ergebnisse von Tätigkeiten, die keinen sinnvollen Zweck erfüllen, aber trotzdem aus irgendeinem Grund stattfinden.

Zuerst ein kurzer Blick zurück. Als Schimpfwort existiert Bullshit etwa seit dem ersten Weltkrieg und stammt angeblich ursprünglich aus Australien und Neuseeland. Zu Beginn ein blosser Ausruf der Frustration, wandelte er sich mit der Zeit zu einem Werturteil über eklatant unsinnige Zustände oder Sachverhalte. In dieser Bedeutung erstmalig  umfassend beschrieben wurde er 1986 vom amerikanischen Philosophen Harry G. Frankfurt in seinem legendären Aufsatz On Bullshit.

Aufbauend darauf definierte der amerikanische Anthropologe David Graeber 2018 die Kategorie der Bullshit Jobs, also von Berufen, die ihrem Wesen nach unsinnig oder überflüssig sind, die aber trotzdem in Organisationen vorgeschrieben oder von ihren Inhabern ausgeübt werden. Beispiele dafür sind der Manager, der aussagefreie Statistiken erhebt oder der Büroarbeiter, der nicht wertstiftende oder nicht nachhaltige Tätigkeiten durchführt.

Die Bullshit Jobs haben seitdem einen festen Platz in der Betrachtung grosser Organisationen gefunden, was aber eher wenig betrachtet wird sind ihre Arbeitsergebnisse. Auf den ersten Blick ist das auch unnötig, schliesslich werden sie ja gerade durch ihre Nicht-Wertschöpfung charakterisiert. Auf den zweiten Blick ist eine Beschäftigung damit aber um so dringlicher, schliesslich stellt sich die Frage, ob nicht doch Ergebnisse entstehen, die genauso unsinnig sind wie die Tätigkeiten.

Und tatsächlich ist genau das der Fall. Zwar entsteht kein nutzbarer Mehrwert, dafür aber Hinterlassenschaften (organisationssoziologisch: Artefakte), verschiedener Art. Diese sind sogar noch kritischer zu betrachten, als man denken könnte, denn nicht nur werden bei ihrer Erstellung Zeit und Ressourcen verbraucht, sie sind häufig auch Ausgangspunkt für weitere, ebenso wenig wertvolle Tätigkeiten, die wiederum weitere derartige Hinterlassenschaften erzeugen, etc.

Bei genauerer Betrachtung lassen sich zwei Typen derartiger Bullshit-Artefakte erkennen. Bei der ersten handelt es sich um die Ergebnisse von Sinnlos-Tätigkeiten. Beispiele dafür sind von niemandem angeforderte und von niemandem gelesene Berichte, die Einhaltung irrelevanter Formatierungen (z.B. der alphabetischen Anordnung von Email-Empfängern) oder das Ausdrucken, Stempeln und wieder Einscannen von Formularen. Schwierig wird das, wenn es zur Vorschrift wird, die alle erfüllen müssen.

Der zweite Typ liegt vor, wenn eigentlich sinnvolle Tätigkeiten mit Sinnlos-Prozessen überzogen werden. Beispiele dafür sind (schein-)genaue Aufwandsschätzungen in volatilen Markt- oder Technik-Umfeldern, die übergreifende Priorisierung aller Aufgaben in Unternehmen, in denen die Teams so spezialisiert sind, dass sie die höher priorisierten Aufgaben im Zweifel gar nicht übernehmen können, oder die Erstellung von Fortschrittsberichten auf Basis unfertiger Arbeitspakete.

Besonders der zweite Typ kann in immensem Ausmass Bullshit-Folgetätigkeiten nach sich ziehen, nämlich dann, wenn versucht wird, die Realität an die Inhalte des jeweiligen Bullshit-Artefakts anzupassen. Das geschieht in derartigen Kontexten nämlich meistens durch noch mehr Bullshit Jobs, also durch weitere unrealistische Aufwandsschätzungen, weitere nicht umsetzbare Priorisierungen, weitere aussagefreie Fortschrittsberichte, etc.

Wichtig beim Gegensteuern gegen derartige Verhältnisse ist übrigens, bei der Wurzel anzufangen. Dort wo sich Bullshit-Artefakte häufen, wird es nur wenig helfen, auf eine bessere Qualität der offensichtlich unsinnigen Berichte, Priorisierungen, Schätzungen, etc. zu dringen. Die erfolgversprechendste Methode ist die ersatzlose Abschaffung der dahinterliegenden Bullshit Jobs. Mit ihnen verschwinden dann auch die von ihnen produzierten unsinnigen Ergebnisse.

Es gibt Begriffe, die komplexe Sachverhalte prägnant auf den Punkt bringen, und einer davon ist gerade neu erfunden worden: die Immerschlimmeritis. Gemeint ist damit der Glaube, dass sich die Verhältnisse denen man ausgesetzt ist permanent verschlechtern - auch wenn in Wirklichkeit das Gegenteil der Fall ist. Geprägt hat ihn der Ökonom Georg Cremer, VWL-Professor an der Universität Freiburg, in einem Zeit-Artikel über Falschwahrnehmungen der Vermögensentwicklung in Deutschland.

Die spannende Frage ist jetzt, wie es zu einer derartigen, nicht der Realität entsprechenden Immerschlimmeritis kommen kann, und tatsächlich gibt es darauf sogar eine wissenschaftlich fundierte Antwort. Der berliner Soziologie-Professor Stefan Liebig (auf dessen Forschung Cremer seine Analyse aufbaut) hat das Phänomen untersucht und kommt zu der Erklärung, dass sich Einstellungen nur träge an veränderte Trends anpassen. Aber was heisst das?

Wenn sich Verhältnisse über eine längere Zeit in eine bestimmte Richtung entwickelt haben, gehen die betroffenen Menschen unbewusst davon aus, dass das mit einer gewissen Zwangsläufigkeit geschieht und aufgrunddessen auch so weitergehen muss. Wenn es also über längere Zeit zu Stagnationen oder Verschlechterungen gekommen ist, werden neu auftretende Verbesserungen nicht als solche erkannt oder lediglich für temporäre Abweichungen von einer dauerhaften Tendenz gehalten.

Wer schon einmal Veränderungsmanagement in grösseren Organisationen betrieben hat, wird jetzt vermutlich ein Deja-vu haben - selbst spürbare Verbesserungen werden in derartigen Kontexten oft nicht als solche anerkannt oder es wird ihnen eine dauerhafte Wirksamkeit abgesprochen. Diese Grundhaltung lässt sich in vielen Fällen anhand von Liebigs Modell mit der unbewussten Fortschreibung vorhergegangener langfristiger Stagnations- und Verschlechterungs-Erfahrungen erklären.

Diese Erklärung ist zunächst einmal frustrierend, bedeutet sie doch, dass Erfolge und Verbesserungen trotz spürbarer Effekte als vergebliche Mühen und sinnlose Aufwände betrachtet werden können, was im schlimmsten Fall zur Folge haben kann, dass sogar erfolgreiche Veränderungsvorhaben wegen einer irrtümlich wahrgenommenen Wirkungslosigkeit beendet oder sogar rückgängig gemacht werden können. Allerdings gibt es auch eine positive Deutung.

Wenn es gelingt, über einen längeren Zeitraum kontinuierliche Verbesserungen aufzuzeigen, dann kann die verzögerte Anpassung von Einstellungen an veränderte Trends zu einem verstärkenden Faktor von Verbesserungsvorhaben werden - die wiederholten derartigen Erfahrungen führen dann zu einem strukturellen Verbesserungsoptimismus, der spiegelbildlich zur Immerschlimmeritis dafür sorgt, dass die Beteiligten davon ausgehen, dass sich die Lage im Zweifel immer weiter verbessern wird.

Für das Veränderungsmanagement in grösseren Organisationen bedeutet das auf den Punkt gebracht, dass es sich lohnt, einen langen Atem zu haben und sich von anfänglicher fehlender Anerkennung nicht entmutigen zu lassen. Denn wenn kontinuierliche Verbesserungen gelingen, dann kann irgendwann die Zustimmung ähnlich stark werden wie zu Beginn die Ablehnung. Und das ist doch ein Ziel auf das es sich lohnt hinzuarbeiten.

Kommen wir noch einmal zurück zum Cult of the agile Amateur, also zu dem Phänomen, dass ein Grossteil der Agile Coaches, Scrum Master und Agile Consultants nur eine eher schmale Datenbasis zur Untermauerung ihrer Konzepte vorweisen kann und stattdessen sein Vorgehen vor allem auf Buchwissen, starke Meinungen (eigene und andere), subjektive Erfahrungen, unvalidierte Hypothesen, anekdotische Evidenz und ähnliche nicht-empirische Ansätze aufbaut.

Dieser Zustand hat sich mittlerweile in grossen Teilen verflüchtigt oder wenigstens abgeschwächt, da zumindest die grossen agilen Frameworks (Scrum, Kanban und SAFe) mittlerweile auf eine Anwendungsdauer von mehreren Jahrzehnten und eine Anwenderbasis von tausenden verschiedener Organisationen zurückblicken können, die auch in zahllosen Studien, Konferenzvorträgen, Fachartikeln und Erfahrungsberichten dokumentiert wurden.

Unabhängig davon gibt es aber weiterhin ein Phänomen, auf das der Name des Cult of the agile Amateur zutreffend ist: die Überzeugung, dass man den Job des Scrum Masters, Agile Coaches oder Agile Consultant nicht nur ohne technisches, fachliches und betriebswissenschaftliches Vorwissen ergreifen kann, sondern dass es auch dauerhaft unbedenklich möglich ist (oder sogar erstrebenswert ist), ihn ohne derartige Kenntnisse auszuüben.

Egal ob auf Konferenzen, auf Meetups oder in den Unternehmen selbst - regelmässig kann man hier agilen Methodikern begegnen, die nicht nur offen gestehen, die genannten Wissensgebiete nicht einmal in Ansätzen durchdrungen zu haben, sondern die es sogar als für ihre Berufsausübung als förderlich ansehen, diesen Zustand beizubehalten, um sich ausschliesslich auf die menschlichen und zwischenmenschlichen Aspekte ihrer Arbeit konzentrieren zu können.

Das mag zwar auf den ersten Blick irgendwie rational wirken, schliesslich gibt es für diese Wissensgebiete bereits Spezialisten, deren Berufs sich explizit um diese dreht. Was aber bei einer solchen Betrachtung vergessen wird, ist, dass technische, fachliche und betriebswissenschaftliche Aspekte sich in einem agilen Arbeitsmodus ändern müssen, und dass das jemandem in einem eher traditionellen Arbeitsmodus sozialisiert wurde nicht immer von alleine klar wird.

Egal ob es sich um continuous Integration, modulare Architektur, outcome-orientierte Anforderungen, Minimum Viable Products oder incrementelle Auslieferung handelt - im Vergleich zu klassischen Prozessen sind diese Ideen so anders und ungewohnt, dass oft grössere Erklär- und Überzeugungsarbeiten zu leisten sind, bevor sich darauf eingelassen wird. Und um diese leisten zu können, braucht es zumindest ein Grundverständnis in diesen Bereichen.

Das heisst natürlich nicht, dass man das alles von Beginn an können muss. Es heisst aber, das man bereit sein muss, sich in diese Wissensgebiete einzuarbeiten und sie sich anzueignen. Und die Bereitschaft dazu sinkt, wenn einem von den Anhängern des Cult of the agile Amateur eingeredet wird, dass das unnötig oder sogar nicht zielführend wäre. Wer daher auf Konferenzen, Meetups oder in Unternehmen derartige Aussagen hört, tut sich und Anderen einen Gefallen, wenn er ihnen wiederspricht.

An sich klingt es erst einmal wie etwas Positives: mit Hilfe der immer besseren und intuitiveren KI-Tools ist es heute so einfach wie nie, Software zu erstellen. Sei es als Programmier-Unterstützung, wie im Fall des Github Copilot, oder als ein Programm, dass einem den Grossteil der Arbeit abnimmt, wie Lovable - es gibt eine ganze Reihe von Möglichkeiten, die eigene Produktivität in bisher ungeahnte Höhen zu schrauben. Und doch steckt auch ein Risiko dahinter.

Vereinfacht gesagt: wenn es auf einmal so einfach ist, neue Programme und Features zu erstellen, wird das auch mit grösserer Bereitwilligkeit getan werden als bisher. Statt aufgrund der begrenzten Kapazität der IT-Abteilungen nur die wirklich wichtigsten Anforderungen umzusetzen, kann jetzt jeder Kundenwunsch, jede einzelne Stakeholder-Anforderung und jede Entwickler-Idee in Produktion gebracht werden. Und das ist bei weitem nicht so positiv, wie es klingen mag.

Die offensichtlichste Folge eines derartigen bereitwilligen Umsetzens aller Wünsche ist die Entstehung von Bloatware, also von Anwendungen, die derartig mit Funktionen überladen sind (von denen viele nur eine sehr kleine oder ggf. sogar lediglich eine hypothetische Anwendergruppe haben) dass sie unübersichtlich werden, schlecht zu bedienen sind, hohe Ladezeiten haben und viel Speicherplatz einnehmen. Mit anderen Worten - es wird ein aus Kundensicht schlechtes Produkt.

Und auch unterhalb der Benutzeroberfläche führt das massenhafte Erzeugen von Funktionalitäten (und damit von Code) zu Problemen. Auch hier ist die Unübersichtlichkeit ein zentrales Problem. Je grösser die Codebase wird, desto schwieriger wird es zu sagen, an welcher Stelle was passiert. Die Überprüfung der KI-Ergebnisse durch einen Menschen (deren Verzicht einem Kontrollverlust gleichkäme) wird immer schwieriger und irgendwann sogar unmöglich.

Diese Phänomene erinnern nicht ohne Grund an die Build Trap (sinngemäss die Produktivitäts-Falle), die 2019 von Melissa Perri in ihrem gleich benannten Buch beschrieben wurde. Auch ihr selbst ist diese Parallele aufgefallen, und sie hat sie in mehreren Social Media-Posts thematisiert. Von ihr stammt auch die Erweiterung des ursprünglichen Begriffs zu dem der AI Build Trap, der damit als zusätzliche und spezifische Ausprägung dieses Antipatterns beschrieben ist.

Um auch hier zu einem konstruktiven Ausblick zu kommen: in die AI-Produktivitäts-Falle zu geraten, ist zum Glück kein Naturgesetz, man kann (und sollte) es auf verschiedene Weisen verhindern. Zum einen, indem man durch kleine, schnell veröffentlichte Incremente überprüft, ob es für die neuen Funktionen überhaupt Bedarf oder Akzeptanz gibt, zum anderen indem intern regelmässig sichergestellt wird, dass der Code von Menschen verstanden wird und ggf. verändert werden kann.

Das kann sich natürlich wie eine Entschleunigung der gerade erst gewonnenen Programmier-Höchsgeschwindigkeit anfühlen - und es ist auch eine. Trotzdem ist es sinnvoll, sich darauf einzulassen, wenn man nicht riskieren will, sich in der Build Trap wiederzufinden, und Produkte gebaut zu haben, die vom  Kunden nicht gewollt und von den eigenen Entwicklern nicht verstanden werden.