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.

Vor einiger Zeit reifte in einer Behörde, deren IT-Projekte ich begleiten durfte, die Einsicht, dass die eigenen Prozesse zu starr und zu langwierig waren. Um dem zu begegnen wurde ein neues "Referat für den Abbau von Bürokratie" geschaffen, das dem entgegenwirken sollte. Seine erste Amtshandlung bestand darin, alle anderen Referate anzuweisen, alle ihre Arbeitsabläufe detailliert zu dokumentieren. Auf Basis dieser Dokumente sollte dann entschieden werden, wo Bürokratie abgebaut werden könnte.

Dieses widersinnige Vorhaben (das nicht zu weniger sondern zu mehr Verwaltungsaufwand führte) gehört zu einem Trend, den der Soziologie-Professor Stefan Kühl treffend als "Bürokratisierung der Entbürokratisierung" beschrieben hat. Hinter ihm verbergen sich die zunehmend verbreiteten Massnahmen, Bürokratieabbau, Digitalisierung, Effizienzzsteigerung und ähnliche Dinge dezidierten Organisationseinheiten zuzuordnen - und damit versehentlich alles nur noch schlimmer zu machen.

Diese Verschlimmerung ergibt sich aus verschiedenen, mit grosser Wahrscheinlichkeit eintretenden Dynamiken. Zunächst gibt es für die neue Zentraleinheit starke Anreize, Informierungs-, Beteiligungs- und sonstige Pflichten anzuordnen, wodurch es wie im Fall des oben genannten Bürokratieabbau-Referats dazu kommen kann, dass alleine der dadurch notwendige Kommunikationsaufwand zu der perversen Konsequenz führt, dass alles ineffizienter wird statt effizienter.

Wenn es darüber hinaus dazu kommt, dass nicht nur über die eigenen Prozesse berichtet werden muss, sondern Änderungen an ihnen zentral begutachtet und ggf sogar genehmigt werden müssen, wird die dafür zuständige Einheit zu einem verlangsamenden Flaschenhals für alle anderen. Schlimmstenfalls kann es dazu kommen, dass selbst dringende und von allen gewollte Änderungen lange verzögert werden, weil die für die Freigabe zuständigen Personen überlastet sind.

Als Folge dessen kann es sogar zu nochmals weiteren Verschlechterungen kommen: um eine eigene Überlastung zu verhindern oder abzubauen neigen viele Zentraleinheiten dazu, der restlichen Organisation einheitliche Vorgehensmodelle oder Berichtsformate vorgeben zu wollen, um deren Lage einfacher verstehen und vergleichen zu können. Diese Vereinheitlichung kann oft nur auf Kosten der optimalen Bedienung der lokalen Bedürfnisse erreicht werden.

Gleichzeitig entstehen demotivierende Auswirkungen für die dezentralen Einheiten. Wenn plötzlich alle eigenen Verbesserungsbemühungen zu Dokumentations- und Kommunikationsmehraufwand führen und darüber hinaus befürchtet werden muss, dass von aussen gut gemeinte Verschmlimmbesserungen stattfinden, dann ist das ein Anreiz, solche Bemühungen gar nicht mehr (oder nur lokal, unangekündigt, unabgestimmt und intransparent) durchzuführen.

Zuletzt stehen Bürokratieabbau-Einheiten aufgrund der mit ihnen verbundenen Erwartungen und Aufwände unter hohem Erfolgsdruck, der (vor allem dann wenn die Erfolge Voraussetzung für Gehalts-, Karriere- und Statusverbesserungen sind) dazu führen kann, dass Fortschritte aufgebauscht und voreilig oder wahrheitswidrig verkündet werden, mit der Folge, dass vordergründig Verbesserungen stattzufinden scheinen, während in Wahrheit Verspätung, Stillstand und Verschlechterungen vorherrschen.

Die Zuordnung von Bürokratieabbau, Digitalisierung, Effizienzzsteigerung, etc. zu dezidierten Organisationseinheiten ist aus all diesen Gründen mit dem hohen Risiko verbunden, das Gegenteil des Angestrebten zu erreichen. Ein wesentlich besserer Weg kann es sein, dezentrale Freiräume für Verbesserungsbemühungen (incl. Zeit und Budget) zu schaffen, alleine verbunden mit der Bedingung einer transparenten Durchführung, um auf versehentliche Fehlentwicklungen hinweisen zu können.

Und um Missverständnissen vorzubeugen - Referate die den Abbau von Bürokratie bürokratisieren gibt es nicht nur in der staatlichen Verwaltung, sondern auch in der freien Wirtschaft. Sie tragen dort nur andere Namen, z.B. Prozessmanagement, Inhouse Consulting, Betriebsorganisation oder Agiles Transitionsteam.

Nachtrag 24.04.2025:

Stefan Kühl hat seine Gedanken zur Bürokratisierung der Entbürokratisierung im Sozialtheoristen-Blog präzisiert.

Wer versucht in grossen Organisationen Bürokratie zu bekämpfen, der wird möglicherweise an der folgenden paradoxen Situation vorbeigekommen sein: während die Ausführungs-Ebene unter der Last der Prozesse und Vorschriften ächzt, ist sich die Führungsebene keiner Schuld bewusst, und kann sogar darauf verweisen, dass das offizielle Regelwerk sogar relativ schlank ist. Für diesen scheinbar widersinnigen Zustand gibt es einen häufigen Grund: Overcompliance.

Um das besser begreifen zu können schauen wir uns zunächst den zugrundeliegenden Begriff an: die Compliance. Hinter ihm verbirgt sich die anzustrebende Regelkonformität von Unternehmen, Behörden und sonstigen Organisationen, also die Einhaltung von Gesetzen, Richtlinien und internen Vorschriften. Compliance zu haben (bzw. Compliant zu sein) ist als Folge dessen das Ziel zahlreicher Prozesse, Tätigkeiten und Organisationseinheiten, die nur zu diesem einen Zweck existieren.

Das Problem bei der Herstellung von Compliance ist allerdings, dass es an ihren Rändern eine Grauzone gibt. Ab wann wird aus einer Routine ein zu dokumentierender Prozess? Gibt es Bagatellgrenzen für Zeit-, Qualitäts- und Budgetabweichungen? Wann können Anweisungen mündlich erfolgen, wann ist die Text-Form ausreichend und wann ist die Schriftform nötig? Alle diese Fragen sind in den Einzelfällen nicht immer eindeutig zu beantworten und lassen einen Interpretationsspielraum offen.

So lange dieses freie Interpretieren innerhalb der Grauzone keine negativen Folgen hat, ist das auch meistens unproblematisch, schwierig kann es aber werden, wenn das zu Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen führt. Viele Organisationen kehren in derartigen Situationen den Interpretationsspielraum um - alles woraus sich eine wie auch immer geartete Verantwortlichkeit ableiten lässt, wird rückwirkend zur Norm erklärt - oft mit disziplinarischen Folgen für die Betroffenen.

Und an dieser Stelle kommt es zur Overcompliance: um nicht ebenfalls oder erneut für etwas zur Verantwortung gezogen zu werden, was sich innerhalb einer Grauzone abspielt, beginnen die Mitarbeiter jetzt die jeweils strengste (und für sie sicherste) Auslegung der Gesetze, Richtlinien und internen Vorschriften anzuwenden. Im Zweifel also alles dokumentieren und schriftlich genehmigen zu lassen, und bereits kleinste Abweichungen zu verfolgen und zu eskalieren.

