On Lean and Agility

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.

Bild: CCNull / Marco Verch - CC BY 2.0

Dass willkürlich gesetzte Deadlines problematisch sind, dürfte wohl bei kaum jemandem einen Widerspruch auslösen. Dass sie trotzdem immer wieder anzutreffen sind, hat menschliche und politische Gründe, die leider immer wieder vorkommen werden. Wer in einem solchen Umfeld beruflich unterwegs ist, muss sich daher mit diesem Thema beschäftigen und sollte am Besten überzeugende Gründe parat haben, warum sie keine gute Idee sind.

Zu den überzeugendsten dieser Gründe dürfte gehören, dass willkürliche Deadlines negativ auf den zurückfallen, der sie festlegt. Das ist zunächst für viele Menschen kontraintuitiv, schliesslich scheint in solchen Fällen der schwarze Peter doch bei denen zu liegen, die die gesetzten Fristen nicht einhalten können. Ein Praxisbeispiel zeigt aber, dass auch die andere Seite in Mitleidenschaft gezogen werden kann: das Onlinezugangsgesetz (OZG).

Das OZG wurde im Jahr 2017 im Parlament verabschiedet und legte fest, dass bis zum Jahr 2022 alle Behördengänge auch digital zu erledigen sein müssen. Der letzte Tag dieses Jahres, der 31.12.2022, wurde damit automatisch zur Deadline für die Umsetzung. Schon damals gab es Zweifel, dass diese Fristsetzung realistisch war, mittlerweile weiss man, sie war es nicht. Selbst Monate später sind erst 101 von 600 geplanten Leistungen online.

Die offensichtlichste Folge eines solchen Verzuges: weitere Fristsetzungen verlieren durch ihn ihre Glaubwürdigkeit nach aussen. Neben der fristsetzenden und der (verspätet) umsetzenden Seite gibt es nämlich fast immer eine dritte Partei, die externen Stakeholder. Und um beim Beispiel des OZG zu bleiben: verschiedene Kommentare in den Medien lassen keinen Zweifel daran, dass zukünftigen Zielsetzungen nicht mehr vertraut wird.

In Folge dessen werden zukünftige Zeitpläne von Anfang an mit grosser Skepsis begleitet, regelmässig hinterfragt und mit der ständigen Forderung nach Transparenz in Form von Zwischen-Fristen und Zwischen-Berichten konfrontiert. Diese führen bei allen Beteiligten zu z.T. erheblichen Mehraufwänden, die die Umsetzung nochmals verzögern und dadurch selbst solche Teilziele gefährden, die eigentlich erreichbar gewesen wären. Auch hierzu gibt es Beispiele aus dem OZG-Umfeld.

Anders, aber ähnlich schwerwiegend sind die Folgen nach innen. Das offensichtliche und deutliche Verpassen der Frist führt nämlich bei den mit den unrealistischen Umsetzungszielen beauftragten Menschen zu der Erkenntnis, dass ein solcher Verzug eigentlich kein Problem ist, schliesslich gibt es keine negativen Folgen (die meistens einzig vorhandene Sanktionsmöglichkeit, das Entziehen von Mitteln, würde schliesslich nur zu noch mehr Verzögerung führen).

Ist dieser Eindruck erstmal entstanden, kann von einem weiteren Effekt fast sicher ausgegangen werden - ohne ernsthafte Konsequenzen schwindet die Motivation, sich bei der Umsetzung über das übliche Mass hinaus zu engagieren. Selbst mit relativ geringen Mehraufwänden erreichbare Zieldaten lässt man verstrechen, erst recht wenn diese in einer grösseren Menge von Bitten, Forderungen und Eskalationen untergehen, von denen "alles wichtig ist". Es kommt ungewollt zur Erziehung zur Normverletzung.

In Summe entsteht so durch willkürliche Deadlines extern ein grundlegender Zweifel, der durch (gut gemeinte) Kontrollmassnahmen alles noch weiter verzögert und intern ein gewisser Nihilismus, der Eigeninitiative und Engagement verdrängt und ab einem gewissen Grad sogar dazu führt, dass es zu einer Abstimmung mit den Füssen kommt, also zu Kündigungen, durch die es nochmal zu zusätzlichen Verzögerungen kommt.

Ich habe als externer Berater Fälle erlebt, in denen willkürliche Deadlines zu solchen Aufwands-Explosionen geführt haben, dass eigentlich nur leicht verspätete Vorhaben sich um Jahre verlängert haben oder sogar abgebrochen werden mussten - häufig verbunden mit einem empfindlichen Karriereknick der verantwortlichen Manager. Und alleine die Aussicht das am eigenen Fall zu erleben sollte eigentlich ein überzugender Grund sein, sich bei "ambitionierten Zielsetzungen" zurückzuhalten. Schliesslich kann nicht jeder Probleme so einfach aussitzen wie die Digitalisierungs-Politiker.

