Die sechs (nicht fünf) Phasen einer Retrospektive

Bild: Pixabay / Inspired Images - CC0 1.0

Beim Neuaufsetzen eines Scrum-, Kanban- oder XP-Teams ist es eine der immer wiederkehrenden Fragen: wie werden die Retrospektiven, KVP-Meetings oder Kaizen-Events aufgesetzt in denen das bisherige Vorgehen unter die Lupe genommen, hinterfragt und gegebenenfalls angepasst wird? Vor allem im Fall von Teams in denen der neue Scrum Master (bzw. der Facilitator, Flow Manager, etc.) selbst keine Erfahrungen in der Rolle hat kann es helfen diese Frage zu beantworten indem am Anfang auf eine bewährte Struktur zurückgegriffen wird.

Gute Erfahrungen gibt es vor allem mit einem Phasen-Modell, in dessen Rahmen in verschiedenen Arbeitsschritten verschiedene Tätigkeiten ausgeübt werden. häufig werden in diesem Zusammenhang fünf derartige Phasen genannt, zu empfehlen sind aber eine mehr, also sechs. Welche davon häufig vergessen wird wird später in diesem Text noch beleuchtet, zuerst geht es aber darum die ersten fünf kurz zu erklären. Es sind: Setting the stage, Gathering data, Generating insights, Deciding what to do, Closing (zahlreiche Beispiele für diese Phasen finden sich auf Retromat.org).

Setting the stage könnte man auch als Einleitung oder Ankommen bezeichnen. In der einfachsten Form kann das nur die Abfrage sein mit welcher Stimmung die Teilnehmer in das Meeting gehen, in komplexeren Settings kann schon ein thematischer Schwerpunkt gefunden oder ein Ventil für Frust und Freude geschaffen werden. Ein nicht zu unterschätzender sekundärer Effekt sollte es sein, symbolisch eine Unterbrechung des Arbeitsalltags vorzunehmen.

Gathering data ist als zweite Phase praktisch selbsterklärend - es geht darum die Datenbasis für das weitere Vorgehen zu schaffen. Sehr häufig ist die Unterteilung der Wand in Sektionen (z.B. start doing, keep doing, stop doing), verbunden mit der Aufforderung entsprechende Themen auf Post-Its daranzuhängen. Andere Durchführungen können Brainstormings sein, Design Thinking-Events oder Self Assessments.

Generating insights besteht fast ausschliesslich aus der Diskussion der vorher gesammelten Themen, ob in Gruppen, als Lean Coffee, Fishbowl oder in anderen Formaten. Vorgeschaltet ist oft ein Clustern zusammenhängender Themengebiete und eine Priorisierung der Themen, bzw. Themencluster. Gegebenenfalls kann es hier schon starkte Überlappungen mit der nächsten Phase geben, in der aus den Diskussionen Massnahmen abgeleitet werden.

Deciding what to do ist genau das, das Erarbeiten von Massnahmen. Welche das sind ist natürlich hochgradig Einzelfallabhängig, es gibt aber Kriterien, die bei der Formulierung hilfreich sein können: die Massnahmen sollten in nächster Zeit umsetzbar sein, sie sollten vom Team selbst umgesetzt werden können und sie sollten validierbar sein, es muss sich also überprüfen lassen ob sie erfolgreich waren.

Closing bildet gewissermassen zusammen mit dem Setting the Stage die Klammer um die Retrospektive. Auch hier wäre eine Stimmungsabfrage die einfachste Form, es ist aber auch eine "Retrospektive der Retrospektive" möglich um zu bewerten wie gut das Meeting gelaufen ist. Eine andere Form wäre das Einstimmen auf bevorstehende Herausforderungen.

Soweit die weit verbreiteten fünf Phasen. Dass die sechste relativ selten ist, ist an sich bereits bezeichnend, es handelt sich nämlich um das Inspecting the last retro's action Items, also um das Überprüfen der beim letzten mal beschlossenen Massnahmen auf Erfolg. Wie wenn nicht so soll ein Inspect and Adapt stattfinden? Und sinnigerweise sollte das auch relativ früh stattfinden. Ein zu empfehlender Ablauf einer Retrospektive wäre demnach:

Setting the stage, Inspecting last retro's action Items, Gathering data, Generating insights, Deciding what to do, Closing

Deine Muda: Overproduction