Bereits das kann lähmende Auswirkungen auf nahezu alle Abläufe haben, im schlimmsten Fall kann es aber sogar noch schlimmer werden - wenn es als Reaktion auf eine kontrollierende und überwachende Variante der Overcompliance dazu kommt, dass selbst für kleinste Aufwände explizite und schriftliche Anweisungen und Abnahmen nötig sind (gewissermassen Gegen-Overcompliance), ist es nicht mehr weit bis zu gegenseitigen Blockaden und bis zum totalen und dauerhaften Stillstand.

Um sich aus einer derartigen Situation zu befreien (oder um es gar nicht erst soweit kommen zu lassen) sind zwei Dinge notwändig: zum einen muss man akzeptieren, dass sich nicht alle Eventualitäten vorhersehen und mit vertretbarem Aufwand regulieren lassen, und zum anderen muss man darauf verzichten, nach in Grauzonen stattgefundenen Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen immer nach einem Schuldigen zu suchen und ihn bestrafen zu wollen.¹

Was darüber hinaus ein sinnvolles Werkzeug für die Verhinderung von Overcompliance sein kann, ist eine Vereinbarung, bei allen Regel-Umsetzungen immer die am wenigsten restriktive Variante anzustreben und von anderen zu fordern. Idealerweise kann das sogar Teil eines "Gesellschaftsvertrages" werden, an dem sich die gemeinsame Zusammenarbeit ausrichtet und auf den man sich bei Prozessgestaltungen, in Konflikten und bei Meinungsverschiedenheiten berufen kann.

Wer die politischen Ereignisse in den Vereinigten Staaten von Amerika verfolgt, wird mit hoher Wahrscheinlichkeit früher oder später an einem merkwürdigen Slogan vorbeikommen: Flooding the Zone (with Shit). Dahinter verbirgt sich ein Vorgehen, das genauso obszön ist, wie es sich anhört, das man aber auch in vielen Veränderungsvorhaben beobachten kann. Sobald man es sich bewusst gemacht hat, erkennt man es an vielen Stellen wieder.

Popularisiert worden ist das Flooding the Zone von Steve Bannon, dem ehemaligen Chief Strategist (obersten Berater) von Donald Trump. Angelehnt an eine Taktik aus Mannschaftssportarten, in denen darunter Überzahlspiel verstanden wird, erklärte er es zum Ziel, eine Diskussion derartig mit Themen zu überladen, dass es der Gegenseite nicht mehr möglich ist, sich auf eines davon zu konzentrieren um es auszudiskutieren oder zu widerlegen.

Da das Change Management in grossen Organisationen wesentlich aus dem Erklären, Hinterfragen und Ausdiskutieren von Veränderungsmassnahmen besteht, sind die Einsatzmöglichkeiten des Flooding the Zone in diesem Bereich offensichtlich. Differenziert betrachtet treten dabei verschiedene Dimensionen auf. Zum einen ist es von Bedeutung, mit welchem Ziel die Flutung stattfindet, des Weiteren womit und zuletzt ob es sich dabei um eine taktische oder eine strategische Massnahme handelt.

Das Ziel des Floodings kann sowohl das Vorantreiben als auch das Behindern von Veränderungen sein. Im ersten Fall findet es statt indem immer neue Ideen und Initiativen angekündigt oder thematisiert werden, im zweiten indem immer neue Bedenken, Argumente und Fragen gegen laufende oder kommende Vorhaben aufgeworfen werden. Die Absicht in beiden Fällen: die andere Seite soll aus dem Konzept gebracht werden, ständig reagieren müssen und dadurch sprunghaft und konfus erscheinen.

Bei der Frage womit die Überflutung stattfindet gibt es erneut zwei Möglichkeiten. Entweder mit realen (ggf. aber kleinteiligen oder redundanten) Bedenken, beliebt sind dabei solche, die einen (angeblich) drohenden Verlust von Qualität, Verlässlichkeit oder Rechtssicherheit zum Gegenstand haben. Alternativ kann man das tun, was Bannon Flooding the Zone with Shit nannte - absurd überspitzte, unsinnige oder falsche Argumente vorbringen, nur mit dem Ziel, der anderen Seite die Lust an dem Thema zu nehmen.

Ob ein Flooding taktischer oder strategischer Natur ist, entscheidet sich schliesslich am jeweiligen Zeit-Horizont. Eine taktische Überflutung findet kurzfristig im Rahmen eines Gesprächs, Meetings oder Mail-Verkehrs statt und hat das Ziel, sie ohne Ergebnis enden zu lassen. Eine strategische Überflutung findet langfristig und kontinuierlich statt und meistens auch gleichzeitig auf verschiedenen Hierarchie- oder Granularitätsebenen und in verschiedenen Organisationseinheiten. Ziel ist eine allgemeine Konfusion.

Gegenmassnahmen gegen das Flooding the Zone sind anstrengend aber möglich. Naheliegend ist es, dieses Verhalten anzusprechen (und damit wahrnehmbar zu machen), auf seine Destruktivität hinzuweisen und darum bitten, es zu unterlassen. Findet es dann trotzdem weiter statt greift die alte Weisheit, dass die Kultur eines Unternehmens vom schlechtesten Verhalten definiert wird, das vom Management zugelassen wird. Mit anderen Worten - es wird zu einem Führungs- oder Disziplinar-Thema.

Soll das Thema Team- oder Gruppen-intern gelöst werden, sind gemeinsame Vereinbarungen der beste Weg. Die können zum Beispiel darin bestehen, für Bedenken oder Änderungs-Anträge eigene Termine oder Agenda-Punkte zu schaffen und die anderen davon freizuhalten, oder zu Beginn eines Meetings die Agenda gemeinsam zu priorisieren (z.B. durch Dot-Voting), wodurch destruktive Agendapunkte gar nicht erst diskutiert werden, oder erst dann wenn die konstruktiven bereits geklärt sind.

Bild: Rawpixel - CC0 1.0

Es ist eines der Phänomene, mit denen man hochrangige Manger so wahnsinnig machen kann wie mit kaum einem anderen, und gleichzeitig ist es erstaunlich häufig: es geht um Projekte, von denen lange Zeit behauptet wird, dass sie im Plan liegen, in denen aber kurz vor dem geplanten Ende auf einmal erhebliche Verspätungen entstehen. Wer verstehen will, wie es meistens zu diesem Ärgernis kommt, kann es sich an einem bekannten Beispiel erklären lassen - den Zügen der Deutschen Bahn.

Regelmässige Zugreisende kennen sehr ähnliche Abläufe: vor dem Beginn ihrer Reise, z.B. von Bonn nach Köln, überprüft man in der App den Reiseplan, und der Zug ist pünktlich. Auf dem Weg zum Bahnhof nochmal, noch immer keine Verspätung. Eine Viertelstunde vor der geplanten Abfahrt empfängt man die erste kleine Verzögerungsmeldung von fünf Minuten, aus denen werden bald 10, dann 15, dann 20 ... irgendwann fährt der Zug schliesslich mit 45 Minuten Verspätung ein. Was ist da passiert?