Bild: Pixabay / Robin Higgins - Lizenz

Um es vorwegzunehmen: ich bin grosser Fan von Scrum im Allgemeinen und von der Rolle des Scrum Masters im Besonderen. Wie aber bei allen guten Ideen gibt es aber leider auch hier die Möglichkeit, sie so umzusetzen, dass sie eher schadet als nützt. Das kann schon bei der Ausgestaltung und Besetzung der Rolle beginnen (siehe hier), es kann aber auch sein, dass der Rollen-Inhaber sich (ggf. unbewusst) kontraproduktiv verhält. Um einen solchen Fall soll es hier gehen.

Ein Verhaltensmuster, das immer wieder zu beobachten ist, ist dass der Scrum Master bestimmte Tätigkeiten auf sich monopolisiert. Das kann auf den ersten Blick sinnvoll erscheinen, da die Absicht dahintersteckt das Team zu entlasten oder zu beschützen, im Ergebnis führt ein solches Verhalten aber meistens zu Flaschenhälsen in der Kommunikation, zu Unselbstständigkeit des Teams und zur Errichtung von Barrieren zwischen Menschen die eigentlich zusammenarbeiten sollten.

Der Klassiker unter diesen Monopolisierungen betrifft die Moderation der Meetings. Obwohl im Scrum Guide nicht vorgegeben ist, wer die Moderatoren-Rolle einzunehmen hat, wird sie in gefühlt 99 Prozent der Fälle vom Scrum Master übernommen. Dafür gibt es auch Gründe (der einfachste ist der, dass er es am besten kann), die Konsequenz ist aber häufig, dass in seiner Abwesenheit die Termine ausfallen, unstrukturiert ablaufen oder einen externen Moderator brauchen. Alles nicht im Sinn der Idee.

Ebenfalls problematisch ist die Monopolisierung des Impediment-Lösens. Auch hier ist die Absicht meistens eine gute: die anderen Teammitglieder sollen sich auf ihre Arbeit konzentrieren können und für die Stakeholder soll ein durchgehender Ansprechpartner da sein. Das Ergebnis sind aber häufig stille Post-Effekte und verlangsame Kommunikation, da die von Problemen betroffenen Personen und die, die es lösen können nicht mehr in direktem Kontakt sind.

Ein dritter Problemfall tritt auf, wenn die Koordination zwischen den Teams vor allem über deren Scrum Master läuft, z.B. wenn nur sie an einem Scrum of Scrums teilnehmen, neben dem es keine anderen gemeinsamen Kommunikations-Gelegenheiten gibt. Stille Post-Effekte und verlangsame Kommunikation sind auch in diesem Fall wahrscheinlich und werden oft dadurch verstärkt, dass die Scrum Master keinen technischen Hintergrund haben.

Die Lösung für diese (und viele weitere) Probleme ist es, gezielt nach den Themen zu suchen, die bisher ausschliesslich beim Scrum Master liegen und dafür zu sorgen, dass auch andere Mitglieder des Scrumteams Übung darin bekommen, sie zu übernehmen. Das ist am Einfachsten möglich bei der Meeting-Moderation, relativ einfach bei den teamübergreifenden Abstimmungen und am schwierigsten bei der Impediment-Lösung. Möglich ist es aber in allen Fällen.

Zuletzt noch zu möglichen Gegenargumenten. Anders als häufig angenommen wird gibt der Scrum Guide nicht vor, dass bestimmte Themen ausschliesslich dem Scrum Master zugeordnet sind. Um die häufigsten Missverständnisse zu nennen - "ensuring that all Scrum events take place" bedeutet eben nicht, dass er sie alle moderiert (im Daily ist nichtmal seine Anwesenheit nötig), und "causing the removal of impediments" bedeutet eben nicht, dass er sie alle selbst beseitigt.

Auch das Argument, dass die Übernahme von Meeting-Moderation, Impediment-Lösungen und übergreifender Kommunikation die Team-Mitglieder von ihrer "eigentlichen Arbeit" abhält, ist mindestens fragwürdig. In Scrum sind "self-management and cross-functionality" explizit für das gesamte Team vorgesehen, eben um zu verhindern, von einzelnen Personen abhängig zu sein. Die (scheinbaren) Scrum Master-Aufgaben zu übernehmen gehört also explizit zur Arbeit dazu.

