On Lean and Agility

Manche Dinge ändern sich über die Zeit erstaunlich wenig. Vor genau 10 Jahren habe ich darüber geschrieben, dass (vor allem grosse) Unternehmen Prozessverbesserungen in erster Linie dadurch angehen, dass sie ihnen neue Regeln, Rollen und Liefergegenstände hinzufügen wollen - in vielen Fällen mit dem Ergebnis, dass sich alles eher verschlechtert als verbessert. Dieses kuriose Verhalten lässt sich nahezu überall beobachten - und mittlerweile auch erklären.

Im Artikel People systematically overlook subtractive changes veröffentlicht 2024 im Nature-Magazin haben die schwedischen und amerikanischen Wissenschaftler Joshua Juvrud, Laurence Myers und Pär Nyström  das Phänomen beschrieben, dass die meisten Menschen Verbesserungen vor allem durch das Hinzufügen von etwas (additive Veränderung) bewirken wollen, selbst wenn das Weglassen von etwas (subtraktive Veränderung) zu deutlich besseren Ergebnisse führen würde.

Dabei beobachteten die erwähnten Forscher in ihren Untersuchungen nicht etwa, dass subtraktive Veränderungen kategorisch ausgeschlossen wurden. Vielmehr war es so, dass additive Veränderung den meisten untersuchten Menschen als die spontan naheliegendere Option erschien und unreflektiert gewählt wurde, während subtraktive Veränderung erst dann erwogen wurde, wenn additive Veränderungen ergebnislos, unmöglich oder offensichtlich unsinnig waren.

Dieses grundlegende Vernachlässigen subtraktiver Veränderungen (das so genannte Subtraction Neglect) war dabei abhängig von unterschiedlichen Faktoren unterschiedlich stark ausgeprägt. Zu ihnen gehörten neben der Art der Aufgabe auch Alter, sozialer Hintergrund und nationale, bzw. kulturelle Zugehörigkeit. Die zentrale Erkenntnis hierbei war, dass der Subtraction Neglect wenn nicht sogar durch Sozialisation erworben, dann zumindest deutlich von ihr geprägt ist.

Und das bringt uns zurück zu den grossen Organisationen, die ihre Prozesse durch ständiges Hinzufügen weiterer Regeln, Rollen und Liefergegenstände immer stärker überladen und sie so verschlechtern, statt sie zu verbessern. Ausgehend von der erwähnten Forschung kann zunächst mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass das in weiten Teilen auf das Phänomen des Subtraction Neglect zurückzuführen ist, es also unbewusste Ursachen hat.

Gleichzeitig ermöglicht die Beeinflussung der Subtraction Neglect durch soziale Prägung aber auch ein Gegensteuern. Alleine das Bewusstmachen der subtraktiven Veränderung als möglicher Massnahme kann bereits zu einer besseren Optionenabwägung führen und eine Empfehlung sie anzuwenden kann das nochmal verstärken. Und wird dadurch sogar noch ein Erfolg erzielt, kann sich sogar die Grundeinstellung ändern, auch das geht aus der erwähnten Forschung hervor.

Eine häufige Beschwerde bei Veränderungsvorhaben in grossen Organisationen ist, dass unverhältnismässig viel Zeit in Meetings aller Art verloren geht. Workshop folgt auf Workshop, Steuerungskreis auf Steuerungskreis, Entscheidungsrunde auf Entscheidungsrunde - nur damit am Ende ein Ergebnis steht, für dessen Festlegung bereits ganz am Anfang alle Informationen zur Verfügung gestanden hätten. Warum tut man sich das an?

Eine interessante Erklärung dafür bietet der Soziologie-Professor Stefan Kühl im wie immer hörenswerten Podcast "Der ganz formale Wahnsinn". Ihm zufolge dienen derartiger Meetings nicht nur der rationalen Entscheidungsfindung, sondern auch dem Austragen von Machtkämpfen, deren Stattfinden zu derartigen Anlässen nicht nur möglich, sondern sogar gewünscht ist, die dort aber nach Möglichkeit auch abgeschlossen werden sollen - etwas, was ich mehrfach genau so erlebt habe.

Um das zu verstehen holen wir zunächst etwas aus: Veränderungen führen in sehr vielen Fällen dazu, dass es Gewinner und Verlierer gibt. Ein Abbau von Hierarchien reduziert Bürokratie, verknappt aber dafür die Karriereoptionen; die Schaffung von Spezialistenlaufbahnen ermöglicht individuellen Statusgewinn, das aber auf Kosten der Gleichbehandlung in Teams; etc. etc. Das ist meistens schon früh erkennbar und löst bei den negativ Betroffenen die erwartbaren Widerstände aus.

Werden Veränderungen jetzt (zu) schnell beschlossen, finden diese Widerstände im Rahmen der bereits neu geordneten Organisation statt, was diese von Beginn an lähmen kann. Gelingt es dagegen, die Widerstände (und die Anstrengungen zu ihrer Überwindung) vor die Entscheidung zur Neuordnung zu legen, und zwar so, dass die Gewinnerseite des dadurch entstehende Machtkampfes diese Entscheidung prägen darf, dann kann die Startphase der neuen Organisation weitgehend ungestört beginnen.

Die verschiedenen Workshops, Steuerungskreise und Entscheidungsrunden bilden in dieser Betrachtungsweise eine Arena, in der die verschiedenen Parteien vor den Augen der restlichen Organisation gegeneinander antreten, einzelne Auseinandersetzungen gewinnen, andere verlieren, nach und nach ermüden, neue Kraft schöpfen, Bündnisse schliessen und Rückzugsgefechte führen, bis letztendlich eindeutig klar ist, wer sich in welchem Bereich durchgesetzt hat.

Am Ende dieser Vorgänge stehen gleich mehrere Ergebnistypen: zum einen die Entscheidungen der Machtkämpfe, und mit ihnen auch die über das Ausmass und die Weiterführung der Veränderungen, zum anderen aber auch eine Legitimation und Delegitimation von Standpunkten. Die Gewinner können sich zukünftig auf den langen und ausführlichen Entscheidungsprozess berufen, den Verlierern kann vorgehalten werden, dass sie trotz ausreichender Zeit keine Mehrheiten für ihre Ideen finden konnten.

Was mit dieser Art einer Change-Herbeiführung verbunden ist, ist natürlich das Risiko einer hochemotionalen Konfliktaustragung, da jede Seite befürchten muss, nach einer Niederlage auf unabsehbare Zeit kein Gehör für Ihr Anliegen mehr zu finden. Schlimmstenfalls kann sogar das Gegenteil des Angestrebten erreicht werden, einer belasteter statt eines unbelasteten Neustarts, nur mit einer Belastung durch Verbitterung und Verletzungen statt durch weitergehende Widerstände.

Um das zu vermeiden kann es sich anbieten, Veränderungen nicht in seltenen, grossen Programmen durchzuführen, sondern in einer stetigen Reihe von kleineren Vorhaben. Der Arena-Effekt verschwindet dadurch zwar nicht, dadurch dass die Auseinandersetzungen kleiner und reversibler werden, gehen aber die zur Schau Stellung und die potentielle Emotionalität zurück. Und als ein Seiteneffekt sind in jedem einzelnen Fall auch weniger Meetings nötig, was wiederum zu weniger Beschwerden führt.

Grafik: Pixabay / Mohammed Hassan - Lizenz

Change Management ist einer dieser Begriffe, die je nach Betrachtungsweise unterschiedliche Bedeutungen haben können - von denen aber keine einzige die "offiziell richtige" ist. Das kann Gespräche und Vorhaben zu diesem Thema leicht in Missverständnisse führen. Um das zu vermeiden hilft es, sich die verschiedenen möglichen Bedeutungen bewusst zu machen, um auf dieser Basis gemeinsam explizit zu machen, welche man gerade meint.

Eine Möglichkeit sich dem zu nähern ist die Frage, was genau im Change Management eigentlich "gemanaged" wird, denn das ist tatsächlich keineswegs so eindeutig wie es auf den ersten Blick scheinen mag (der Grund dafür ist die Vieldeutigkeit des englischen Wortes "Management", der nicht-Muttersprachlern zum Teil nicht bewusst ist). Gegenstand des Change Managements können nämlich sowohl die Veränderungen selbst sein, als auch der Umgang mit ihnen.

Die erste Variante dürfte auch die eingängigere sein. In ihr ist Change Management die Summe aller Tätigkeiten, durch die Veränderungen auf Organisationsebene (Team, Abteilung, Firma, etc.) ausgelöst, verhindert, begleitet, durchgeführt, verstärkt, abgeschwächt, beendet oder verstetigt werden sollen. Diese Art von Tätigkeiten ist im klassischen Projektmanagement häufig Teil eines Change Management Plans, dessen Einhaltung Gegenstand von Controlling und Reporting ist.

Die zweite Variante ist in gewisser Weise eine Äquivalenzklasse zu Konzepten wie Stress Management und Anger Management und kann sich ggf. mit diesen überschneiden. In ihr ist Change Management ein auf individueller Ebene stattfindender (und ggf. professionell begleiteter) Prozess, in dem es darum geht, zu erkennen, ob und wie man von Veränderungen betroffen ist, welche persönlichen Konsequenzen sich daraus ergeben und wie man mit ihnen stress- und frustrationsvermeidend umgehen kann.

Je nach Art der Veränderung kann die zweite Variante auch eine soziale Dimension haben, also ganze Gruppen betreffen, die dann gemeinsam einen Weg finden müssen, damit umzugehen. Das ist vor allem dann der Fall, wenn gemeinsame identitätsstiftende Elemente sich ändern oder ändern sollen, zum Beispiel (organisatorische) Zugehörigkeiten, Ziele und Aufgaben, aber auch Überzeugungen, Identitäten, Gewohnheiten oder Erwartungen.