Bild: Flickr / Jordi Bernabeu Farrús - CC BY 2.0

Sechster Teil der Deine Muda-Serie. Die fünfte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Überproduktion, auf englisch Overproduction. Wie bei der Lagerhaltung ist es auch hier auf den ersten Blick etwas was in Hardware und Software ähnlich erscheint, während sich auf den zweiten Blick Unterschiede zeigen.

In Bezug auf die Gemeinsamkeiten von Hardware- und Softwareproduktion gibt es zunächst eine große Überschneidung mit der gerade erwähnten Lagerhaltung. Zuviel produzierte Güter können nicht schnell genug verkauft werden und müssen gelagert werden. Da die Produktion bereits bezahlt ist, die Verkaufserlöse aber noch nicht eingegangen sind, binden die Produkte in diesem Zustand Geld, sind also totes Kapital.

Gleichzeitig bindet die Überproduktion Menschen und Maschinen die an anderer Stelle fehlen, wodurch sich dort die Arbeitsfortschritte verzögern. Im schlimmsten Fall kommt es sogar zu zusätzlichen (und eigentlich unnötigen) Neueinstellungen und Neuanschaffungen, durch die es zu einer dauerhaften Zunahme von Lohn- und Instandhaltungskosten kommt, ohne dass diese durch Gewinne refinanziert werden.

Zusätzlich zu diesen Faktoren kommt es zu Verschleisserscheinungen, und zwar sowohl bei Maschinen als auch bei Menschen. Während die ersten sich durch Gebrauch abnutzen tritt bei den Mitarbeiter nicht nur physischer sondern auch psychischer Verschleiss auf. Die Erkenntnis am Markt vorbeizuproduzieren kann deprimmierend sein und sich negativ auf Arbeitsmoral, Engagement und Sorgfalt auswirken.

Softwarespezifisch kommt ein weiterer Faktor dazu, nämlich die unnötige Aufblähung der Code Base und des Funktionsumfangs. Diese sorgen zunächst für gesteigerte Kosten bei Wartung und Instandhaltung, langfristig aber auch für erhebliche Mehraufwände in der Weiterentwicklung, da mit dem Umfang auch die Menge der nötigen Integrations- und Regressionstests, des Bugfixings und des Refactorings steigt.

Zur Behebung dieser Misstände reicht es daher in der Software (anders als im Fall der Hardware) nicht aus einfach die Produktion zu drosseln. Darüber hinaus ist auch ein Rückbau der bereits implementierten Feature-Überproduktion nötig um die negativen Effekte abzustellen. Man zahlt also doppelt, einmal für die Überproduktion selbst, einmal für den Rückbau. Ein Grund mehr, damit gar nicht erst anzufangen.

Scrum-Zertifiziert - und ratlos wie Scrum funktioniert

Bild: Pexels / Bruce Mars - CC0 1.0

Zertifizierungen sind ein grosses Thema. In der Wirtschaft im allgemeinen, in der IT im Speziellen, im agilen Kontext im ganz Speziellen und vor allem im Umfeld von Scrum. Alleine die grössten beiden Organisationen, die Scrum Alliance und Scrum.org haben weltweit mehr als 500.000 Zertifikate für Scrum Master und Product Owner vergeben, dazu kommt eine unklare Nummer von anderen Anbietern wie Scaledagile Inc. (SAFe) oder als deutschem Kuriosum dem TÜV.

Viel Expertise, sollte man denken. So viele Menschen mit bestandenen Prüfungen und (bei einigen Anbietern) regelmässigen Re-Zertifizierungen sollten eine gute Grundlage bilden, basierend auf der viele Unternehmen gekonnt an die Implementierung von Scrum gehen können. Denn wer so ein Zertifikat sein Eigen nennt hat bewiesen, dass er weiss wie man dieses Framework ein- und durchführt - richtig? Nun, leider nein.

Irritierenderweise ist keine der gängigen Zertifizierungen ausreichend um auf die Arbeit in oder mit Scrum vorzubereiten. Nicht nur weil sie lediglich Theorie vermitteln (obwohl schon das ein gewichtiger Punkt ist). Viel wichtiger ist aber ein zweiter: selbst das in den Zertifizierungskursen vermittelte und in den Prüfungen unter Beweis gestellte Wissen bildet nicht vollständig ab was nötig ist um später damit zu arbeiten. Selbst wer es vollständig verinnerlicht hat wird meistens an der Umsetzung scheitern, solange er nicht in grossem Umfang nicht prüfungsrelevanten Stoff verinnerlicht hat.

