On Lean and Agility

Grafik: Pixabay / Brian Penny - Lizenz

Itamar Gilad: The Product Operating Model Explained

Liam Kane: An Agile Transformation Dashboard

Mike Bowler: The big rewrite

Maret Kruve: ADEPT - The Product Discovery Framework that Fits on a Sticky Note

Celine Nguyen: The Perils of ‘Design Thinking’

Dass die öffentliche Verwaltung an manchen Stellen agiler ist als man vermuten würde, habe ich schon an der einen oder anderen Stelle geschrieben. Ich muss aber zugeben, dass jeder neue Fall auch mich etwas überrascht, so viele sind es schliesslich auch wieder nicht. Die aktuelle Überraschung tritt dabei an einer besonders prominenten Stelle auf, nämlich in der Bundesregierung, genauer gesagt im neuen Bundesministerium für Digitales und Staatsmodernisierung (BMDS).

Die erste Anwendung agiler Praktiken findet dabei gleich im Rahmen des Organisationsaufbaus statt. Statt möglichst lange möglicht im Verborgenen an einem möglichst perfekten Organigramm zu arbeiten, das dann nicht mehr verändert werden soll, hat das BMDS bewusst einen noch unfertigen Entwurf veröffentlicht, in gewisser Weise ein MVP. Dadurch sollen möglichst viele der zukünftigen Mitarbeiter früh Wünsche und Feedback äussern können, die dann in spätere Versionen einfliessen können.

Und damit nicht genug - diese Transparenz und Offenheit für Rückmeldungen soll nicht nur einmal stattfinden sondern mehrfach, das Ministerium plant "die Umsetzung in eine feste Struktur [...] in Form eines iterativen Prozesses", es wird also mehrere Veröffentlichungs-, Feedback- und Ansassungs-Schleifen geben, bis irgendwann ein Organisationsaufbau in einer Form definiert worden ist, die eine zeit lang stabil bleiben kann (so ähnlich habe ich auch schon einmal gearbeitet).

Alleine das ist für eine Behörde bereits beeindruckend genug, bei der Süddeutschen Zeitung kann man aber nachlesen, dass noch weitergehende Organisationsdesign-Prinzipien umgesetzt werden sollen: in einer Abkehr von sonst üblichen Paradigmen sollen die entstehenden Abteilungen nicht in Form von Silos auf Fach- oder Aufgabenteilungs-Basis entstehen, sondern um so genannte "Missionen" gruppiert sein, also um konkrete Modernisierungs- und Digitalisierungs-Aufgaben.

Eher der Umbruchssituation geschuldet, trotzdem aber bemerkenswert ist der Improvisationsgeist, von dem die Süddeutsche Zeitung berichtet. Statt sich lange mit den in der öffentlichen Verwaltung legendär langwierigen und komplizierten Bestellprozessen aufzuhalten werden Büroausstattungen gebraucht gekauft oder geliehen, unbürokratisch verteilt und bei Bedarf zweckentfremdet. Und noch etwas erinnert mich an ein eigenes Erlebnis: die pragmatische Beschaffung von dringend nötigem Klopapier.

Ob sich der "agile Geist" in diesem neuen Ministerium halten wird, ist natürlich noch nicht absehbar. Bestenfalls wird er in die Organisationskultur übergehen, schlimmstenfalls wird er sich nach und nach verflüchtigen. Aber alleine dass Agilität an einem solchen Ort, an dem man sie nicht vermuten würde, möglich ist, ist schon für sich genommen eine bemerkenswerte Geschichte. Eine die man durchaus weitererzählen könnte, wenn wieder jemand undifferenziert auf Behörden schimpft.

Ich bin ein Fan der Vorträge von Jeff Patton, zum einen wegen der inhaltlichen Tiefe, zum anderen wegen seines besonderen Stils, Life Visualisierungen für seine Ausführungen zu erstellen. In diesem Fall zum Thema des Minimum Viable Product (MVP).

Spannend an diesem Vortrag ist unter anderem, dass er durch die Erläuterung des MVP scheinbare Gewissheiten der agilen Produktentwicklung in Frage stellt, zum Beispiel die Definition of Done - aber nicht etwa, weil er in dieser Idee keinen Sinn sieht, sondern weil er aufzeigen kann, dass sie nur Teile dessen abdeckt, was man unter agil verstehen kann. 