Die vom freundlichen Schaffner durchgegebene Erklärung lautet, dass es kurz vor dem Bahnhof eine grössere Baustelle gibt, wegen der die Gleise nur langsam befahrbar sind. Dadurch verspätet sich irgendwann der erste Zug des Tages. Der zweite Zug muss hinter ihm halten und warten bis die Gleise frei sind, und danach auch langsam weiterfahren. Hinter dem wartet der dritte, bevor auch er verlangsamt weiterfährt, hinter dem der vierte, und je mehr es werden, desto mehr Verspätung kommt zusammen.

Jetzt kommt der entscheidende Punkt: bis zu diesem Stau auf den Gleisen sind alle dort feststeckenden Züge pünktlich gewesen. Sie haben diese Stelle in der selben Zeit erreicht, die nötig gewesen wäre, wenn die gesamte Strecke frei befahrbar gewesen wäre. Und da nur der aktuelle Streckenstand überprüft wird um die Pünktlichkeit zu ermitteln, kommt es ab dort zum genannten Phänomen: bis kurz vor Bonn sind alle Züge pünktlich, sammeln auf den letzten Metern aber noch erhebliche Verspätungen an.

Die Parallelen zu Grossprojekten dürften offensichtlich sein: auch die passieren oft ein Stage- oder Quality-Gate nach dem nächsten in Time und in Budget, bis sie gegen Ende durch eines müssen, das viel mehr Zeit beansprucht als ursprünglich angenommen (häufig sind das Integration, QA, Rollout oder Inbetriebnahme). Und das Verrückte daran: Obwohl diese Verzögerungen absehbar sind, sind bis zu ihrem Eintreten alle Ampeln grün - schliesslich ist bis dahin noch alles im Zeitplan.

Der Weg es besser zu machen ist bei Zügen und Projekten der Gleiche: sobald absehbar ist, dass es in einem späteren Abschnitt zu Verspätungen kommen wird, müssen diese mit ihrem voraussichtlichen Wert zu der aktuellen Pünktlichkeits-Vorhersage addiert werden, auch (und gerade) dann, wenn bisher alle Zwischenziele dem Zeitplan entsprechend erreicht wurden. Nur dann hat die Pünktlichkeitsmessung überhaupt irgendeine Aussagekraft und Verwendbarkeit.

Eine wichtige Voraussetzung dafür, dass das passiert, ist übrigens, dass derjenige, der Verspätungen meldet, nicht dafür bestraft wird. Ist das doch der Fall, ist das für alle Beteiligten der frühen Phasen ein handfester Anreiz, nur Pünktlichkeitsmeldungen durchzugeben und die Verspätungsmeldung irgendwem möglichst weit hinten auf der Strecke zu überlassen. So entstehen aufgrund falscher Anreizgebung Wassermelonen-Projekte und Arschkarten-Lücken (mehr dazu hier).

Wenn derjenige, der die absehbar näherkommende Verspätungsursache meldet, nicht dafür bestraft wird, können bestenfalls noch Gegenmassnahmen ergriffen werden, schlimmstenfalls kann man aber zumindest die Verspätung mit ausreichendem Vorlauf kommunizieren. Den an der nächsten Station wartenden Menschen wird es dadurch möglich, sich darauf einzustellen, den eigenen Plan anzupassen und die durch die Verspätung freiwerdende Zeit anders zu benutzen als durch blosses Warten.

P.S.: der eine oder andere wird es sich schon gedacht haben - die Erklärung des Phänomens der spät auftretenden Verspätungen anhand der Züge von Bonn nach Köln kommt nicht von ungefähr. Wenn hier jemand von der Bahn mitliest: für den Reparaturbedarf auf der Strecke könnt Ihr nichts, aber realistische Verspätungs-Ankündigungen wären etwas, was vielen Reisenden wirklich helfen würde.

Bevor wir heute in die Business-Welt eintauchen, gibt es einen kleinen Ausflug in die Weltliteratur: wir werfen einen kurzen Blick in den Science Fiction-Roman Picknick am Wegesrand, von den legendären Brüdern Arkadi und Boris Strugazki. Er spielt in der fiktiven amerikanischen Stadt Harmont, in der Jahre zuvor Ausserirdische mit einer unbekannten Mission gelandet sind, nach deren Abschluss sie den Planeten Erde wieder verlassen haben.

Inhaltlich dreht sich der Roman um den Umgang der Menschen mit verschiedenen rätselhaften Objekten, die die Ausserirdischen zurückgelassen haben. Sie sind hoch entwickelt und hübsch anzusehen, der Versuch sie zu benutzen ist aufgrund des fehlenden Wissens um ihre Funktionsweise aber hochriskant und endet für die Menschen oft mit Verletzungen oder Unfällen. Und damit genug von der Literatur und zurück ins Business.

Auch in grossen Unternehmen und Behörden gibt es das Phänomen, dass von ausserhalb kommende Besucher rätselhafte Hinterlassenschaften zurückgelassen haben, von denen keiner genau weiss wie sie funktionieren und deren Benutzung für jeden der es versucht riskant ist. In Anlehnung an Picknick am Wegesrand, bzw. an dessen fiktiven Hadlungsort, beschreibe ich die Entstehung dieser Hinterlassenschaften gerne als den Harmont-Effekt.

Was das für von ausserhalb kommende Besucher sind? Verschiedene, aber die vermutlich wichtigste Gruppe unter ihnen dürften ganz klar die Strategieberatungen sein, die einfliegen, auf Topmanagement-Ebene ihre Ideen verkaufen, und wieder abfliegen ohne sich an der Umsetzung zu beteiligen (oder genau zu wissen wie das ginge). Klassische Strategieberatungs-Hinterlassenschaften sind SpotiSafe und OKRs, die irgendwie auf bestehende Strukturen gekippt werden und dort alles verbürokratisieren.

Die zweite Gruppe sind die Vertreter grosser Standardsoftware-Hersteller, deren Versprechen darin besteht, dass ihr Produkt zwar nicht alle, zumindest aber viele Probleme lösen könnte. Sobald diese Systeme dann angewandt werden sollen, beginnen aber die Schmerzen der inkompatiblen Formate und Workflows, verbunden mit fehlendem Wissen über Konfigurierbarkeit und Erweiterungen. Klassische Hinterlassenschaften dieser Art sind Systeme von SAP, Atlassian, Salesforce und ähnlichen Anbietern.

Eine dritte Gruppe sind Thought Leader und Management-Gurus, auf die der sie beauftragende Manager durch einen Konferenzvortrag oder eines ihrer Bücher aufmerksam geworden ist. Meistens sind ihre Lösungen durch Vereinfachung und Generalisierung anschlussfähig, scheitern in der Regel aber am Wissen, wo sie im Einzelfall Sinn machen und wo nicht. Klassische Thought Leader-Hinterlassenschaften sind Open Space-Formate für Meetings oder unbenutzte Flight Level-Boards.

Als letzte, aber seltenere Gruppe könnte man Manager nennen, die in anderen Unternehmen oder Unternehmensteilen beruflich sozialisiert wurden, und die jetzt versuchen, die dort erlerntern Strukturen und Prozesse auf ihre neue Umgebung zu übertragen. Oft endet das darin, dass nur noch Probleme für diese Lösungen gesucht werden, statt umgekehrt. Klassische Hinterlassenschaften dieser Art sind die "Playbooks" von Google, Amazon oder Spotify.