Man kann schnell erkennen, dass diese beiden Varianten des Change Managements vollkommen unterschiedliche Notwendigkeiten, Herausforderungen und Rahmenbedingungen mit sich bringen, und ggf. sogar gegenläufig zueinander sein können, etwa dann, wenn auf organisations-Ebene Veränderungen schnell vorangetrieben werden sollen, während auf Personen- oder Gruppenebene der Wunsch vorherrscht, diese zu verlangsamen, um sich besser auf sie einstellen zu können.

Bild: Unsplash / Annie Spratt - Lizenz

Zu den Grundüberzeugungen aller agilen Frameworks gehört, dass Entwicklungsteams nach Möglichkeit Crossfunktional sein sollten, also in der Lage, alle im Rahmen der Produktentwicklung nötigen Tätigkeiten selbst durchzuführen, ohne dabei von anderen Abhängig zu sein. In traditionell arbeitenden Unternehmen dominieren dagegen die Spezialistenteams, die nur eine bestimmte Spezialtätigkeit beherrschen, die aber besonders effizient.

Am Anfang von agilen Transitionen stehen daher häufig Reorganisationen, in denen die Spezialistenteams aufgelöst und ihre Mitglieder auf die neuen, crossfunktionalen Teams verteilt werden. Wenn es in solchen Situationen aber mehr dieser neuen Teams gibt als bisher Spezialisten, treten Probleme auf. In den einen Teams feht das Spezialistenwissen, sie sind also doch wieder von anderen abhängig. Die anderen Teams müssen wiederum die erste Gruppe unterstützen, was zu Defocussierung und Prioritätskonflikten führt.

Um das zu vermeiden ist es sinnvoll, die Auflösung der Spezialistenteams nicht von jetzt auf gleich durchzuführen, sondern im Rahmen eines langsamen Prozesses, während dem immer mehr Wissen und Zuständigkeiten in die Breite verlagert werden. Wie das im Einzelnen geschehen kann wird natürlich von Fall zu Fall unterschiedlich sein, es gibt allerdings einen Denkansatz, mit dessen Hilfe sich der Übergang strukturiert durchführen lässt: Team Topologies.

Team Topologies geht von vier grundlegenden Team-Typen aus: Stream-aligned Teams (crossfunktional, können alles selbst), Enabling Teams (befähigen andere Teams), Complicated Subsystem Teams (besondere Spezialistenteams, deren Tätigkeit sich nicht so einfach aufteilen lässt) und Platform Teams (stellen anderen Teams Produkte oder Dienstleistungen zur Verfügung, die diese ohne externe Unterstützung sich selbst beschaffen und benutzen können). Mehr dazu hier.

Da spezialisierte Teams in Team Topologies den Complicated Subsystem Teams entsprechen sind diese der Ausgangspunkt, von dem aus zwei Weiterentwicklungen möglich sind: entweder sie können ihr Spezialgebiet zu einer Plattformdienstleistung umwandeln, die von den anderen Teams in einem Selbstbedienungs-Modus genutzt werden kann, oder sie wandeln sich zu enabling Teams indem sie das, was sie bisher selbst gemacht haben, anderen beibringen.

Häufige Anwendungsfälle für die Weiterentwicklung in Richtung Platform Team sind Spezialisten-Einheiten, von denen bisher Werkzeuge, Daten oder Infrastruktur verantwortet wurden. Die können in Selbstbedienungs-Portale überführt werden, in denen man sich Entwicklungsumgebungen, Testdaten, Anleitungen, Nutzungs-Simulationen o.ä. konfigurieren kann, die dann automatisiert erstellt und zur Verfügung gestellt werden.

Alternativ kann das bisherige Spezialisten-Team seine bisher verantworteten Themen direkt an die neuen, crossfunktionalen Teams weitergeben, allerdings mit einer wichtigen Ergänzung - statt diese mit ihrer neuen Aufgabe alleinzulassen, stehen die bisherigen Spezialisten als Trainer, Ratgeber, Erklärer und Notfallhelfer zur Verfügung, und das so lange bis sichergesetellt ist, dass ihre Unterstützung nicht mehr benötigt wird und sie sich neue Aufgaben suchen können.

In beiden Fällen (Umwandlung in ein Platform Team und Umwandlung in ein Enabling Team) kann es schliesslich zu einer finalen Entwicklungsstufe kommen, in der sich die ursprüngliche Spezialisteneinheit zwar auflöst, als "virtuelles Team" aber erhalten bleibt. Das kann z.B. in Form einer Community of Practice stattfinden, in der (ggf wechselnde) Vertreter aller crossfunktionalen Teams gemeinsam eine Platform-Dienstleistung oder einen Wissenstransfer am Leben halten.

Bild: Pexels / Tara Winstead - Lizenz

Mit der Zeit haben sich viele Menschen Gedanken über die ungeschriebenen Gesetze der Organisationsentwicklung gemacht und versucht sie (auf manchmal seriöse, manchmal aber auch eher zynische Art) auf Papier zu bringen. Besonders produktiv war dabei Craig Larman, der Erfinder von LeSS, der insgesamt fünf Gesetze verfasst hat, die er Larman's Laws of Organizational Behavior genannt hat. Heute soll es hier um das Fünfte von ihnen gehen. Es lautet:

In large established orgs culture follows structure. And in tiny young orgs, structure follows culture.

Zum Hintergrund: Larman verfasste dieses Gesetz als Reaktion auf die in der agilen Community verbreitete Ansicht, dass Veränderungsvorhaben grundsätzlich  damit beginnen müssten, die Kultur zu verändern. Da diese bestimmend für alles weitere wäre, würden alle weiteren Veränderungen mehr oder weniger von selbst folgen. Diese Ansicht hält er (zumindest in grösseren Organisationen) für nicht zutreffend und realitätsfern.

Die von Larman (und vielen Anderen) beobachtete Realität ist eine andere. In ihr ist die Unternehmenskultur (also die Summe aller informellen Erwartungen, Glaubenssätze, Deutungsmuster, etc.) stark von der Formalstruktur beeinfusst, bzw. eine Reaktion auf sie (zur Formalstruktur gehören Regel, Hierarchien, Anweisungen, o.A.). Ein einfaches Beispiel: in einem Unternehmen in dem alles zentral und geheim entschieden wird, wird es kaum zu einer partizipativen Mitmach-Kultur kommen.

In einem derartigen Umfeld haben Veränderungsvorhaben daher eine höhere Erfolgswahrscheinlichkeit, wenn sie mit strukturellen Veränderungen beginnen, z.B. mit der Delegation von Entscheidungen auf untere Hierarchieebenen, wodurch eine passive Gehorsams-Kultur dort nicht mehr möglich ist. Ob die dadurch herbeigeführten Kulturveränderungen die erhofften sind oder ob und wie nachgesteuert werden muss, ist dann nochmal ein separates Thema, das weit in das Change Management hineinführt.

Nun zum umgekehrten Fall: es gibt einige Firmen in denen es doch so ist, dass die Unternehmenskultur die Unternehmensstruktur definiert. Wie kann das sein? Larman gibt die Antwort, indem er darauf verweist, dass das vor allem in kleinen und jungen Organisationen gegeben ist. In derartigen Umgebungen sind Strukturen meistens nur rudimentär vorhanden (da noch nicht nötig) und verfestigen sich erst mit der Zeit. Diese Verfestigung bildet dann in der Regel die Kultur ab.

Zum besseren Verständnis muss man Change Management dabei differenzieren: gemeint ist hier nicht, eine im Voraus gefasste und nicht veränderbare Entscheidung umzusetzen, sondern im Rahmen des Prozesses Änderungsbedarfe zu erkennen und Lösungsansätze zu testen. Vor allem in diesem Umfeld werden die hier vorgestellten Ansätze funktionieren.

Manchmal hilft es, Dinge mit einem gewissen Abstand zu betrachten. In diesem Sinn wirft die britische Zeitung The Guardian gerade einen Blick zurück auf die Regierungszeit der ehemaligen Premierministerin Liz Truss, die nur 49 Tage dauerte. Eine der interessanteren Diagnosen aus diesem Text ist, dass Truss unter anderem deshalb scheiterte, weil sie durch zu viele Stellen-Neubesetzungen das institutionelle Gedächtnis der eigenen Verwaltung zerstörte. Was hat es damit auf sich?

Das institutionelle Gedächtnis ist eine Unter- und Sonderform des kollektiven Gedächtnisses und bezeichnet das gesammelte Wissen und die Summe der Erfahrungen einer organisierten Gruppe von Menschen, insbesondere in einer formalisierten Institution wie z. B. einer Behörde oder Firma. Es ist vor allem im Zusammenhang mit informellen Strukturen und Prozessen wichtig, also solchen, die nicht offiziell festgelegt und schriftlich festgehalten wurden.

Zu den typischen Informationen aus dem institutionellen Gedächtnis gehört, welche Inhalte wo abgelegt sind, welche Vorhaben in der Vergangenheit unternommen wurden (und wie), welche Mitarbeiter mit welchen anderen bekannt und vernetzt sind, wer bereits mit welchem Themengebiet zu tun hatte und wer besser oder schlechter mit bestimmten Rahmenbedingungen klarkommt (z.B. mit Stress, nicht-muttersprachlicher Kommunikation oder besonders hoher, bzw. niedriger Formalisierung).

