On Lean and Agility

Bild: Pexels / Sternsteiger Stahlwaren - Lizenz

Eine der kontroverseren agilen Praktiken sind die so genannten "Hardening Sprints", in denen keine neuen Funktionalitäten entwickelt werden, sondern in denen stattdessen die noch fehlenden Restarbeiten erledigt werden, die nötig sind um mit Betrieb, Benutzung, Verkauf, o.Ä. beginnen zu können. Warum sie kontrovers ist? Weil sie dem Anspruch zuwiderläuft, nach jedem Sprint durch Erfüllung der Definition of Done "potentially shippable", also direkt gebrauchsfertig zu sein.

Trotz dieser umstrittenen Natur gehören Hardening Sprints zu den ältesten und langlebigsten Scrum-Praktiken. Bereits 2007 wurden sie vom Scrum-Pioneer Mike Cohn (moch unter dem Namen Release Sprint) als ein übliches Vorgehen beschrieben, zu Beginn der 2010er Jahre waren sie Teil von SAFe, (wo aus ihnen später die Innovation and Planning Iteration wurde) und bis heute werden sie von vielen Teams und Unternehmen vor Releases durchgeführt.

Vermutlich geht die kategorische Verteidigung oder Ablehnung von Hardening Sprints aber ohnehin in die falsche Richtung. Statt dogmatisch auf einer dieser Positionen zu verharren könnte man sich fragen, was in einem solchen Sprint stattfinden könnte, selbst wenn das in der vorherigen Zeit entwickelte Produkt nach jedem Sprint potentially shippable gewesen ist (zur Abgrenzung: um Kontexte in denen kontinuierliches potentially shippable nicht möglich ist geht es hier nicht, das ist ein eigenes Thema).

Refactoring

Es kann vorkommen, dass eine Anwendung funktionierend auf Production deployed ist, ohne dass es unter der Motorhaube durchgehend Clean Code, eingehaltene Benennungskonventionen, konsistente Architektur, o.Ä. gibt. Das kann in einem nachgelagerten Sprint nachgeholt werden, um sicherzustellen, dass auch zukünftig alles verstanden und mit geringem Aufwand erweitert werden kann.

Langlaufende Tests

Es ist zugegebermassen ein Edge Case, aber es in manchen Kontexten (z.B. bei kombinierten Hardware-/Software-Produkten) gibt Last- und Regressiontests, die mehrere Tage lang laufen, und damit gegebenfalls sogar länger als ein Sprint dauert. Diese Tests zu Ende zu führen kann sinnvoll und notwendig sein um sicherzustellen, dass wirklich alles funktioniert.

Löschen von Testdaten

Mitunter können sich an erstaunlich vielen Stellen eines Systems noch Testdaten befinden, was ggf. auch unvermeidbar ist, wenn bis zum letzten Tag des letzten richtigen Sprints noch entwickelt und getestet wird. Ein System vor dem Go Live auf derartige Datensätze fiktiver Produkte, Nutzer, etc. zu durchsuchen, bzw. sie mit Probe-Durchläufen sichtbar zu machen, kann eine gute Idee sein.

Aufspielen von Produktionsdaten

Der umgekehrte Fall. Bei vielen der im Echtbetrieb verwendeten Daten ist es wichtig, dass sie so aktuell und genau wie möglich sind, etwa im Fall von Zahlungs- und Auslieferungsbelegen. Dazu kommt, dass ihre Aufspielung auf Entwicklungs- und Testsysteme oft datenschutz- und haftungsrechlich problematisch wäre. Ihre Übertragung kann eine der Entwicklung nachgelagerte Arbeit sein. 

Monitoring (und ggf. Bugfixing)

Auch nach dem Übertragen aller Funktionen und Daten auf die Produktionsumgebung können noch zu erledigende Arbeiten übrigbleiben. Da sich der echte Livebetrieb nie völlig simulieren lässt, beginnt er oft mit einer "Hypercare"-Phase in der durch intensives Monitoring sichergestellt wird, dass nur dort auftretende Bugs schnell gefunden und behoben werden.

Schulung der Service-Mitarbeiter

Ein in vielen Fällen nicht zu unterschätzender Aufwand ist die Schulung der Service-Mitarbeiter, die für die Betreuung der Anwender einer neuen Software zuständig sind. Gerade wenn agil bin in den letzten Sprint Features entwickelt werden, kann sich das Systemverhalten auch bis zum letzten Entwicklungstag ändern, so dass eine Schulung in einer stabilen Phase sinnvoll sein kann.