Dieser hochgradig irritierende Zustand der "zertifizierten Praxisuntauglichkeit" ist kein Zufall. Er ergibt sich zwangsläufig aus dem Zusammenspiel zweier Faktoren. Zum einen aus der Framework-Natur von Scrum und zum anderen aus der (schon vor Scrum existierenden) grundsätzlichen Arbeitsweise der Schulungsindustrie, an die die Zertifizierungsorganisationen die vorbereitenden Kurse ausgelagert haben.

Werfen wir zunächst einen Blick auf den Framework-Charakter. Mit voller Absicht erwähnt der Scrum Guide (das offizielle Regelwerk) zentrale Punkte nicht. Nirgendwo in ihm wird erwähnt wie Abnahmen stattfinden oder warum (und dass) paktisch alle Scrum-Teams Boards benutzen, kein einziges mal geht er auf DoR und User Stories ein, etc. etc. Das bedeutet nicht, dass es unklar wäre wie damit umgegangen werden kann - im letzten Vierteljahrhundert haben sich zahlreiche Best Practices und Good Practices herausgebildet. Da diese in Einzelfällen nicht passend sein könnten stehen sie aber nicht im Scrum Guide. Kennen muss man sie trotzdem.

Als nächstes zur Arbeitsweise der Schulungsindustrie. Es ist nicht so, dass diese die Good Practices und Best Practices nicht vermitteln könnte - sie will es aber nicht. Der Grund dafür ist, dass die üblichen ein- oder zweitägigen Kurse gerade ausreichend sind um die Inhalte des Scrum Guides zu vermitteln. Die umgebenden Kontextinformationen ebenfalls aufzunehmen würde dazu führen, dass aus Tagen Wochen würden. Da das kaum ein Arbeitgeber finanzieren würde bleibt es bei den besser verkaufbaren Kurzveranstaltungen. Umsatz ist hier letztendlich wichtiger als umfassende Wissensvermittlung.¹

In Kombination führen der Frameworkcharakter von Scrum und die Gewinnorientierung der Schulungsindustie zur oben genannten zertifizierten Praxisuntauglichkeit. Sie ist der Grund für das Scheitern zahlloser Scrum-Einführungen und agiler Transitionen, denn da zahlreiche Unternehmen die oben genannten Hintergründe nicht kennen glauben sie, dass mit dem Zertifikat alles nötige Wissen erworben wäre. Sobald die Lücken im Framework auffallen werden diese dann reflexhaft mit Versatzstücken des alten Vorgehens gefüllt, wodurch Agilität meistens unmöglich wird.

Um mit einer positiven Note zu enden - das alles heisst nicht, dass man sich nicht mit dem Scrum Guide beschäftigen sollte. Man kann und sollte es tun. Man kann sein Wissen sogar prüfen lassen wenn man das möchte. Man sollte diese Prüfung nur nicht mit einem "theoretischen Führerschein für Scrum" verwechseln. Das ist sie nicht und das kann sie in der gegenwärtigen Konstellation auch nicht sein.


¹Verständlicherweise, schliesslich sind die Schulungsanbieter private Unternehmen und müssen ihr Einkommen erwirtschaften

Wann finden in agilen Teams Abnahmen statt?

Bild: Pixabay / Tero Vesalainen - CC0 1.0

Zu den vielen Dingen die in den gängigen agilen Frameworks nicht geregelt werden gehören die Abnahmen eines fertigen Produktincrements. Dass sie stattfinden sollten ist naheliegend, zumindest so lange wie es einen Product Manager, Onsite Customer oder Product Owner gibt, der die Anforderung ursprünglich verfasst hat. Wann sie stattfinden soll ist weniger klar.

Was in vielen Teams stattfindet ist scheinbar naheliegend - eine Abnahme in den Review- oder Demonstrations-Meetings, die es nicht nur in Scrum gibt sondern überall dort wo Kunden, Auftraggebern oder Benutzern die Ergebnisse umgesetzter Anforderungen vorgeführt werden. Doch so naheliegend das auch erscheinen mag, eine gute Idee ist es nicht.