Natürlich muss man diese Ansichten nicht teilen, man kann auch der Meinung sein, dass es effizienter oder effektiver ist, derartige Aufgaben vom Team fernzuhalten. Der Punkt ist aber: selbst wenn man das aus dem besten Willen heraus tut, wird man sehr schnell in einen Widerspruch zu den Regeln von Scrum geraten. Und jemand, der die Regeln von Scrum unterläuft oder aufhebt, ist per Definiton ein Impediment, selbst dann wenn diese Person der Scrum Master ist.

Grafiken: Freepik / Pikisuperstar - License

Eine der beissendsten Persiflagen von nicht fertig durchdachtem Vorgehen findet man in der Fernsehserie South Park, in der Folge Gnomes. Auf der Suche nach ihren verschwundenen Unterhosen entdecken die Hauptfiguren hier eine Gruppe Gnome, die einen grossen, dreistufigen Plan verfolgen. Stufe eins ist das Stehlen der Unterhosen, Stufe drei ist geschäftlicher Erfolg, wie die verbindende Stufe zwei aussehen soll, ist noch unklar. Obwohl diese Lücke allen bewusst ist, wird der Plan weiter verfolgt.

Da Angestellte von Grossorganisationen in dem Unterhosen-Plan die Unsinnigkeit vieler Vorgänge ihrer eigenen Umgebung wiedererkennen, ist er mit der Zeit zu einem Meme geworden, dessen häufige Zitierung ein starker Indikator dafür ist, dass in einem aktuell vorangetriebenen Vorhaben keine Verbindung zwischen den aktuellen Massnahmen und dem angestrebten Ziel erkennbar ist. Auch in agilen Transitionsprogrammen findet das immer wieder statt, und zwar vor allem in einer Konstellation.

Ein "agiler Unterhosen-Plan" liegt regelmässig dann vor, wenn zu Beginn ausführlich (und gegebenenfalls ausschliesslich) daran gearbeitet wird das Mindset der Mitarbeiter zu verändern, so dass ein "agiles Mindset" entsteht. Selbst wenn wir jetzt nicht näher auf die Frage eingehen ob man das Mindset anderer Menschen überhaupt ändern kann (zweifelhaft) und unterstellen, dass alle das Selbe darunter verstehen (auch zweifelhaft) - wie das zu einer agilen Produktentwicklung führen soll bleibt fast immer offen.

Weist man auf diese Lücke hin bekommt man häufig die Erklärung, dass ein agiles Mindset alleine deshalb zu Verbesserungen führt, weil jeder der es hat sich automatisch besser verhält. Allerdings ist das wenn überhaupt nur in Kleinorganisationen richtig, in grösseren Organisationen sorgen organisatorische Silos, Überregulierung, Ressourcen-Überoptimierung, Customer-Vendor-Beziehungen, Code Ownership und ähnliche Phänomene dafür, dass man gar nicht beschliessen darf das eigene Verhalten zu ändern.

Diese Begrenzungen des eigenen Handlungsspielraums sind auch jedem klar, der in grösseren Organisationen arbeitet (man wird schliesslich regelmässig auf sie hingewiesen). Bemerkenswerterweise ändert das aber nichts daran, dass man trotzdem immer wieder auf die agilen Unterhosen-Pläne trifft, in denen davon ausgegangen wird, dass nach der Herstellung des agilen Mindsets schon irgendetwas noch Unbekanntes passieren wird, was dann die agile Transformation erfolgreich macht.

Eine naheliegende Erklärung dafür wäre Esoterik, was leider öfter man man denken sollte stimmt, aber in vielen Fällen zu kurz greifen dürfte. Wahrscheinlicher ist, dass den Beteiligten einfach nicht klar ist wie sonst Veränderungen Richtung Agilität funktionieren könnten. Change Management-Abteilungen stecken viel zu oft noch in sehr klassischen Ideen von Veränderungsbegleitung fest und auf den unteren Ebenen fehlen einfach Erfahrungen und Systemverständnis, da sie dort nie vermittelt wurden.

Das muss allerdings nicht so bleiben. Dem Change Management kann man die Ideen von iterativem, incrementellem und adaptivem Arbeiten näherbringen den unteren Hierarchie-Ebenen kann man erklären wie das Systemdesign bestimmte Verhaltensweisen möglich, wahrscheinlich oder unmöglich macht und an welchen Stellen es notwendig ist dieses Design zu verändern, wenn man mit einer individuellen Mindset-Getriebenheit nicht vor Wände laufen will.

Dort wo das stattgefunden hat und angenommen wurde, werden agile Unterhosen-Pläne deutlich seltener werden, und das alleine deshalb, weil ab diesem Moment das Arbeiten an dem Mindset der einzelnen Personen sicher nicht mehr die erste Phase von Veränderungsprogrammen sein wird. Mit grosser Wahrscheinlichkeit wird diese Idee sogar ganz verschwinden, samt der Lücke, die bis dahin in der folgenden Phase zwei geklafft hat.