User Onboarding

Eine ähnliche, und häufig auf den letzten Punkt aufbauende Tätigkeit. Vor allem bei grossflächig firmeninternen Anwendungen kann es notwendig sein, den Anwendern neuer Funktionen die Möglichkeit zu geben, sie auszuprobieren, Fragen zu stellen und Erklärungen zu erhalten. Das kann ggf. bereits im Echtbetrieb stattfinden.

Natürlich ist diese Aufzählung nicht vollständig. Es sind noch viele weitere Tätigkeiten denkbar, die in einem nach dem Ende der Entwicklung stattfindenden Hardening Sprint stattfinden können, ohne dass es sich dabei um Dinge handelt, die bei Einhaltung der Definition of Done früher hätten erledigt werden müssen. Und mit diesem Wissen im Hintergrund sollte es möglich sein, die Diskussion um derartige Sprints sachlich und undogmatisch zu führen.

Bild: Pexels / Sharath G. - Lizenz

Unter den vielen Arten, den Umgang mit Veränderungen zu strukturieren, gehört es, sich nicht nur eine Grundhaltung zuzulegen, sondern mehrere. Das geht ein bisschen gegen gängige Weisheiten und Faustregeln, die meistens nur eine derartige Haltung empfehlen, wie z.B. kritischen Rationalismus, Bias for Action, Being like a River und viele weitere. Der Wechsel zwischen Haltungen macht aber Sinn, und ich empfehle besonders zwei: Aktivismus und Stoizismus.

Unter Aktivismus versteht man eine Einstellung in deren Rahmen man bewusste Handlungen durchführt, die das Ziel haben, Veränderungen zu fördern, meistens solche, die man persönlich für wichtig oder dringlich hält. Wie diese Veränderungs-Förderung aussieht kann von Fall zu Fall unterschiedlich sein, vom Schaffen eines Sense of Urgency über das Beschleunigen bereits stattfindender Veränderungen bis hin zum Beseitigen von Hindernissen.

Beim Stoizismus dagegen steht im Mittelpunkt die Fähigkeit, gelassen mit Veränderungen umzugehen, vor allem solchen, die sich nicht verhindern lassen. Mögliche Mittel zu diesem Zweck sind die Bewusstmachung der relativen Nichtigkeit und Flüchtigkeit vieler Sachverhalte, das Gegenüberstellen grösserer, von den Veränderungen nicht betroffener Werte und Zusammenhänge, das Einüben von Anpassungsfähigkeit und Resilienz und der Verzicht auf übermässige Emotionalität.

Beide Haltungen haben in bestimmten Kontexten ihren Sinn. Dort wo Veränderungen möglich, aber ggf. schwierig sind, hilft der Aktivismus. Mit ihm kann man ständig neue Impulse setzen, andere überzeugen und ein Zurückfallen in alte Muster vermeiden. Dort wo unerwünschte oder gegenläufige Veränderungen nicht zu verhindern sind, hilft dagegen der Stoizismus gegen Frustration und ergebnisloses Aufreiben im Kampf gegen das Unvermeidbare.

Die entscheidende Frage ist jetzt "nur noch" wann welcher der beiden Kontexte gegeben ist. Das lässt sich natürlich nicht kategorisch beantworten, allerdings kann man mit der Zeit die Fähigkeit entwickeln, Merkmale zu identifizieren, die starke Indikatoren für einen der beiden sind. Diese Erfahrungsweisheit ist der Schlüssel für den situationsgemäss passenden Einsatz von Aktivismus und Stoizismus. Oder mit einem bekannten Stossgebet gesagt:

Gott, gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann,
den Mut, Dinge zu ändern, die ich ändern kann,
und die Weisheit, das eine vom anderen zu unterscheiden.

Reinhold Niebuhr: Gelassenheitsgebet, ca. 1940

Ich bitte um Entschuldigung, aber hier wird jetzt geflucht. Genauer gesagt wird es um Bullshit gehen, die englische (und wesentlich obszönere) Übersetzung des deutschen Wortes Bockmist, und dabei um ein Phänomen, das viel zu selten beachtet wird - das der Bullshit-Artefakte. Gemeint sind damit Hinterlassenschaften und Ergebnisse von Tätigkeiten, die keinen sinnvollen Zweck erfüllen, aber trotzdem aus irgendeinem Grund stattfinden.

