Leitplanke oder Schlagbaum?

Ohne Vertrauen, schreibt Niklas Luhmann sinngemäß, kämen wir morgens nicht einmal aus dem Bett¹. Wir brauchen also schon eine gehörige Portion Vertrauen, nur um unseren (Arbeits-)Alltag zu bewältigen. Wir vertrauen in uns selbst, in unsere Kolleginnen und Kollegen und vielleicht sogar in die Institutionen um uns herum. Trotzdem wäre es töricht, einfach allem und jedem blind zu vertrauen und Code ungeprüft in die Produktionsumgebung auszuliefern. Deshalb lassen die effektivsten Teams, die ich kennenlernen durfte, ihren Code bei jeder Änderung von einer Maschine auf Herz und Nieren prüfen. Mit Architekturregeln, Testsuiten, Quality Gates und mehr wird der Code gegen essenzielle Regeln geprüft, um die sich die Teams dann nicht mehr selbst wieder und wieder kümmern müssen. Vertrauen sich diese Teams also nicht mehr selbst? Greift das Misstrauen ins Team oder in die eigenen Fähigkeiten so sehr um sich, dass diese Teams sich selbst an die Leine nehmen müssen? Und wann kippt das Ganze eigentlich? Wann wird aus den Automationen, die unser Leben erleichtern, die Bürokratie, die uns einfach nur einengt und aufhält?

Ob Regeln Vertrauen zerstören oder erst ermöglichen, hängt meiner Erfahrung nach nicht davon ab, ob Mensch oder Maschine prüft. Es hängt davon ab, wem die Regeln gehören.

Kontrolle ist kein Gegenteil von Vertrauen

„Vertrauen ist gut, Kontrolle ist besser” wird gern Lenin zugeschrieben. Belegen lässt sich das nicht. Der Satz unterstellt aber einen Gegensatz, der in der Realität so nicht haltbar ist.

Luhmann beschreibt Vertrauen als Mechanismus, der soziale Komplexität reduziert¹. Wer vertraut, muss nicht jede mögliche Zukunft durchspielen, bevor er handelt. Deshalb das Bett: Wer allem misstraut, kommt vor lauter Unsicherheit nicht mehr zum Handeln.

Zwei seiner Unterscheidungen sind für uns zentral. Die erste trennt personales Vertrauen in konkrete Menschen von Systemvertrauen in funktionierende Verfahren. Die zweite ist überraschender: Misstrauen ist für Luhmann kein Gegenteil von Vertrauen, sondern ein funktionales Äquivalent. Es reduziert ebenfalls Komplexität, nur teurer, weil es dauerhaft unsere Aufmerksamkeit bindet. Organisationen können Misstrauen deshalb an einer Stelle institutionalisieren, damit an anderer Stelle Vertrauen möglich wird.

Genau das kann auch eine gute ArchUnit-Regel leisten. Wenn die Pipeline Schichtverletzungen zuverlässig findet, muss ich im Review nicht mehr manuell Imports gegenprüfen. Das gibt uns den Raum, über fachliche Schnitte zu diskutieren und über die Frage, ob ein Modul überhaupt existieren sollte. Die Maschine übernimmt das Misstrauen. Das Team bekommt neue Spielräume.

Das ist keine Auslagerung von Vertrauen. Es ist eine Umverteilung.

Also automatisieren wir jetzt einfach immer alles und dann wird alles gut? Leider nicht.

Leitplanke oder Schlagbaum

Paul Adler und Bryan Borys haben untersucht, warum Formalisierung manche Menschen motiviert und andere in den Wahnsinn treibt². Ihre Antwort: Es gibt zwei Arten von Bürokratie. Ermöglichende Regeln helfen den Menschen, die mit ihnen arbeiten, ihre Arbeit besser zu machen. Erzwingende Regeln dienen vor allem dazu, Abweichungen zu erkennen und zu sanktionieren.

Den Unterschied machen vier grundlegende Eigenschaften aus:

Können die Betroffenen die Regel selbst reparieren oder anpassen?
Verstehen sie, warum es die Regel gibt?
Sehen sie, welchem größeren Ziel die Regel dient?
Und gibt es einen legitimen Weg für begründete Ausnahmen von der Regel?

