Kommentierte Links (CXXXII)

Grafik: Pixabay / Brian Penny - Lizenz

Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Russ Miles: A Myth of Progress

Der Untertitel dieses Artikels fasst gut zusammen, worum es Russ Miles geht: On hype cycles and how to break them by focussing on human needs. Er vergleicht die Versprechen und Befürchtungen rund um Künstliche Intelligenz mit vergangenen Hypes, erkennt vieles wieder und arbeitet Gemeinsamkeiten heraus. Praktisch ist dabei eine Checkliste am Ende, mit deren Hilfe man überprüfen kann, ob man gerade einem Hype aufsitzt und wie man sich davon befreit.

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

Ein weiterer Beitrag zur ewigen Produkt vs Projekt-Debatte, die mittlerweile schon seit mindestens zwei Jahrzehnten durch Blogs und Konferenzen wabert. Diesesmal zumindest eine, die sich nicht in den rhetorischen Schützengraben begibt, sondern differenziert einordnet. Denn was Petra Wille hier beim Namen nennt, sollte eigentlich Common Sense sein - es geht nicht um ein entweder/oder sondern um ein sowohl als auch, bzw. um die Frage, was gerade besser zum Kontext passt.

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

Was passiert, wenn die Frau eines Prozessmanagement-Experten ins Krankenhaus eingeliefert wird? Er beginnt die um sie herum stattfindenden Abläufe zu analysieren, um dafür sorgen können, dass sie in der bestmöglichen Art und Weise genutzt werden. Herausgekommen ist dabei dieser bemerkenswerte Erfahrungsbericht des DevOps-Experten Gene Kim, der zwar sicher etwas USA spezifisch, aber trotzdem hochinteressant zu lesen ist.

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

Ein Drama an dem man immer wieder in IT-Projekten vorbeikommt sind Entscheidungen, die sich aus technischen Gründen kaum rückgängig machen lassen, selbst wenn sie sich als falsch herausstellen. Maarten Dalmijn zieht daraus den einzig sinnvollen Schluss: wenn der richtige Weg nicht sicher ist, sollte man sich keine Optionen derartig verbauen, sondern sich immer die Möglichkeit offen lassen, Features wieder ausbauen zu können.

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

Zum Schluss ein Gedankenanstoss von Sean Goedeke, der einer häufigen Annahme widerspricht - auch als einfacher Softwareentwickler der untersten Hierarchiestufe kann man strategische Entscheidungen im eigenen Sinn beeinflussen - wenn man weiss wie grosse Organisationen funktionieren und sich das zu Nutze macht. Mit anderen Worten: man braucht Systemsicht, Vorbereitung und Reaktionsfähigkeit.

Master

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.

Virtue Signaling (II)

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.

Steering Committees und Advisory Boards

Bild: Harris & Ewing / Library of Congress - Public Domain

Manche Dinge schliessen sich gegenseitig aus: Feuer und Wasser, Licht und Dunkelheit, Materie und Antimaterie, Selbstorganisation und Steering Committees. Soviel zum leicht polemischen Einstieg, hinter dem aber ein reales Problem steckt - das klassische Management-Instrument des Steering Committee kollidiert alleine aufgrund seiner Natur zwangsläufig mit allen Formen des Empowerment und der Selbstorganisation. Aber zum Glück gibt es eine Alternative.

Zunächst zur Definition: ein Steering Committee (auch Steuerungskreis, Lenkungsausschuss, o.Ä.) ist im klassischen Projektmanagement ein Gremium, das das übergeordnete Entscheidungen für ein einzelnes Projekt oder Programm treffen darf und soll. Wie das im Detail aussieht kann sich je nach Fall unterscheiden, weit verbreitet ist aber, dass Umfang, Qualität, Wirtschaftlichkeit und Zeitplan eines Projekts kontrolliert und ggf. durch Eingriffe korrigiert werden.

Die dahinter stehende Grundidee ist auch erst einmal vernünftig: grössere Projekte sind meistens derartig komplex, dass einzelne Personen kaum in der Lage sind, alle Dimensionen zu überblicken. Durch die Bildung eines Steering Committee aus verschiedenen Experten (z.B. Finance, Marketing, Sales, Legal, IT, Quality, Strategy und Customer Care) werden sie dagegen in der Breite abgedeckt - in gewisser Weise wird die Projektleitung dadurch crossfunktional, was eigentlich etwas Gutes ist.