Zuerst ein kurzer Blick zurück. Als Schimpfwort existiert Bullshit etwa seit dem ersten Weltkrieg und stammt angeblich ursprünglich aus Australien und Neuseeland. Zu Beginn ein blosser Ausruf der Frustration, wandelte er sich mit der Zeit zu einem Werturteil über eklatant unsinnige Zustände oder Sachverhalte. In dieser Bedeutung erstmalig  umfassend beschrieben wurde er 1986 vom amerikanischen Philosophen Harry G. Frankfurt in seinem legendären Aufsatz On Bullshit.

Aufbauend darauf definierte der amerikanische Anthropologe David Graeber 2018 die Kategorie der Bullshit Jobs, also von Berufen, die ihrem Wesen nach unsinnig oder überflüssig sind, die aber trotzdem in Organisationen vorgeschrieben oder von ihren Inhabern ausgeübt werden. Beispiele dafür sind der Manager, der aussagefreie Statistiken erhebt oder der Büroarbeiter, der nicht wertstiftende oder nicht nachhaltige Tätigkeiten durchführt.

Die Bullshit Jobs haben seitdem einen festen Platz in der Betrachtung grosser Organisationen gefunden, was aber eher wenig betrachtet wird sind ihre Arbeitsergebnisse. Auf den ersten Blick ist das auch unnötig, schliesslich werden sie ja gerade durch ihre Nicht-Wertschöpfung charakterisiert. Auf den zweiten Blick ist eine Beschäftigung damit aber um so dringlicher, schliesslich stellt sich die Frage, ob nicht doch Ergebnisse entstehen, die genauso unsinnig sind wie die Tätigkeiten.

Und tatsächlich ist genau das der Fall. Zwar entsteht kein nutzbarer Mehrwert, dafür aber Hinterlassenschaften (organisationssoziologisch: Artefakte), verschiedener Art. Diese sind sogar noch kritischer zu betrachten, als man denken könnte, denn nicht nur werden bei ihrer Erstellung Zeit und Ressourcen verbraucht, sie sind häufig auch Ausgangspunkt für weitere, ebenso wenig wertvolle Tätigkeiten, die wiederum weitere derartige Hinterlassenschaften erzeugen, etc.

Bei genauerer Betrachtung lassen sich zwei Typen derartiger Bullshit-Artefakte erkennen. Bei der ersten handelt es sich um die Ergebnisse von Sinnlos-Tätigkeiten. Beispiele dafür sind von niemandem angeforderte und von niemandem gelesene Berichte, die Einhaltung irrelevanter Formatierungen (z.B. der alphabetischen Anordnung von Email-Empfängern) oder das Ausdrucken, Stempeln und wieder Einscannen von Formularen. Schwierig wird das, wenn es zur Vorschrift wird, die alle erfüllen müssen.

Der zweite Typ liegt vor, wenn eigentlich sinnvolle Tätigkeiten mit Sinnlos-Prozessen überzogen werden. Beispiele dafür sind (schein-)genaue Aufwandsschätzungen in volatilen Markt- oder Technik-Umfeldern, die übergreifende Priorisierung aller Aufgaben in Unternehmen, in denen die Teams so spezialisiert sind, dass sie die höher priorisierten Aufgaben im Zweifel gar nicht übernehmen können, oder die Erstellung von Fortschrittsberichten auf Basis unfertiger Arbeitspakete.

Besonders der zweite Typ kann in immensem Ausmass Bullshit-Folgetätigkeiten nach sich ziehen, nämlich dann, wenn versucht wird, die Realität an die Inhalte des jeweiligen Bullshit-Artefakts anzupassen. Das geschieht in derartigen Kontexten nämlich meistens durch noch mehr Bullshit Jobs, also durch weitere unrealistische Aufwandsschätzungen, weitere nicht umsetzbare Priorisierungen, weitere aussagefreie Fortschrittsberichte, etc.

Wichtig beim Gegensteuern gegen derartige Verhältnisse ist übrigens, bei der Wurzel anzufangen. Dort wo sich Bullshit-Artefakte häufen, wird es nur wenig helfen, auf eine bessere Qualität der offensichtlich unsinnigen Berichte, Priorisierungen, Schätzungen, etc. zu dringen. Die erfolgversprechendste Methode ist die ersatzlose Abschaffung der dahinterliegenden Bullshit Jobs. Mit ihnen verschwinden dann auch die von ihnen produzierten unsinnigen Ergebnisse.