Die gemeinsame Ursache für diese verschiedenen Ausprägungen des Harmont-Effekts ist, dass in keinem dieser Fälle eine in die Breite gehende Vermittlung von Systemverständnis, Kontextwissen und Prozessdesign-Techniken stattgefunden hat. Stattdessen ist es jeweils eine kleine, oft nur kurzzeitig präsente Gruppe, die Hau Ruck-artig Neuerungen einführt und bereits wieder verschwunden ist, wenn sich aus der Anwendung Fragen und Probleme ergeben.

Ein besseres Vorgehen wäre es, von Beginn an so in die eigenen Mitarbeiter zu investieren, dass diese zu Problemanalyse und Lösungsentwicklung selbst in der Lage sind. Das kann auch gerne mit externer Unterstützung passieren, diese sollte aber nicht mit dem Ziel erfolgen, dass fertige Lösungen von Aussen mitgebracht werden, sondern dass sie intern bedarfsgerecht entwickelt werden können. Derartige Ergebnisse würden dann auch nicht mehr wie rätselhafte ausserirdische Hinterlassenschaften wirken.

Das hier ist eines der Videos, bei denen der alte Spruch stimmt: das Lachen bleibt einem im Hals stecken. Entdeckt habe ich es in den Kommentaren eines Linkedin-Posts, in dem die These aufgestellt wurde, dass Retrospektiven bestenfalls sinnlose Zeitverschwendung sind und schlimmstenfalls eine an Mobbing grenzende Zwangs-Infantilisierung erwachsener Menschen. Das Bittere daran ist, dass es viele Teams gibt, in denen genau das der Fall ist. Das Video ist verstörend nah an einer häufigen Realität.

Anzutreffen sind derartige Katastrophen-Termine immer dann, wenn der Scrum Master, Agile Coach oder Design Thinking-Facilitator den anderen gegen ihren Willen "spielerische Elemente" aufzwingt, unter denen sie eher leiden als von ihnen in irgendeiner Form zu profitieren. Alleine ich habe über die Jahre eine mittlere zweistellige Anzahl derartig entgleister Meeting-Moderationen erlebt, einige davon noch verheerender als hier zu sehen (!) - und alle aus bestem Willen heraus so durchgeführt (was das Ganze um so tragischer macht).

Das soll natürlich nicht heissen, dass Ice Breaker und Gamification per se schlecht wären, viele Teams lieben sie. Genau darin steckt aber ein entscheidender Punkt: wer solche Elemente als Moderator nutzen möchte, sollte genau darauf achten, ob die Teilnehmer sie wollen oder sich davon zumindest nicht gestört fühlen - sowohl grundsätzlich als auch im jeweiligen Einzelfall. Immer dann, wenn das nicht der Fall ist, kann man nur dringend raten, damit sofort aufzuhören. Wenn nicht, wird man das Gegenteil dessen erreichen, was eigentlich beabsichtigt ist.

Bild: Pexels / Antoni Shkraba - Lizenz

In vielen Unternehmen ist gerade ein scheinbar paradoxes Nebeneinander von zwei Phänomenen zu beobachten. Zum einen ist  mittlerweile allgemein anerkannt, dass Firmen agil (d.H. in kurzen Abständen Liefer- und Reaktionsfähig) sein müssen, um Umbrüchen wie Wirtschaftskrisen, Covid19 oder dem Aufstieg von KI-Anwendungen begegnen zu können. Zum anderen trennen sich gerade viele Firmen von ihren Scrum Mastern, Agile Coaches und sonstigen "agilen Methodikern". Wie passt das zusammen?

Spricht man mit Managern in diesen Unternehmen, ist die meistens von ihnen kommende Erklärung eine, die für besagte Methodiker nicht besonders angenehm ist: ja, Agilität ist wichtig und wird (wenn auch z.T. unter anderen Namen) weiter angestrebt. Dass trotzdem gleichzeitig Scrum Master- und Agile Coach-Stellen abgebaut werden liegt daran, dass aus Unternehmenssicht nicht erkennbar ist, dass diese in nennenswertem Ausmass zu diesem Ziel (agil zu werden oder zu bleiben) beitragen.

Diese Bewertung ist heftig und muss darum eingeordnet werden. Zum einen gibt es natürlich auch viele Firmen, in denen nicht so gedacht wird und in denen die agilen Methodiker weiterhin eine hohe Wertschätzung erfahren. Des Weiteren beruhen derartig negative Beurteilungen mitunter auf Unwissen oder hidden Agendas. Die schiere Menge der Fälle legt aber nahe, dass auch solche dabei sind, in denen diese negative Aussenwahrnehmung gerechtfertigt ist.¹

Wenn wir unterstellen, dass diese Rollen grundsätzlich Sinn machen (ein Argument dafür findet sich hier), stellt sich jetzt die Frage, was in so vielen Firmen falsch läuft. Was sind die Gründe dafür, dass Scrum Master und Agile Coaches dort nicht dazu beitragen, die Produktentwicklung agiler zu machen? Die Gründe dürften vielfältig sein, nachdem ich in zahlreichen Unternehmen bestimmte Muster immer wieder erlebt habe, wage ich aber die Hypothese, dass die folgenden Ursachen eine zentrale Rolle spielen:

Fehlende Methoden-Expertise

Eine der irritierendsten Beobachtungen zu Beginn: viele Methodiker haben nur ein erstaunlich dünnes Methodenwissen. Häufig beschränkt es sich auf Scrum (und selbst das manchmal nur oberflächlich²), Kanban wird auf ein Task-Board mit WIP-Limits reduziert, von SAFe sind nur die inneren Mechaniken der Release Trains bekannt, etc. Das engt nicht nur den eigenen Werkzeugkasten ein, es führt auch zum Verlust des Status als Experte für Agilität und Organisationsentwicklung.

Fehlende technische Expertise

Um einem häufigen Einwand direkt zu begegnen - nein, ein Scrum Master oder Agile Coach muss keinen Code schreiben können. Er sollte aber zumindest auf einer abstrakten Ebene verstanden haben, was Continuous Integration, Feature Toggles, Code Coverage und Software Architektur mit Agilität zu tun haben. Ist das nicht der Fall, wird er viele Impediments und Wissenslücken in seiner Umgebung nicht erkennen und damit auch nicht beheben können.

Fehlende fachliche Expertise

Auch hier eine direkte Erwiderung auf einen häufigen Einwand - ja, das ist das Themengebiet des Product Owners. Aber: die Beratung des Product Owners gehört zu den expliziten Aufgaben des Scrum Masters. Und zumindest dort wo Elemente der Fachlichkeit mit dem agilen Vorgehen zu kollidieren drohen (z.B. im Fall von Vorgaben durch gesetzliche Regulierung) müssen diese bekannt und verstanden sein, um ein mit ihnen kompatibles und trotzdem agiles Vorgehensmodell entwickeln zu können.

Fehlende wirtschaftliche Expertise

Dass viele Scrum Master und Agile Coaches dieses Themengebiet nicht als ihres ansehen ist ein schwerwiegendes Missverständnis. Time to Market, Minimum Viable Products, Lead Times, Technische Schulden, (die Vermeidung von) Waste und viele andere Themen sind zutiefst betriebswirtschaftlich und gleichzeitig von zentraler Bedeutung für agile Produktentwicklung. Wer sie nicht kennt wird sich oft schwer damit tun, einem Stakeholder die Sinnhaftigkeit agilen Arbeitens zu erklären.

