On Lean and Agility

Es kommt nicht mehr oft vor, dass eine neue Art der Software-Programmierung erfunden wird, aber es kommt vor, zuletzt im Februar 2025 durch Andrej Karpathy, einen slowakisch-kanadischen Software-Entwickler und ehemaligen Manager von Tesla und OpenAI. Der neue Programmier-Stil wurde von ihm in einem Posting im Social Nework X zum ersten mal beschrieben und Vibe Coding genannt. In kurzer Zeit erreichte er weitgehende Bekanntheit. Hier ist seine Beschreibung:

Zu Deutsch: Vibe Coding benötigt eine künstliche Intelligenz mit Spracherkennung. In der Interaktion mit dieser gibt man sich ganz seiner gegenwärtigen Stimmung (den Vibes) hin, äussert Wünsche und Vorstellungen und und lässt die KI auf diese Weise fast ausschliesslich durch Spracheingabe ein Stück Software erstellen, das dann irgendwann mehr oder weniger fertig und lauffähig ist. Mit Karpathys eigenen Worten: "just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works".

Aufbauend auf diesen Beitrag kam es in kurzer Zeit zu zahlreichen Artikeln in Medien wie Fortune, Forbes, TechCrunch und New York Times, die grossteils den selben Tenor hatten: Programmieren lernen ist nicht mehr nötig, auch als Laie kann man jetzt Software erstellen. Viele dieser Beiträge waren ausserdem verbunden mit marktschreierischen Verheissungen (jeder kann jetzt ein Startup gründen und reich werden) oder Untergangsszenarien (alle Entwickler werden bald arbeitslos sein).

Dass all das erkennbar an der Realität vorbeigeht hätte man dabei bei einem sorgfältigeren Lesen von Karpathys Post leicht erkennen können. Wie er selbst schreibt und wie kritische Stimmen bald anmerkten führt Vibe Coding dazu, dass selbst der "Urheber" nicht mehr genau sagen kann, wie sein Code entstanden ist und was er im Detail tut. Im besten Fall führt dieser Blindflug zu vielen kleinen Bugs, im schlechtesten Fall zu schweren Fehlfunktionen. Zum Herumspielen ist das gut, zu mehr aber nicht.

In diesem Herumspielen steckt allerdings auch eine Potential, das man nicht verachten sollte: mit Vibe Coding erstellte Anwendungen taugen zwar nicht für echte Markt- oder Produktions-Anwendungen, was sie aber sein können sind erstaunlich realitätsnahe Prototypen, mit denen man in Product Discovery oder Lean Startup Nutzerbedürfnisse und Nutzungsbereitschaft evaluieren kann, um sich dann schnell dem Bedarf anzupassen - frühe Entwicklungsphasen lassen sich so deutlich beschleunigen.

Und was ebenfalls oft nicht ausreichend beachtet wird: das "Programmieren" mit Hilfe gesprochener Prompts führt dazu, dass Anforderungen wesentlich klarer und präziser formuliert werden müssen als das in den meisten klassischen Anforderungs-Dokumenten der Fall ist, die oft eher kryptisch, verschachtelt und inkonsistent sind. Am Ende hat man im Vibe Coding also gleich zwei Ergebnisse - einen vorführbaren Prototyp und klarer formulierte Wünsche und Anforderungen.

Grafik: Pixabay / Brian Penny - Lizenz

Lavaneesh Gautam: Behind the Bottlenecks - The Root Causes of Dependencies in Teams

Roman Pichler: Setting up Product Teams for Success

Militarnyi: Saab Develops Anti-Aircraft System in Record 84 Days

Pawel Rola: Product Backlog Management with Upstream Kanban – From Chaos to Clarity

John Ward: Agile marketing - The source of enterprise agility

Bild: Flickr / McKinney75402 - CC BY 2.0