Dieses Wissen kann für das Funktionieren einer Organisation entscheidend sein, da seine Träger in der Lage sind zu erkennen, an welcher Stelle welche Vorhaben mit geringen Reibungsverlusten umgesetzt werden können und an welchen Stellen mit Missverständnissen, Zusatzaufwänden, Ineffektivität oder Widerständen zu rechnen wäre. Wichtig dabei ist, dass bei einer rein formalen Betrachtung diese Unterschiede nicht wahrnehmbar wären, da sie sich nur aus der "Organisationsgeschichte" ergeben.

Vor allem nach Management- oder Regierungswechseln kann ein fehlendes institutionelles Gedächtnis von neuen Mitarbeitern dazu führen, dass die Ideen der neuen Führungsebene nur unter grossen Schwierigkeiten umgesetzt werden können, weshalb fast immer versucht wird, einen Teil der bisherigen Mitarbeiter zu übernehmen und einzubinden, selbst dann wenn man sich deren Loyalität nicht vollkommen sicher sein kann (ein bekanntes und besonders kontoverses Beispiel wäre dieses hier).

Für das, was passieren kann, wenn man nach einem Management-Wechsel versucht weitgehend ohne die bisherigen Mitarbeiter (und damit auch ohne deren nicht-verschriftlichtes Wissen) zu arbeiten, kann die zu Beginn erwähnte kurze Regierungszeit von Liz Truss als (abschreckendes) Beispiel gelten: dem von ihr mitgebrachten neue Regierungsteam fehlte das institutionelles Gedächtnis in einem derartigen Ausmass, dass es in vielen Bereichen handlungsunfähig war.

An overwhelming number of the senior figures brought into the administration had limited experience running a Whitehall department, let alone the country. The entire legislative affairs team – in charge of drafting and timetabling bills – was replaced too. “It was like she’d stripped off all the wallpaper, then the paint and floorboards too. There was basically zero institutional memory left,” one Truss-era cabinet minister said.

The Guardian, The inside story of the unravelling of Liz Truss’s premiership

Wie immer gilt natürlich auch hier, dass es nicht nur einen Weg gibt, mit derartigen Situationen umzugehen. Statt Teile des bisherigen Teams zu übernehmen kann man z.B. auch Mitarbeiter-Interviews, Unterlagen-Recherche und andere Arten der "Geschichtsforschung" durchführen um ein neues institutionelles Gedächtnis aufzubauen. Wenn das geplant ist sollte man allerdings ausreichend Zeit einplanen und nicht erwarten sofort uneingeschränkt handlungsfähig zu sein.

Bild: Unsplash / Brooke Cagle - Lizenz

Ein Hoch auf die Wissenschaft! In der Zeit bin ich auf "More in Common"-Sozialstudie gestossen, in der es zwar eigentlich um gesamtgesellschaftliche Zusammenhänge geht, die aber (für mich) aus einem ganz anderen Grund interessant ist: in ihrem Mittelpunkt steht ein Modell, mit dem versucht wird, anhand des Umgangs mit Veränderungen soziale Gruppierungen zu identifizieren. Und dieses Modell ist erstaunlich gut auf Change Management in Unternehmen übertragbar.

Was diese Studie von anderen unterscheidet ist genau diese Art der Gruppenzuordnung. Statt bestehende Gruppen zu nehmen und in ihnen Erhebungen durchzuführen (was in der Realität aufgrund der gruppeninternen Heterogenitäten oft zu kaum brauchbaren Ergebnissen führt) ist das in diesem Ansatz entscheidende Zuordnungskriterium die Frage, wie Veränderungen wahrgenommen werden und wie auf sie reagiert wird (um das festzustellen gibt es standardisierte Fragenkataloge).

Die Involvierten

Die Involvierten sind im Grunde genommen die Personen, die man sich bei Veränderungsvorhaben wünscht. Sie haben Ressourcen-Zugriff oder sind vernetzt und engagiert (und dadurch einflussreich) und sie sind bereit sich in den Dienst der neuen Ideen zu stellen, wenn sie einen Sinn darin sehen. Wichtig ist, dass ihr Einfluss nicht zwingenderweise mit ihrer öffentlichen Wahrnehmbarkeit korreliert.

Die Etablierten

Das Gegenstück zu den Involvierten. Sie sind ebenfalls vernetzt, engagiert und einflussreich, und auch bei ihnen kann der Einfluss größer sein als die öffentliche Wahrnehmbarkeit. Sie haben es sich in den bestehenden Verhältnissen aber so gut eingerichtet, dass sie diese nach Möglichkeit beibehalten wollen (was übrigens eine durchaus legitime Haltung sein kann).

Die Offenen

Die Offenen bilden die eine der stark wahrnehmbaren Extrempositionen im sozialen Diskurs und befürworten Veränderungen stärker als alle anderen. Beeinflussen können sie diese aber nur eingeschränkt, was weniger paradox ist als es zunächst klingt. Durch ihre lautstarke Kommunikation sollen ihre Anliegen bei den Entscheidungsträgern addressiert werden, um dort umgesetzt zu werden.

Die Wütenden

Erneut das Gegenstück. Auch die Wütenden können nur eingeschränkt selbst die Dinge beeinflussen und äussern ihre Meinung daher lautstark in Richtung der Entscheidungsträger. Der Tenor ist allerdings ein anderer, nämlich der, dass Veränderungen eher als Belästigungen wahrgenommen werden, von denen man gerne verschont bleiben würde.

Die Pragmatischen

Die Pragmatischen können (und wollen) Veränderungen nicht beeinflussen und hätten oft auch gar nicht die nötigen Ressourcen und Einblicke um das zu tun, sie sind aber in der Lage (und gewillt) sich mit den meisten Neuerungen irgendwie zu arrangieren oder sogar einen kleinen Vorteil daraus zu ziehen. Sie sehen alles so wie sie heissen: pragmatisch.

Die Enttäuschten

Das letzte Gegenstück. Genau wie den Pragmatischen fehlen den Enttäuschten die Mittel, der Wille und das Systemverständnis, die für das Beeinflussen von Veränderungen nötig wären. Sich mit den Neuerungen arrangieren können oder wollen sie aber auch nicht, weshalb sie diese einfach irgendwie und passiv über sich ergehen lassen.

Wie immer bei derartigen Typologien ist es auch bei dieser so, dass sie Verständlichkeit auf Kosten von Differenziertheit erzeugt, wer bereits an grösseren Veränderungsvorhaben beteiligt war wird die sechs Typen aber direkt wiedererkennen. Change-Strategien und -Massnahmen gezielt auf sie auszurichten dürfte möglich sein und Erfolgspotential haben, alleine deshalb weil dadurch das häufige Antipattern aufgebrochen wird, alle Gruppen gleich behandeln zu wollen.

Wichtig dabei ist aber, dass die Zuordnung zu diesen Gruppen nicht auf Intuition oder "Expertenmeinung" beruht sondern auf rationalen und überprüfbaren Kriterien. Auf der More in Common-Website findet sich einiges zur Methodik, zu den Tools und zu ihrer möglichen Anwendung, hier kann man sich inspirieren lassen und bekommt einen guten Werkzeugkasten für eigene Anwendungen mitgegeben. 

Bild: Flickr / Rasmus Anderson - CC BY-NC 2.0

Reden wir noch einmal über das berühmt-berüchtigte Spotify Model, jenen Erfahrungsbericht, der ohne dass es von seinem Verfasser jemals geplant war zu einer Blaupause für zahllose agile Transitions- und Skalierungsvorhaben geworden ist. Dass diese Verwendung nicht im Sinne des Erfinders ist und besser unterlassen werden sollte ist ein immer wieder vorgebrachtes Mantra vieler überzeugter Agilisten. Ein bekannter Name sieht das allerdings anders - der Erfinder selbst, Henrik Kniberg.

Wird Kniberg zu "seinem" Framework befragt (z.B. hier) äussert er sich in der Regel undogmatisch und realistisch. Er sagt, dass in seiner Wahrnehmung die überwiegende Mehrzahl der Umsetzungen weder zu Verbesserungen noch zu Verschlechterungen führt, dass es eine kleine Menge gibt bei der es zu signifikanten Verbesserungen kommt, aber fast keine Beispiele dafür, dass Verschlechterungen die Folge sind. Und diese Beobachtung ist bemerkenswert genug für einige Überlegungen.

Dass die Mehrzahl der Umsetzungen alles beim Alten lässt liegt an einem schlichten Grund: das Spotify Model wird von Beratungen vor allem an Konzerne verkauft, und die sind in der Regel als Matrix-Organisation aufgestellt. Auch das Spotify Model ist eine solche Matrix-Organisation, so dass seine Einführung oft nur eine Umbenennung ist - aus Abteilungen werden Chapter, aus Projekten Squads oder Tribes. So wird zwar nichts besser, aber eben auch nichts schlechter.

Zu Verbesserungen kommt es dort wo die über den blossen Organisationsaufbau hinausgehenden Vorteile des Spotify Models erkannt und umgesetzt werden (mehr dazu hier). Die Ähnlichkeit zur klassischen Matrix-Organisation kann dabei sogar ein Vorteil sein, da der Umbruch weniger hart erscheint und die Sorgen und Widerstände dementsprechend geringer ausfallen. Die Veränderungen erfolgen in solchen Fällen eher evolutionär, was sie aber nicht weniger wirksam macht.

Wirklich interessant ist aber, dass es kaum Fälle gibt in denen eine Umstellung auf das Spotify Model zu einer Verschlechterung des Gesamtzustandes führt (was ich aufgrund der Erfahrungen die ich in über 10 Jahren bei vielen Kunden und auf zahllosen Meetups gemacht habe nur bestätigen kann). Gerade vor dem Hintergrund, dass erschütternd viele Veränderungsvorhaben nur Verschlimmbesserungen hervorbringen, sollte das nicht geringgeschätzt werden.