Fehlendes Systemverständnis

Gemeint ist hier das organisatorische Gesamtsystem. Ausserhalb der eigentlichen Produktentwicklung gibt es verschiedene Prozesse und Einheiten, die starke Einflüsse auf den Grad der möglichen Agilität haben: von Budgeting und Compliance über HR und Betriebsrat bis hin zum Facility Management. Ähnlich wie im Fall der technischen Expertise ist es ohne Systemverständnis an vielen Stellen nicht möglich, Impediments zu erkennen (und damit auch nicht, sie zu lösen).

Um es noch ein weiteres mal zu wiederholen: es gibt viele Firmen in denen sich andere Konstellationen finden lassen, die gerade genannten Qualifikationslücken sind also keineswegs typisch für die agilen Methoden-Berufe. Es gibt aber eine signifikante Menge in dieser Gruppe, die diese Aspekte (bewusst oder unbewusst) wenig beachtet hat, um sich stattdessen mit Themen wie Coaching, Achtsamkeit und kreativer Meeting-Moderation zu beschäftigen. Nicht dass die keine Berechtigung hätten, aus einer unternehmerischen Sicht sind sie aber deutlich weniger wichtig als die zuvor genannten.

Was man für ein vollständiges Bild aber auch sagen muss: aus einer unternehmerischen Sicht ist es ebenfalls sinnvoll und notwendig, die oben genannten Themengebiete in die Ausbildung und Weiterentwicklung der eigenen Scrum Master und Agile Coaches zu integrieren. Dort wo das geschehen ist, dürften diese Jobs wertstiftend (und damit sicher) sein. Dort wo es nicht geschehen ist sollte man sich fragen, ob die aktuellen Entlassungen nicht auch ein Zeugnis einer verfehlten Personalpolitik sind.

Dieser Vortrag von Nigel Thurlow ist eine Provokation, allerdings eine mit einem ernsthaften Hintergrund. Anhand der Definitionen aus dem Buch Bullshit Jobs bezeichnet er Product Owner, Scrum Master und Agile Coaches als genau solche, da sie oft nur Schein- oder Alibi-Tätigkeiten ausüben, weil die Verbesserungen, die sie eigentlich bewirken sollen, durch politische oder systemische Faktoren verhindert werden. Man muss es leider zugestehen - das was er beschreibt kommt in der Realität vor.

Umgekehrt kann man seine Ausführungen aber auch als Anleitung dafür nehmen, wie es besser geht. Wenn wirkliche Agilität das Ziel ist, kann man Output-Fixierung, fehlende Systemsicht, falsche Anreizgebung, komplizierte Aufbauorganisationen und die weiteren von ihm genannten Hindernisse abbauen. Und wenn Product Owner, Scrum Master und Agile Coaches daran arbeiten dürfen, sind es auch keine Bullshit-Jobs mehr.

Bild: Pexels / Antoni Shkraba - Lizenz

Ursprünglich ist das Customer-Vendor Antipattern eine Verhaltensweise, die zwischen Menschen auftritt. Mehrere von ihnen planen ein gemeinsames Vorhaben, trauen sich aber nicht so ganz. Also versuchen sie möglichst genau festzulegen, wer für was zuständig ist. Das paradoxe Ergebnis sind mehr Streit und Zuständigkeitslücken, da alle Seiten sich bei ungeplanten Zusatzaufwänden auf den Standpunkt zurückziehen können, diese nicht in ihrem offiziellen Aufgabenbereich zu haben.

Vor allem in grossen Organisationen legen aber auch ganze Organisationseinheiten dieses Verhalten an den Tag. Das ist vor allem dort der Fall, wo hochspezialisierte Einheiten sich gegenseitig beauftragen, z.B. dann, wenn eine Fachabteilung eine Kampagne vom Marketing oder eine Vertriebs-Ressort neues Feature vom konzerneigenen IT-Systemhaus haben möchte. Sobald eine oder mehrere Seiten sich in solchen Szenarien gegen ungeplante Entwicklungen "absichern" möchten, nimmt das Drama seinen Lauf.

Als erste Folgeauswirkung werden mit z.T. riesigem Aufwand telefonbuch-dicke Lasten- und Pflichtenhefte erstellt, in denen selbst kleinste Details fachlich und technisch beschrieben werden und in denen (offen oder verklausuliert) jeder versucht, der jeweils anderen Seite die Verantwortung für unentdeckte Risiken oder unvorhersehbare Entwicklungen zuzuschieben. Die beauftragende Seite strebt dabei in der Regel einen Festpreis an, die beauftragte Seite einen Fixed Scope.

Da den meisten Organisationen mittlerweile klar ist, dass die meisten Pläne nicht umsetzbar sind wie gedacht, kommt es als zweite Folgeauswirkung zur Festlegung von Prozessen, mit denen diese Anforderungen gegebenenfalls geändert werden können. Um dabei nicht übervorteilt werden zu können, enthalten sie oft Kontroll- und Freigabeschritte in einem Ausmass, dass die Umsetzung selbst beim besten Willen aller Beteiligten nur noch bürokratisch sein kann.

Als dritte Folgeauswirkung wird in der Regel versucht, ein möglichst kleinteiliges Reporting über dem Umsetzungsprozess zu etablieren, mit regelmässigen und eng getakteten Meilensteinen, Fortschrittsberichten, Lenkungsausschüssen, Abnahmen und Change Requests. Besonders die beiden letzten sind häufig stark formalisiert und nur mit grossem Aufwand revidierbar, auch das wieder getrieben vom Wunsch nach möglichst viel Sicherheit und Kontrolle.

Sobald in einem derartigen Szenario die Umsetzung beginnt, ist es meistens nur eine Frage weniger Wochen oder Monate bis alles entgleist. Es werden Notwendigkeiten entdeckt, die in den den Lasten- und Pflichtenheften nicht abgedeckt sind, die Änderungsprozesse werden angestossen, dauern ewig, führen aber zu keiner Einigung, Streitpunkte werden bis auf die höchste Hierarchie-Ebene eskaliert und schlimmstenfalls muss bis zu einer Klärung die Umsetzung pausieren.

Nochmal zur Erinnerung: wir reden hier nicht von verschiedenen Firmen, sondern von verschiedenen Einheiten eines gemeinsamen Unternehmens oder Konzerns.

Für die beauftragende Einheit bedeutet das, dass sie versuchen muss, für möglichst wenig Geld möglicht viel Leistung einzukaufen (und dass ohne im Detail zu verstehen, wie die Erbringung funktioniert), für die auftragsannehmende Einheit bedeutet das, dass sie versuchen muss, mit möglichst geringem Aufwand möglichst hohe Einnahmen zu erzielen (und das ohne verstehen zu können, ob die zu diesem Zweck in Rechnung gestellten Tätigkeiten fachlich durchgehend sinnvoll sind). Das kann nicht gut gehen.

Eine nachhaltige Lösung kann daher nur daraus bestehen, die strukturellen Gründe für das Customer-Vendor Antipattern zu beseitigen. Und das kann eigentlich nur dadurch nachhaltig stattfinden, dass die verschiedenen organisatorischen Silos aufgelöst werden und ein und die selbe Einheit sowohl für das Budget, als auch die Fachlichkeit und die Umsetzung verantwortlich ist, also möglichst weite Teile der Wertschöpfungskette verantwortet.