Grafik: Wikimedia Commons / Craig Chelius - CC BY 3.0

Die Geschichte der Agilität ist voller Missverständnisse, besonders dann wenn es darum geht, wie das, was wir heute die agile Bewegung nennen, entstanden ist. Das liegt zum Teil einfach daran, dass die "agiler Vor- und Frühgeschichte" der 80er und 90er Jahre mittlerweile schon etwas länger her ist, zum anderen aber auch daran, dass sie sich zu Beginn in den Schatten abgespielt hat, ohne Namen und ohne Bekanntheit. Und an dieser Stelle wird es interessant.

Bevor wir dazu kommen aber kurz zu den beiden verbreitetsten Missverständnissen über die Entstehung des agilen Produkt- oder Projektmanagements: das erste ist, dass sie 2001 in Snowbird, Utah entstanden sind, als dort das Manifest für agile Softwareentwicklung verfasst wurde. Das zweite erkennt zwar an, dass Frameworks wie Scrum, Crystal und XP deutlich älter sind als das Manifest, geht aber davon aus, dass ihre Erfinder erst in Snowbird ihre Gemeinsamkeiten erkannten (und einen Namen dafür suchten).

Dass die Wahrheit nochmal anders geartet war, kann man im Podcast The Pragmatic Engineer erfahren, genauer gesagt in der Episode TDD, AI agents and coding, in der Kent Beck zu Gast ist, der Erfinder von XP (Extreme Programming) und der erste Unterzeichner des agilen Manifests. Neben XP-Praktiken und seinen Erfahrungen mit dem Einsatz von künstlicher Intelligenz teilt er auch Geschichten rund um die Verfassung des besagten Manifests, unter anderem, das dieses einem bestimmten Zweck diente.

Und damit kommen wir zurück zur Zeit, in der die agile Bewegung keinen Namen und keine Bekanntheit hatten, denn laut Beck sollte die Zusammenkunft in Snowbird genau das ändern. Es war nämlich kein gegenseitiges Kennenlernen, das dort stattfand (fast alle Beteiligten kannten sich bereits) und auch kein Erarbeiten von Gemeinsamkeiten (das war bereits früher passiert, u.a. bei einer gemeinsamen Hurtigruten-Kreuzfahrt einiger Teilnehmer). Es ging um Marketing und Brand Building.

Die angehenden Verfasser des agilen Manifests waren sich bewusst, dass sie bereits über eine kleine aber treue Gruppe von Anhängern verfügten, der Grossteil ihrer Zielgruppe (Software-Entwickler und IT-Manager) aber noch nicht bereit war, sich auf die neuen Arbeitsweisen einzulassen. In Anlehnung an das Technology Adaption-Modell aus dem Buch Crossing the Chasm suchten sie nach einem Weg, um die Lücke zwischen den ersten Anhängern und der Mehrheit der Anwender zu überwinden.

"Agile" oder die anderen in Snowbird erwogenen Namen, wie "Adaptive" oder "Lightweight" waren bewusst gedacht als einfache, attraktive und wirkmächtige "Dachmarken", mit deren Hilfe es einfacher werden sollte, die verschiedenen dahinterstehenden Frameworks bekannt und populär zu machen und so dafür zu sorgen, dass möglichst viele Softwareentwickler zu deren Anwendern werden konnten, wollten und in ihren Firmen auch durften.

Die Ironie dieser Geschichte liegt darin, dass der gewählte Vermarktungsansatz am Ende zu erfolgreich war - zumindest in der rückwirkenden Betrachtung von Kent Beck. Dadurch, dass fast ausschliesslich die positiven Effekte im Mittelpunkt der Aussendarstellung standen, wollten plötzlich auch Menschen und Organisationen dieses Label tragen, die die notwendigen Kriterien gar nicht erfüllten. Hierin liegt sicherlich einer der Ursprünge von Cargo Cult Agile und dem agil-industriellen Komplex.

