On Lean and Agility

Bücher zum Thema Unternehmenskultur gibt es mittlerweile unübersehbar viele, und wer einige davon gelesen hat wird gemerkt haben, dass auch die Vorstellungen davon, was Kultur eigentlich ist, ebenfalls unübersehbar vielfältig sind. Das Schöne daran: es gibt immer wieder interessante neue Sichtweisen, so wie in- dem Buch Making Organizational Culture Great - Moving Beyond Popular Beliefs, geschrieben von den amerikanischen Wirtschaftswissenschaftlern Jennifer A. Chatman and Glenn R. Carroll.

Passend zum von ihnen gewählten Untertitel ist es das Ziel der beiden Autoren, die Diskussion über Unternehmenskulturen zu versachlichen, weshalb der Aufbau um fünf populäre Annahmen kreist, die anhand realer und bekannter Beispiele validiert und in diesem Rahmen bestätig oder widerlegt werden (oder differenziert betrachtet, wenn das Ergebnis nicht eindeutig ist). Bei diesen fünf untersuchten Annahmen handelt es sich um die folgenden:

Unternehmenskultur entsteht irgendwie, existiert einfach so wie sie ist und kann nicht geändert werden

Diese Annahme ist in den Augen von Chatman und Carroll nicht völlig falsch, aber auch nicht zwangsläufig richtig. Während z.B. bei Kodak und PanAm ein Kulturwandel scheiterte war er bei Ford und Roche erfolgreich. Und bei Apple scheiterte er zunächst, um unter später unter neuer Führung (der von Steve Jobs) zu gelingen. Entscheidend ist jeweils der Kontext.

Unternehmenskultur kann verändert werden, aber nut Top-Down durch das Management

Auch hier ist die Antwort differenziert. Auf der einen Seite wird an Beispielen wie dem Southwest Airlines-CEO Herb Kelleher gezeigt, wie gross die Gestaltungsmöglichkeiten hoher Manager sein können, auf der anderen Seite wird an Firmen wie Boeing (vor der Fusion mit McDonnell Douglas) gezeigt, dass Kultur (in diesem Fall Ingenieur-Kultur) auch dezentral entstehen kann.

Unternehmenskultur ist etwas Weiches und Amorphes und kann nicht konkretisiert oder quantifiziert werden

Vermutlich das kontroverseste Kapitel des Buches. In ihm wir klar davon ausgegangen, dass Kultur konkretisierbar und messbar ist, und dass nicht nur qualitativ (etwa durch Zufriedenheits-Erhebungen) sondern auch quantitativ (etwa durch Umfang und Geschwindigkeit der Aneignung von Insider-Sprache). Praxisbelege gibt es auch hier, über deren Repräsentativität kann man aber diskutieren.

Unternehmenskultur erfordert, dass Mitarbeiter sich an sie anpassen, wenn sie Wirksamkeit entfalten oder keine Nachteile erfahren wollen

Für Chatman und Carroll ist das zu einfach gedacht. Zum einen erfordern viele Unternehmenskulturen (z.B. in innovativen Umfeldern) eine gewisse Nonkonformität, was im Widerspruch zum angepasst Sein steht, zum anderen ist Kultur oft implizit oder dynamisch, was Anpassungen erschwert. Sehr deutliche Kulturunterschiede sind aber meistens nachteilig, wie anhand von Disney und Netflix gezeigt wird.

Unternehmenskultur kann zu Mitarbeiterzufriedenheit beitragen, aber nicht zu wirtschaftlichem Unternehmenserfolg

Diese Annahme drehen die beiden Autoren zunächst um. Was eine (schlechte) Unternehmenskultur definitiv bewirken kann, ist ein wirtschaftlicher Schaden, wie sie u.a. am Beispiel Volkswagen zeigen. Darüber hinaus können eine Leistungs- oder Innovationskultur erkennbar zu wirtschaftlichem Erfolg beitragen, wofür Walmart und SpaceX als Belege genannt werden.