Natürlich wäre das für fast jede grössere Organisation eine radikale Abkehr von ihren bisherigen Organisations- und Arbeitsteilungs-Prinzipien, aber es wäre auch eine die gut begründbar ist und alleine durch die Auflösung interner Konflikte und Blockaden für mehr Effektivität und Effizienz sorgen würde.

Bild: Pexels / Anna Tarazevich - Lizenz

Eigentlich sind Learning & Development-Angebote grossartig: Firmen wollen die Aus- und Weiterbildung ihrer Mitarbeiter fördern und stellen ihnen darum kontinuierlich neue Lerninhalte zur Verfügung. Gerade in grösseren Organisationen kippt dieser eigentlich gute Ansatz aber immer wieder ins Dysfunktionale. Ein aktueller Fall, den man den Medien entnehmen kann, ist der von Slack, bzw. Salesforce. Das Drama, das hier wohl stattgefunden hat, ist leider exemplarisch für vieles was häufig schiefläuft, und verdient daher eine nähere Betrachtung.

Ausgangspunkt ist anscheinend die Digitalisierung und Automatisierung von Lern-Angeboten, die Salesforce irgendwann durchgeführt hat, vermutlich um die Einheitlichkeit der vermittelten Inhalte sicherzustellen, um sich von der Verfügbarkeit von Trainern und Schulungsleitern unabhängig zu machen, um Reiseaufwände zu den Schulungszentren zu sparen und um durch die beliebig häufige Wiederholbarkeit des einmal erstellten Materials Kosten einzusparen. So weit, so gut.

Ebenfalls betriebswirtschaftlich getrieben dürfte eine zweite Entscheidung gewesen sein: als interne Lernplattform wurde Trailhead gewählt, ein bereits vorhandenes Tool, das eigentlich dafür gedacht ist, Anwendern beizubringen, wie die Salesforce-Anwendungen funktionieren. Ein wesentliches Element dieses Tools sind Gamification-Elemente, das heisst, Lern-Punkte, die man für das Bewerten von Kursen und das Abschliessen von Wissenstests sammeln kann. Ebenfalls erstmal ok.

Eher humanistisch motiviert war vermutlich die dritte Entscheidung: Im Sinn eines Studium Generale wurden auch Inhalte in die "Lehrpläne" einbezogen, die keinen unmittelbaren Bezug zur täglichen Arbeit haben, etwa Eräuterungen der "vierten Industriellen Revolution" (Industrie 4.0) oder zur gesunden Ernährung. Auch daran kann man für sich genommen nur Gutes finden, ein Blick über den Tellerrand schadet nie und beugt dem Entstehen von Fach-Idiotie vor.

Was anscheinend nicht bedacht wurde, war der durch diese Art der Wissensvermittlung entstehende Zeitaufwand. Die verschiedenen Inhalte erreichten in Summe einen bemerkenswerten Umfang, und durch die Gamification-Elemente liessen sie sich nicht mehr im Hintergrund abspielen, sondern erforderten ständige Interaktion. Um die vorgegebenen Lernziele zu erreichen musste daher Zeit im Umfang von mindestens 40 Stunden investiert werden.

Man kann jetzt versuchen, sich in die Mitarbeiter der Salesforce-Tochtergesellschaft Slack hineinzuversetzen. In ihrem Learning & Development-Portal fanden sie Inhalte, die zum Teil generisch und zum Teil beruflich irrelevant waren, nur mit hohem Zeitaufwand konsumierbar waren, in einem Tool angeboten wurden, das eigentlich erkennbar einem anderen Zweck dienen sollte, ohne die Möglichkeit Verständnis- oder Vertiefungsfragen zu stellen. Kaum einer nahm diese Lern-Angebote an.

Peinlich wurde das aus Sicht des Unternehmens dadurch, dass es für jeden offensichtlich war. Die Gamification Elemente sorgten nicht nur dafür, dass die einzelnen Mitarbeiter Lern-Punkte sammeln konnten, dadurch dass die Ranglisten intern öffentlich waren, wurde klar, dass kaum jemand Punkte sammelte, was im Umkehrschluss bedeutete, dass kaum jemand die Learning & Development-Angebote wahrnahm. Ein offensichtliches und verheerendes Feedback.

Ebenfalls verheerend war die Reaktion des Unternehmens: das Lernen wurde erzwungen, indem angeordnet wurde, dass alle anderen Tätigkeiten eingestellt werden mussten, bis vorgegebene Mindest-Punktzahlen im Lern-Tool erreicht waren. Und das am Ende des Jahres, mitten in der Phase, in der viele damit voll ausgelastet gewesen sein dürften, an der Erreichung ihrer (gehaltsrelevanten) Jahresziele zu arbeiten. Die Nicht-Begeisterung angesichts dieses "Lern-Zwangs" kann man sich vorstellen.

Aber wo Frustration entsteht, da wird nach Auswegen gesucht. Und da Software-Entwickler das Lösen technischer Probleme als Beruf haben, kam es bald zur absehbaren Pointe der Geschichte: die Mitarbeiter programmierten sich ihre eigenen Tools, die automatisiert die Gamification-Elemente in Trailhead durchklickten. So konnten die geforderten Lern-Punkte erzeugt werden, ohne dass man sich mit den aufgezwungenen Themen beschäftigen musste. Formalismus erfüllt, Lerneffekt gleich null.

Man kann sich jetzt überlegen, an welcher Stelle der eigentlich gute Learning & Development-Ansatz entgleist ist. Vielleicht bei der Idee, generische Inhalte für alle Mitarbeiter festzulegen, vielleicht beim Versuch, durch die Wiederverwendung eines für einen anderen Zweck konzipierten Tools Geld zu sparen, vielleicht bei der Erstellung einer Punkte-basierten "Lern-Planwirtschaft", vielleicht beim Versuch, den Erfolg des Vorgehens zu erzwingen. Vermutlich war es eine Kombination von allem.

Selbst wenn dieser Fall vermutlich ein extremer ist, die verschiedenen Entgleisungs-Ursachen finden sich in unterschiedlicher Ausprägung in sehr vielen grossen Organisationen wieder, was auch erklärt, dass die internen Lernangebote einen nicht besonders guten Ruf haben. Und ich kann es aus eigener Erfahrung sagen: selbstgebaute Tools, mit denen Entwickler lästige Pflichtkurse "wegautomatisieren", gibt es nicht nur bei Salesforce, sondern auch in anderen Firmen.

Bild: Wikimedia Commons / Alien Property Custodian - Public Domain

Ein Begriff an dem man immer wieder vorbeikommt, wenn es darum geht, ein (negatives) Gegenstück zur agilen Produktentwicklung zu finden, ist die so genannte Feature Factory. Genauer erklärt wird er allerdings nur selten, und wenn, dann meistens nur mit Assoziationen zu Akkordarbeit und starren Kontrollstrukturen. Dabei steckt durchaus mehr dahinter, wenn man es sich näher anschaut. Starten wir damit in einer weit zurückliegenden Vergangenheit.