Ein in der Realität immer wieder auftretende Ergebnis ist aber, dass durch derartige Einheiten Verzögerungen, Kosten und Qualitätsverluste entstehen. Zum einen wegen des Zeitaufwandes, der alleine dadurch entsteht, dass jedem Mitglied alle Informationen mitgeteilt und verständlich gemacht werden müssen, zum anderen aber auch dadurch, dass die im Kommittee versammelten Spezialisten gegenläufige Interessen haben und versuchen, sie durchzusetzen.

Die Beispiele kann man sich denken - der Finance-Vertreter möchte durch möglichst günstige Material- und Personal-Preise Kosten sparen, der Quality-Vertreter hätte dagegen gerne die besten (und dadurch teuersten) Werkstoffe und Teammitglieder. Der Sales-Vertreter möchte neue Features  möglichst schnell verkaufen, die Vertreter von IT und Operations möchten dagegen zuerst technische Schulden abbauen und eine hohe Betriebsstabilität sicherstellen. Etc., etc.

Das Bemerkenswerte an solchen Situationen ist, dass keines dieser Anliegen falsch ist. Für sich genommen sind sie sogar in der Regel hoch rational, wie oben gezeigt aber oft untereinander gegenläufig. Da aber jeder Spezialist aus dem Steering Committee zuerst seine Partikular-Interessen vertritt (was auch Teil seiner Stellenbeschreibung ist), führt das entweder zu Streit untereinander oder zu einer in Summe völlig unrealistischen Erwartungshaltung an das Umsetzungsteam.

Wenn dieses Umsetzungsteam dann auch noch selbstorganisiert sein soll, sind alle Voraussetzungen für eine weitgehende und dauerhafte Blockade gegeben. Sowohl der Versuch, es von aussen zu steuern, als auch die widersprüchlichen Signale in welche Richtung es gesteuert werden soll, führen zusätzlich zu den gegenläufigen Interessen innerhalb des Kommittees zu einem Konflikt zwischen Steuerung und Umsetzung, bzw. darum, bis zu welchem Grad sich das Umsetzungsteam überhaupt steuern lassen muss.

Aus diesem Dilemma gibt es mehrere Wege. Der (zumindest in grossen Organisationen) häufigste ist der, dass im Konfliktfall eine stärkere Führung angeordnet wird, was in den meisten Fällen ein Euphemismus für Micromanagement durch das Lenkungsgremium ist. Das beseitigt zwar den Konflikt mit dem (ab diesem Punkt nicht mehr) selbstorganisierten Umsetzungsteam, lässt die gegenläufigen Interessen innerhalb des Steering Committee aber weiter bestehen.

Ein wesentlich besserer Weg besteht darin, das Steering Committees zu einem Advisory Board (Beratungsgremium) zu machen, dass die Expertise seiner Mitglieder zwar weiter anbietet, aber keine zwingend zu befolgenden Vorgaben mehr machen kann. Einen vernünftigen Mittelweg zwischen den verschiedenen Einzelinteressen zu finden, obliegt dann dem empowerten und (teil-)autonomen Umsetzungsteam (bzw. dessen Projektleiter, Product Owner, o.Ä.).

Das wird vor allem dann möglich, wenn in diesem Rahmen darauf verzichtet wird, die einzelnen Mitglieder des Beratungsgremiums dafür verantwortlich zu machen, dass sie ihre Maximalvorstellungen umsetzen. Wird nicht darauf verzichtet, ist das ein starker Anreiz dazu, sie durch Eskalationen, Katastrophenszenarien, o.Ä. durchdrücken zu wollen. Wird dagegen darauf verzichtet, können sie ihren Standpunkt noch immer vermitteln, allerdings mit deutlich weniger Drama und Emotion.

Eine solche Konstellation bringt natürlich weitere Implikationen mit sich, von denen nicht alle unproblematisch sind. Wenn Umfang, Qualität, Wirtschaftlichkeit und Zeitplan eines Projekts nicht ausser Kontrolle geraden sollen, ist ein starkes Team mit unterstützendem Advisory Board aber erfolgversprechender als ein Steering Committee, in dem Vertreter starker Partikular-Interessen sich gegenseitig blockieren und widersprüchliche Umsetzungsvorgaben machen.

Immerschlimmeritis und Verbesserungsoptimismus