In Frankreich und Deutschland hat die Passage "Passierschein A38" aus dem Film Asterix erobert Rom es geschafft, sprichwörtlich für die Exzesse überbordender Verwaltungsappareate zu werden, die die Betroffenen durch nicht enden wollende Bürokratie in den Wahnsinn treiben. Mittlerweile kann man sich durchgehend an ihr erfreuen, denn der Rechte-Inhaber Canal+ hat sie auf Youtube veröffentlicht.

Ein häufiger unterschätzter, die Realität gut darstellender Seitenaspekt ist dabei, dass die Bürokraten selbst keineswegs Teil einer sinistren Verschwörung sind, sondern eigentlich normale Menschen, die nur irgendwann durch die sie umgebenden absurden Abläufe abgestumpft wurden, und die ihnen gegebenenfalls ebenfalls als Betroffene ausgeliefert sind.

Bild: Unsplash / Alex Mihai C - Lizenz

Wer Methoden und Techniken einsetzt, die in einer anderen Sprache entwickelt wurden, wird das Phänomen kennen: nicht alles ergibt für einen intuitiv den Sinn, den ein Muttersprachler einfach erfassen könnte, viele Bedeutungen müssen nachgeschlagen werden, und an einigen Stellen kommt es vor, dass man erst zu spät herausfindet, irgendetwas falsch verstanden zu haben. Das ist auch bei den verschiedenen agile Frameworks nicht anders.

Ein Problem das dabei für Nicht-Muttersprachler immer wieder auftreten kann, ist die mögliche Mehrdeutigkeit der Begriffe. Besonders bei denjenigen, die vorher unbekannt waren, besteht das Risiko, dass sie nur der einen Bedeutung zugeordnet werden, mit der man sie zu Beginn kennengelernt hat. Im Folgenden kann es schlimmstenfalls zu einem so eingeengten Begriffsverständnis kommen, dass weitere Bedeutungen abgelehnt werden, selbst dann wenn sie ebenfalls richtig sind.

Ein häufig anzutreffendes Beispiel für dieses Phänomen ist das Committment, das vor allem in Scrum eine zentrale Bedeutung hat. hier aber in gleich zwei Bedeutungen vorkommt. Zum einen als einer der Scrum-Werte, der sich übersetzen lässt als die ständige Anstrengung, gute Arbeit abzuliefern, zum anderen als Teil der drei Artefakte Product Backlog, Sprint Backlog und Increment, bei denen es sich um konkrete Umfangs- und Qualitätsbeschreibungen von Zielen und Ergebnissen handelt.

Je nachdem welche dieser Bedeutungen man zuerst gelernt hat, wird man (unter der Voraussetzung, dass man sich die andere mittlerweile nicht auch angeeignet hat) eine sehr einseitige und unvollständige Idee davon haben, wofür das Committment in Scrum steht. Entweder man wird es als einen anspruchsvollen aber abstrakten Anspruch verstehen oder als eine konkrete Beschreibung von Ziel- und Liefergegenstand-Eigenschaften, die die Ausgangsbasis für Planungen und Erfolgskontrollen bildet.

Derartige Beispiele lassen sich immer wieder finden. Eine Policy kann z.B. in Kanban ein Kriterien-Katalog sein, der zu erfüllen ist, bevor eine Aufgabe in den nächsten Status bewegt werden kann, es kann aber auch jegliche andere Regel oder Strategie sein. Ready kann je nach Kontext bedeuten, dass man die Arbeit an etwas beginnen kann, oder dass die Arbeit an etwas abgeschlossen wurde. Ein Planning kann am Anfang eines Sprints stattfinden, aber auch für Einzelaufgaben durchgeführt werden. Etc., etc.

Der beste Weg, sich vor derartigen Begriffsverengungen und den daraus folgenden Missverständnissen zu schützen besteht natürlich darin, die Sprache zu lernen, in der das jeweilige Vorgehen ursprünglich entwickelt wurde. Im Fall der verschiedenen agilen Ansätze ist das fast ausnahmslos (amerikanisches) Englisch und im Fall von Lean Management japanisch, im Fall von einzelfallspezifischen Vorgehensmodellen können auch weitere dazukommen, etwa spanisch oder holländisch.

Für alle, denen dafür Zeit, Geduld oder Veranlagung fehlen, gibt es aber noch eine zweite Möglichkeit: das Zeigen von Demut und Neugier. Demut in dem Sinn, dass man sich ständig bewusst macht, bei der Durchdringung aller Begrifflichkeits-Nuancen Defizite zu haben, und Neugier dahingehend, dass man ständig überprüft, ob es nicht noch weitere Bedeutungen gibt, die einem bisher entgangen sind.