Näher betrachtet ist ein Grund dafür, dass es nicht nötig ist die alte, funktionierende Struktur zu zerstören um die neue Zielstruktur errichten zu können. Die Ähnlichkeit zur alten Matrix-Organisation ermöglicht schrittweises Ausrollen, eine beliebig lange Koexistenz von alter und neuer Welt und im Extremfall sogar ein relativ schmerzloses rückgängig Machen. Ein riskanter "methodischer Big Bang Release" wird dadurch unnötig, ein dezentrales und asynchrones Change Management wird einfacher.

Ein zweiter Grund ist die einzigartige Benennung der Organisationseinheiten, die verhindert, dass aus anderen Kontexten bereits mit Bedeutungen belegte Begriffe umgedeutet werden müssen. Weder bedeuten alte Namen wie Abteilung oder Projekt plötzlich etwas anderes, noch müssen "agile Fachbegriffe" für Konzern-Erfordernisse verbogen und verfremdet werden, wie es z.B. mit der Scrum-Terminologie in SAFe passiert. Mehrdeutigkeit und Missverständnisse werden so unwahrscheinlicher.

Zusammengenommen tragen diese Faktoren zu Knibergs Beobachtungen bei, dass das Spotify Model meistens wenig verändert, immerhin manchmal die Zustände verbessert und sie dafür nur sehr selten verschlechtert. Zwar bedeutet das, dass man mit ihm keinen "Grossen Sprung nach vorne" durchführen kann, das Risiko, dass es zu Widerständen kommt und die Wahrscheinlichkeit von versehentlichen Verschlimmbesserungen sind dafür aber gering.

Grafik: Wikimedia Commons / Meyers Konversationslexikon - Public Domain

Ein bemerkenswertes Phänomen im Change Management ist die weitgehende Unklarheit darüber was dieser Begriff eigentlich bedeutet. Beide Bestandteile - Change und Management - sind bereits für sich genommen mehrdeutig und weit interpretierbar, zusammengenommen sind sie es erst recht. Als Folge dessen hat sich eine ganze Reihe möglicher Bedeutungen entwickelt, die zum Teil parallel und ohne klare Abgrenzung zueinander verwendet werden. Sie sich vor Augen zu führen und explizit zu machen ist von elementarer Bedeutung wenn man für sich selbst definieren will was eigentlich zu tun ist wenn man von Change Management redet. Hier sind sie:

Veränderungen durchführen

Die technokratische Variante. Die sozialen und psychologischen Dimensionen von Veränderungsvorhaben werden nicht gesehen oder bewusst ignoriert. Für Fragen und Proteste ist keine Anlaufstelle vorgesehen, Kommunikation beschränkt sich auf die Verkündung von Stichtagen an denen Veränderungen in Kraft treten. Kritisch zu sehen, da sich Probleme und Emotionen immer weiter aufstauen und selbst offensichtliche Fehlentwicklungen aufgrund fehlender Feedbackkanäle nicht bemerkt werden können.

Veränderungen durchsetzen

Die rabiateste Variante, gleichzeitig aber auch eine die in klassischen Organisationen noch immer sehr häufig ist. Meistens getrieben von einem Menschenbild in dem Mitarbeiter "zu ihrem Glück gezwungen werden müssen" oder in dem ihnen Destruktivität unterstellt wird, werden Veränderungen mit Befehlen, Drohungen und Bestrafungen in die Organisation hineingezwungen. In der Wissensarbeit ein hochgradig kontraproduktiver Ansatz, da er in der Regel zu dysfunktionalem "Dienst nach Vorschrift" führt.

Veränderungen erträglich machen

Die abgeschwächte Form des Durchsetzens. Statt mit Befehlen oder Strafen wird mit anderen Mitteln gearbeitet, vor allem mit ausgleichenden Belohnungen (Boni, kostenloser Kaffee, modernere Büros, etc.), oder mit dem in Aussicht Stellen von bald folgender Ruhe und Sicherheit ("Wenn Ihr das mitmacht sind für erste alle Personalabbaupläne vom Tisch"). Dieses Vorgehen kann zwar Widerstände dämpfen, kann aber nicht verhindern, dass Unzufriedenheiten unterschwellig erhalten bleiben.

Veränderungen verkaufen

Verkaufen ist hier gemeint im Sinn von Vermarkten. Das kann passieren durch die Suggestion von Notwendigkeit oder Modernität ("Nur so bleiben wir wettbewerbsfähig", "Google macht das auch so") oder durch emotionale Vereinnahmung ("Und jetzt alle: Tschakka, wir schaffen das!"). Dosiert eingesetzt kann es durchaus wirkungsvoll sein, bei häufigem oder regelmässigen Einsatz kommt es aber schnell zu Gewöhnungs-, Abstumpfungs- oder Abstossungs-Effekten.

Veränderungen aushandeln

Ab hier beginnt eine Begegnung auf Augenhöhe, wenn auch noch eher in Form eines Kuhhandels. "Was müssten wir für Euch tun, damit Ihr Euch umgekehrt an den Veränderungen beteiligt?" Solche und ähnliche Verhandlungen treiben die Veränderungen voran, sorgen aber auch dafür, dass nicht mehr die Sinnhaftigkeit des Neuen im Vordergrund steht sondern die zu erwartende Gegenleistung. Kann zu einer "für Geld machen wir alles, auch wenn es sinnlos ist"-Einstellung führen.

Veränderungen gemeinsam gestalten

Schon ein sehr moderner Ansatz. Dass Veränderungen stattfinden müssen wird zwar noch als gegeben hingenommen, in welcher Form, in welchem Zeitraum und von wem sie umgesetzt werden wird aber bereits weitgehend delegiert und dezentral umgesetzt. Zu beachten ist, dass Mitarbeiter ohne entsprechende Vorkenntnisse bei der Umsetzung in die Autonomie-Falle tappen können und daher zu Beginn ggf. Unterstützung brauchen.

Veränderungsbedarfe gemeinsam suchen, bewerten und darauf reagieren

State of the Art in agil arbeitenden Organisationen. Im Rahmen der üblichen Inspect & Adapt-Prozesse wird kontinuierlich und dezentral ermittelt ob und wo Veränderungen notwendig sind, dort wo das der Fall ist wird möglichst dezentral und selbstorganisiert darauf reagiert (hilfreich sind dabei transparente Regelungen wann Zentralisierungen doch Sinn machen können, z.B. diese hier). Häufige agile Praktiken sind Retrospektiven und Kaizen-Prozesse.

Veränderungen kontrolliert verursachen und institutionalisieren

Die post-moderne Endausbaustofe. Es wird nicht mehr darauf gewartet, dass Veränderungsbedarfe irgendwo entdeckt werden, stattdessen werden die eigenen Prozesse und Strukturen immer wieder durch kontrollierte Experimente und Belastungstests verändert, überprüft und angepasst. Zwar lässt sich nicht alles voraussehen, viele Veränderungsnotwendigkeiten und Verbesserungspotentiale können so aber im voraus erkannt und ohne Zeitdruck umgesetzt werden.

Wie bei anderen Begriffsdifferenzierungen gilt auch hier, dass noch zahllose weitere Abstufungen möglich sind, und natürlich kann in jedem dieser Fälle die Ausgestaltung nochmal sehr unterschiedliche Formen annehmen. Dennoch bietet diese Übersicht gute Anhaltspunkte wenn man Change Management-Massnahmen plant - und auch wenn man die analysieren will von denen man gerade betroffen ist.

Bild: Wikimedia Commons / Elvey - CC0 1.0

Wenn agiles Arbeiten irgendwo zum ersten Mal vorgestellt wird klingt es meistens zu schön um wahr zu sein. Alles wird schneller, besser, kundenorientierter und Mitarbeiter-freundlicher, dazu ist es irgendwie modern und hip - wer würde das nicht wollen? Irgendwann während der Umsetzung kommt dann aber das unschöne Erwachen: auf einmal ist vieles anstrengend und ungewohnt. Und vor allem gibt es plötzlich eine lange Liste von bisher gewohnten Praktiken die man nicht mehr machen soll.

Es ist dabei normalerweile nicht so, dass im Vorfeld irgendetwas bewusst verschwiegen worden wäre. Für einen überzeugten Agilisten sind die meisten dieser gewohnten Praktiken Notlösungen, die nur da sind weil es bisher nicht Besseres gab, weshalb sie auch niemand vermissen wird. Für viele andere Menschen sind sie aber wichtig und geben Sicherheit, weshalb voher klar kommuniziert werden sollte: der Preis der Agilität ist, dass es einige andere Dinge nicht mehr geben kann.

Was mit der Einführung agiler Arbeitsweisen zum Beispiel verschwindet ist die Möglichkeit langfristige Detailpläne zu machen. In einem Arbeitsmodus der davon ausgeht, dass es sinnvoll und richtig ist seine Pläne regelmässig an Veränderungen anzupassen kann man nicht mehr festlegen woran ein Team im zweiten Sprint des vierten Monats des übernächsten Jahres arbeiten wird. Ziele müssen abstrakter werden und auf unterschiedlichen Wegen erreichbar sein.

Zusammenhängend damit verschwindet auch die Möglichkeit einer detail-Budgetierung. Lange im Voraus Tätigkeiten bestimmte Buchungsnummern zuzuordnen und festzulegen, dass Arbeitsstunden nur noch auf diese gebucht werden dürfen nähme der Organisation jegliche schnelle Reaktionsfähigkeit (Anpassungen der Budgets sind zwar möglich, in der Regel aber mit Bürokratie verbunden). Budgetiert werden müssen stattdessen jeweils ganze Produkte oder Projekte.