Stellen wir uns zwei Szenarien aus unserem Projektalltag vor. In dem ersten Szenario behandelt das Team einen Incident. Die Teammitglieder entscheiden sich, als Improvement im nächsten Sprint eine neue ArchUnit-Regel einzuführen, um zu verhindern, dass dieser Incident in der Zukunft noch einmal so oder so ähnlich auftreten kann. Das ist Odysseus, der sich freiwillig an den Mast binden lässt, weil er seine eigene Schwäche kennt³. Im zweiten Szenario komme ich als neues Teammitglied hinzu. Als erste Amtshandlung bringe ich eine ArchUnit-Regel aus einem früheren Projekt mit und lege diese in das Repository. In beiden Szenarien ist die Message an das Team klar. Fall 1 besagt: Wir kennen uns. Fall 2 besagt: Ich kenne euch nicht, aber ich kenne Entwicklungsteams im Allgemeinen.

In die Kategorie des zweiten Falls müssen auch statische Codeanalysewerkzeuge mit Standardprofil eingeordnet werden. Diese beinhalten hunderte Regeln, die niemand im Team ausgewählt hat und deren Begründung niemand kennt oder je nachvollzogen hat. Das ist Bürokratie von der Stange, deren Findings in vielen Fällen einfach nur ignoriert werden.

Das Gegenstück kennen die meisten von uns: automatisierte Tests. Bei testgetriebener Entwicklung schreibt das Team die Prüfung selbst, und zwar bevor der Code existiert. Näher kann eine Regel ihrem Team kaum sein. Kent Beck beschreibt TDD ausdrücklich als Methode, mit der Angst beim Programmieren umzugehen⁴. Im Sinne Luhmanns ist eine Testsuite institutionalisiertes Misstrauen gegenüber dem eigenen Code, und genau das macht Vertrauen in Veränderung möglich. Ohne Tests traut sich niemand an ein größeres Refactoring, zumindest niemand, der noch bei Verstand ist.

Aber auch Tests können kippen. Tests, die Implementierungsdetails statt Verhalten festschreiben, schlagen bei jedem Refactoring an und bestrafen genau die Veränderung, die sie absichern sollten. Flaky Tests werden irgendwann mit @Disabled markiert oder schlicht auskommentiert.

Ergeben sich die automatisierten Regeln organisch aus dem Team, so ist dies eigentlich nichts anderes als agiles Arbeiten zu Ende gedacht. Das Agile Manifest verlangt, Projekte um motivierte Menschen herum aufzubauen und ihnen die Arbeit zuzutrauen. Und es verlangt ebenso, dass diese Teams regelmäßig ihre Zusammenarbeit reflektieren und ihr Verhalten anpassen⁵. Eine Regel, die in der Retro entsteht, ist das Ergebnis genau einer solchen Reflexion. Sie hält fest, was wir gemeinsam gelernt haben. Problematisch wird es erst, wenn die Regel den Kreislauf verlässt und nie wieder verhandelt wird. Dann glauben wir ausgerechnet den Werkzeugen mehr als dem Team, obwohl das Agile Manifest Individuen und Interaktionen ausdrücklich höher gewichtet als Prozesse und Werkzeuge.

quadrantChart
    title Vertrauensinfrastruktur im Projekt
    x-axis Mensch prüft --> Maschine prüft
    y-axis Erzwingend --> Ermöglichend
    quadrant-1 Leitplanke
    quadrant-2 Mentoring
    quadrant-3 Flaschenhals
    quadrant-4 Schlagbaum
    Pair Programming: [0.2, 0.8]
    Architekt reviewt alles: [0.2, 0.2]
    Teameigene ArchUnit-Regel: [0.8, 0.8]
    Mitgebrachte ArchUnit-Regel: [0.75, 0.3]
    Analyse mit Standardprofil: [0.9, 0.15]
    TDD-Testsuite: [0.65, 0.92]
    Fragile Mock-Tests: [0.6, 0.4]

Die Kosten der Bürokratie

Die von uns geschaffene maschinelle Bürokratie hat allerdings Kosten, die die menschliche Bürokratie nicht hat.