Es gibt Begriffe, die komplexe Sachverhalte prägnant auf den Punkt bringen, und einer davon ist gerade neu erfunden worden: die Immerschlimmeritis. Gemeint ist damit der Glaube, dass sich die Verhältnisse denen man ausgesetzt ist permanent verschlechtern - auch wenn in Wirklichkeit das Gegenteil der Fall ist. Geprägt hat ihn der Ökonom Georg Cremer, VWL-Professor an der Universität Freiburg, in einem Zeit-Artikel über Falschwahrnehmungen der Vermögensentwicklung in Deutschland.

Die spannende Frage ist jetzt, wie es zu einer derartigen, nicht der Realität entsprechenden Immerschlimmeritis kommen kann, und tatsächlich gibt es darauf sogar eine wissenschaftlich fundierte Antwort. Der berliner Soziologie-Professor Stefan Liebig (auf dessen Forschung Cremer seine Analyse aufbaut) hat das Phänomen untersucht und kommt zu der Erklärung, dass sich Einstellungen nur träge an veränderte Trends anpassen. Aber was heisst das?

Wenn sich Verhältnisse über eine längere Zeit in eine bestimmte Richtung entwickelt haben, gehen die betroffenen Menschen unbewusst davon aus, dass das mit einer gewissen Zwangsläufigkeit geschieht und aufgrunddessen auch so weitergehen muss. Wenn es also über längere Zeit zu Stagnationen oder Verschlechterungen gekommen ist, werden neu auftretende Verbesserungen nicht als solche erkannt oder lediglich für temporäre Abweichungen von einer dauerhaften Tendenz gehalten.

Wer schon einmal Veränderungsmanagement in grösseren Organisationen betrieben hat, wird jetzt vermutlich ein Deja-vu haben - selbst spürbare Verbesserungen werden in derartigen Kontexten oft nicht als solche anerkannt oder es wird ihnen eine dauerhafte Wirksamkeit abgesprochen. Diese Grundhaltung lässt sich in vielen Fällen anhand von Liebigs Modell mit der unbewussten Fortschreibung vorhergegangener langfristiger Stagnations- und Verschlechterungs-Erfahrungen erklären.

Diese Erklärung ist zunächst einmal frustrierend, bedeutet sie doch, dass Erfolge und Verbesserungen trotz spürbarer Effekte als vergebliche Mühen und sinnlose Aufwände betrachtet werden können, was im schlimmsten Fall zur Folge haben kann, dass sogar erfolgreiche Veränderungsvorhaben wegen einer irrtümlich wahrgenommenen Wirkungslosigkeit beendet oder sogar rückgängig gemacht werden können. Allerdings gibt es auch eine positive Deutung.

Wenn es gelingt, über einen längeren Zeitraum kontinuierliche Verbesserungen aufzuzeigen, dann kann die verzögerte Anpassung von Einstellungen an veränderte Trends zu einem verstärkenden Faktor von Verbesserungsvorhaben werden - die wiederholten derartigen Erfahrungen führen dann zu einem strukturellen Verbesserungsoptimismus, der spiegelbildlich zur Immerschlimmeritis dafür sorgt, dass die Beteiligten davon ausgehen, dass sich die Lage im Zweifel immer weiter verbessern wird.

Für das Veränderungsmanagement in grösseren Organisationen bedeutet das auf den Punkt gebracht, dass es sich lohnt, einen langen Atem zu haben und sich von anfänglicher fehlender Anerkennung nicht entmutigen zu lassen. Denn wenn kontinuierliche Verbesserungen gelingen, dann kann irgendwann die Zustimmung ähnlich stark werden wie zu Beginn die Ablehnung. Und das ist doch ein Ziel auf das es sich lohnt hinzuarbeiten.

Flooding the Zone (II)

Bild: Wikimedia Commons / Katsushika Hokusai - Public Domain

Noch einmal einige Gedanken zum Flooding the Zone, also zu einem derartigen Überladen einer Diskussion mit Themen, dass es nicht mehr möglich ist, sich auf eines davon zu konzentrieren um es auszudiskutieren oder zu einer Massnahme oder Lösung zu kommen. In sehr vielen Fällen ist dieses Phänomen ein Ausdruck einer destuktiven Einstellung, es gibt aber auch Fälle, in denen es stattfindet ohne dass eine negative Absicht dahintersteht.