Während der Umsetzung ändert sich, dass man Ressourcen (→ Menschen) nicht mehr so effizient einsetzen kann, dass sie tage- oder stundenweise zwischen Team und Projekten hin- und hergeschoben werden, je nachdem wo es gerade dringend ist. Würde das gemacht hätte jede Planänderung sofort Auswirkungen quer durch die Organisation, da neue Ressourcenverschiebungen nötig würden. Nötig ist stattdessen eine feste Zugehörigkeit zu langlebigen Teams.

Am Ende der Verarbeitungsketten muss schliesslich auf die Synergie-Effekte gemeinsamer Gross-Integrationen, Gross-Abnahmen und Gross-Releases verzichtet werden, genauso wie auf die (scheinbare) Sicherheit nachgelagerter Testphasen. Um auf Änderungen reagieren zu können muss man diese früh entdecken und daher möglichst oft integrieren, testen und releasen. Statt das in späten Phasen zu tun muss das früher und häufiger stattfinden.

Es liessen sich noch viele weitere Beispiele finden, die Botschaft ist aber klar: vieles von dem was im bisherigen Organisationsmodell richtig und wichtig war kann nicht weiter beibehalten werden wenn der Arbeitsmodus agil wird. Es abzuschaffen bringt so grosse Vorteile mit sich, dass es lohnt das zu machen, für die Menschen die bisher so gearbeitet haben (und deren Stelle mitunter davon abhängt) kann es aber anstrengend und schmerzhaft sein.

Diese Änderungen und damit verbundenen Schmerzen sind der Preis den man dafür zahlen muss agil zu werden. Und dort wo die strategische Entscheidung ansteht in Zukunft agil werden zu wollen sollte dieser Preis klar und deutlich genannt werden. Unterbleibt das werden die gegenläufigen Arbeitsweisen ständig Störungen und Widerstände erzeugen. Wird es klar benannt klingt der Zielzustand zwar nicht mehr zu schön um wahr zu sein, man kann aber deutlich besser daran arbeiten dorthin zu kommen.

Bild: Pixabay / Aymanejed - Lizenz

Um das Thema genauer einzugrenzen: es geht hierbei nicht darum ob die Mitarbeiter sich Umstrukturierungen oder sonstigen Änerungsvorhaben grundsätzlich verweigern können, das wäre nicht zielführend. Worum es geht ist die Art der Durchführung, die von beiden Seiten (denen die Veränderungen anstreben und denen die davon betroffen sind)² sowohl konfliktlastig als auch konfliktvermeidend gestaltet werden kann. Ein konfliktvermeidender Change-Vertrag sähe so aus:

Die Seite die eine Veränderung anstrebt (z.B. eine Umstellung der Arbeitsmethodik) verpflichtet sich dazu, diese Bemühungen nicht im Geheimen zu beginnen und voranzutreiben sondern das in weitestmöglicher Offenheit und Transparenz zu tun. Diese sollte sowohl die zugrundeliegenden Motivationen umfassen als auch die dazugehörigen Massnahmen, die möglichen Folgen für alle Beteiligten (auch die unangenehmen) sowie den angestrebten Zeitplan.

Die Seite die von den Veränderungen betroffen ist verpflichtet sich im Gegenzug, diese früh sichtbar werdenden Veränderungsbemühungen nicht von Anfang an zu behindern, zu verlangsamen oder unnötig aufwändig zu machen. Wichtig dabei ist, dass das auch dann nicht geschieht wenn eine der möglichen Konsequenzen ist, dass der eigene Job tendenziell schwieriger wird. Das ist untrennbar mit dem nächsten Punkt verbunden.

Die Seite die eine Veränderung anstrebt verpflichtet sich dazu,die Sorgen und Einwände der betroffenen Seite ernst zu nehmen und Veränderungsmassnahmen nicht mit Zwang durchzudrücken wenn eine Mehrheit der Betroffenen sich dagegen ausspricht. Dass die Veränderungen in einem derartigen Fall nur abgeschwächt und vielleicht sogar in anderer Form kommen können ist ein Ausgang der von Anfang an als grundsätzlich möglich gelten muss.

Die Seite die von den Veränderungen betroffen ist verpflichtet sich im Gegenzug, die eigenen Partikularinteressen nicht über die berechtigten Gesamtinteressen der Gesamtorganisation zu stellen (z.B. nicht einen besseren Kundenservice zu verhindern um in Ruhe arbeiten zu können). Und dort wo sie die Veränderungen für unzumutbar hält verpflichtet sie sich nach Alternativen zu suchen die dem Gesamtinteresse dienen, selbst wenn dafür Anstrengungen und Umgewöhnungen nötig sind.

Wie immer in der Vertragstheorie gilt auch hier, dass der "Gesellschaftsvertrag über konstruktives Change Management" nur dann Bestand hat, wenn er von beiden Seiten durchgehend respektiert wird, auch dann wenn eine Seite durch den Bruch einen Vorteil gewinnen könnte und auch dann wenn es gerade dringend, wichtig oder weniger anstrengend wäre die jeweils andere Seite zu umgehen. Ihn zeitweise aussetzen geht nicht, es gibt ihn ganz oder gar nicht.

Wie im Fall anderer inoffizieller Gesellschaftsverträge wäre es auch in diesem eine spannende Idee daraus etwas Explizites zu machen, eben durch Ausformulieren und Aufschreiben. Sichtbar auf eine Wand geschrieben dürfte es viele Diskussionen um Change-Vorhaben zwar lebhafter gestalten, dafür aber auch deutlich zielführender machen als es zur Zeit häufig der Fall ist.

Grafik: Flickr / Jurgen Appelo - CC BY 2.0

Wenn es darum geht Organisationen auf einen neuen Arbeitsmodus wie z.B. Agilität umzustellen stehen die Vordenker und Pioniere vor dem gleichen Problem das auch aus anderen Change-Vorhaben bekannt ist. Die Gruppe derer die nicht nur zu überzeugen sondern überhaupt mit der neuen Idee bekanntzumachen sind ist riesig, so gross dass sich kaum sagen lässt bei wem angefangen werden sollte. Ein Ansatz diese Zielgruppe zu strukturieren ist das Modell der Innovations-Durchdringung (Diffusion of Innovations). Da es relativ bekannt ist und immer wieder versucht wird es einzusetzen ist es hilfreich es zu kennen, samt seiner Vor- und Nachteile.

Das Modell geht auf die beiden amerikanischen Organisationsforscher Everett Rogers und Geoffrey A. Moore zurück, genauer gesagt auf ihre Bücher Diffusion of Innovations (1962) und Crossing the Chasm (1991). In ihnen wird die Zielgruppe unterteilt in die fünf Untergruppen der Innovatoren (Innovators), der frühen Anwender (early Adopters), der ersten Hälfte der Mehrheit (early Majority), der zweiten Häfte der Mehrheit (late Majority) und der Nachzügler (Laggards). Es wird weiterhin davon ausgegangen, dass die Teil-Zielgruppen unterschiedlich gross sind, bei einer Anordnung von links nach rechts eine Glockenkurve bilden (siehe Abbildung oben) und nacheinander zu überzeugen sind.¹

Die Akzeptanz und Anwendung von Innovationen "durchdringt" dabei von links nach rechts die einzelnen Teil-Zielgruppen. Dabei wird angenommen, dass auch diese Durchdringung in Phasen abläuft. Auf der Ebene einzelner Personen sind das Kenntnis des Neuen (Knowledge), Überzeugt werden (Persuasion), Zustimmung (Decision), Umsetzung (Implementation) und Erfolgswahrnehmung (Confirmation), auf der Ebene der Teil-Zielgruppen entsprechen dem Themensetzung (Agenda-Setting), Planung (Matching), Einführung (Restructuring), Gewöhnung (Clarifying) und Verinnerlichung (Routinizing). Auf beiden Ebenen sind Rückfälle und Ablehnungen möglich, werden aber in späten Phasen unwahrscheinlicher.¹

Der Vorteil des Innovations-Durchdringungs-Modells ist zunächst, dass die zuvor grosse und schwer fassbare Gesamtmenge der zu überzeugenden Menschen sich in besser greifbare kleinere Einheiten unterteilen lässt. Darüber hinaus bieten die Reihenfolge der Gruppen und die beiden Phasenmodelle ein zwar grobes aber universell anwendbares Muster, anhand dessen bestimmt und geplant werden kann welche Werbe- oder Change Management-Massnahme auf welche Gruppe anzuwenden ist (was in der Detail-Umsetzung je nach Gruppe und Phase sehr unterschiedlich gestaltet werden kann und muss). Vereinfacht gesagt: Mustererkennung und Massnahmenplanung werden einfacher.

Der Nachteil des Modells liegt darin, dass es für die Einführung von Produkt-Neuheiten entwickelt wurde und nicht für die Einführung von Arbeitsmethoden und Vorgehensweisen. Infolgedessen geht es von eher binären Entscheidungen aus: man bleibt bei der Handwäsche oder steigt auf die Waschmaschine um, man bleibt beim Tastentelefon oder kauft sich ein Smartphone, etc. etc. Die Übernahme neuer Arbeitsweisen ist dagegen eher vielschichtig: man kann sie z.B. abstrakt verstanden haben aber noch nicht wissen wie sie umzusetzen sind oder sie mechanisch durchführen ohne den Sinn dahinter zu erkennen. Die eindeutige Zuordnung zu den Gruppen oder Phasen funktioniert so nicht mehr.