Zum einen ist eine Abnahme vor den Augen von Leuten ausserhalb des Teams eine zweischneidige Angelegenheit. Bestenfalls werden sie durch intern wichtige aber für Aussenstehende irrelevante Details gelangweilt (Wurden die Regressionstests aktualisiert? Entspricht die Schriftart dem Corporate Design? Etc.), schlimmstenfalls wird die Abnahme verweigert und sie haben sich umsonst in das Meeting begeben.

Zum anderen nimmt sich ein Team das Abnahmen zu einem so späten Zeitpunkt durchführt ohne Notwendigkeit selbst einen Teil der eigenen Flexibilität. Zur Verdeutlichung: wird ein Ergebnis erst am Ende eines Sprints oder Produktionsszyklus überprüft ist es im Regelfall zu spät um einen festgestellten Änderungsbedarf ohne Planänderungen umzusetzen. Der nächste Sprint, bzw. Zyklus steht ja unmittelbar bevor und muss kurzfristig noch die Nacharbeiten aufnehmen.

Eine bessere Vorgehensweise wäre eine Abnahme sofort nach der Fertigstellung der letzten Arbeit am jeweiligen Increment. Wenn dann unmittelbar eine Vorführung und Überprüfung stattfindet bleibt auch bei entdeckten Fehlern noch genug Zeit für Korrekturmassnahmen, so dass der Zeitplan eingehalten wird und im Review, bzw. Demo-Meeting der Focus da liegen kann wo er hingehört - beim Einsammeln und Diskutieren von Feedback zum fertigen Ergebnis.

Ein häufiger Hinweis an dieser Stelle ist übrigens, dass man Abnahmen doch nicht einfach irgendwann und ohne Meeting durchführen könnte, nur weil es da gerade passt. Die Antwort darauf: doch, das geht auch ohne offizielles Meeting, und ja, gerade dann wenn es passt ist der richtige Zeitpunkt. Ganz ehrlich - wann denn sonst?

A lot of what managers do shouldn't be done

Wenn es um agile Vorzeigeunternehmen geht werden immer die gleichen Beispiele genannt: Google, Facebook, Amozon, Spotify. Eines der unbekannteren aber trotzdem hochinteressanten ist Semco aus Brasilien:



Dass das Video über 10 Jahre alt ist macht die Geschichte übrigens noch beeindruckender, denn nach allem was man hört hat sich diese Firma ihren Geist bis heute erhalten.

Kommentierte Links (XXXXVI)

• Joe Procopio: How To Deliver Software Without Deadlines

  Ein weiterer dieser nur scheinbar selbsterklärenden Begriffe. Genau wie #NoEstimates mehr ist als der Verzicht auf Aufwandsschätzungen ist Dateless Delivery mehr als arbeiten ohne Zieldatum. Joe Procopio geht sogar soweit und sagt, dass es auch hier ein Lieferdatum gibt, nur eben keines das vom Management unverrückbar festgesetzt ist. Stattdessen gibt es einen dynamischen, sich permanent aktualisierenden Forecast, basierend auf kleinen, schrittweisen Auslieferungen, ständigen Risiko-Neubewertungen, Abstimmungen mit Stakeholdern und darauf basierenden Priorisierungs-Anpassungen. Die Frage die sich stellt: tut man diesem hochgradig vernünftigen Vorgehen einen Gefallen wenn man es mit derart missverständlichen Kampfbegriff benennt, oder hätte es nicht auch eine weniger kontroverse Wortwahl getan?
  

• Brett Luckabaugh: The Risk Management Paradox - Enable Your Teams By Giving Up Control

Ein grosses Plädoyer für selbstverantwortliche Teams, mit einer einfachen aber oft vergessenen Offensichtlichkeit: wer Selbstorganisation will muss sie zulassen - auch und vor allem dort wo es wichtig und kritisch ist. Das damit verbundene, scheinbar paradoxe Versprechen: ein Manager der sich dazu durchringt wird am Ende nicht weniger Kontrolle haben sondern mehr, da seine von unrealistischen Vorgaben befreiten Mitarbeiter ihm sorgenfrei alle Einsichten bieten können die sie einem drängelnden und gängelnden Vorgesetzten aus reinem Selbstschutz vorenthalten würden. Wenn es darum geht Selbstorganisation im eigenen Unternehmen zu verkaufen dürfte das eine wesentlich überzeugendere Idee sein als die im letzten Abschnitt genannten plakativen Negationen.