Nach diesen zentralen Kapiteln endet Making Organizational Culture Great mit einem weiteren, in dem konkrete Ratschläge zur Kulturgestaltung gegeben werden, auch hier wieder basierend auf vielen Praxisbeispielen. Vieles davon ist naheliegend, etwa die gezielte Personalauswahl oder Weiterbildung. Andere, wie das Verfassen von kulturellen Leitbildern oder das oben genannte Messen von Kultur sind kontrovers. Und einige, wie das Feuern kulturell unpassender Mitarbeiter, wären in Deutschland illegal.

Am Ende spiegelt sich aber in dieser Mischung, warum das Buch lesenswert ist. Es verbindet das Hinterfragen scheinbarer Gewissheiten mit konkreten Praxiserfahrungen und -anleitungen sowie kontroversen Standpunkten, an denen man sich Reiben kann. Das regt an zum Nachdenken, Hinterfragen und Ausprobieren - was passenderweise auch ein erfolgsversprechender Ansatz für die Erforschung und Gestaltung von Unternehmenskulturen ist. 

Bild: Unsplash / Chase Chappell - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Sicht auf die Arbeitswelt entwickeln ist bedauerlich, aber erklärbar. Wer sich täglich 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.

Diese hier hat auf den ersten Blick kein besonders agiles Ergebnis gehabt, schliesslich handelte es sich bei ihm um die Einführung von Quartalsplanungen. Eine Quartalsplanung - wie soll das mit den kurzen Lieferzyklen zusammenpassen, die Erkennungsmerkmal der agilen Arbeitsweisen sind? Um das zu erklären muss ich etwas ausholen, denn wie immer steckt auch hinter dieser Geschichte eine Entstehungsgeschichte, die man kennen sollte.

In der Vergangenheit hatte das Unternehmen mit dem ich zu dieser Zeit zusammengearbeitet habe einen eher klassischen Planungsansatz. Am Anfang stand die so genannte "Mifri" (die mittelfristige Finanzplanung), die jeweils für die nächsten drei Jahre die vorgesehenen Budgets festlegte, und das z.T. auf erstaunlich detailliertem Niveau. Den Budgets wurden dann für jeweils das nächste Jahr Ressourcen (also Mitarbeiter) zugeordnet. Für die ganzen zwölf Monate, ebenfalls in hohem Detailgrad.

Ob es jemals den Fall gegeben hatte, dass ein solcher Plan aufgegangen war, konnte keiner sagen. In den letzten zehn Jahren war das aber nicht der Fall gewesen, ständig liefen Plan und Realität auseinander. Zu Beginn eines Jahres wurde das versucht mit Mehrarbeit zu kompensieren, in der Mitte des Jahres gab es bürokratische Plananpassungen, ab Herbst floss ein Grossteil der Arbeit dann in Rechtfertigungen dafür, dass die Planziele nicht erreicht worden waren. So lief es jedes Jahr.

Irgendwann war der durch dieses Vorgehen erzeugte Schmerz zu gross geworden, und das Vorgehen wurde angepasst. Die mittelfristige Finanzplanung gab es zwar noch, sie wurde aber wesentlich weniger kleinteilig durchgeführt. Statt für einzelne Features waren die Budgets jetzt für Systeme oder Services vorgesehen, wodurch der Handlungsspielraum deutlich grösser wurde. In gleicher Art wurden auch die Jahresplanungen abstrahiert und vereinfacht.

Die eigentliche Planung fand ab diesem Zeitpunkt auf Quartalsbasis statt, also immer für drei Monate im Voraus. Und um zu verhindern, dass Überläufer-Themen des letzten Quartals de facto zu einer Verlängerung der Planungszyklen führten, wurden alle Aktivitäten und Prioritäten vor Planungsbeginn auf Null zurückgesetzt, so dass Restaufwände ggf. nicht mehr umgesetzt wurden. Mit der Zeit erwies sich das als wirkungsvolles Mittel gegen die bis dahin weit verbreiteten überoptimistischen Pläne.

Der so entstehende Kontrast zwischen dem alten und dem neuen Vorgehen war drastisch: vorher hatten die Pläne ab Frühling kaum noch Realitätsbezug, stattdessen flossen bemerkenswerte Aufwände in Eskalationen, bürokratische Umplanungen und Rechtfertigungen. Nach der Umstellung führten die kürzeren Planungszeiträume dazu, dass Plan und Realität ständig nah beieinanderlagen, wodurch die gerade genannten Aufwände unnötig (oder zumindest stark reduziert) wurden.