Noch unklarer wird es im Fall agiler Transitionen, da hier verschiedene Teilbereiche zusammenkommen die zwar erst zusammengenommen einen Sinn ergeben, die aber separat angeeignet werden können. Naheliegende Beispiele dafür sind Selbstorganisation im Team, (technische) Releasefähigkeit in kurzen Abständen, Produkt- und Domänenverständnis und Kundenorientierung. Tatsächlich ist es in Umbruchphasen häufig so, dass diese Teile über einen längeren Zeitraum unterschiedlich stark ausgebildet sind und erst nach und nach alle ein hohes Level erreichen.² Auch das erschwert die im Modell vorgesehene eindeutige Zuweisung.

Und selbst wenn irgendwann alle Teilgruppen alle Veränderungsphasen durchlaufen haben kann nicht davon ausgegangen werden, dass dieser Status Bestand hat. Der Versuch erfolgreich agil arbeitende Einheiten durch Skalierung zu vergrössern oder auf ein gemeinsames Ziel auszurichten kann zu Bürokratie und Erstarrung führen, technische Schulden können die Releasefähigkeit untergraben und über längere Zeit stabile Teams können verengte Weltsicht und Konformitätsdruck entwickeln. Eine Folge davon kann z.B. sein, dass Innovatoren in frühe Entwicklungsphasen zurückrutschen und dann sogar schlechter dastehen als die Nachzügler. Die Innovations-Durchdringung ist damit ausgehebelt.

Heisst das, dass dieses Modell für agile Transformationsvorhaben völlig unbrauchbar ist? Natürlich nicht, im Gegenteil: das Herunterbrechen (zu) großer Vorhaben in kleine, handhabbare und separat abschliessbare Arbeitspakete passt hervorragend zu agilem Arbeiten. Was aber nicht funktionieren wird ist der Versuch Personen oder Gruppen fix oder auch nur längere Zeit in Gruppen oder Phasen einzuordnen oder sogar Fortschrittsstände daraus abzuleiten (z.B. "Wir haben jetzt die Innovatoren und die frühen Anwender überzeugt, als nächstes gehen wir die erste Hälfte der Mehrheit an."). Das wird fast zwangsläufig in Missverständnissen und Scheinerfolgen enden, mit bösen Überraschungen als Folge.

Zusammengefasst: in der Produktentwicklung und -vermarktung hat das Innovations-Durchdringungs-Modell seine Berechtigung, auf die Einführung von Arbeitsmethoden und Vorgehensweisen lässt es sich aber nur sehr eingeschränkt übertragen. Inspirieren lassen kann man sich davon, man sollte sich aber seiner Limitierungen bewusst sein.

Bild: Wikimedia Commons / Klausrxt - CC BY-SA 4.0

"Verhältnisse sind wichtiger als Verhalten", lautet eine alte Soziologenweisheit, die in grossen Change-Projekten leider noch zu selten beachtet wird. Zu oft wird hier in erster Linie versucht die Menschen (bzw. ihre Kultur oder ihr Mindset) zu verändern, ohne zu bedenken, dass diese vor allem durch das sie umgebende System beeinflusst und geprägt werden. Zum Glück gibt es gute Sinnbilder um diesen Fehlschluss zu verdeutlichen, darunter ein besonders einprägsames - das vom lebendigen und toten Holz.

Sehr oft wird es W. Edwards Deming zugeschrieben, einem der Vor-Väter des Lean Management, tatsächlich kommt es aber lediglich aus seiner näheren Umgebung. Der Urheber ist Peter Scholtes, ein anderer amerikanischer Management-Theoretiker, der es zu einem nicht mehr rekonstruierbaren Zeitpunkt prägte und schliesslich in seinem 1997 erschienenen Management-Ratgeber "The Leaders's Handbook" veröffentlichte.

The common objection to seniority pay is, “It’s rewarding dead wood!” My response is, “Why do you hire dead wood? Or why do you hire live wood and kill it?

Peter Scholtes, The Leaders's Handbook, S.331

Zuerst zur Übersetzung des zentralen Begriffs. Totes Holz (Dead Wood) ist ein englischer Management-Slangbegriff für Menschen die es aufgegeben haben mitzudenken, proaktiv zu handeln, Probleme anzusprechen und Lösungen vorzuschlagen. Er bildet ein Gegensatzpaar mit dem lebendigen Holz (Live Wood), das diejenigen Menschen symbolisiert denen all das noch zu eigen ist. Eine Belegschaft aus totem Holz zu haben gehört zu den häufigen Beschwerden in schlecht laufenden Firmen.

Was Scholtes damals mit seinem Ausspruch verdeutlichen wollte ist Folgendes: wenn in einer Firma der Fall eingetreten ist, dass praktisch alle Mitarbeiter die eine gewisse Betriebszugehörigkeitsdauer überschritten haben (d.h. Seniorität erreicht haben) in die Totholz-Kategorie fallen, dann ist das nur bei sehr oberflächlicher Betrachtung eine Aussage über die Angestellten. Bei genauerer Betrachtung zeigt sich, dass das soziale System (die Firma) die Stelle ist an der die Probleme liegen.

Das Vorhandensein von Totem Holz lässt sich auf nur zwei mögliche Entstehungsursachen zurückführen. Entweder sind in grossem Ausmass Mitarbeiter eingestellt worden die von Beginn an passiv, uninteressiert oder unverständig waren. In diesem Fall ist offensichtlich der Rekrutierungsprozess schlecht gestaltet worden, schliesslich hat er die unpassenden Kandidaten entweder nicht erkannt oder nicht aussortiert. Und das in noch der positivere Fall.

Im schlimmeren Fall haben die neuen Mitarbeiter ursprünglich alle der Kategorie des lebenden Holzes angehört, waren also aufmerksam, lösungsorientiert und von hoher Auffassungsgabe. Wenn diese Menschen aber nach einer gewissen Zeit die Charakterzüge toten Holzes aufweisen, dann kann das nur eines bedeuten - sie wurden im Unternehmen umgewandelt, dort muss es also Faktoren geben die Eigeninitiative, Neugier und Wissensdrang abtöten.

In beiden Fällen (und auch in dem nicht unwahrscheinlichen Fall, dass ein Mischtyp aus beiden vorhanden ist) wäre es kurzsichtig und vermutlich nicht von nachhaltigem Erfolg gekrönt lediglich direkt auf die Angestellten einzuwirken um ihr Verhalten, bzw. ihre Kultur oder ihr Mindset zu ändern. Die Rahmenbedingungen die sie geprägt haben blieben bei diesem Vorgehen schliesslich bestehen und würden weiter ihre Wirkung entfalten.

Sinnvoller und wirksamer wäre es am System zu arbeiten, also zu überprüfen an welcher Stelle Motivatoren und Demotivatoren oder Belohnungen und Bestrafungen die Ursache für eine Verhaltensänderung in die eigentlich nicht gewünschte Richtung sind - oder ob es nicht sogar bewusst oder unbewusst gefordert und gefördert wird, dass die Menschen eine hinnehmende und nicht hinterfragende Haltung annehmen.

Sind diese Stellen identifiziert können sie nach und nach so umgestaltet werden, dass sie den Angestellten Anreize geben kreative, konstruktiv-kritische, und partizipative Haltungen zu entwickeln. Das ist keineswegs einfach und kann den Systemverantwortlichen einiges abverlangen (siehe hier, hier und hier), es ist aber in der Regel der deutlich erfolgsversprechendere Ansatz, zumindest wenn eher nachhaltige als (scheinbar) schnelle Verbesserungen angestrebt werden.

Bild: Pexels / Tima Miroshnichenko - Lizenz

Dass Change-Projekte in deren Rahmen agile Frameworks und agile Produktentwicklung eingeführt werden nicht immer so verlaufen wie das dafür verantwortliche Management es sich wünscht ist ein erstaunlich häufig zu beobachtendes Phänomen. Die Gründe dafür sind vielfältig und reichen von der Zielsetzung bis zur Ergebniskommunikation. Ein weiterer, der häufig unterschätzt wird, ist eine bestimmte Art des Kontrollverlustes: das sich verändernde Unternehmen beitzt keine Deutungshoheit über den neuen Arbeitsmodus mehr.

Um zu verstehen warum es sich dabei um einen Ausnahmefall handelt hilft ein Blick auf den Normalfall. In ihm werden methodische Veränderungen dadurch eingeleitet, dass das von Unternehmensberatern unterstützte Management sich in ein Tagungshotel zurückzieht um dort in Ruhe neue Strukturen und Abläufe zu konzipieren. Diese werden dann nur noch verkündet, und zwar so, dass die betroffenen Mitarbeiter kaum noch widersprechen können.

Dabei ist eines wichtig: dass Widerspruch kaum möglich ist liegt meistens nicht daran, dass er nicht erlaubt wäre. Deutlich schwerer wirkt eine Informations-Asymetrie: egal ob es sich um Synergieeffekte und Sparpotentiale handelt oder um erfolgversprechende "Best Practices" und Industrie-Standards, den meisten Menschen fehlen sowohl die Erfahrungs- und Vergleichswerte um mitreden zu können als auch Zeit und Informationszugang für eigene Recherchen.

Bedingt dadurch befindet sich in diesem Szenario die Deutungshoheit über das angestrebte Vorgehen nahezu ausschliesslich auf der Seite von Management und Beratern. Nur sie haben den vollständigen Blick darauf wie der methodische Ansatz gedacht ist, er umgesetzt wird, sein Erfolg gemessen wird, etc. Verstärkt wird das oft noch dadurch, dass die Dokumentation des angestrebten Vorgehens nicht für alle zugänglich ist (wofür es sowohl gute als auch schlechte Gründe geben kann).