Grafik: Pixabay / Brian Penny - Lizenz

Russ Miles: A Myth of Progress

Petra Wille: Why It’s Time to Forget the Project vs. Product Operating Model Debate

Gene Kim: A Patient Advocate's Guide to Navigating A Hospital System

Maarten Dalmijn: The Best Product Managers Optimize For Reversibility and Optionality

Sean Goedeke: How I influence tech company politics as a staff software engineer

Eigentlich sind Projekt- oder Produktmanagement-Methoden per se unpolitisch, da sie (bzw. ihre Anwender) aber Teil der Gesellschaft sind, schwappen gesellschaftliche Debatten aber immer wieder herüber in den Methodendiskurs. Eine dieser Debatten dreht sich um den vielleicht bekanntesten Titel aller agilen Frameworks, den Scrum Master oder Agile Master, der in Scrum, SAFe, LeSS, Disciplined Agile und ähnlichen Ansätzen eine zentrale Rolle spielt. Aber worum geht es dabei?

Im Englischen hat der Begriff des "Master" eine Dimension, die der deutsche "Meister" nicht hat, nämlich die des Sklavenhalters (siehe hier), die sich in sprichwörtlichen Gegensatzpaaren wie Master and Slave oder Master and Servant bis heute gehalten hat. Seit mehr als zehn Jahren wird daher darüber diskutiert, ob der Scrum Master nicht bedenkliche Stereotype reproduziert und abgeschafft werden sollte (siehe beispielsweise hier, hier, hier, hier und hier).

Wichtig für das Verständnis dieser Debatte ist, dass es in der IT tatsächlich Begriffe gibt, die einen derartig problematischen Hintergrund haben. Am bekanntesten dürfte die Verwendung von Master und Slave für steuernde und gesteuerte Systeme sein, ebenfalls verbreitet sind "Whitelist" und "Blacklist" für gewährte und verwehrte Systemzugänge. Diese Verwendungen werden von immer mehr Firmen zugunsten neutralerer Benennungen aufgegeben (siehe hier).

Das in Frage stellen des Scrum Master- bzw. Agile Master-Titels ist vor diesem Hintergrund zu sehen. Er tritt im Arbeitsalltag sehr häufig zusammen mit den gerade genannten problematischen Benennungen auf, wird deshalb mitunter auf die selben Hintergründe zurückgeführt und deshalb gemeinsam mit ihnen in Frage gestellt. Die Frage, die sich aufbauend darauf stellt: ist der Ursprung tatsächlich der Gleiche, oder ist es eher ein anderer, weniger problematischer?

Um diese Frage zu beantworten wären Aussagen von Ken Schwaber und Jeff Sutherland, den Erfindern der Scrum Master-Rolle am besten geeignet, die sich allerdings online nicht auffinden lassen. Was es dagegen gibt, sind Sekundärquellen auf Scrum.org, der von Schwaber gegründeten Zertifizierungs-Organisation, die dort wohl kaum stehen bleiben würden, wenn sie ihm Falschaussagen unterstellen würden. Und aus ihnen ergibt sich eine andere Herkunftsgeschichte (siehe hier und hier).

Der Ursprung des Rollen-Titels ist ihnen zufolge, dass das für die Methodik zuständige Teammitglied diese in allen wesentlichen Aspekten kennen und beherrschen sollte. Bewusst wird dabei von Schwaber und Sutherland die Parallele zum Handwerks-Meister (genauer gesagt zum Master Carpenter, also zum Schreinermeister) gezogen, der zuerst sein Können über längere Zeit unter Beweis stellen musste, bevor er diesen Titel führen durfte.

Der Entstehungshintergrund ist damit ein völlig anderer als bei den oben genannten Master/Slave oder Whitelist/Blacklist-Begriffspaaren. Er entspricht eher dem Status der aus langer Übung errungenen Meisterschaft, der auch im Englischen eine positive Bedeutung hat und neben dem Handwerksmeister z.B. auch im Schachgrossmeister (Grand Master of Chess) oder in dem (fiktiven) Jedi-Meister aus den Star Wars-Filmen gefunden werden kann.