Wie es besser gegangen wäre hat im Übrigen ebenfalls Kent Beck gezeigt, und auch darüber berichtet er im Pragmatic Engineer-Podcast. Für sein eigenes Framework Extreme Programming hat er einen Namen gefunden, der einerseits gut vermarktbar ist, andererseits aber klar macht, dass es anspruchsvoll und anstrengend sein kann, so zu arbeiten. Man kann lange darüber spekulieren, welchen Weg die agile Bewegung wohl gegangen wäre, wenn man sie auf diese Weise vermarktet hätte.

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) einfach. Man setzt ein abstraktes, mittelfristiges Objective (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen messbaren Key Results (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Eine Herausforderung, die dadurch entsteht ist aber die Verbindung der OKRs mit der übergreifenden Unternehmensstrategie.

Um klarer zu machen warum das eine Herausforderung ist: eine übergreifende Strategie setzt sich zusammen aus Entscheidungen, auf welche Märkte, Produkte, Preissegmente und Produktionsprozesse sich ein Unternehmen in der länger- und langfristigen Zukunft konzentrieren will, was in der Regel einen Zeithorizont von Jahren oder sogar Jahrzehnten bedeutet. Zwischen einer solchen auf Jahre ausgerichteten Strategie und den nur wenige Monate umfassenden OKR-Zyklen klafft eine Lücke.

Versucht man diese Lücke zu schliessen entsteht die nächste Herausforderung: so wie OKRs gedacht sind, sollten die Objectives keine bereits lange im Voraus festestehenden Teile eines Work Breakdown aus einem Strategie-Umsetzungsplan sein, sondern noch kurz vor jedem Zyklus verfasst oder angepasst werden können. Das Ziel sollte also sein, eine Verbindung zwischen Strategie und OKRs zu schaffen, die zwar für eine übergreifende Ausrichtung sorgt, dabei aber möglichst wenig einengend ist.

Wie das im Einzelfall aussehen kann hängt vom jeweiligen Kontext ab. Wenn der z.B. eher von Product Discovery geprägt ist, also von einer Neu- oder Weiterentwicklung mit schnellen Feedback-Zyklen, kann es Sinn machen, Outcome-orientierte längerfristige Ziele zu formulieren (z.B. "langfristige Power User werden für ihre Treue belohnt"), ohne vorzugeben, durch welche Massnahmen, mit welcher Belohnung oder oder in welchen Systemen das erreicht werden soll.

Wenn es dagehen eher um die kontinuierliche Optimierung etablierter Produkte oder Services geht, kann es ein guter Weg sein, North Star-Metriken zu definieren (z.B. je nach Produkt Anzahl der Buchungen, Interaktionsraten, Nutzungsdauern, etc) und deren dauerhafte und langfristige Optimierung anzustreben, auch hier ohne eine länger im Voraus verfasste Vorgabe, wie das stattzufinden hat. Und natürlich gibt es neben diesen beiden Kontexten noch viele weitere mögliche.

Da es auch im Umfeld der OKRs zur Entwicklung einer eigenen Fachsprache gekommen ist, gibt es auch für diese Verbindungselemente zwischen Strategie und Objectives einen eigenständigen Namen. Man spricht von "Moals",  wobei es sich um eine Abkürzung für "mid-term Goals" handelt, also um mittelfristige Ziele im Sinn von Jahreszielen, o.Ä. Wie immer im Fall solcher Begriffe kann man sich auch bei diesem über Sinnhaftigkeit und Originalität streiten, zumindest ist er aber OKR-spezifisch.

Ob man den Begriff benutzt oder nicht ist am Ende auch relativ egal, viel wichtiger ist, dass die Lücke zwischen Strategie und OKRs überhaupt geschlossen wird. Und eine letzte wichtige Faustregel kann man sich merken: immer wenn versucht wird, Prozesse und Formate rund um diese Verbindungsschicht vorzugeben (formalisierte Moal Plannings, zu befogende Moal Templates, etc) hat das nicht mehr viel mit der ursprünglichen Idee der OKRs zu tun, sondern ist Teil des agil-industriellen Komplexes.

Bild: Unsplash / Olga Guryanova - Lizenz

Mit dem Scrum-Framework haben Jeff Sutherland und Ken Schwaber etwas Bemerkenswertes geleistet: es ist ihnen gelungen, das de facto-Standard-Vorgehen der globalen Software-Industrie zu entwickeln. Der Minimalismus, der die Stärke von Scrum bildet, ist dabei gleichzeitig seine Schwäche - es ist schnell zu verstehen, lässt dabei aber auch einen Freiraum, der mit komplizierten und umfangreichen Regelwerken gefüllt werden kann, von denen SAFe und Disciplined Agile (DA) die bekanntesten sein dürften.

Da ein Grossteil der agilen Community diese beiden Ansätze ablehnt, gibt es bereits seit langem den Wunsch, ihnen eine dem ursprünglichen Geist von Scrum eher entsprechende Erweiterung entgegenzusetzen, idealerweise beruhend auf bereits verbreiteten Praktiken. Large Scale Scrum (LeSS) ist vor diesem Hintergrund entstanden, hat aber nur einen eher inoffiziellen Status. Erst seit Juni 2025 gibt es eine quasi-offizielle Erweiterung, verfasst (u.a.) von Jeff Sutherland: das Scrum Guide Expansion Pack.

Dieses Expansion Pack (mit ca 50 Seiten deutlich umfangreicher als der 13-seitige Scrum Guide, aber auch deutlich schlanker als SAFe und DA) wurde neben Sutherland von John Coleman und Ralph Jocham mitverfasst und besteht aus vier Sektionen: der eigentlichen Erweiterung mit dem Namen Adaptation of: The original Scrum Guide und einem Appendix aus den drei Teilen MORE executive SUCCESS extract, Cynefin Framework Kind of Explanation unofficial & unauthorized und Emergent Strategy.

In die erste Sektion ist auch der eigentliche Scrum Guide eingebettet, um ihn zu ergänzen enthalten alle vier Sektionen weiterführende Erläuterungen, einige der erwähnten verbreiteten Praktiken und historische Hintergründe. Das ist zum Teil banal (etwa wenn erklärt wird, dass "self managing" ein von aussen kommendes Management ausschliesst) zum Teil aber auch durchaus aufschlussreich (z.B. dann wenn erklärt wird, welche Untergruppen die eher diffuse Gesamtgruppe der "Stakeholder" haben kann).

An einigen Stellen finden de facto Erweiterungen des Scrum Guides statt, so gibt es jetzt nicht mehr lediglich drei Artefakte (Product Backlog, Sprint Backlog und Increment) sondern mit dem Product ein viertes; aus der einen Definition of Done sind die Definition of Outcome Done und die Definition of Output Done geworden; zu den drei Rollen, bzw. Accountabilies (Developer, Product Owner, Scrum Master) kommt mit den Stakeholdern eine vierte.

Zu den aufgenommenen Praktiken gehören am prominentesten die Produkt Vision (die das Product Goal nicht ersetzt sondern ergänzt), die Akzeptanzkriterien (die nochmal aufgeteilt werden in die eigentlichen Akzeptanzkriterien und so genannte Outcome-Kriterien) und die häufigsten in Retrospektiven besprochenen Themen (u.a. Professionalität, Effektivität und Teamdynamiken), über den Text verstreut finden sich aber auch weitere, etwa Systems Thinking, (Product) Discovery und Beyond Budgeting.

Eher in den Berech der Nerd-Wissens gehören einige Exkurse zu historischen Begrifflichkeiten und Dokumenten. So werden die Scrum Werte Focus, Openness, Courage, Commitment und Respect aus dem amerikanischen Militär-Begriff OODA (Observe, Orient, Decide, Act) abgeleitet und gleich mehrere Absätze widmen sich dem wissenschaftlichen Paper The New New Product Development Game von 1986, das eine zentrale Inspirationsquelle für Sutherland und Schwaber war.

Im Gegenzug dazu gibt es mit einem eigenen Teil zum Thema der künstlichen Intelligenz (KI) auch etwas, das erkennbar von aktuellen Entwicklungen getrieben ist. Kurioserweise eingeordnet zwischen den Rollen, bzw. Accountabilies werden die damit verbundenen Möglichkeiten und Risiken herausgestrichen (und es wird hervorgehoben, dass der Scrum Master keine KI sein darf¹). Das ist nicht falsch, aber etwas willkürlich, mit gleicher Berechtigung hätte man z.B. auch Big Data oder Cloud mit aufnehmen können. 

Ob das Scrum Guide Expansion Pack weite Verbreitung finden und noch weiter modifiziert werden wird, wird sich zeigen, wahrscheinlich ist aber in Analogie zum eigentlichen Scrum Guide (den es nur ergänzt, aber nicht ersetzt) beides. Ob es sich als Ersatz oder Gegenmodell zu den kommerziell erfolgreichen und von professionellem Marketing unterstützen Ansätzen SAFe und DA durchsetzen wird ist dagegen weit weniger klar, das in den nächsten Jahren zu beobachten wird sicherlich spannend sein.

Auf jeden Fall wird man es aber gut nutzen können, um zu erkennen, wer sich wirklich für das Thema Scrum interessiert. Denn ganz sicher werden nus solche Personen bereit sein, die gesamten ca 50 Seiten durchzulesen. Alle anderen werden das vermutlich geflissentlich an ihren Scrum Master delegieren.

Bild: Pexels / Ketut Subiyanto - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Am Anfang von dieser hier stand wie so oft ein Frustrationserlebnis. Eine grosse Firma, bei der ich im Einsatz war, hatte sich in einem Pilotprojekt auf die Idee crossfunktionaler Entwicklungsteams eingelassen, in der Hoffnung, dadurch die alles verzögernden Warte- und Übergabephasen zwischen den bisherigen Spezialistenteams deutlich verkürzen zu können. Bis zu einem gewissen Grad war das auch eingetreten, allerdings bei Weitem nicht in dem von allen erhofften Ausmass.

Eine Untersuchung der betroffenen Einheiten und Prozesse konnte dann klar aufzeigen, woran das lag: das Team war nur crossfunktional innterhalb der Softwareentwicklung (Frontend, Backend, Data Science, UX), was aber bei weitem nicht alle Arbeitsschritte abdeckte. Das Produkt (ein Kundenservice-Chatbot) musste nach der Entwicklung noch zur Fachabteilung, um von der mit Daten versorgt und trainiert zu werden, um dann von der Rechtsabteilung freigegeben zu werden. Hier entstanden weiter Wartezeiten.

Auch Mitglieder dieser beiden Abteilungen in das crossfunktionale Teams aufzunehmen war die offensichtliche Lösung, führte aber zu Beginn zu heftigen Abwehrreaktionen; dafür gäbe doch gar nicht genug Zeit, und es gäbe zu viel Anderes zu tun, das wichtig wäre. Auch hier führte eine Nachforschung schnell zu einer Identifikation des eigentlichen Problems: die betroffenen Kollegen waren stark überplant und hatten nur wenige Stunden pro Woche für das Pilotprojekt zur Verfügung - deutlich zu wenig.

Es brauchte mehrere Wochen und Eskalationen bis ins Top-Management um dieses Problem zu lösen, aber am Ende stand ein deutlich besseres Setup. Aus der Fachabteilung wurden mehrere Mitarbeiter für vier Tage pro Woche exklusiv für das Projekt freigestellt, aus der Rechtsabteilung immerhin ein Kollege für drei halbe Tage pro Woche. Damit konnten sie in das jetzt wirklich crossfunktionale Team eingegliedert werden, an dessen Meetings teilnehmen und eng mit den anderen Teammitgliedern zusammenarbeiten.

Durch diese Neuorganisation trat dann endlich die angestrebte Beschleunigung ein. Durch die täglichen Abstimmungen war jetzt jederzeit klar, wann die Übergaben zwischen den Teilteams stattfinden würden, und durch die realistischere Kapazitätsplanung konnten sie auch fast immer sofort stattfinden. Die Durchschnittlsdauer der Warte- und Übergabephasen sank von Tagen und Wochen auf Stunden (und als Nebeneffekt konnten die Meetings entfallen, in denen die zu übergebende Arbeit verwaltet wurde).

Natürlich gab es noch weitere positive Effekte dieses Vorgehens, z.B. die oben erwähnte Aufdeckung der strukturellen Überplanung vieler Mitarbeiter, da schnellere Durchlaufzeiten durch crossfunktionalere Teams aber das Hauptziel der Umstellung auf agiles Arbeiten waren, steht auch das hier im Focus dieser "agilen Erfolgsgeschichte". Und darüber hinaus ist es ein gutes Beispiel dafür, wie weit wirkliche Crossfunktionalität gehen kann.

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.