Im Fall agiler Transitionen ist diese Asymetrie aufgehoben. Das Manifest für agile Softwareentwicklung und die Grundlagen-Dokumente von Exteme Programming, Scrum und (IT-)Kanban stehen frei verfügbar im Internet und dank der Soft Power der agilen Bewegung findet ihre Verbreitung nicht nur durch (teure) Konferenzen und Bücher statt sondern auch durch zahllose, grösstenteils kostenlose Meetups und Online-Publikationen.

Durch diesen gleichen Informationszugang verschiebt sich die Deutungshoheit, und das in mehrfacher Hinsicht. Zum Einen kann sie nicht mehr (bewusst oder unbewusst) monopolisiert werden, wodurch in der Einführungsphase plötzlich eine Situation der Augenhöhe entsteht die für viele Organisationen höchst ungewohnt ist. Man kann es sich vorstellen - ein Sachbearbeiter oder Tester der einem Manager sagen kann ob dieser Scrum richtig verstanden hat oder nicht kann für ganz neue Dynamiken sorgen.

Zum Anderen (und das ist sogar noch weitergehend) verlagert sich die Deutungshoheit aus der Organisation heraus. Die Verfasser des agilen Manifests sind fast alle noch am Leben und sehr auskunftsfreudig, und die oben verlinkten Regelwerke der einzelnen Frameworks sind zwar minimalistisch, aber dafür ein vielen Stellen von unmissverständlicher Klarheit. Und keine Firma der Welt (egal wie gross sie ist) hat einen Einfluss auf das was darin steht.

Das hat Folgen. Natürlich kommt es in vielen Organisationen während der Change-Projekte zu Kompromissen, Missverständnissen oder halbgaren Lösungen. Aber anders als in den meisten klassischen Veränderungsvorhaben ist das jetzt für alle offensichtlich. "Wenn man agil arbeitet macht man das so" funktioniert nicht mehr als Universalbegründung wenn alle wissen dass das nicht stimmt. Und beim Scheitern alles auf die angeblich unpassende Methodik zu schieben geht auch nicht mehr.

Für viele Entscheidungsträger mag das zunächst bedrohlich klingen, man kann aber auch das Positive darin sehen. Dadurch dass die agilen Frameworks ausserhalb der eigenen Deutungshoheit liegen kann man sie als Leitstern benutzen, der alle (im Zweifel gut gemeinten) Kompromisse oder Minimalkonsense unverfälscht übersteht, so dass es immer wieder von neuem möglich ist zu refocussieren und sich erneut an ihm zu orientieren. Es kann sogar befreiend sein, keine eigene Methodik erarbeiten zu müssen.

Natürlich kollidiert ein solches Vorgehen mit vielen eingeübten Change-Routinen, die Veränderungen eher schnell beenden als durch regelmässige Refocussierungen immer wieder neu starten wollen. Genau das ist der zu Beginn genannte Verlauf den sich das verantwortliche Management häufig anders wünschen würde. Aber genau das ist eben auch - agil.

Bild: Pixabay / Metsik Garden - Lizenz

Es gibt Bücher die nicht in erster Linie wegen der Innovativität oder Eloquenz ihres Inhalts grosse Bekanntheit erreichen, sondern weil in ihnen zum ersten mal vor einer grossen Öffentlichkeit eine tabuisierte Wahrheit ausgesprochen oder ein scheinbarer Widerspruch aufgelöst wird. Dynamic Reteaming von Heidi Helfland gehört in diese Kategorie, weshalb es Sinn macht seine Besprechung nicht mit dem Buch selbst zu beginnen sondern mit seinem Entstehungskontext.

Vereinfacht gesagt besteht dieser Kontext aus dem Spannungsfeld zwischen möglichst weitgehender Ressourcenoptimierung und möglichst ungestörtem Arbeiten. Die erste führt dazu, dass versucht wird eine möglichst hundertprozentige Auslastung der Mitarbeiter zu verwirklichen indem sie (ganz oder in Teilen ihrer Zeit) immer dorthin versetzt werden wo gerade Bedarf ist, das zweite geht in die andere Richtung und nimmt ggf. sogar Leerlauf in Kauf um Ineffektivität durch Multitasking und Versetzungs-Bürokratie zu vermeiden.

Während in hierarchisch-arbeitsteiligen Organisationen die Ressourcenoptimierung das dominierende Paradigma ist, wird in agilen Arbeitsumgebungen meistens Wert auf das ungestörte Arbeiten gelegt. Grundsätzlich ist das auch sinnvoll (siehe hier und hier), an vielen Stellen hat es aber zu dem sehr dogmatischen Ansatz geführt, dass ein Wechsel zwischen verschiedenen Teams grundsätzlich abgelehnt wird - schliesslich würde er Unruhe in das Arbeitsumfeld bringen, was ja vermieden werden soll.

An dieser Stelle setzt Helflands Buch an. Nicht etwa durch ein Einsteigen in die gerade beschriebene Diskussion, sondern ganz pragmatisch durch die Feststellung, dass es gute Gründe für neue Teamschnitte oder den Wechsel von Personen zwischen Teams geben kann, und durch Vorschläge wie das möglichst selbstorganisiert und unbürokratisch vor sich gehen kann. Aus diesen Ansätzen ergeben sich auch die drei Abschnitte in die das Buch eingeteilt ist.¹

Im ersten Teil "What is Dynamic Reteaming?" werden die Grundlagen gesetzt. Es geht darum was überhaupt ein Team ist, wie man dorthin versetzt werden kann (Spoiler: es gibt mehr als eine Art) und was Gründe dafür sein können einen neuen Teamschnitt anzustreben. Dazu gehören sowohl solche aus der Angestelltenperspektive, etwa der Wunsch nach dem nächsten Karriereschritt, als auch solche aus Systemsicht, wie das Verhindern von Silobildung und eingefahrenen Denkmustern.

Im zweiten Teil geht es konkret um den Vorgang des "Reteamings", bei dem Helfland fünf Haupttypen beschreibt: Einzelversetzung, Teamteilung, Bildung neuer Produkt- oder Spezialistenteams, Teamzusammenlegung und Neuordnung zum Zweck von Wissens- und Erfahrungsaustausch. Für jeden dieser Fälle gibt sie Beispiele und Handlungsempfehlungen, warnt aber auch vor möglichen Fehlern, die die angestrebten positiven Effekte zunichtemachen können.

Im dritten Teil wird schliesslich beschrieben welche Rahmenbedingungen und Praktiken in der umgebenden Organisation dazu beitragen können, dass das Reteaming dynamisch, also schnell und flexibel, wird. Zum Teil ist das sehr spezifisch auf IT-Teams bezogen, es gibt aber auch grundsätzliche Elemente, z.B. vergleichbare Rollen in den verschiedenen Einheiten. Hervorgehoben wird auch, dass die Reteamings nicht nur vor- sondern auch nachbereitet werden sollten.

Wie oben gesagt - das ist alles nicht wirklich innovativ, viele Organisationen (egal ob klassisch oder agil organisiert) nutzen viele Elemente des Dynamic Reteaming schon lange unter anderem Namen. Trotzdem bietet das Buch einen Mehrwert: zum einen in dem es das Dogma der unbedingt zu erhaltenden stabilen Teams aufbricht, zum anderen indem es den bisherigen Wissensstand konsolidiert, zusammenführt und agil-kompatibel aufbereitet. Daher eine klare Leseempfehlung.

Mit welcher Methodik machen wir eigentlich unser nächstes Projekt? Mit SAFe, Scrum oder Kanban? Vielleicht auch mit Lean Six Sigma, LeSS oder Extreme Programming? Diese Frage stellt sich immer wieder, und wie so oft ist die einzig richtige Antwort darauf das gute alte "kommt darauf an". Spannend ist aber das worauf es ankommt. Das können Erfahrungswerte, Vorlieben, Rahmenbedingungen oder Unternehmensstandards sein, es kann aber auch auf einen weiteren, oft unterschätzten Faktor ankommen - die jeweilige Phase des Projekt-Lebenszyklus.

Bevor wir darauf eingehen etwas Grundsätzliches: es macht grossen Sinn Arbeit nicht um Projekte sondern um Produktlinien zu gruppieren, da dadurch kontinuierliche Weiterentwicklung, DevOps und andere sinnvolle Dinge einfacher werden. Manchmal geht das aber nicht wirklich gut, etwa bei Legacy-Ablösungen, Auftragsarbeiten für externe Kunden oder Hardware-Produkten, die ja irgendwann in die Serienfertigung überführt werden. Hier machen Projekte meistens mehr Sinn, und um diese Fälle soll es hier gehen.

Am Anfang derartiger Vorhaben steht  in der Regel eine Phase grosser Ergebnis-Offenheit. Es werden vor allem Hypothesen geprüft und Proofs of Concept, Prototypen und frühe MVPs erzeugt, zwischen deren Erstellung längere Pausen liegen können in denen Ergebnisse validiert, Make or Buy-Entscheidungen getroffen oder Budgets ausgehandelt werden. Hier können Design Thinking-Workhops Sinn machen, Design Sprints, Rapid Prototyping oder in Teilzeit betriebene Innovationsprojekte. Für voll ausgelastete Projektteams ist es meistens noch zu früh.

Erst wenn diese Vollauslastung möglich ist (z.B. nach Bestätigung der Bedarfshypothese, der Bestätigung der Machbarkeitshypothese und Bestätigung des Budgets) kann ein dazu passender Arbeitsmodus eingesetzt werden, wobei sich im Rahmen komplexer Vorhaben mehr und mehr iterative Ansätze wie Scrum, SAFe, XP oder LeSS durchsetzen. Neben den kontinuierlichen Lern- und Lieferzyklen bieten sie den Vorteil, dass ihre Regeltermine lange im Voraus festliegen, so dass Stakeholder und Nutzervertreter dann verfügbar sein können.