Dieser Hintergrund in der Ausübungs-Meisterschaft bedeutet übrigens ganz nebenbei auch, dass eine solche Rolle eigentlich nicht geeignet ist, von Berufs- oder Quereinsteigern ausgeübt zu werden. Das aber ist nochmal ein ganz eigenes Thema.

Kommen wir noch einmal zurück zum Thema Virtue Signaling, also zum demonstrativen öffentlichen Kommunizieren von Standpunkten, die als moralisch gut oder sogar überlegen wahrgenommen werden. In der agilen Community ist dieses Verhalten sehr stark ausgeprägt, sowohl als Zeichen der Überlegenheit des eigenen Vorgehens gegenüber "traditionellen" Ansätzen (v.a. Wasserfall), als auch gegenüber falsch verstandenem agilen Arbeiten (so genanntem Cargo Cult). 

Auf den ersten Blick ist das auch naheliegend: wenn der eigene Ansatz nun mal als effektiver, effizienter, wirtschaftlicher und humaner empfunden wird, dann kann man das auch sagen, und wenn es darüber hinaus dazu führt, dass man dadurch einfacher in der Lage ist, Gleichgesinnte zu finden und von ihnen gefunden zu werden - um so besser. Die so entstandenen Erfahrungsaustausch- und Unterstützungs-Netzwerke sind für ihre Mitglieder wertvoll und hilfreich.

Das Problem, das dadurch entstehen kann, ist aber, dass sich andersdenkende Menschen ausgeschlossen oder im schlimmsten Fall sogar auf ungerechte Weise herabgesetzt fühlen können. Auch unter den Anwendern von Prince2, SAFe und weiteren nicht- oder halb-agilen Methoden wird die Mehrheit mit den besten Absichten (und oft sogar mit Erfolg) zur Arbeit gehen. Sich ständig anhören zu müssen, dass nur ein anderes Vorgehen das einzig Wahre ist, kann schnell verletzend wirken.

Alleine die auf diese Art aufgerissenen Gräben zwischen den ständig Virtue Signaling betreibenden Anhängern des agilen Arbeitens und den sich unfair behandelt fühlenden Vertretern klassischer und hybrider Ansätze können bereits zu unnötigen Konflikten, nicht zielführenden Grundsatz-Diskussionen und einem gestörten Betriebsklima führen, im schlimmsten Fall kann die Situation aber auf unschöne Weise noch stärker eskalieren, wenn es nämlich zu einer Gegen-Überreaktion kommt.

Aus politischen Debatten ist das Phänomen des Vice Signaling bekannt, also des Konterns des Virtue Signaling durch das Einnehmen bewusst überspitzter oder übertriebener Gegenpositionen. In gewisser Weise handelt es sich dabei um kollektive Reaktanz, also um den Versuch, einer gefühlten Bedrohung des eigenen Freiheits-Spielraums dadurch entgegenzuwirken, dass er vorsorglich über das notwendige Mass hinaus ausgedehnt wird, so dass er selbst bei einer Einschränkung noch hinreichend gross bleibt.

Sobald sich eine Debatte einmal in einer Wechselwirkung (oder sogar einer Eskalationsdynamik) zwischen agilem Virtue Signaling und nicht-agilem Vice Signaling verfangen hat, ist konstruktives Arbeiten kaum noch möglich. Im schlimmsten Fall verlagern sich die Auseinandersetzungen dann sogar auf eine identitätspolitische Ebene, auf der andersdenkenden Menschen nur aufgrund ihrer Meinung charakterliche oder kognitive Defizite unterstellt werden. Der Diskurs ist dann nachhaltig vergiftet.

Um es nicht dazu kommen zu lassen, kann es sinnvoll sein, das Virtue Signaling in einem überschaubaren Rahmen zu halten - auch und gerade dann wenn man sich selbst absolut im Recht fühlt. Statt das eigene Vorgehen kategorisch zu überhöhen kann man sachlich darlegen, aufgrund welcher Faktoren es in welchen Rahmenbedingungen welche erkennbaren Vorteile im Vergleich zu anderen Methoden bringt. Das Risiko, dass Konflikte entstehen, wird so deutlich geringer ausfallen.

Und der Vollständigkeit halber: natürlich kann es auch Situationen geben, in der das Virtue Signaling von klassisch sozialisierten Projektmanagern ausgeht und das Vice Signaling von überreagierenden Agilisten. Es gibt keine Gruppe, die gegen derartige Fehltritte immun ist. Umso wichtiger ist es, das eigene Verhalten regelmässig kritisch auf den Prüfstand zu stellen.