Organisationen funktionieren oft nur, weil Menschen Regeln situativ brechen, wenn die Regel und ihr Zweck auseinanderdriften. Luhmann nannte das brauchbare Illegalität⁶. Eben diese Grauzonen kennt eine Pipeline nicht. Jede Abweichung muss explizit formuliert werden, bspw. mit einer Ignore-Annotation oder mit einer FreezingArchRule in ArchUnit. Das ist transparent und für alle Teammitglieder nachvollziehbar. Wenn der offizielle Weg zur Ausnahme aber zu mühsam ist, dann wird das Team inoffizielle Wege finden, das gewünschte Ziel zu erreichen. Eine Hilfsklasse wandert dann in ein erlaubtes Package und reicht einen Aufruf durch, nur um die Schichtverletzung loszuwerden. Die Regel ist erfüllt, ihr Zweck wird aber verfehlt.

Dazu kommt, was Lisanne Bainbridge die Ironie der Automatisierung nennt⁷: Je zuverlässiger eine Maschine eine Aufgabe übernimmt, desto weniger üben wir Menschen genau die Fähigkeiten, die dafür nötig sind. Sollte die Maschine zu einem späteren Zeitpunkt versagen, dann sind wir aber dennoch auf diese Fähigkeiten angewiesen. Wenn unser Build eine Schichtverletzung meldet, dann muss unser Team nicht mehr verstehen, warum die Schichtung wichtig ist. Die Regel konserviert unser Lernen eines Moments. Danach hört das Lernen auf.

Regeln überleben zudem immer auch ihren Anlass. Nach zwei Jahren weiß im Falle des Falles niemand mehr so genau, warum diese Regel damals eingeführt wurde, aber alle haben sich damit abgefunden, dass sie um sie herumarbeiten müssen. Max Weber hat für diese Art erstarrter Rationalität das Bild vom „stahlharten Gehäuse” geprägt⁸.

Um aus diesem Gehäuse auszubrechen, braucht es die Überzeugung des Teams, dass es Regeln selbstständig ändern darf und kann. Die Erwartung, eine Situation durch eigenes Handeln bewältigen zu können, nennt Albert Bandura Selbstwirksamkeit⁹. Bei Gruppen spricht er von kollektiver Wirksamkeit¹⁰.

Adler und Borys liefern mit der Reparierbarkeit die strukturelle Bedingung. Selbstwirksamkeit ist die psychologische. Nur wenn beide erfüllt sind, ändert ein Team seine Regeln tatsächlich selbst. Eine Regel, die das Team formal ändern dürfte, an die sich aber niemand herantraut, bleibt ein Schlagbaum. Auch Bainbridges Ironie der Automatisierung greift hier erneut: Wer jahrelang erlebt, dass die Pipeline besser urteilt als man selbst, traut dem eigenen Urteil irgendwann weniger.

Die stärkste Quelle für Selbstwirksamkeit sind nach Bandura eigene Bewältigungserfahrungen, nicht gut gemeinte Appelle. Ein Team, das in der Retro eine Regel löscht und danach erlebt, dass nichts zusammenbricht, lernt mehr über seine Handlungsspielräume als aus jedem Vortrag über Eigenverantwortung. Eine verlässliche Testsuite liefert solche Erfahrungen im Kleinen: Jedes Refactoring, nach dem die Tests grün sind, ist ein Erfolg.

Wenn die Zahl zum Ziel wird

Bei Metriken wird es noch eine Spur heikler. Eine ArchUnit-Regel verbietet eine konkrete Struktur. Eine Metrik verdichtet dagegen viele Entscheidungen zu einer Zahl, und über der Zahl hängt ein Schwellwert.

Gern wird an dieser Stelle Heisenberg bemüht: Wer misst, verändert das Gemessene. Physikalisch ist das eher der Beobachtereffekt als die Unschärferelation, aber das Bild trägt. Soziologisch präziser sprechen Wendy Espeland und Michael Sauder von Reaktivität¹¹. Menschen ändern ihr Verhalten, sobald sie wissen, dass sie beobachtet werden oder ihr Verhalten gemessen wird. Der Ökonom Charles Goodhart hat daraus 1975 eine Beobachtung über Geldpolitik gemacht¹², die in der Fassung der Anthropologin Marilyn Strathern berühmt wurde: Sobald ein Maß zum Ziel wird, taugt es nicht mehr als Maß¹³.