Als zusätzlichen Effekt konnte man eine deutliche Zunahme der Produktivität beobachten. Die gesamte bisher notwendige Eskalations, Umplanungs und Rechtfertigungszeit konnte jetzt für die eigentliche Arbeit verwendet werden, was zu deutlich schnelleren Umsetzungen führte. Und wenn Annahmen oder Planungen sich als unrealistisch erwiesen, belastete das nicht mehr das ganze Jahr, sondern nur die Zeit bis zur nächsten Quartalsplanung, bei der alle Pläne zurückgesetzt wurden.

Eine tatsächliche Erfolgsgeschichte also. Aber auch eine agile Erfolgsgeschichte? Wie oben gesagt, sind dafür drei Monate nicht zu lang? Statt einer eigenen Antwort darauf möchte ich die Primärquelle zitieren, das Manifest für agile Softwareentwicklung, bzw. dessen zweite Seite, die Principles behind the Agile Manifesto. Zu denen gehört nämlich auch eines, dass sich mit den anzustrebenden Umsetzungszeiträumen befasst, und das liest sich so:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Die Hervorhebung ist von mir, den Rest kann man für sich sprechen lassen.

Das was Randy Shoup hier abliefert ist ein bemerkenswerter Einblick in die Welt grosser (IT-)Organisationen. Seine zentrale Botschaft, die er mit zahlreichen Beispielen aus seiner Zeit bei Ebay unterlegt: wenn ein Unternehmen eine dysfunktionale Unternehmenskultur hat, dann wird eine Modernisierung der Prozesse, Tools und IT-Systeme nur in begrenztem Ausmass zu Verbesserungen führen. Keine neue Erkenntnis, aber sehr anschaulich an einem bekannten Beispiel erklärt.

Eine zweite von ihm erzählte Geschichte, die in der oben genannten Enthalten ist, ist die der bei Ebay vorgenommenen Prozess-, Tool- und System-Modernisierungen, die trotz des letztendlichen Scheiterns an kulturellen Mustern zwischenzeitlich zu deutlichen Verbesserungen geführt haben. Shoup zufolge ist das mit einem geradezu minimalistischen Vorgehensmodell gelungen: der kontinuierlichen Identifikation von verlangsamenden Faktoren und deren sequentieller Abarbeitung durch ein die Entwicklungsteams unterstützendes Plattform-Team. Geradezu das Gegenmodell zu SAFe & Co.

Es gibt für Retrospektiven kein kategorisch richtiges oder für alle Situationen passendes Format, jedes Team kann seine eigene Variante entwickeln. Umgekehrt gibt es aber Verhaltensmuster, die besser zu vermeiden sind. Ein leider immer wieder anzutreffendes besteht daraus, Probleme nur zu identifizieren, für ihre Lösung aber später stattfindende Folgetermine einzurichten (oder noch schlimmer: sich lediglich vorzunehmen, derartige Termine zu planen).

Dabei ist es natürlich nicht so, dass es gar keine Konstellationen gäbe, in denen dieses Vorgehen Sinn macht. Wenn für eine Problemlösung z.B. Fachexperten oder Kooperationspartner anwesend sein müssen, die nicht zum Team gehören, dann muss man selbstverständlich vorher deren Verfügbarkeit und Bereitschaft in Erfahrung bringen. Aber bei Team-internen Themen, wie z.B. der Überarbeitung der eigenen Definition of Done, ist diese Sinnhaftigkeit nicht gegeben.

Dass trotzdem immer wieder so vorgegangen wird hat verschiedene Gründe. Ein häufiger ist der, dass auf diese Weise (scheinbar) mehr Themen erledigt werden können: nur Fünf Folgetermine zu planen geht schneller als Fünf Themen zu besprechen und zu Ergebnissen zu kommen. Auch dass das Thema für einen Teil der Anwesenden von nur wenig Interesse ist, ist ein  häufiger Grund. Und ein ebenfalls häufiger (wenn auch keineswegs Guter) ist der, dass man schon immer so vorgegangen ist.