Gegen Ende wird diese regelmässige Verfügbarkeit von Stakeholdern und Nutzervertretern allerdings weniger wichtig. Da dann (bei richtig umgesetztem agilem Vorgehen) keine kritischen Entscheidungen oder Weiterentwicklungen mehr anstehen, sondern vor allem Restarbeiten umgesetzt und kleinere Optimierungen durchgeführt werden, gibt es zum Einen kaum noch wirkliche Neuerungen zu denen in Reviews Feedback gegeben werden kann, zum anderen werden die Ergebnisse eher kleinteilig, Detail-spezifisch oder technisch (z.B. bei Refactorings). Hier können Lean-Ansätze wie Kanban oder Six Sigma passend sein.

Sich auf die Idee der Methodenwechsel während des Projektlebenszyklus einzulassen kann aus mehreren Gründen sinnvoll sein. Nicht nur weil es den Arbeitsmodus den aktuellen Erfordernissen anpasst (statt das Umgekehrte zu versuchen), sondern auch weil es in Erinnerung ruft, dass Methoden kein Selbstzweck und keine Silberkugeln sind, und weil es daran erinnert, dass man auch spät im Projekt noch Scrum Master oder ähnliche Rollen braucht die regelmässig aus dem Hamsterrad heraustreten und Sinnfragen stellen (auch hier nochmal: nein, der Scrum Master macht sich nicht irgendwann selbst überflüssig).

Zum Schluss noch eine häufig gestellte Frage: ist so ein "häufiger" Methodenwechsel nicht teuer? Die Antwort darauf kann nur sein: umsonst ist er zwar nicht, ein Projekt über weite Strecken mit einer zu diesem Zeitpunkt nicht passenden Methodik zu betreiben ist im Zeifel aber viel teurer. Die Umstellung lohnt sich also.

Grafik: Wikimedia Commons / Nasa - Public Domain

Am Anfang von Douglas Adams Roman The Hitchhiker's Guide to the Galaxy steht die Zerstörung der Erde. Ausserirdische Raumschiffe erscheinen und kündigen die Sprengung des Planeten an um Platz für eine Hyperraum-Autobahn zu schaffen. Auf die entsetzten Bitten das nicht zu tun folgt nur der Hinweis, die Pläne hätten lang genug im Bauamt auf Alpha Centauri ausgelegen, jetzt sei es zu spät für Protest. Und diese Szene ist nicht nur der Beginn einer der bekanntesten literarischen Erzählungen überhaupt, sie ist auch eine beissende Kritik an der scheinbaren Transparenz von grossen Planungsprozessen.

There’s no point acting all surprised about it. All the planning charts and demolition orders have been on display in your local planning department in Alpha Centauri for fifty of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now.

The Hitchhiker's Guide to the Galaxy

Um mit dem offensichtlichsten zu beginnen: die Existenz des galaktischen Bauamts ist den von den geplanten Bauarbeiten betroffenen Menschen gar nicht bewusst, und damit auch nicht, dass man dort Pläne einsehen kann. Dies ist eine deutliche Parallele zu vielen grossen Bau-, Produktions- und internen Change-Vorhaben. Theoretisch hätte man ja wissen können wo die dokumentiert werden, weshalb eine ankündigende Kommunikation für nicht nötig gehalten wird.

Direkt daran anknüpfend kommt dazu, dass der Standort Alpha Centauri von der Erde aus nicht einfach zu erreichen ist. Auch hier kann man eine Gemeinsamkeit zu vielen Grossvorhaben erkennen. Man muss für Einsicht und Einspruch zwar nicht auf andere Planeten, der Zeitaufwand, die nötigen Prozesskenntnisse und die ggf. geforderten Bearbeitungsgebühren sind aber für viele Menschen ein Hindernis das so gross ist, dass es kaum noch überwindbar ist.

Die Kombination aus geringem Wissen und hohem Aufwand führt schliesslich zu einem weiteren Effekt: einem sehr starken Unterschied beim jeweils anfallenden Aufwand. Die planende Seite muss ihn nur einmal auf sich nehmen um die Dokumente zu hinterlegen, die von den Planungen betroffene Seite müsste das immer wieder tun um sicher zu sein, dass es keine Planänderungen gibt. Da in den meisten Fällen aber keine anliegen wäre das unwirtschaftlich und frustrierend, weswegen es meistens unterbleibt.

Der vermutlich weitreichendste Punkt ist aber einer der nicht sofort in Auge fällt: sowohl in Adams Roman als auch in den real existierenden Grossvorhaben fühlen sich die Planungsverantwortlichen absolut im Recht und sehen darum keine Notwendigkeit ihr Verhalten zu ändern. Aus ihrer Sicht wäre es die Holschuld der von den Vorhaben Betroffenen gewesen sich zu informieren ob und in welcher Weise sie betroffen sind. Tun diese das nicht sind sie selbst schuld.

Hier - und das ist entscheidend - liegt auch der Schlüssel für eine bessere Kommunikation: statt es durch zusätzliche Regeln und Standards scheinbar immer offensichtlicher zu machen wo die Betroffenen sich informieren können (was in der Realität aber nur zu noch mehr Bürokratie und Intransparenz führt) müssen die Planungsverantwortlichen auch für die proaktive Kommunikation verantwortlich sein. Was dabei zu beachten ist steht hier.

Bild: Wikimedia Commons / Matthias Süßen - CC BY-SA 4.0

Zu den Tätigkeiten die ein Agile Coach ausüben kann gehört eine die man als "Auditierung" agil arbeitender Projekte oder Unternehmen bezeichnen könnte. In den meisten derartigen Fällen ist die dahinterstehende Motivation die, dass die Umstellung des Arbeitsmodus nicht zu den Verbesserungen geführt hat die erhofft waren, und dass das Unternehmen herausfinden möchte ob es bei der Umstellung etwas falsch gemacht hat. Und zu den häufigsten Fehlern die dabei gefunden werden gehört das so genannte "Air Sandwich".

Erstmals geprägt von der amerikanischen Strategieberaterin Nilofer Merchant in ihrem 2009 erschienenen Buch The New How: Creating Business Solutions Through Collaborative Strategy beschreibt dieser Begriff einen der klassischen Gründe dafür, dass grosse Veränderungsvorhaben wirkungslos bleiben - das fehlende Herunterbrechen des grossen Plans auf ein Detail- und Abstraktions-Niveau das auf der Ausführungsebene umsetzbar ist. Mit ihren Worten:

An Air Sandwich is a strategy that has clear vision and future direction on the top layer, day-to-day action on the bottom, and virtually nothing in the middle.

Am Beispiel einer nicht gut verlaufenden Umstellung auf agiles Arbeiten würde das so aussehen: in der obersten Unternehmensebene ist grundsätzlich verstanden, dass schnelle Liefer- und Reaktions-Zyklen wichtig sind, und deren Implementierung wird angeordnet. Im Idealfall würde jetzt in der Mitte die Operationalisierung beginnen, zum Beispiel in Form eines Rückbaus von Silos und Hierarchien, so dass auf der unteren Ebene selbstorganisierte, crossfunktionale Produktteams entstehen können.

In der Realität ist es dagegen häufig so, dass die Anordnung schneller und flexibler zu werden in der Mitte auf die dort vorhandene Luftschicht (das Air Sandwich) trifft, ungebremst durch diese hindurchfällt und weiter unten auf der Umsetzungsebene einschlägt. Da in diesem Szenario die Hierarchien und starken Aufgabenteilungen aber nicht verändert worden sind (das hätte in der Mitte passieren müssen) kommt es dort nur zu symbolischen Veränderungen, wie z.B. Scrum in Komponententeams.

Eine populäre Deutung für das Air Sandwich ist, dass die in der Mitte liegenden Management-Schichten kein Interesse haben sich selbst ändern zu müssen, weshalb sie derartige Anweisungen einfach nach unten durchreichen. Sie sagt aber meistens mehr über das Menschenbild des so Urteilenden aus als über die Realität. Eine wahrscheinlichere Erklärung ist aber, dass das Gesamtsystem so konstruiert wurde, dass es durch die Umsetzung organisatorischer Veränderungen an seine Grenzen gebracht wird.

Zur Erklärung: in den meisten klassischen Organisationen ist es eben nicht die Aufgabe der mittleren Schichten Organisationsveränderungen durchzuführen, stattdessen haben sie vor allem eine Kommunikationsfunktion: auf dem Weg von oben nach unten werden Ziele und Anweisungen immer weiter ausdetailliert und auf die verschiedenen Empfänger aufgeteilt, auf dem Weg nach oben werden Rückmeldungen und Ergebnis-Berichte immer weiter zusammengefasst und vereinheitlicht.

Um zu verhindern dass eine Umstellung auf agiles Arbeiten durch ein Air Sandwich wirkungslos wird sind demnach zwei Dinge elementar: zum einen muss allen Beteiligten klar werden, dass in der Mittelschicht nicht nur die Veränderungs-Vision nach unten durchkommuniziert werden muss, sondern dass in diesem Rahmen auch organisatorische Veränderungen geplant und durchgeführt werden müssen. Zum anderen muss klar sein, dass viele klassische Mittelschichten darin weder Expertise noch Erfahrung haben¹.

Natürlich sind derartige Überlegungen und Erkenntnisse zunächst einmal frustrierend, da durch sie klar wird, dass Veränderungsbemühungen schwieriger sind als gedacht und meistens eine Unterstützung durch externe Experten benötigen. Auf der anderen Seite bewahren sie aber auch davor, dass als einziges Ergebnis das entsteht was in Air Sandwiches in beliebiger Menge erzeugt werden kann: heisse Luft.