Bei uns sieht das so aus: Das Quality Gate verlangt 80 Prozent Testabdeckung, also entstehen Tests, die Code ausführen, aber keine Assertions enthalten. Die Abdeckung steigt, das Vertrauen in die Tests sinkt. Jerry Muller nennt dieses Muster „metric fixation”¹⁴: Die Zahl verdrängt das Urteil, das sie eigentlich unterstützen sollte.

Besonders tückisch sind Schwellwerte, deren Herkunft niemand mehr kennt. Mein Lieblingsbeispiel stammt aus der Finanzpolitik. 1981 brauchte François Mitterrand eine Regel, mit der er Ausgabenwünsche seiner Minister abwehren konnte. Der Beamte Guy Abeille erzählte 2012, die Drei-Prozent-Defizitgrenze sei in weniger als einer Stunde entstanden, ohne theoretische Grundlage¹⁵. Gut zehn Jahre später stand die Zahl im Vertrag von Maastricht, und seitdem wird europäische Haushaltspolitik an ihr gemessen. Philippa Sigl-Glöckner zeigt in Gutes Geld, wie wenig ökonomische Substanz hinter solchen Zielwerten steckt und wie stark sie trotzdem unser Leben bestimmen¹⁶.

Unsere 80 Prozent Testabdeckung haben oft eine ähnlich dünne Herkunft. Sie stehen im Standard-Quality-Gate, also gelten sie. Eine willkürliche Zahl wird zur Maxime des Handelns. Ich möchte an dieser Stelle auch nicht behaupten, dass der Schwellwert falsch ist. Ich sage nur, dass ihn niemand von uns begründen kann. Warum 80 Prozent und nicht 81? Warum nicht 100?

„Kannst du nicht einfach alles reviewen?”

In den Projekten, in denen das Vertrauen nicht technischer Stakeholder in ihr Entwicklungsteam schwindet, höre ich hin und wieder den Wunsch: „Ich möchte, dass du alle Änderungen des Teams reviewst, damit wir sicher sein können, dass sie in Ordnung sind.”

Als Bewältigungsstrategie machen Laien ihr Vertrauen in abstrakte Expertensysteme an Personen fest. Anthony Giddens nennt diese Personen access points¹⁷. Wer den Code nicht selbst lesen kann, der hat auch keine Möglichkeit zu beurteilen, ob das Team wirklich gute Arbeit leistet. Also braucht es eine Person, an der dieses Vertrauen hängt. In diesem Szenario bin ich es. Dahinter steht ein durchaus legitimes Bedürfnis nach Zurechenbarkeit und Verantwortung.

Die vorgeschlagene Maßnahme ist trotzdem die teuerste Form von institutionalisiertem Misstrauen, die ich kenne: menschlich, zentral und erzwingend. Forsgren, Humble und Kim zeigen in Accelerate, dass externe Freigabeprozesse mit schlechterer Delivery-Performance einhergehen, ohne die Fehlerrate von Änderungen merklich zu senken¹⁸. Eine Studie bei Microsoft zeigte, dass Code Reviews vor allem Wissen verteilen und seltener Fehler finden, als die Beteiligten erwarten¹⁹. Zudem wiesen Falk und Kosfeld experimentell nach, dass sichtbare Kontrolle bei einem Teil der Menschen die Leistung senkt, weil sie Kontrolle als Misstrauenssignal lesen²⁰.

Außerdem verschiebt sich die Verantwortung hierdurch. Zu wissen, dass ich am Ende über alle Änderungen schaue, erhöht nicht die Qualität, sondern senkt die Aufmerksamkeit aller anderen. Die Stakeholder wünschen sich also dieselbe Art von Bürokratie, die ich mit meinen automatisierten Regeln und Werkzeugen selbst gebaut habe. Wir wollen beide Kontrolle, setzen aber mit anderen Werkzeugen an.

Ausbrechen können wir aus diesem Dilemma, wenn wir Sichtbarkeit schaffen. Welche Regeln werden automatisiert? Warum werden diese Regeln automatisiert? Wie organisieren wir Code Reviews im Team? Wie haben wir aus unseren vergangenen Fehlern gelernt? Das ist, was Onora O’Neill als „intelligent accountability”²¹ bezeichnet hat. Mit diesem Konzept beschreibt sie Rechenschaft, die verstehbar macht, statt nur Nachweise zu produzieren. Kennzahlen gehören dazu, aber als Anlass für ein Gespräch, nicht als Ziel. Aus personalem Vertrauen in mich wird so Systemvertrauen in ein Verfahren, welches Stakeholder selbst nachvollziehen und verhandeln können.