Die Folgen dieser Vorgehensweise sind zum einen, dass die Kalender immer voller werden, und zum anderen, dass die angestrebten Lösungen und Ergebnisse immer später entstehen. Diese Phänomene stehen sogar in Beziehung zueinander. Weil für zusätzliche Meeting nicht unbegrenzt Zeit (und Lust) vorhanden sind, kann nur eine begrenzte Zahl zeitnah stattfinden. Schlimmstenfalls können sie sogar erst so weit in der Zukunft stattfinden, dass bis dahin schon die nächste Retrospektive stattgefunden hat.¹

Ein deutlich besseres Vorgehen ist es, die aufgekommenen Themen direkt in dem Termin zu behandeln, in dem sie zum ersten Mal thematisiert wurden. Um beim oben genannten Beispiel zu bleiben: wenn eine Überarbeitung der eigenen Definition of Done nötig ist, dann ist das etwas, was sofort angegangen und erledigt werden kann. Das Gleiche gilt auch für zahlreiche weitere Themen, von Coding Standards über zwischenmenschliche Unstimmigkeiten bis zur Planung des nächsten Team-Events.

Bleiben noch die gerade genannten Einwände. Einfach zu entkräften ist der Erste: mehrere Themen nur kurz anzudiskutieren und dann Folgetermine zu vereinbaren, sorgt eben nicht dafür, dass insgesamt mehr erledigt werden können. Es führt nur dazu, dass die Arbeit an mehreren parallel begonnen wird (ein wichtiger Unterschied). Nur an wenigen zu arbeiten, dafür aber richtig, lässt natürlich andere Themen unbehandelt - aber wenn sie wichtig bleiben, können sie nächstes Mal erneut eingebracht werden.

Dass bei manchen Themen nicht alle Mitglieder eines Teams nicht alle bei allen Themen in gleicher Tiefe mitreden können ist schon ein besseres Argument, aber auch kein wirklich Gutes. Zum einen bietet ein sofortiges und gemeinsames Angehen die Möglichkeit, neue Themen kennenzulernen und in ihnen besser zu werden. Und sollte der Extremfall zweier extrem unterschiedlicher Teilteams gegeben sein, lassen sich ggf. auch zwei Arbeitsgruppen bilden, von denen jede an jeweils einem Thema arbeitet.

So oder so sollten die Vorteile einer sofortigen Problembehandlung durch eine Workshop-artige Retrospektive klar sein. Schnelle Ergebnisse, kein Aufschieben der Lösungsfindung auf zukünftige Zeitpunkte, keine zusätzlichen Meetings, kein paralleles Herumwerkeln an mehreren Themen. Warum nicht alle Teams das so sehen ist mir schleierhaft, aber immerhin ist es meine Erfahrung, dass die meisten sich darauf hinweisen lassen und diesen Impuls dann auch verstehen und annehmen.

Wenn die Aussenwahrnehmung eines Arbeitgebers sehr stark durch einen einzigen HR-Aspekt geprägt ist, dann muss das schon ein ganz besonderer sein. Dementsprechend sind solche Fälle zwar selten, aber es gibt sie immer wieder. Die Side Project Time bei Google ist ein bekanntes Beispiel oder die freie Vorgesetzten-Wahl bei Uber. Das vermutlich kontroverseste dieser Beispiele dürfte aber der so genannte "Keeper Test" von Netflix sein.

Besagter Test wurde in dieser Firma bereits 2001 als Praktik eingeführt, 2009 im so genannten Culture Deck offiziell gemacht und 2020 im Buch No Rules Rules einer breiteren Öffentlichkeit vorgestellt. Es gibt ihn in verschiedenen (inhaltlich gleichen) Varianten, die im besagten Buch vorgestellte ist diese hier:

If a person in your team were to quit tomorrow, would you try to change their mind? Or would you accept their resignation, perhaps with a little relief? If the latter, you should give them a severance package now, and look for a star, someone you would fight to keep.

Zu Deutsch: jeder Manager sollte sich bei jedem seiner Untergebenen fragen, ob er ihm eine Kündigung ausreden würde - und wenn nicht, dann soll er ihm eine Abfindung zahlen, damit er geht, und sich einen besseren Ersatz suchen. Das klingt zunächst einmal extrem hart und hat tatsächlich auch dazu geführt, dass Netflix in den Medien das Schaffen einer Angstkultur vorgeworfen wurde. Aber wie so oft in derartigen Fällen: ganz so einfach ist es nicht.