Eine häufige Ursache dafür ist, dass ein Gesprächsteilnehmer seit langem keine Möglichkeit mehr gehabt hat, seine Einwände oder Bedenken vorzubringen (weil das von anderen unterbunden wurde, weil er nicht in die dafür geeigneten Termine eingeladen wurde, weil er erst seine Introvertiertheit überwinden musste - es kann viele Gründe dafür geben). Ihn dann darum zu bitten kann einen Dammbruch zur Folge haben, der erstmal alles an die Oberfläche bringt was sich aufgestaut hat. 

Eine anderer Grund kann sein, dass der Gesprächsteilnehmer die Erfahrung gemacht hat, dass er im Durchschnitt nur ein- oder zweimal pro Meeting zu Wort kommt, z.B. weil die strukturell mit Themen überladen sind oder mit zu vielen Teilnehmern stattfinden. In derartigen Fällen hat er einen starken Anreiz, sofort alles vorzubringen, was irgendwann im Gespräch wichtig werden könnte, da er nicht sicher sein kann, ein zweites mal die Gelegenheit dazu zu haben.

Eine dritte mögliche Ursache ist, dass durch solche Momente Probleme der Unternehmenskultur sichtbar werden. Wenn z.B. dem ersten, der ein konfliktlastiges Thema anspricht, sein Standpunkt am meisten geglaubt wird, dann kann das einen Wettlauf zum Mikrofon mit anschliessendem thematischem Rundumschlag zur Folge haben. Das ist im übrigen auch dann das Ergebnis, wenn dieses Kulturproblem gar nicht existiert, es aber irrigerweise unterstellt wird.

Abhängig davon, welche dieser Konstellationen gegeben ist (was sich allerdings nicht immer einfach herausfinden lässt) sind verschiedene Herangehensweisen sinnvoll, um das Flooding the Zone in den Griff zu bekommen. Sinnvoll ist in jedem Fall eine vorher gemeinsam Agenda, bei der den einzelnen Themen realistische Zeiträume zugeordnet sind (womit auch klar ist, worüber nicht geredet wird). Mit Berufung darauf lassen sich zeitlich oder inhaltlich ausufernde Beiträge einfacher abmoderieren.

Ebenfalls hilfreich ist es, wegmoderierte Themen öffentlich sichtbar zu "parken", z.B. auf einer Wand mit entsprechend beschrifteten Post Its oder Moderationskarten. Dadurch wird denjenigen, die sie eingebracht haben, die Sorge genommen, dass sie unter den Tisch fallen könnten. Ggf. kann am Ende des Termins sogar schon festgelegt werden, wann diese Themen stattdessen behandelt werden, auch in welchem Umfang und mit welcher Reihenfolge.

Das meiste Fingerspitzengefühl ist nötig, wenn das Flooding the Zone auf eine problematische Unternehmenskultur zurückgeht. Ein einigermassen erfolgsversprechendes Mittel in derartigen Fällen ist es, die nicht in der Agenda vorgesehenen Debatten konsequent aus der Ergebnis-Dokumentation herauszuhalten, wodurch ein derartiges Verhalten seinen Mehrwert verliert. Um so wichtiger ist in solchen Fällen der Verweis auf einen späteren Zeitpunkt für die Besprechung.

Erfahrungsgemäss kann diese Art, mit zeitlich und inhaltlich ausufernden Wortbeiträgen umzugehen, nach und nach zu einer Verbesserung führen, selbst wenn es zu Beginn eine Zeit lang zu Unzufriedenheit und Widerspruch kommt. Man muss sich dabei aber bewusst machen, dass ein derartiges Verhalten in der Regel über eine längere Zeit entstanden ist, und es dadurch auch entsprechend dauern kann, bis es wieder verschwunden ist.

Ein Bild sagt mehr als 1000 Worte (LII)

Grafik:Forrest Brazeal - CC BY-NC-ND 4.0

Tech Debts VS More Features

Nachdem ich dieses Video in den letzten Monaten immer wieder zugeschickt bekommen habe, ist es höchste Zeit, es auch hier einzubinden. Keine Ahnung ob KI-generiert oder nicht, den Urhebern ist damit ein kleines Kunstwerk gelungen.

Und falls der Inhalt irgendjemandem zu weit hergeholt vorkommen sollte - es lohnt sich, das Video jemandem zu zeigen, der in einer grossen IT-Organisation arbeitet. Mit grosser Wahrscheinlichkeit wird er sagen, dass ihm das Ganze sehr bekannt vorkommt.