Unter den verschiedenen "Gesetzmässigkeiten", die in Projektmanagement-Kreisen gerne zitiert werden, nimmt das Gesetz der unbeabsichtigten Konsequenzen eine Sonderstellung ein. Anders als fast alle anderen (Conway's Law, Gall's Law, Goodhart's Law, etc) ist es nicht nach einer Person benannt, die es erfunden und popularisiert hat, sondern ist nach und nach in den Wirtschafts- und Sozialwissenschaften entwickelt worden, u.a. von John Locke, Adam Smith und Friedrich Hayek.

Sie alle hatten unabhängig voneinander die folgende Einsicht: wer in komplexen, vernetzten oder volatilen Systemen Veränderungen vornimmt, der wird nicht nur den Effekt erzielen den er beabsichtigt,¹ sondern auch andere, unbeabsichtigte. Zu einem "Gesetz" wird es dadurch, dass diese ungewollt eintretenden Konsequenzen praktisch unvermeidbar sind, einzig ihre Art und Intensität kann von Fall zu Fall anders sein. Vereinfacht gesagt sind mindestens sechs verschiedene Varianten möglich:

Unerwartete positive Konsequenzen

Der beste Fall der eintreten kann, in ihm treten positive Effekte auf, mit denen man gar nicht gerechnet hatte. Ein Beispiel wäre ein Sparkurs, durch den ein Grossprojekt auf nur noch wenige Teams zusammenschrumpft. Da diese jetzt jeweils mehr Themengebiete abdecken müssen, werden sie crossfunktionaler und weniger arbeitsteilig, wodurch nicht nur die Personalkosten sinken, sondern auch der bisherige Koordinationsaufwand und mit ihm weitere Kosten.

Unerwartete negative Konsequenzen

Das Gegenteil des ersten Falls. Ein Beispiel dafür wäre die Neueinführung gehaltsrelevanter Ziele für einzelne Mitarbeiter. Die arbeiten dann zwar mit gesteigerter Motivation an diesen Zielen, aber das im Zweifel auch auf Kosten der gemeinsamen Team- oder Unternehmensziele. Ein Sicherheitsbeauftragter, der für jeden gefundenen Regelverstoss belohnt wird, hat etwa einen starken Anreiz, seine Kollegen mit einer lähmenden und demotivierenden Kontroll-Bürokratie zu überziehen.

Unerwartete perverse Konsequenzen

Eine derartige Übersteigerung der negativen Konsequenzen, dass es sogar zu einer Verschlechterung in dem Bereich kommt, der eigentlich verbessert werden sollte. Ein bekannter Fall der Versuch, durch die Einführung von gemeinsamen Grossraumbüros die Kommunikationsbarrieren zwischen Mitatarbeitern abzubauen. Forschungsergebnisse zeigen, dass das Gegenteil der Fall ist - um den Geräuschpegel auszublenden werden Headsets aufgesetzt, wodurch die Kommunikation sogar zurückgeht.

Unerwartete positive Seitenauswirkungen

In diesem Fall treten unbeabsichtigte positive Effekte auf, die ihre Auswirkungen in einem anderen Bereich entfalten als dem, in dem die Veränderungen stattgefunden haben. So können Programme zur Förderung von Achtsamkeit und Sorgfalt nicht nur zu geringeren Fehlerquoten bei der Arbeit führen, sondern auch zu einem generell bewussteren und verantwortungsvolleren Konsumverhalten, wodurch im Privatleben der Beteiligten weniger Haushaltsmüll erzeugt wird.

Unerwartete negative Seitenauswirkungen

Wieder das Gegenteil des letzten Falls, hier tretennegative Effekte in einem anderen Bereich auf als dem, in dem die Veränderungen stattgefunden haben. Wenn eine Firma beispielsweise Kosten senken will indem sie von externen Mitarbeitern Gebühren für die Nutzung des eigenen Parkhauses verlangt, wird sie dadurch die Verkehrs- und Parkplatz-Situation in der Nachbarschaft verschlechtern, da auf die hier befindlichen Pakkplätze ausgewichen wird.

Sonstige unerwartete Seitenauswirkungen

Auch das gibt es - unbeabsichtigte Auswirkungen auf andere Bereiche als den, in dem die Veränderungen stattgefunden haben, die weder positiv noch negativ sind. Ein anschaulicher Fall dafür wäre eine Firma, die im Rahmen eines Corporate Design-Relaunch die Farbe ihrer Dienstwagen von Gelb zu Grün ändert. Das Strassenbild der Umgebung wird das zwar verändern, allerdings nicht zum Besseren oder Schlechteren, es sieht einfach nur anders aus.

Welche auch immer es sind, die Gemeinsamkeit der verschiedenen unbeabsichtigten Konsequenzen ist, dass sich weder ihre Art noch die Schwere ihrer Auswirkungen vorhersagen lassen. Dort wo in komplexen, vernetzten oder volatilen Systemen Veränderungen vorgenommen werden, ist es daher eine gute Idee, regelmässig zu überprüfen, ob derartige Effekte auftreten. Nur dann ist es möglich ggf. schnell Gegenmassnahmen zu ergreifen. Auch hier gilt also wieder: Inspect & Adapt.

Bild: Pexels / Moe Magners - Lizenz

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

Diese hier habe ich mehrfach in ähnlicher Form erlebt, aber die an die ich gerade denke, begann damit, dass ich als externer Scrum Master oder Agile Coach in eine Firma gekommen bin und dort Teams vorgefunden habe, die mir gleich zu Beginn Eines unmissverständlich klar machen wollten: dass es agiles Arbeiten bei ihnen nicht geben würde. Sie hätten das bereits versucht gehabt, es sei furchtbar gewesen und sie wären heilfroh, es zugunsten eines besseren Vorgehens  hinter sich gelassen zu haben.

Bedingt dadurch, dass ich diese Erfahrung wie gesagt bereits mehrfach gemacht habe, lasse ich mich in derartigen Situationen zunächst noch auf keine Diskussion über das zukünftige Vorgehen ein, sondern lasse mir zuerst erklären, warum der agile Arbeitsmodus als so furchtbar empfunden wurde und was den stattdessen gewählten so viel besser macht. Und es stellte sich dabei heraus, dass hier zwei aufeinander aufbauende Missverständnisse vorlagen.¹

Das erste dieser Missverständnisse betraf das, was dort irgendwann mal unter dem Namen "Agile" eingeführt worden war. Mit der zugrundeliegenden Idee hatte das eher wenig zu tun, stattdessen wurden lediglich zusätzlich zu den bereits bestehenden (und z.T. unverändert gültigen) Prozessen einzelne aus Scrum oder SAFe entlehnte Meetings, Titel und Begriffe eingeführt, die aber ohne geänderte Rahmenbedingungen nichts verbessert sondern nur alles verkompliziert hatten. Cargo Cult also.

Aufbauend darauf war das zweite Missverständnis entstanden. Da "Agile" als komplizierter, unverständlicher und bürokratischer Prozess wahrgenommen wurde, hatten die Teams stattdessen ein Alternativvorgehen entwickelt, dass auf direkter Kommunikation, crossfunktionaler Zusammenarbeit, wenigen Regeln, kurzen Lieferzyklen und regelmässigen Prozessverbesserungen beruhte.² Folgerichtig hielten sie dieses Vorgehen für nicht-agil und dem agilen Arbeiten überlegen.

Als ich auf diese beiden Missverständnisse hinwies, und darauf, dass der "nicht-agile Arbeitsmodus" in Wirklichkeit sehr agil war, waren zunächst Überraschung und Unglaube gross. Erst nachdem sich einige Teammitglieder bereiterklärten, einige der Originalquellen (Scrum Guide und Agiles Manifest) zu lesen, setzte sich langsam die Erkenntnis durch, dass sie die Idee falsch verstanden hatten, und durch die Abwehr der Cargo Cult-Methode "versehentlich" agil geworden waren.

Wirklich warm geworden sind sie mit dem Begriff zwar nicht mehr, dafür hatten sie sich bereits zu sehr auf ihn eingeschossen. Aber ganz ehrlich - sie waren nah am Kunden, lieferten regelmässig Mehrwert aus, passten das eigene Vorgehen regelmässig an und arbeiteten gut zusammen. Angesichts dessen war die Ablehnung des Wortes "Agil" ein Thema, das man mit gutem Gewissen vernachlässigen konnte. Wenn das Ergebnis stimmt, ist der Name des Prozesses nicht so wichtig.

Das hier gefällt mir wirklich: Barry O'Reilly versucht sich an einem philosophischen Blick auf das Konzept der Software-Architektur. Verkürzt gesagt - während sie häufig als ein logischer und konsistenter Ansatz zur Strukturierung von Software gesehen wird, ist sie in Wirklichkeit eine soziale Technik, mit der versucht wird, Ordnung in eine Welt zu bringen, die sich in einem Prozess der permanenten Unordnung befindet.

Alleine die oben genennten Gedanken hätten vermutlich schon für einen eigenen Vortrag gereicht, aber dieser geht deutlich weiter, und berührt unter anderem Essentialismus, Strukturalismus, Determinismus (und dessen Negierung), die Diskrepanz zwischen Sein und Werden, Positivismus, Interpretivismus, naive Kybernetik, Kausalität, Dekonstruktion und die philosophischen Grundlagen der Matrix-Filmreihe. Definitiv sehens- und hörenswert.

Bild: Pexels / Yan Krukau - Lizenz

Das Silicon Valley - Speerspitze des Fortschritts, Verkörperung technischer Disruptionen, Geburtsstätte bahnbrechender Innovationen und immerwährender Kreativität. Sich durch die Übernahme eines dort angesiedelten Startups in diese Wunderwelt einzukaufen erscheint den Managern vieler deutscher Konzerne und Mittelständler eine gute Idee zu sein, in der Realität enden diese Zukäufe allerdings meistens in Enttäuschungen. Und dass es immer wieder so kommt ist kein Zufall.

Um es vorwegzunehmen: was jetzt folgt ist anekdotische Evidenz. Ich habe einige dieser gescheiterten Silicon Valley-Expansionen selbst miterlebt, bei einigen weiteren kenne ich Menschen die dabei waren. In Summe lediglich eine niedrige zweistellige Zahl von Fällen, also Nichts was wissenschaftliche oder statistische Validität hätte. Da aber bestimmte Probleme immer wieder aufgetreten sind, glaube ich, dass es hier erkennbare (und prognostizierbare) Muster gibt.

Um mit dem Folgenschwersten (und auf den ersten Blick unglaublichsten) zu beginnen - die meisten deutschen Unternehmen sind sehr schlecht im Gestalten und Befolgen von Prozessen. Das kann bedeuten, dass es selbst für zentrale Geschäftsvorgänge keine offizielle Definition gibt (v.a. im Mittelstand anzutreffen), oder dass in Konzernen alles so überreguliert ist, dass die Mitarbeiter gezwungen sind, sich auf informelle Prozesse zurückzuziehen, um überhaupt arbeitsfähig zu sein (→ brauchbare Illegalität).¹

In beiden Fällen ist das Ergebnis, dass neue Mitarbeiter die inoffiziellen, aber für das Funktionieren der Firma elementaren Prozesse erst nach und nach herausfinden müssen, da diese lediglich im kollektiven Gedächtnis festgehalten sind. In Folge dessen dauert es entsprechend lange bis sie wirklich arbeitsfähig sind - sechs bis zwölf Monate sind in grossen Unternehmen nicht ungewöhnlich. Da in Deutschland viele Angestellte jahrzehntelang in ihrer Firma bleiben, ist das aber ein eher geringes Problem.

Im Silicon Valley findet man gleichzeitig ein Muster, das mit dem zuvor genannten komplett inkompatibel ist - die meisten Angestellten bleiben weniger als zwei Jahre bei einem Arbeitgeber, viele wechseln sogar mehrmals im Jahr. Das langsame Aufbauen von Wissen über die inoffiziellen Prozesse ist daher nicht möglich, weshalb die offiziellen möglichst minimalistisch gehalten, dafür aber strikt durchgesetzt und neuen Mitarbeitern durch starke und umsetzungsnah agierende Manager vermittelt werden.

Übernimmt jetzt ein deutsches Unternehmen ein Silicon Valley-Startup, kommt es mit hoher Wahrscheinlichkeit zu einem Culture Clash: in der (unbewussten) Erwartung, dass sich die Mitarbeiter die (inoffiziellen) Prozesse mit der Zeit selbst aneignen werden, wird von den deutschen Managern ein weniger strikter Führungsstil eingeführt. Der ständig wechselnden Belegschaft fehlen damit sowohl die schnelle Einweisung in die offiziellen, als auch das langsame Erlernen der inoffiziellen Prozesse.

Die unvermeidbare Folge eines derartigen Zusammenpralls so unterschiedlicher und inkompatibler Unternehmenskulturen ist ein erstaunlich schnelles Zusammenbrechen von Abläufen und Strukturen. Innerhalb von ein bis zwei Jahren sind kaum noch Kollegen da, die Erfahrung damit haben, die Prozesse am Laufen zu halten, stattdessen sind die meisten erst seit einigen Monaten an Bord, wurden nie richtig eingearbeitet und sind dadurch nur eingeschränkt zu effektivem Arbeiten in der Lage.

Diesem rapiden Verfall des intellektuellen Kapitals folgt meistens ein genauso schneller Einbruch der Produktqualität. Marktforschung, Product Discovery, technische Exzellenz und Qualitätssicherungs-Routinen sind mit den sich auflösenden Strukturen und Prozessen nur noch eingeschränkt durchführbar, Bugs und technische Schulden häufen sich an, die Umsetzungsgeschwindigkeit sinkt und mit ihr die Wettbewerbsfähigkeit und die Marktanteile. Irgendwann kann man alles nur noch abwickeln.

Selbst wenn diese Abläufe immer wieder zu beobachten sind, sind sie natürlich kein Naturgesetz. Sind die zugrundeliegenden Muster einmal erkannt, kann man gegensteuern und eine Silicon Valley-Tochtergesellschaft auch von Deutschland aus gut führen. Voraussetzung dafür ist allerdings, sich die Unzulänglichkeit oder Lückenhaftigkeit der meisten offiziellen Prozesse einzugestehen und ihre Unbrauchbarkeit in einer Umgebung mit hoher Personalfluktuation zu erkennen. Eine hohe Hürde.

Bild: Unsplash / Annie Spratt - Lizenz

Zu den Grundüberzeugungen aller agilen Frameworks gehört, dass Entwicklungsteams nach Möglichkeit Crossfunktional sein sollten, also in der Lage, alle im Rahmen der Produktentwicklung nötigen Tätigkeiten selbst durchzuführen, ohne dabei von anderen Abhängig zu sein. In traditionell arbeitenden Unternehmen dominieren dagegen die Spezialistenteams, die nur eine bestimmte Spezialtätigkeit beherrschen, die aber besonders effizient.

Am Anfang von agilen Transitionen stehen daher häufig Reorganisationen, in denen die Spezialistenteams aufgelöst und ihre Mitglieder auf die neuen, crossfunktionalen Teams verteilt werden. Wenn es in solchen Situationen aber mehr dieser neuen Teams gibt als bisher Spezialisten, treten Probleme auf. In den einen Teams feht das Spezialistenwissen, sie sind also doch wieder von anderen abhängig. Die anderen Teams müssen wiederum die erste Gruppe unterstützen, was zu Defocussierung und Prioritätskonflikten führt.

Um das zu vermeiden ist es sinnvoll, die Auflösung der Spezialistenteams nicht von jetzt auf gleich durchzuführen, sondern im Rahmen eines langsamen Prozesses, während dem immer mehr Wissen und Zuständigkeiten in die Breite verlagert werden. Wie das im Einzelnen geschehen kann wird natürlich von Fall zu Fall unterschiedlich sein, es gibt allerdings einen Denkansatz, mit dessen Hilfe sich der Übergang strukturiert durchführen lässt: Team Topologies.

Team Topologies geht von vier grundlegenden Team-Typen aus: Stream-aligned Teams (crossfunktional, können alles selbst), Enabling Teams (befähigen andere Teams), Complicated Subsystem Teams (besondere Spezialistenteams, deren Tätigkeit sich nicht so einfach aufteilen lässt) und Platform Teams (stellen anderen Teams Produkte oder Dienstleistungen zur Verfügung, die diese ohne externe Unterstützung sich selbst beschaffen und benutzen können). Mehr dazu hier.

Da spezialisierte Teams in Team Topologies den Complicated Subsystem Teams entsprechen sind diese der Ausgangspunkt, von dem aus zwei Weiterentwicklungen möglich sind: entweder sie können ihr Spezialgebiet zu einer Plattformdienstleistung umwandeln, die von den anderen Teams in einem Selbstbedienungs-Modus genutzt werden kann, oder sie wandeln sich zu enabling Teams indem sie das, was sie bisher selbst gemacht haben, anderen beibringen.

Häufige Anwendungsfälle für die Weiterentwicklung in Richtung Platform Team sind Spezialisten-Einheiten, von denen bisher Werkzeuge, Daten oder Infrastruktur verantwortet wurden. Die können in Selbstbedienungs-Portale überführt werden, in denen man sich Entwicklungsumgebungen, Testdaten, Anleitungen, Nutzungs-Simulationen o.ä. konfigurieren kann, die dann automatisiert erstellt und zur Verfügung gestellt werden.

Alternativ kann das bisherige Spezialisten-Team seine bisher verantworteten Themen direkt an die neuen, crossfunktionalen Teams weitergeben, allerdings mit einer wichtigen Ergänzung - statt diese mit ihrer neuen Aufgabe alleinzulassen, stehen die bisherigen Spezialisten als Trainer, Ratgeber, Erklärer und Notfallhelfer zur Verfügung, und das so lange bis sichergesetellt ist, dass ihre Unterstützung nicht mehr benötigt wird und sie sich neue Aufgaben suchen können.

In beiden Fällen (Umwandlung in ein Platform Team und Umwandlung in ein Enabling Team) kann es schliesslich zu einer finalen Entwicklungsstufe kommen, in der sich die ursprüngliche Spezialisteneinheit zwar auflöst, als "virtuelles Team" aber erhalten bleibt. Das kann z.B. in Form einer Community of Practice stattfinden, in der (ggf wechselnde) Vertreter aller crossfunktionalen Teams gemeinsam eine Platform-Dienstleistung oder einen Wissenstransfer am Leben halten.

Wer versucht in grossen Organisationen Bürokratie zu bekämpfen, der wird möglicherweise an der folgenden paradoxen Situation vorbeigekommen sein: während die Ausführungs-Ebene unter der Last der Prozesse und Vorschriften ächzt, ist sich die Führungsebene keiner Schuld bewusst, und kann sogar darauf verweisen, dass das offizielle Regelwerk sogar relativ schlank ist. Für diesen scheinbar widersinnigen Zustand gibt es einen häufigen Grund: Overcompliance.

Um das besser begreifen zu können schauen wir uns zunächst den zugrundeliegenden Begriff an: die Compliance. Hinter ihm verbirgt sich die anzustrebende Regelkonformität von Unternehmen, Behörden und sonstigen Organisationen, also die Einhaltung von Gesetzen, Richtlinien und internen Vorschriften. Compliance zu haben (bzw. Compliant zu sein) ist als Folge dessen das Ziel zahlreicher Prozesse, Tätigkeiten und Organisationseinheiten, die nur zu diesem einen Zweck existieren.

Das Problem bei der Herstellung von Compliance ist allerdings, dass es an ihren Rändern eine Grauzone gibt. Ab wann wird aus einer Routine ein zu dokumentierender Prozess? Gibt es Bagatellgrenzen für Zeit-, Qualitäts- und Budgetabweichungen? Wann können Anweisungen mündlich erfolgen, wann ist die Text-Form ausreichend und wann ist die Schriftform nötig? Alle diese Fragen sind in den Einzelfällen nicht immer eindeutig zu beantworten und lassen einen Interpretationsspielraum offen.

So lange dieses freie Interpretieren innerhalb der Grauzone keine negativen Folgen hat, ist das auch meistens unproblematisch, schwierig kann es aber werden, wenn das zu Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen führt. Viele Organisationen kehren in derartigen Situationen den Interpretationsspielraum um - alles woraus sich eine wie auch immer geartete Verantwortlichkeit ableiten lässt, wird rückwirkend zur Norm erklärt - oft mit disziplinarischen Folgen für die Betroffenen.

Und an dieser Stelle kommt es zur Overcompliance: um nicht ebenfalls oder erneut für etwas zur Verantwortung gezogen zu werden, was sich innerhalb einer Grauzone abspielt, beginnen die Mitarbeiter jetzt die jeweils strengste (und für sie sicherste) Auslegung der Gesetze, Richtlinien und internen Vorschriften anzuwenden. Im Zweifel also alles dokumentieren und schriftlich genehmigen zu lassen, und bereits kleinste Abweichungen zu verfolgen und zu eskalieren.

Bereits das kann lähmende Auswirkungen auf nahezu alle Abläufe haben, im schlimmsten Fall kann es aber sogar noch schlimmer werden - wenn es als Reaktion auf eine kontrollierende und überwachende Variante der Overcompliance dazu kommt, dass selbst für kleinste Aufwände explizite und schriftliche Anweisungen und Abnahmen nötig sind (gewissermassen Gegen-Overcompliance), ist es nicht mehr weit bis zu gegenseitigen Blockaden und bis zum totalen und dauerhaften Stillstand.

Um sich aus einer derartigen Situation zu befreien (oder um es gar nicht erst soweit kommen zu lassen) sind zwei Dinge notwändig: zum einen muss man akzeptieren, dass sich nicht alle Eventualitäten vorhersehen und mit vertretbarem Aufwand regulieren lassen, und zum anderen muss man darauf verzichten, nach in Grauzonen stattgefundenen Unfällen, Qualitätsmängeln oder versehentlichen Regelverstössen immer nach einem Schuldigen zu suchen und ihn bestrafen zu wollen.¹

Was darüber hinaus ein sinnvolles Werkzeug für die Verhinderung von Overcompliance sein kann, ist eine Vereinbarung, bei allen Regel-Umsetzungen immer die am wenigsten restriktive Variante anzustreben und von anderen zu fordern. Idealerweise kann das sogar Teil eines "Gesellschaftsvertrages" werden, an dem sich die gemeinsame Zusammenarbeit ausrichtet und auf den man sich bei Prozessgestaltungen, in Konflikten und bei Meinungsverschiedenheiten berufen kann.