Zunächst muss man die wichtige Kontext-Information kennen, dass in der IT-Industrie im Allgemeinen und im Silicon Valley im Besonderen kurze Firmenzugehörigkeiten von jeweils wenige Jahren nichts Ungewöhnliches sind, bei vielen Unternehmen sind sie sogar der Normalfall. Den Menschen, die den Keeper Test nicht bestanden haben, wird also keine Job weggenommen den sie bis zur Rente behalten wollten, es fällt lediglich eine von vielen Stationen etwas kürzer aus.

Ebenfalls wichtig ist, dass die Angestellten von Netflix keineswegs in ständiger Ungewissheit über die Meinung ihrer Vorgesetzten leben müssen. Es gibt sogar ein fest definiertes Auskunftsverfahren, den so genannten "Keeper Test Prompt", mit dem man sein aktuelles Ergebnis erfragen kann. Und da dieses Ergebnis nicht nur aus den Extremwerten Bleiben und Gehen besteht, sondern auch aus vielen Zwischenstufen, hat jeder die Gelegenheit, an sich zu arbeiten um das Testergebnis wieder zu ändern.

Auch ist in der Realität auch das Scheitern an einem Keeper-Test nicht automatisch mit einer Kündigung verbunden (selbst wenn auch das natürlich oft genug vorkommt). In No Rules Rules werden auch Fälle beschrieben, in denen stattdessen eine Versetzung in andere Abteilungen stattfand, in denen die Betroffenen für sie passendere Rahmenbedingungen vorfanden. In Einzelfällen kann die Überlegung, wo der durch den Test gefallene Kollege einen Mehrwert stiften kann, sogar zu Beförderungen führen.

Zuletzt sollte man nicht aus den Augen verlieren, dass der Keeper-Test auch eine sehr positive Seite haben kann. Elizabeth Stone, der Chief Product and Technology Officer (CPTO) von Netflix, hat beispielsweise in einem Podcast erzählt, dass sie in den Personalgesprächen mit ihren Untergebenen regelmässig hervorhebt, was diese so gut machen, dass sie darum kämpfen würde, sie in jedem Fall bei sich zu behalten. Denn auch das gehört dazu: in vielen Einheiten bestehen alle den Test.

Trotz allem bleibt aber die Kernaussage aber natürlich bestehen - die Mitarbeiter, um die man nicht kämpfen würde, sollen bitte gehen. Auch das wird in No Rules Rules detaillierter erklärt: zu denen, von denen man sich trennt, gehören nicht nur die, die schlechte Arbeit leisten, sondern auch die, die sich technischen Innovationen verweigern, die strategische Entscheidungen und organisatorische Veränderungen nicht mittragen wollen, oder die einfach ständig für schlechte Stimmung sorgen.

Aber führt das am Ende nicht doch zu einer Angst- und Ellenbogen-Kultur? Nicht unbedingt. Das Buch zitiert Forschungsergebnisse der amerikanischen Business School-Professorin Erin Meyer, die folgende Zahlen ermittelt hat: Netflix kündigt jährlich im Schnitt 8% seiner Angestellten, und liegt damit nur leicht über dem Branchenschnitt von 6% - gleichzeitig liegt aber die Kündigungsrate der Mitarbeiter bei nur 4%, während diese im Branchenschnitt bei 12% liegt. Eine Angstkultur sähe anders aus.

Was hinter diesen Zahlen steckt ist die Erkenntnis, dass mit den Angestellten, die den Keeper Test nicht bestehen, nicht nur menschlich geschätzte Kollegen die Firma verlassen, sondern vor allem solche, die durch konstant schlechte Arbeitsergebnisse oder durchgehend grenzwertige Verhaltensweisen auf alle anderen demotivierend wirken. Vielleicht ist das der eigentlich kontroverse Gedanke - dass das humane Verhalten gegenüber denen, die die Erwartungen nicht erfüllen, inhuman gegenüber allen anderen ist.

The new development cycle in one image. pic.twitter.com/18bBgKPQF2

— Kr$na (@krishdotdev) July 16, 2026

Der Vollständigkeit halber sollte man sagen: die neue Form eines schlechten Softwareentwicklungs-Zyklus. Leider trotzdem eine Häufige.