• Ken Schwaber: Look at Capability, not Title

  Möglicherweise die Ankündigung der nächsten Veränderung des Scrum Guide. Gegenstand könnte diesesmal die dritte Scrum-Rolle sein, die des Development Teams, bzw. Entwicklungsteams. Die hier andiskutierte Umbenennung in Delivery Team könnte auf Englisch vielleicht klärend sein, im Deutschen aber zu Verwirrung führen. Wäre "Auslieferungsteam" überhaupt ein Wort, und wenn ja, wäre es eines das erklärbar und verständlich wäre? Gegebenenfalls müsste statt einer Übersetzung der englische Originalbegriff verwendet werden, mit allen damit verbundenen Problemen. Man kann gespannt sein ob (und wenn ja wann) es dazu kommt.
  

• Steve Denning: The Irresistible Rise Of Agile - A Paradigm Shift In Management

  Manchmal könnte man das Gefühl bekommen, dass Steve Denning Agilität fast im Alleingang in Richtung Management Attention geschrieben hat, gegen alle Ablehnung und alle Widerstände. Wie immer ist die Welt vermutlich zu komplex für eine solche Leistung von nur einer Person, aber alleine das in diesem Jahr voll werdende Jahrzehnt journalistischer Begleitung ist eine beeindruckende Bilanz. Die spannende Frage ist jetzt, wie es vom mittlerweile erreichten (scheinbaren?) Gipfel weitergeht. Sowohl in Bezug auf die Popularisierung der Agilität als auch in Bezug auf Dennings Berichterstattung scheint es mittlerweile nicht mehr so, dass noch viel Neues kommen könnte. Vielleicht ist diese Wahrnehmung aber noch zu sehr durch die agile Filterblase geprägt. Unterstellend dass er über diese hinaus Leser erreicht könnte er noch einiges an Artikeln vor sich haben.

• Stefan Kühl: Agile Praktiker

  Apropos Filterblase. Das hier scheint eine Geschichte zu sein die sich in einer zugetragen hat. In irgendwelchen "deutschen Wirtschaftsmedien" soll der amerikanische Systemtheoretiker Talcott Parsons wegen seines AGIL-Schemas (Adaptation - Goal Attainment - Integration - Latency) als "Vorreiter der Agilität" gefeiert worden sein, obwohl sein Werk das gar nicht hergibt. Als im agilen Umfeld gelandeter Geisteswissenschaftler kann ich nur sagen: sollte derartiges irgendwo gestanden haben, dann nur als Orchideenmeldung. Eher könnte es so sein, dass das FAZ-Feuilleton hier genau das versucht was es anderen vorhält - durch simplifiziertes Umdeuten anschlussfähig an Diskurse aus anderen Sachgebieten werden. Agile kommt wirklich im Mainstream an.

Die Paradoxie der agilen Skalierung

Bild: MaxPixel - CC0 1.0

Dass die Koordination, bzw. das Alignment agiler Teams eine der grösseren Herausforderungen ist mit denen man als Manager, Scrum Master oder Product Owner konfrontiert werden kann dürfte mittlerweile Common Sense sein. Chief Product Owner, Release Trains, Tribes, Chapter, Gilden, Integration Teams und Scrum of Scrums sind mittlerweile in fast jedem grösseren Unternehmen zu finden das sich an Agilität versucht, in den meisten Fällen aber nur mit durchwachsenem Erfolg. Es entsteht meistens doch wieder Bürokratie, nur eben eine andere Art davon.

Vor allem in eher traditionell aufgestellten Unternehmen hört man vor diesem Hintergrund immer wieder, dass oberhalb der Team- oder Abteilungsebene wieder mit klassischem Management gearbeitet werden müsste. Agile Ansätze hätten "genug Zeit gehabt sich zu beweisen", wären aber den Nachweis schuldig geblieben, dass sie auch für koordinerte Lieferzyklen von 30, 50 oder noch mehr Organisationseinheiten sorgen könnten.

Auf den ersten Blick ist diese Aussage auch nicht falsch, ab einer bestimmten Grössenordnung (ob die jetzt bei 30, 40 oder 50 Teams liegt ist nebensächlich) werden die oben genannten Skalierungswerkzeuge mit sehr grosser Wahrscheinlichkeit zu Verwaltungs-Overhead führen. Gegenbeweise grosser Gruppen alignter Teams gibt es zwar, aber sie sind eher selten. Doch das ist nicht die ganze Wahrheit. Auf den zweiten Blick kommen auch andere Einsichten zum Tragen.