Prescott's Pickle Principle

Bild: CCnull /  Tim Reckmann - CC BY 2.0

Nachdem es hier schon länger keine Besprechung eines "Management-Gesetzes" mehr gab, ist hier ein besonders schönes: Prescott's Pickle Principle, geprägt 1985 vom Informatiker und Unternehmensberater Gerald M. Weinberg in seinem Buch The Secrets of Consulting, in dem er zahreiche derartiger halb ernstgemeinter Gesetzmässigkeiten gesammelt und z.T. mit selbst erfundenen Ursprungsgeschichten versehen hat. Ein derartiges, nach dem fiktiven Lebensmittelhändler Prescott benanntes Gesetz lautet:

Cucumbers get more pickled than brine gets cucumbered.

Gerald M. Weinberg: The Secrets of Consulting; S. 72

Die zugrundeliegende Idee ist gewissermassen aus der Mengenlehre abgeleitet: die Flüssigkeit in einer Gurke (Cucumber) ist so viel weniger als die im umgebenden Essigglas, dass im Endprodukt der Essiggurke vor allem der Geschmack von Essig (Brine) übrigbleibt, und nur wenig Gurkengeschmack. Dieses Phänomen übertrug Weinberg als ein plastisches Bild auf die Tätigkeit, mit der er beruflich grossteils beschäftigt war - das Change Management.

 

Übertragen auf Veränderungsprozesse beschrieb er damit das häufige Phänomen, dass Personen, die in eine Organisation geholt werden um neue Impulse einzubringen, sich nach und nach durch Kompromisse, Sachzwänge, Unternehmenspolitik und andere Faktoren an den ursprünglich vorherrschenden Zustand anpassen, bis sie irgendwann zu einem Teil von ihm geworden sind und aufgrunddessen keine Veränderungsimpulse mehr setzen können. Sachlicher ausgedrückt:

A small system that tries to change a big system through long and continued contact is more likely to be changed itself

Gerald M. Weinberg: The Secrets of Consulting; S. 73

Diese Betrachtungsweise mag zunächst pessimistisch oder sogar defätistisch wirken, da man sie so verstehen kann, dass am Ende alle Veränderungsvorhaben zum Scheitern verurteilt sind. Das allerdings würde weit an Weinbergs Interntion vorbeigehen, der genau die gegenteilige Aussage treffen wollte: Veränderungen sind möglich, allerdings nur dann, wenn man sich der Mechanismen von Prescott's Pickle Principle bewusst ist und ihnen entgegenwirkt.

 

Die Analogie der Gurke im Essigwasser wurde in The Secrets of Consulting nämlich noch weiter getrieben - genau wie die harte Schale einer Gurke eine Zeit lang das Eindringen des Essigs verhindert, kann ein Change Agent (oder wie auch immer das auf deutsch heisst) sich eine Zeit lang dagegen wehren, von dem ihn umgebenden sozialen System assimiliert zu werden. In dieser Zeit kann er Wirkung entfalten, er sollte aber in der Lage sein zu erkennen, ab wann das nicht mehr der Fall ist und dann wieder gehen.

 

Wie alles an derartigen "Gesetzmässigkeiten" ist auch dieser Schluss mit Vorsicht zu betrachten und sollte vor allem im Kontext von Weinbergs Einsätzen in grossen, veränderungs-aversen Organisationen gesehen werden. In diesem Rahmen hat er aber eine gewisse Gültigkeit und erklärt damit auch, warum viele Konzerne, Behörden und sonstige Grossorganisationen in einem Zustand der "Dauerberatung" befinden, und ständig neue Unternehmensberater beauftragen, ohne dass das irgendwann ein Ende findet.

 

 Die Pointe in Weinbergs Buch besteht übrigens daraus, dass der Lebensmittelhändler Prescott den Verkauf von Essiggurken so stark verinnerlicht hatte, dass er in seinem nächsten Geschäft, einem italienischen Restaurant, die Pizza damit belegte. Damit entspricht er dem Antipattern eines Change Agents, der nicht nur zum Teil des ursprünglichen Problems wurde, sondern das auch noch als scheinbare Lösung weiterverbreitete. Eine Mahnung, wie man im schlimmsten Fall selbst enden könnte.