Bild: Pexels / Ekam Juneja - Lizenz

Lucas F. Costa: Lucas' Laws of Project Management

Nigel Thurlow: The Toyota Production System (TPS) - What the House Actually Represents

Chris Chinchilla: Nokia’s 14 Years of Mobile-Phone Supremacy Ended in an Afternoon

Rahul Singal: Prefactoring - Clear the Way for Your New Feature

Selten in der Geschichte der organisierten Arbeit haben angestellte Menschen ein solches Ausmass an Freiheit und Mitbestimmung gehabt wie in agilen (Software-)Entwicklungsteams. Sie können selbst entscheiden wie viel Arbeit sie in nächster Zeit beginnen wollen, wie viel Beschreibungsumfang die Anforderungen haben müssen, wie sie sich die Arbeit intern aufteilen und noch Vieles mehr. Aber paradoxerweise sind viele von ihnen hochgradig unzufrieden.

Wie immer in komplexen Konstellationen gibt es nicht einen einzigen Grund, der das abschliessend erklärt, und auch keinen (Teil-)Grund der in allen Fällen vorliegt, meiner Erfahrung nach gibt es aber einen der in sehr vielen Fällen zu beobachten ist. Es ist die so genannte hedonistische Tretmühle, womit das Phänomen beschrieben wird, dass Menschen auch nach deutlichen Verbesserungen ihrer Situation mittelfristig wieder auf ihr vorheriges Zufriedenheits-Niveau zurückkehren.

Um es an einem konkreten und häufig zu beobachtenden Beispiel festzumachen: wenn einem Team nicht mehr die Aufwandsschätzungen und Umsetzungswege der Anforderungen von Aussen vorgegeben werden, führt das kurzzeitig zu Erleichterung, Aufbruchsstimmung und ähnlichen positiven Emotionen. Mittelfristig entstehen aber neue Demotivations-Ursachen, z.B. Unzufriedenheit mit der Anforderungs-Priorisierung oder der Feedback-Frequenz. Am Ende ist die schlechte Stimmung wieder da.

Die Erklärung, die in verschiedenen psychologischen Studien postuliert wurde, ist die, dass ein Grossteil der Menschen (viele, aber nicht alle) ein stabiles Niveau an Zufriedenheit und Glück hat, von dem zwar situationsbedingt Abweichungen nach unten oder oben möglich sind, zu dem aber immer wieder zurückgekehrt wird. Unwissenschaftlich formuliert: manche Menschen sind halt Miesepeter, während andere durchgehend gute Laune haben.

In der Aussenbetrachtung werden Teams, die auch bei spürbaren Verbesserungen ihrer Situation immer wieder auf ihr ursprüngliches Zufriedenheitslevel zurückfallen, in der Regel kritisch gesehen, oft mit Urteilen oder Vorwürfen wie Undankbarkeit und Destruktivität bedacht, und in Extremfällen sogar mit "Diagnosen" wie Dysphorie pathologisiert. Sich des Phänomens der hedonistischen Tretmühle bewusst zu sein, kann dabei helfen, derartigen (in der Regel vorschnellen) Annahmen nicht zu verfallen.

Eine konstruktive Möglichkeit des Umgangs mit derartigen Situationen ist es, den Teams kontinuierlich Erfolgserlebnisse zu ermöglichen, wodurch eine Gegendynamik gegen das Zurückfallen auf das ursprüngliche Zufriedenheitslevel entstehen kann. Die Schaffung derartiger Erlebnisse ist einer der Hintergründe für Sprint Reviews, Kaizen Boards und ähnliche Events und Tools, in denen Verbesserungen und Erfolge sichtbar gemacht werden.

Idealerweise geschieht das übrigens nicht mit verdeckter und manipulativer Absicht (selbst dann nicht wenn es gut gemeint ist), sondern den Teams gegenüber offen und transparent, um ihnen diesen zusätzlichen Mehrwert der jeweiligen Events und Tools bewusst zu machen. Natürlich kann das dann zu einer Ablehnung führen, aber letztendlich ist auch das Selbstorganisation: wer dauerhaft unzufrieden sein will, den kann man nicht abhalten - aber zum Glück ist das eher selten der Fall.