Nachhaltige Lernprozesse

Wenn wir aus unseren Fehlern nachhaltig lernen wollen, dann geht das nur, wenn wir diese auch offen benennen dürfen, ohne dass hieraus negative Konsequenzen für uns folgen. Amy Edmondson nennt das psychologische Sicherheit²². Außerdem müssen wir darauf vertrauen, dass wir die Situation selbst zum Besseren wenden können. Das ist wieder die Selbstwirksamkeit. Wer Fehler zwar benennen darf, aber nicht glaubt, an den Regeln etwas ändern zu können, hört irgendwann auf, Fehler zu melden. Wo niemand den Fehler zugibt, der eine Regel notwendig gemacht hätte, entsteht keine Leitplanke, höchstens ein Schlagbaum, der von außen aufgestellt wird.

Vertrauen und Kontrolle sind keine Gegner. Wir müssen uns stattdessen fragen, wem die Kontrolle gehört.

Luhmann, N. (1968): Vertrauen. Ein Mechanismus der Reduktion sozialer Komplexität. Stuttgart: Enke. Aktuelle Auflage: UVK/UTB. ↩ ↩²
Adler, P. S.; Borys, B. (1996): Two Types of Bureaucracy: Enabling and Coercive. Administrative Science Quarterly, 41(1), S. 61–89. ↩
Elster, J. (1979): Ulysses and the Sirens. Studies in Rationality and Irrationality. Cambridge: Cambridge University Press. ↩
Beck, K. (2002): Test-Driven Development: By Example. Boston: Addison-Wesley. ↩
Beck, K. et al. (2001): Manifesto for Agile Software Development sowie Principles behind the Agile Manifesto. https://agilemanifesto.org ↩
Luhmann, N. (1964): Funktionen und Folgen formaler Organisation. Berlin: Duncker & Humblot. ↩
Bainbridge, L. (1983): Ironies of Automation. Automatica, 19(6), S. 775–779. ↩
Weber, M. (1904/05): Die protestantische Ethik und der „Geist” des Kapitalismus. Archiv für Sozialwissenschaft und Sozialpolitik, 20 und 21. ↩
Bandura, A. (1977): Self-efficacy: Toward a Unifying Theory of Behavioral Change. Psychological Review, 84(2), S. 191–215. ↩
Bandura, A. (2000): Exercise of Human Agency Through Collective Efficacy. Current Directions in Psychological Science, 9(3), S. 75–78. ↩
Espeland, W. N.; Sauder, M. (2007): Rankings and Reactivity: How Public Measures Recreate Social Worlds. American Journal of Sociology, 113(1), S. 1–40. ↩
Goodhart, C. A. E. (1975): Problems of Monetary Management: The U.K. Experience. In: Papers in Monetary Economics, Vol. I. Sydney: Reserve Bank of Australia. ↩
Strathern, M. (1997): „Improving ratings”: audit in the British University system. European Review, 5(3), S. 305–321. ↩
Muller, J. Z. (2018): The Tyranny of Metrics. Princeton: Princeton University Press. ↩
Interview mit Guy Abeille in Le Parisien, 28.09.2012. Abeille schildert die Entstehung auch in La Tribune (2010). ↩
Sigl-Glöckner, P. (2024): Gutes Geld. Wege zu einer gerechten und nachhaltigen Gesellschaft. Köln: Quadriga (Bastei Lübbe). ↩
Giddens, A. (1990): The Consequences of Modernity. Stanford: Stanford University Press. ↩
Forsgren, N.; Humble, J.; Kim, G. (2018): Accelerate. The Science of Lean Software and DevOps. Portland: IT Revolution Press. ↩
Bacchelli, A.; Bird, C. (2013): Expectations, Outcomes, and Challenges of Modern Code Review. Proceedings of the 35th International Conference on Software Engineering (ICSE), S. 712–721. ↩
Falk, A.; Kosfeld, M. (2006): The Hidden Costs of Control. American Economic Review, 96(5), S. 1611–1630. ↩
O’Neill, O. (2002): A Question of Trust. The BBC Reith Lectures 2002. Cambridge: Cambridge University Press. ↩
Edmondson, A. (1999): Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), S. 350–383. ↩