Rule Redesign

Systemproblem

Entwickler benehmen sich genau so, wie es die Spielregeln erlauben. Hat die Firma ein toxisches Regel-Set ("Nur das Release-Management darf in Produktion deployen, immer dienstags um 04:00 Uhr"), erzeugt sie toxische Entwickler. Die Entwickler hören 10 Tage lang auf, ihren Code qualitativ abzusichern, formieren am Montagabend einen gigantischen Pull-Request (Big Bang Release) und werfen ihn mit geschlossenen Augen über den Zaun. Das System züchtet Bug-Fabriken, da die dummen Regeln jeden anderen Verhaltensstrom unterdrücken.

Intervention

"Rule Redesign" ist Hebelpunkt Nr. 5 nach Meadows (Einer der mächtigsten Stützpfeiler der Veränderung). Wer die Regeln schreibt, besitzt das System. Du streichst den Dienstags-Deploy. Neue Regel: "Jeder Pull Request, der 95% Test-Coverage hat und alle End-to-End-Pipes besteht, fährt sofort (Continuous Deployment) ohne menschliches Eingreifen in Produktion." Du tauschst eine Erlaubnis-Regel (Hierarchie) gegen eine physikalische Regel (Automatisierung) aus. Du designst den Rahmen, in dem die Systemakteure handeln.

Erwartete Wirkung

Das System reinigt sich selbst (Selbst-Regulation). Anstatt dass Architekten täglich 100 Entwicklern mit dem Stock hinterherlaufen müssen ("Bitte schreibt mehr Tests!"), greift die neue Spielregel: Niemand muss mehr nachts aufbleiben. Niemand füllt mehr Release-Formulare aus. Der Entwickler erkennt sofort den Vorteil für sein eigenes Leben. Plötzlich schreiben sie alle brillanten, grünen Test-Code, um das manuelle Dienstags-Deployment zu überspringen. Durch die Veränderung der Regel hat sich die Architektur über Nacht selbst verbessert.

Nebenwirkungen und Risiken

Regeln definieren Machtgefüge, deshalb wird Rule-Redesign immer auf Sabotage treffen. Wenn du die Regel änderst von "Das Architektur-Board muss alle Cloud-Services genehmigen" hin zu "Teams dürfen ihre Cloud-Ressourcen bis 2.000€ im Monat selbst provisionieren", hast du dem zentralen Architektur-Board seine Daseinsberechtigung entzogen. Wenn neue Regeln nicht gut designet sind ("Tragedy of the Commons"), missbrauchen Akteure die Freiheiten sofort (Die Cloud-Kosten der Firma explodieren unkontrolliert in Millionenhöhe).

Diagramm

Wann diese Intervention wirksam wird

Meadows lieferte klassische Beispiele von kybernetischem "Rule Design": Die freie Meinungsäußerung ist eine extrem freie Regel. Sie muss zwingend durch eine andere eisere Regel eingegrenzt werden ("Keine Verleumdung", "Kein Ruf "Feuer" im vollen Theater"), da das System sonst stirbt. In der Architektur ist die "You build it - you run it" die stärkste Regel des Universums. Wenn du willst, dass Teams stabilen Code schreiben, muss die Regel lauten, dass sie bei Abstürzen um 3 Uhr nachts physisch aus dem Bett geklingelt werden. Die Hardware reagiert auf die Biologie der Ingenieure.

Wodurch sich diese Intervention von anderen Hebeln unterscheidet

*Parameter Tuning* ist das Drehen an den Nummern innerhalb eines Prozesses. *Rule Redesign* ist das Umschreiben des Prozesses selbst. Du redest nicht mehr darüber, wie groß das Budget des QA-Teams ist (Parameter), du änderst die Regel: QA darf keine Fehler mehr suchen, QA darf nur noch Entwicklern beibringen, wie man TDD betreibt (Rule).

Wie du die Intervention sauber einleitest

Suche den Kern-Engpass deiner Firma und finde die "stille Regel", die ihn davor schützt, repariert zu werden. Die meisten Regeln in der IT sind implizite Konventionen ("Wir haben das halt schon immer in Java gemacht, weil der Chef Java mag"). Verwandle implizite Verbote in explizite Freiheits-Regeln. Etabliere Architektur-"Fitness Functions", die maschinell als unabdingbare Gesetze gelten (Code, der die Cyclic Dependency Regel bricht, bricht den Build – keine Ausnahme, nicht mal für den CTO).

Erste Umsetzungsschritte

Regeln ohne Konsequenz sind keine Regeln, sie sind Appelle. Appelle funktionieren in komplexen Systemen absolut gar nicht. Ein Rule-Redesign in der Softwarearchitektur darf niemals nur als Manifest im Confluence stehen. Wenn eine neue Sicherheits-Regel gilt, muss sie zwingend als hartes IAM-Policy-Skript in die Amazon Web Services Cloud eingehämmert werden. Kybernetische Regeln müssen in der "Physik" (Dem Code) erzwungen werden.

Woran du Wirkung erkennst

Gibt es in unserer Firma "Heilige Kühe" in Form von veralteten, bürokratischen ITIL-Prozessregeln, die längst durch 100% maschinelle CI/CD Verifizierung ersetzt werden könnten, wenn wir den politischen Mut hätten, sie auf Vorstandsebene abzusägen?

Quellen

Donella Meadows — Leverage Points, Punkt 5: Rules (1999)

Elinor Ostrom — Governing the Commons, Kap. 3: Design Principles (Cambridge UP, 1990)

Wikipedia: Twelve Leverage heavily on rule changes