Korrekt eingesetzt führt der Einsatz agiler Frameworks dazu, dass der Koordinationsaufwand zwischen den Teams sinkt. MVPs und Sprintziele machen grosse Releases fachlich und wirtschaftlich unnötig, CI und CD sorgen dafür, dass sie auch technisch überflüssig sind, crossfunktionale E2E-Teams sind weniger abhängig von anderen Einheiten und müssen nicht mehr koordiniert werden. Zusammengenommen führen diese Faktoren dazu, dass es schlicht keinen Bedarf mehr für agile Skalierung gibt.

Letztendlich ist es eine paradoxe Situation: der Erfolg agiler Zusammenarbeit in grossen Organisationen zeigt sich daran, dass es keine agilen Zusammenarbeitsmodelle auf grosser Ebene gibt. Das klingt un-intuitiv und für viele Verantwortliche erst einmal unglaublich. Diesen Unglauben zu überwinden dürfte eine der zentralen Herausforderungen agiler Skalierungsvorhaben sein.

Hasenbrot-Syndrom

Bild: Pixabay / kalhh - CC0 1.0

Vor langer Zeit habe ich für ein paar Monate in einem Krankenhaus gearbeitet. Unter den vielen Dingen die aus dieser Zeit in Erinnerung geblieben sind sticht eines heraus: die Vorliebe mehrerer älterer Patienten für altes, trockenes Brot, so genanntes Hasenbrot (→ eigentlich zum Verfüttern an die Hasen gedacht). Dass dieses Detail hängengeblieben ist liegt an einer weiteren Begebenheit wenige Jahre später, denn in einem Psychologiebuch an der Universität befand sich eine Erklärung dafür.

Dem Verfasser zufolge führte die Lebensmittelknappheit in den späteren Jahren des zweiten Weltkriegs dazu, dass in vielen Gegenden kaum frisches Brot verfügbar war. Man musste sich mit dem alten, hart gewordenen begnügen. Eine schwierige Situation, der das Unterbewusstsein vieler Menschen mit einer Selbsttäuschung begegnete. Hasenbrot sei doch eigentlich köstlich, redeten die Betroffenen sich ein, man könne froh sein es zu haben. So wurde die Situation erträglicher.

Dieses Phänomen (in der Psychologie spricht man von einem Bestätigungsfehler) setzte sich auch nach dem Krieg fort. Obwohl frisches Brot wieder verfügbar gewesen wäre blieben viele Betroffene bei einer Vorliebe für altes, trockenes. Denn: jetzt davon abzulassen wäre einem Eingeständnis gleichgekommen sich selbst jahrelang belogen zu haben. Bewusst oder unbewusst wurde entschieden diese Lüge aufrechtzuhalten, mit der Konsequenz bis zum Lebensende trockenes Brot essen zu müssen.

Ein derartiges Hasenbrot-Syndrom (so wurde es in dem Buch bezeichnet) kann man auch unabhängig von seinem namensgebenen Objekt vorfinden. Überall dort wo jemand mit belastenden Umständen seinen Frieden gemacht hat kann es dazu kommen, dass er sich selbst vormacht sie unproblematisch oder sogar erstrebenswert zu finden. Je nach Kontext kann das zu grotesken Ergebnissen führen, etwa dazu, dass sogar sinnentleerte, repressive und entmündigende soziale Systeme verteidigt und freiwillig beibehalten werden.

Dort wo gut gemeinte Change-Bemühungen auf derartig begründete Widerstände treffen kann ein weiteres Vorgehen schwierig und schmerzhaft werden. Die Neubewertung einer bisher existierenden Gehorsams- oder Angstkultur als falsch, sinnlos oder unmoralisch kann an Lebenslügen rühren, mittels derer sich die Betroffenen mit den herrschenden Umständen arrangiert haben. Die damit verbundenen Abwehrreaktionen können emotional und heftig sein.

Der Umgang mit solchen Hasenbrot-Syndrom-artigen Widerständen ist schwierig und bewegt sich auf einem schmalen Grad zwischen Fürsorge, gerechtfertigten Eigeninteressen und vorschneller Pathologisierung. Wenn möglich sollte das weitere Vorgehen Menschen überlassen werden die dafür ausgebildet sind.