Im frühen 20. Jahrhundert sind die meisten industriellen Betriebe noch wie Manufakturen organisiert. Es gibt zwar bereits erste berufliche Spezialisierungen und Befehlsketten, die eigentliche Arbeit wird aber noch von Hand durchgeführt, in der Regel von mittelgrossen, crossfunktionalen Teams, die ihre Produkte (Kameras, Autos, Plattenspieler, etc.) Stück für Stück vollständig erstellen, was oft eher den Charakter von Einzelanfertigungen als von Serienfertigung hat.

Diese Serienfertigung kommt erst zu dieser Zeit auf, ihre Erfindung wird vor allem mit den Industriellen Frederick Winslow Taylor und Henry Ford verbunden. Sie sorgen dafür, dass die Arbeit auf hoch-spezialisierte Teams übergeht, die jeweils nur noch wenige, immer gleiche Handgriffe an nur einer Station einer motorisierten Fertigungskette (dem Fliessband) vornehmen. Dass daraus am Ende ein Produkt entsteht, wird durch das Management sichergestellt, das die Fertigungskette entwirft und überwacht.

Erst durch diese hochspezialisierte und teilautomatisierte Serien-, bzw. Fliessband-Fertigung werden Produkte so billig, dass sie mit Erfolg auf dem Massenmarkt verkauft werden können, was dazu führt, dass diese Methoden nach und nach von allen Firmen übernommen werden (bzw. dass die, die sich nicht darauf umstellen, vom Markt verdrängt werden). Zuerst geschieht das in den Fabriken, später aber auch in anderen Bereichen, z.B. in Grossküchen, grossen Büros oder in Call Centern.

Besonders die letzte Entwicklung ist dabei von Bedeutung: nach und nach werden im zwanzigsten Jahrhundert fast alle Wirtschaftszweige nach den Ideen von Winslow und Ford umgeformt, bis irgendwann der Eindruck entsteht, dass sie überall anwendbar und zielführend sind. Dass das dann irgendwann auf Fälle treffen muss, in denen das eben nicht der Fall ist, ist naheliegend. Und damit kommen wir zu einer dieser Ausnahmen, der Softwareentwicklung.

Auf den ersten Blick kann man auch in der Softwareentwicklung eine Art Fertigungskette für neue Funktionen (eben die Feature Factory) aufbauen. Am Anfang steht das Anforderungsmanagement, dann das Anwendungsdesign, dann das Schreiben des Code, die Integration der einzelnen Komponenten, die Qualitätssicherung und schliesslich die Auslieferung. Es scheint nahezuliegen, dafür sequenziell angeordnete Spezialistenteams aufzubauen. Das Problem bei diesem Vorgehen: man bekommt am Ende zwar Ergebnisse, aber leider nicht die, die man gebraucht hätte.

Bedingt dadurch, dass man Software per Copy & Paste vervielfältigen kann, kommt es bei ihrer Erstellung nie zu einer wirklichen Serienfertigung, stattdessen wird lediglich ein Einzelstück nach dem anderen erstellt und das dann gleichzeitig an alle Nutzer ausgeliefert. Da diese Einzelstücke aber jeweils individuell anders sind, müsste die "Software-Fertigungsstrasse" eigentlich jedes mal neu konzipiert werden, da sonst die spezialisierten Einzeltätigkeiten nicht sauber ineinandergreifen.

Das allerdings ist kaum realisierbar, alleine wegen des damit verbundenen Umgewöhnungs-Aufwands der jeweiligen Spezialisten. Die sinnvolle Lösung wäre daher eine Rückkehr zum Manufaktur-Prinzip. Crossfunktionale Teams mit relativ geringer Spezialisierung erstellen ein Software-Produkt nach dem anderen und passen ihre Abläufe dabei jedes einzelne mal so an, dass sie für die in diesem Fall vorhabdenen Erfordernisse passend sind. So weit, so (scheinbar) einfach.

In der Realität wird die eigentlich gut nachvollziehbare Tatsache, dass Softwareentwicklung sich nicht wie eine Fabrik organisieren lässt, von vielen Managern und Unternehmensberatern bis heute bestritten. Sei es wegen fehlendem IT-Bezug, aus Methodismus (das klappt doch überall, also auch hier) oder aus welchem Grund auch immer - wieder und wieder trifft man vor allem in grösseren Firmen auf Fälle, in denen Entwicklungsabteilungen oder -ressorts als Feature Factories organisiert sind.

Praktisch immer führt das zu einer von zwei Dysfunktionen: entweder ist die "Fertigungsstrasse" nicht so optimiert, wie es im jeweiligen Einzelfall nötig wäre, was zu Ineffizienz und Fehleranfälligkeit des Prozesses führt, oder das Design der neu zu bauenden Funktionen wird an den vorhandenen Erstellungsprozess angepasst - im Zweifel auf Kosten der Marktbedürfnisse, was geringere Akzeptanz beim Kunden und geringeren wirtschaftlichen Erfolg zur Folge hat.

Diese Entwicklungen sind der tatsächliche Grund dafür, dass in der Softwareentwicklung Feature Factories hoch problematisch und anti-agil (im Sinne von einschränkend für Geschwindigkeit und Flexibilität) sind. Und selbst wenn man es nie schaffen wird, jeden zu überzeugen - ein besseres Argument als die Ablehnung von gefühlter Akkordarbeit und starren Kontrollstrukturen sind sie auch.

Bild: Pexels / DS Stories - Lizenz

Man hört ja in letzter Zeit immer wieder, dass es so toll wäre, ein agiles Mindset zu haben. Ist es aber nicht. Wir haben es ausprobiert und es hat überhaupt nicht geklappt!

Dabei waren wir echt offen. Unmittelbar nachdem unser Personalvorstand auf seinem Yoga-Retreat gelernt hat, dass man nur die richtige geistige Haltung braucht, damit sofort alles besser läuft, haben wir die Tat ergriffen und alle unsere HR-Führungskräfte in Weiterbildungen zu Achtsamkeit, Spiral Dynamics und Emotionscoaching geschickt. Das lief auch wirklich total super, einige haben sich sogar ein Enneagram tätowieren lassen.

Wir haben es auch geschafft Fehlentwicklungen einzufangen. Statt sich auf Meditation und NLP einzulassen wollte unsere IT alles auf ihre technische Ebene herunterziehen und uns erzählen, dass Implementierungsdetails wie Clean Code, Build Pipelines und Testpyramiden etwas mit Agilität zu tun hätten (was soll das mit geistiger Haltung zu tun haben?). Zum Glück konnten wir klarmachen, dass wir es sind, die entscheiden was agil ist und was nicht, schliesslich sind wir zertifizierte Agile Mindsetter.

Auch weitere gefährliche Missverständnisse haben wir in dem Zusammenhang korrigieren können. Stellen Sie sich vor, die wollten unser agiles Budget nehmen um ihre Leute in Mob-Programming zu trainieren. Mobbing, das geht doch gar nicht. Wir haben das sofort untersagt und stattdessen alle auf verpflichtende Kurse zu gewaltfreier Kommunikation geschickt. War auch höchste Zeit, denn einige Entwickler sind ausfällig geworden als sie das gehört haben. Die mussten direkt nochmal teilnehmen.

Einen Volltreffer gelandet haben wir bei der Besetzung der Stelle des Agile Coach. Den alten, den die IT irgendwoher besorgt hatte, haben wir weggeschickt, der hatte nur ganz merkwürdige Ideen. Beyond Budgeting und Lean Governance zum Beispiel, wir glauben, der hat nur mit dem Zufallsgenerator Wörter zusammengewürfelt. Sein Nachfolger dagegen hat verstanden worum es geht: er hat allen Mitarbeitern eine Spiral Dynamics-Farbe zugeordnet. Endlich Klarheit, wer das richtige Mindset hat und wer nicht!

Basierend darauf haben wir dann die agile Transition in der Belegschaft durchgeführt, mit dem Ziel ein einheitliches agiles Mindset zu bekommen. Allen Kollegen bei denen die Farben Beige, Purpur, Rot, Blau und Orange diagnostiziert wurden, haben wir Tetralemma-Aufstellungen und AQAL-Coachings als Entwicklungsziele gesetzt, damit sie sich aus ihren eigenen geistigen Beschränkungen befreien können. Und glauben Sie uns, die Coaches die wir dafür geholt haben waren nicht billig.

Das Ergebnis war dann auch erstmal überragend. Jedem Mitarbeiter konnte man die Worte "agil ist ..." zurufen und sie wurden wie aus der Pistole geschossen mit "... ein Mindset" beantwortet. Bei Problemen jeglicher Art wurde immer zuerst über die Einstellung der Beteiligten geredet. Und die Querulanten, die das alles bis zum Schluss nicht mitmachen wollten, haben dann irgendwann gekündigt und machen jetzt ihr DevOps, CI, TDD, XP oder was die sonst noch fälschlicherweise für agil halten woanders.

Sie sehen also, wir haben nicht nur alles dafür getan um ein agiles Mindset zu bekommen, wir haben es sogar erfolgreich geschafft, die Agile Mindsetter-Zertifikate sind der Beweis. Aber jetzt kommts: trotzdem sind Arbeitsgeschwindigkeit, Produktqualität, Reaktionsfähigkeit oder Kundenzufriedenheit nicht nach oben gegangen sondern nach unten. Wir müssen deshalb die unbequeme Wahrheit aussprechen: Wir haben es mit dem agilen Mindset versucht, aber es funktioniert nicht. Untertanenkultur war doch besser.

[/ironie off]

Bevor sich jemand aufregt - natürlich ist alles was weiter oben steht populistisch, polemisch und überspitzt. Aber: alles was ich dort aufgeschrieben habe, habe ich irgendwann mal im Rahmen verschiedener agiler Transition erlebt, sogar die Enneagram-Tätowierung und den zertifizierten Agile Mindsetter. Ein Grossteil des angeblichen Veränderungswiderstands in Belegschaften lässt sich damit erklären, dass ihnen derartige Esoterik als Bestandteil von Agilität verkauft wird.

Bild: Pxfuel - Lizenz

Wer dort unterwegs ist, wo mehr oder weniger nach den agilen Frameworks gearbeitet wird, wird früher oder später etwas Erstaunliches feststellen: ein Grossteil der Menschen hier befindet sich mehr oder weniger durchgehend in einem Zustand des Sarkasmus, des Zynismus oder der Ironie, wenn es zum Gesprächsthema Agilität kommt. Komisch eigentlich, schliesslich sollte man denken, das Verbessern der Arbeitswelt sollte doch eine freudige Angelegenheit sein.

Und doch ist es so. Ich bin mittlerweile seit über 10 Jahren in agilen Projekten und Transitionen unterwegs, habe mehr als 100 Meetups und User Groups organisiert oder besucht und bin auf mehr als 20 Konferenzen Speaker und Teilnehmer gewsen. Und in dieser gesamten Zeit habe ich überall einen signifikanten Anteil von Product Ownern, Scrum Mastern, Agile Coaches und sonstigen Agilisten vorgefunden, die durchgehend diese negativen Einstellungen hatten.

Bei näherer Betrachtung ist auch nachvollziehbar, wo das herkommt. Die Umstellung von (gerade grösseren) Organisationen auf agiles Arbeiten kann den Beteiligten wie eine Sisyphos-Arbeit vorkommen. Überall gibt es Missverständnisse, Widerstände und Hindernisse, statt klarer Entscheidungen gibt es oft nur halbgare Kompromisse und immer wieder gibt es Versuche alles wieder rückgängig zu machen. Wie soll man da nicht frustriert werden?

Selbst wenn es darauf keine für alle Kontexte gültige Antwort gibt, glaube ich eine gefunden zu haben, die zumindest mir dabei hilft, positv und optimistisch zu bleiben. Sie ist (wenig überraschend) der Ratschlag sich die Erfolgserlebnisse zu vergegenwärtigen, und zwar vor allem die kurzfristigen und langfristigen. Die dazwischen liegenden "Mühen der Ebene" bleiben zwar bestehen, sie erhalten aber durch das was davor und danach kommt ein neues Framing.

Kurzfristige Erfolgserlebnisse gibt es bei agilen Transitionen viele. Um das vermutlich häufigste zu nennen: wenn Teams nach einer Umstellung ihres Arbeitsmodus auf Scrum zum ersten mal selbst bestimmen dürfen, wie viel Arbeit sie in den nächsten Sprint nehmen, gibt es in der Regel einen Schub plötzlich steigender Arbeitsmoral, und wenn es in den nächsten Monaten zu einer höheren Liefergeschwindigkeit kommt, einen weiteren. Und das ist nur ein Beispiel.

Ich habe immer wieder die fast schon kindliche Freude von Stakeholdern erlebt, die mit einem dringenden Anliegen zum Product Owner gekommen sind und es bereits zwei Wochen später umgesetzt hatten, statt wie vorher mehrere Monate darauf warten zu müssen. Und auch einem Entwickler zuzuhören, der mit leuchtenden Augen davon erzählt, wie er nach 30 Jahren isolierter Arbeit in einer Konzern-IT das Pair Programming für sich entdeckt hat, ist etwas Besonderes.

Langfristige Erfolgserlebnisse muss man sich dagegen bewusst vor Augen halten, am besten durch den Vergleich der Ist-Situation mit der vor mehreren Jahren. Sobald Fachabteilung, Entwicklung, Qualitätssicherung und Betrieb in einem Team zusammenarbeiten wird das z.B. erstaunlich schnell als so normal wahrgenommen, dass in Vergessenheit geraten kann, wie revolutionär das in Relation zum Ausgangszustand ist, in dem nur über das Management miteinander kommuniziert wurde.

Und dass Refactorings, Abbau technischer Schulden und Bugfixing nicht hoch genug priorisiert werden, ist zwar ärgerlich, dass die umzusetzenden Anforderungen aber überhaupt einsehbar sind, dass sie umpriorisiert werden können, und dass für diese Umpriorisierung Wünsche und Hinweise geäussert werden können, ist etwas, das in den meisten klassisch geführten Unternehmen für utopisch oder gefährlich gehalten werden würde.

Ein einfacher Weg, sich selbst zu einem derartigen positiven Framing zu verhelfen, ist in Retrospektiven, Communities of Practice, Meetups und sonstigen Veranstaltungen darauf zu achten, dass dort nicht nur die gerade drängenden Probleme diskutiert werden, sondern auch das was gut läuft, was erreicht wurde und was sich gerade in eine positive Richtung entwickelt. Alleine die Beschäftigung damit kann ein Abgleiten in Sarkasmus, Zynismus oder Ironie vermeiden.