Die 1%-Methode für Code und Architektur: Modernisierung als Gewohnheit

In Kundengesprächen höre ich quer durch alle Branchen fast jede Woche dieselben drei Sätze:

„Wir wollen ja modernisieren, aber das Tagesgeschäft kommt immer dazwischen."

„Das System ist so kaputt, da hilft nur noch ein Big Bang."

„Die technischen Schulden wachsen schneller, als wir sie abbauen können."

Das sieht nach drei verschiedenen Problemen aus. Ist es aber nicht. Es sind drei Symptome derselben Überzeugung: dass Modernisierung etwas ist, was man getrennt von der eigentlichen Software-Entwicklung macht. Ein Projekt. Eine Budgetposition. Ein Programm mit Lenkungsausschuss. Etwas, das ein ruhiges Quartal braucht, ein strategisches Alignment und ein Foliendeck, das jemand zwei Ebenen weiter oben abnickt.

Genau diese Überzeugung ist das Problem. Und sie ist auch der Grund, warum sich nichts in eine gesunde Richtung bewegt.

Das Modernisierungs-Paradox

Das Gespräch endet meistens auch immer gleich: „Wir bräuchten dringend ein großes Aufräumen, aber gerade jetzt geht das nicht."

Gerade jetzt steht ein Termin an. Gerade jetzt hatten wir einen Ausfall. Gerade jetzt liegt ein Feature auf dem Tisch, das das Business bereits zugesagt hat, ohne vorher jemanden zu fragen, ob die Codebasis das überhaupt trägt. Gerade jetzt ist der falsche Zeitpunkt, nächstes Quartal wird der richtige sein. Und nächstes Quartal kommt wieder mit seiner eigenen Variante von „gerade jetzt".

Aus meiner Erfahrung heraus dauert dieses „gerade jetzt" manchmal Jahre.

Während dieser Zeit wird das System immer schlechter. Module, die früher leicht zu verstehen waren, werden komplexer. Grenzen, die einmal klar gezogen waren, verschwimmen. TODO-Kommentare häufen sich. Die Dokumentation entfernt sich immer weiter von dem, was der Code tatsächlich tut. Tests werden im Build deaktiviert, weil niemand Lust hat, sich um die wackligen zu kümmern. Jede einzelne dieser Entscheidungen ist für sich genommen nachvollziehbar. In Summe ergeben sie eine Abwärtsspirale, die sich selbst verstärkt.

Das ist das Paradox: Je länger wir auf den richtigen Moment warten, desto größer muss die Modernisierung werden. Je größer sie werden muss, desto riskanter wird jede Änderung. Und je riskanter jede Änderung wird, desto schwieriger wird es, irgendetwas mit Vertrauen zu testen. Damit wird es immer unwahrscheinlicher, dass wir einen Moment finden, der groß genug, sicher genug und testbar genug ist. Die Projekt-Denkweise legt die Latte so hoch, dass die Latte selbst zum Hindernis wird.

Das System, das eine sechsmonatige Aufräumaktion bräuchte, wird diese sechs Monate nicht bekommen, sei es aus politischen Gründen, wegen Budgetdruck oder weil Features Vorrang haben. Ich höre den Satz schon: „Wir bezahlen für Features, nicht für Refactorings." Stattdessen bekommt das System eine Reihe hektischer Drei-Tage-Pflaster und mit jedem Pflaster wird die eigentliche Aufräumaktion ein Stück schwieriger.

Modernisierung im Rhythmus, nicht im Big Bang

Ich möchte einen anderen Blick auf Modernisierung vorschlagen.

Anforderungen ändern sich ständig. Teams ändern sich ständig, weil Menschen kommen, gehen, rotieren und dazulernen. Auch die Systeme, die wir bauen, ändern sich, sogar wenn wir sie gar nicht anfassen, weil sich die Welt um sie herum bewegt. Jedes Dependency-Update, jede neue Compliance-Regel, jede verschobene Business-Priorität setzt die Architektur ein bisschen unter Druck.

Wenn sich also alles um das System herum permanent ändert, kann das Gesundhalten dieses Systems kein einmaliges Ereignis sein. Eine Modernisierung, die alle vier Jahre gegen eine Welt antritt, die sich alle vier Wochen ändert, wird immer hinterherhinken.

Kontinuierliche Modernisierung ist also kein Projekt, das wir einmal durchziehen. Sie ist eine kleine, stetige Praxis, die das Team jeden Tag in winzigen Schritten ausführt, ungefähr in dem Tempo, in dem Veränderung auf das Team einwirkt.

Das Reframing klingt klein, ist es aber nicht. Es verschiebt Modernisierung aus der Kategorie der Dinge, die wir planen, in die Kategorie der Dinge, die wir tun. Modernisierung ist dann kein Punkt mehr auf einer Roadmap, sondern wird Teil davon, wie das Team arbeitet. Und wenn sie Teil davon ist, wie das Team arbeitet, konkurriert sie nicht mehr mit dem Tagesgeschäft, weil sie Teil des Tagesgeschäfts ist. Kein Spektakel, kein Kickoff, keine große Enthüllung. Einfach nur die Arbeit, ein Stück besser gemacht als gestern. Architektur entsteht ohnehin in dem, was das Team jeden Tag tut, nicht in dem, was es einmal plant. Der Rest dieses Beitrags handelt davon, was passiert, wenn man sich diesem Gedanken bewusst stellt.

Was Laufen mit Code zu tun hat

Stell Dir vor, Du beschließt, mit dem Laufen anzufangen. Du hast seit Jahren keinen Sport mehr gemacht. Am ersten Tag läufst Du nicht wirklich, weil das wehtun würde. Du gehst zehn Minuten zügig spazieren. Das ist unspektakulär. Du legst kaum eine Strecke zurück und nichts an diesen zehn Minuten macht Dich zu einer Athletin oder einem Athleten.

Am nächsten Tag machst Du dasselbe. Und am Tag danach. Nach ein, zwei Wochen fällt Dir der zügige Spaziergang leichter und Du beginnst, hier und da eine Minute langsames Joggen einzustreuen. Nach einem Monat schaffst Du fünf Minuten am Stück. Nach drei Monaten läufst Du eine halbe Stunde durch. Nach sechs Monaten ist ein 10 km Lauf am Wochenende ein realistisches Ziel. Nach einem Jahr peilst Du vielleicht einen Halbmarathon an.

Keine einzelne dieser Trainingseinheiten war bemerkenswert. Bemerkenswert war der Zinseszinseffekt.

Das ist die Grundidee der 1%-Methode, die James Clear in seinem Buch Atomic Habits populär gemacht hat. Das Argument ist einfach: Kleine Änderungen, die für sich genommen unbedeutend wirken, führen über die Zeit zu erstaunlichen Ergebnissen. Clear schreibt darüber vor allem im Kontext persönlicher Gewohnheiten. Was ich in diesem Beitrag versuchen möchte, ist diese Idee dorthin zu übertragen, wo Clear nicht hingegangen ist: in die Architektur von Software-Systemen, die von Teams gebaut werden.

Stell Dir vor, jedes Mitglied eines Teams investiert ungefähr zehn Minuten pro Tag in etwas Kleines. Ein Naming verbessern, sodass des dem entspricht, wie das Business die Sache wirklich nennt. Eine Methode extrahieren. Toten Code löschen. Einen fehlenden Test ergänzen. Eine Dependency aktualisieren. Eine Warnung beheben. Einen Absatz Dokumentation verbessern. Ein veraltetes Konfigurations-Flag entfernen.

Nichts davon ist für sich genommen beeindruckend. Nichts davon verdient ein Jira-Ticket. Nichts davon würde in einem Priorisierungsmeeting gegen einen Feature-Wunsch bestehen. Und genau das ist der Punkt. Diese Aktivitäten sind zu klein, um mit dem Tagesgeschäft zu konkurrieren, und genau deshalb können sie tatsächlich neben dem Tagesgeschäft passieren. Sie passieren leise, unter dem Radar, in den Randzeiten des Tages.

(Ein kleiner Hinweis am Rande: Wenn Du in einem Umfeld arbeitest, in dem jemand Deine Arbeit in Zehn-Minuten-Einheiten misst, wird Dir dieser Beitrag nicht weiterhelfen. Mein Rat in diesem Fall ist ein anderer: lauf, wenn möglich.)

Kleine Verbesserungen sind leicht zu tun. Sie sind aber auch leicht nicht zu tun. Und sie sind unmöglich zu ignorieren, sobald sie sich aufaddieren.

Warum gute Vorsätze eine Falle sind

Wenn Du mit Entwickler:innen über das Thema sprichst, sind sich fast alle einig. Wir sollten den Code jeden Tag ein bisschen verbessern. Wir sollten kleine Refactorings machen, wenn wir an einer Stelle sowieso unterwegs sind. Wir sollten nicht zulassen, dass kleine Probleme so lange wachsen, bis sie zu großen werden. Niemand widerspricht dem Prinzip. Ich habe noch nie eine Entwicklerin oder einen Entwickler erlebt, die oder der gegen die Idee kontinuierlicher kleiner Verbesserungen argumentiert hätte.

Und trotzdem tun es die meisten Teams nicht.

Der Grund ist nicht, dass Entwickler:innen faul oder undiszipliniert wären. Der Grund ist, dass Vorsätze unter Druck nicht halten. Schau Dir eine ganz normale Woche in einem Delivery-Team an. Da gibt es Bereitschaftsdienst. Da gibt es kritische Produktions-Bugs. Da gibt es ein Sprint-Ziel, das schon Dienstag anfängt zu rutschen. Da gibt es die „Bitte ASAP noch dieses eine Feature"-Anfrage von einer Stakeholderin oder einem Stakeholder, die oder der einer Kundin oder einem Kunden etwas zugesagt hat, ohne vorher zu fragen. Eine Kollegin ist im Urlaub. Ein Kollege ist krank. Eine andere Kollegin hat Dir gerade gesagt, dass sie in sechs Wochen das Team verlässt. Der Release-Termin verschiebt sich nicht. Die Roadmap wird nicht kleiner. Und der Termin, der vor zwei Monaten noch entspannt aussah, fühlt sich jetzt knapp an.

In so einer Woche findet die kleine Verbesserung nicht statt. Nicht weil die Entwicklerin oder der Entwickler sie vergessen hätte und auch nicht, weil es sie oder ihn nicht interessieren würde. Sie findet nicht statt, weil das fünfminütige Refactoring in dem Moment zwischen Produktions-Bug und rutschendem Sprint das Einfachste ist, was man von der Liste streichen kann. Es gibt immer etwas Dringenderes.

Das ist die Falle. Wenn das Verbessern von Code oder Architektur von Motivation und guten Vorsätzen abhängt, sehen unsere Codebasen am Ende aus wie Fitnessstudios im März. Voll mit guten Absichten im Januar, halb leer im Februar, im Frühjahr mehr oder weniger verlassen. Die Absicht war echt. Die Struktur, sie zu tragen, war es nicht.

Die Lösung ist nicht mehr Motivation. Die Lösung ist eine Struktur, die Motivation überflüssig macht.

Du hast bereits Gewohnheiten

Wenn ich Vorträge zu diesem Thema halte, stelle ich dem Publikum oft eine Frage: „Was ist das Erste, was Du an Deinem Rechner machst, wenn Du morgens am Schreibtisch sitzt?"

Die Antworten sind fast immer dieselben. E-Mails checken. Slack öffnen. Teams öffnen. In den Kalender schauen.

Dann sage ich: „Glückwunsch, Du hast eine Gewohnheit."

Du bist ins Büro gekommen. Du hast Dir einen Kaffee geholt. Du hast Dich an Deinen Schreibtisch gesetzt. Du hast Deinen Laptop aufgeklappt. Du hast Slack geöffnet. Du hast nicht bewusst entschieden, Slack zu öffnen. Du hast Dich nicht selbst dazu motiviert. Du hast Dir nicht am Vorabend „Slack öffnen" auf die To-do-Liste geschrieben. Du hast es einfach getan, weil die Kette kleiner Aktionen davor Dich dort hingezogen hat. Der Auslöser war der aufgeklappte Laptop. Die Reaktion war der Klick auf Slack. Die Belohnung war der kleine Hit von „jetzt weiß ich, was los ist."

Gewohnheiten brauchen keine Vorsätze. Genau das ist ihr Sinn. Sie laufen auf einer Schiene, die das Gehirn schon angelegt hat, sodass das bewusste Denken keine Energie mehr darauf verwenden muss.

Hier mein Vorschlag, den ich an dieser Stelle im Vortrag immer gebe: Fang bei Dir selbst an. Morgen früh, bevor Du Slack öffnest, investierst Du zehn Minuten in eine kleine Code-Verbesserung. Benenne eine missverständliche Variable um. Lösche eine tote Methode. Schreib den Test, den Du schon ewig schreiben wolltest. Dann öffnest Du Slack. Leg Dir eine kleine Habit-Card auf den Schreibtisch und hak sie ab, wenn Du fertig bist. Mach das zwei Wochen lang, allein, ohne es jemandem zu sagen. Du brauchst dafür keine Erlaubnis. Du brauchst kein Meeting. Du brauchst kein Ticket. Du musst es einfach nur vor Slack in Deine Morgenroutine packen.

Zwei Dinge werden passieren. Erstens wirst Du spüren, wie sich die kleinen täglichen Verbesserungen in den Teilen der Codebasis anhäufen, an denen Du arbeitest. Zweitens, und das ist der spannendere Teil, wird jemand im Team es bemerken. Die Habit-Card auf Deinem Schreibtisch. Den ungewöhnlich sauberen Diff in Deinem Pull Request. Die Dependency, die Du letzte Woche stillschweigend entfernt hast. Menschen sind neugierig. Sie werden fragen. Und sobald sie fragen, hast Du ein Gespräch und keinen Vertriebspitch.

So skaliert das Ganze. Nicht über ein Kickoff-Meeting. Nicht über eine Prozessänderung. Eine Person fängt an, das Team wird neugierig und die Praxis verbreitet sich seitwärts. Damit sie sich aber wirklich festsetzt, muss aus der individuellen Gewohnheit eine Team-Gewohnheit werden, nicht nur eine Sammlung einzelner. Und das ist eine andere Design-Aufgabe.

Von persönlichen Gewohnheiten zu Team-Gewohnheiten

Eine persönliche Gewohnheit muss nur Deine eigenen schlechten Tage überstehen. Eine Team-Gewohnheit muss die schlechten Tage aller Beteiligten gleichzeitig überstehen.

Das klingt wie ein kleiner Unterschied, ist aber keiner. Die persönliche Gewohnheit scheitert, wenn Du müde, abgelenkt oder im Stress bist. Die Team-Gewohnheit scheitert, wenn irgendjemand im Team müde, abgelenkt oder genug im Stress ist, um sie auszulassen. Dann sieht es die nächste Person und das Ritual verliert an Gewicht. Innerhalb von zwei Wochen ist die Gewohnheit etwas, was das Team früher mal gemacht hat. Niemand hat entschieden aufzuhören. Es hat einfach aufgehört.

Manchmal entscheidet auch jemand aktiv, dass das Team aufhört. Es gibt immer eine Senior-Person, die sagt „heute nicht, wir haben einen Termin", und das Team folgt, weil die Senior-Person Autorität hat. Aus einem ausgelassenen Tag werden zwei, dann eine Woche, und die Gewohnheit ist weg. Mir ist auch noch etwas Subtileres aufgefallen: Die Menschen, die am stärksten gegen diese kleinen Verbesserungen anschreiben, sind manchmal genau die, die ihren Status daraus ziehen, alle dunklen Ecken der Codebasis zu kennen. Das Chaos macht sie unentbehrlich. Eine sauberere Codebasis, in der sich alle zurechtfinden, bedroht diese Position leise. Das ist selten bewusst, aber es ist real und es lohnt sich, es auszusprechen.

Eine Team-Gewohnheit muss also anders gestaltet werden als eine persönliche. Sie muss in etwas eingebettet sein, was das Team ohnehin gemeinsam tut, sodass keine Einzelperson sich daran erinnern muss. Sie muss die Person überstehen, die gerade Bereitschaft hat. Sie muss den Workshop am Mittwoch überstehen. Sie muss die neue Kollegin überstehen, die noch nicht von ihr gehört hat. Die Struktur trägt die Gewohnheit, nicht die Willenskraft der Menschen darin.

Clear gibt uns in Atomic Habits vier hilfreiche Design-Regeln für Gewohnheiten: Mach den Auslöser offensichtlich, mach das Verlangen attraktiv, mach die Reaktion einfach und mach die Belohnung befriedigend. Diese Regeln lassen sich auf Team-Gewohnheiten übertragen, müssen aber auf Team-Artefakte gerichtet werden, nicht auf persönliche. Der Auslöser hängt nicht an Deinem Badezimmerspiegel. Er steht in Eurem Pull-Request-Template. Die Belohnung ist nicht ein Gefühl am Ende des Tages. Sie ist eine Metrik auf einem Dashboard, das alle im Team sehen.

Ein persönliches Beispiel: Ich habe mein Peloton-Bike in unser Wohnzimmer gestellt, nicht in ein Gästezimmer und auch nicht in den Keller. Direkt mitten dort, wo ich meine Abende verbringe. Ich bin dadurch nicht motivierter geworden zu trainieren. Ich habe nur den Auslöser unmöglich zu ignorieren gemacht. Jedes Mal, wenn ich daran vorbeigehe, fragt es mich leise, ob heute der Tag ist. Das funktioniert erstaunlich gut. Dasselbe Prinzip lässt sich auf Teams anwenden.

Hier ist, wie die vier Regeln aussehen, sobald man sie auf ein Team richtet:

Mach es offensichtlich. Der Auslöser lebt in den Artefakten, die das Team ohnehin täglich anfasst. Eine Zeile im Pull-Request-Template, die fragt: „Hast Du diesen Code ein bisschen besser hinterlassen, als Du ihn gefunden hast?" Ein sichtbares Improvement-Backlog am Team-Board. Eine kurze Slack-Erinnerung, dass die Doku-Minute nach dem Standup beginnt. Ein Architektur-Dashboard auf einem Bildschirm, an dem alle vorbeigehen. Der Auslöser muss unmöglich zu übersehen sein.

Und für die Tage, an denen jemand denkt „ich will meine zehn Minuten machen, aber mir fällt nichts ein, was ich anfassen könnte": Hängt ein Flipchart oder ein Miro-Board mit kleinen Verbesserungsideen auf, zu dem jede Person im Team etwas beitragen kann. Diese Klasse umbenennen. Jene unbenutzte Konfigurations-Datei löschen. Einen Test für diesen Edge Case ergänzen. Manche Teams, mit denen ich arbeite, vergeben dort anonymisierte Namen wie „Batgirl", „Princess Peach", „Super Mario" oder „Mr. Burns". Das hält die Sache spielerisch und verhindert, dass das Board zu einem Tracking-Werkzeug verkommt. Das Board ist immer voll, weil jede Entwicklerin und jeder Entwickler im Alltag Dinge entdeckt, für die gerade keine Zeit ist. Gib diesen Beobachtungen einen Ort, dann werden sie zum Treibstoff für die zehn Minuten von jemand anderem am nächsten Tag.

Mach es einfach. Zehn Minuten pro Person und Tag. Keine Freigaben. Keine Tickets. Kein Meeting, um die Verbesserung einzuplanen. Keine Schätzung in Story Points. Kein Review-Komitee. Die Autonomie ist Teil des Designs. In dem Moment, in dem ein Team um Erlaubnis fragen muss, um den Code zu verbessern, ist die Gewohnheit tot, weil der Genehmigungsschritt länger dauert als die Verbesserung selbst.

Mach es attraktiv. Feiert die kleinen Erfolge offen. Erwähnt sie im Standup. Visualisiert die Streak am Team-Board. Führt eine Team-Habit-Streak ein: Wir haben unsere tägliche Verbesserung an 14 aufeinanderfolgenden Arbeitstagen geschafft. Hängt es ans Board. Macht es sichtbar. Eine Streak erzeugt eine sanfte soziale Dynamik, in der niemand die Person sein will, die sie reißt. Einen neuen Rekord aufzustellen wird zu etwas, worauf das Team ehrlich stolz ist. Eine wichtige Regel: Urlaubstage, Krankheitstage und Konferenz- oder Trainingstage zählen immer als fortgesetzte Streak. Niemand soll sich gezwungen fühlen, an einem freien Tag zu arbeiten. Die Streak verfolgt die Arbeitstage des Teams, nicht die individuelle Anwesenheit. Wenn drei Personen im Büro sind und ihre zehn Minuten machen, läuft die Streak weiter. Nutzt hier den gesunden Menschenverstand. Die Liste der gültigen Gründe sollte nicht so lang werden, dass sie billige Ausreden erlaubt, aber sie muss schützen, was wirklich wichtig ist. Das Team kennt den Unterschied. Vertraut dem Team an dieser Stelle. Ein Team, das seinen eigenen Fortschritt sieht, will mehr davon. Ein Team, das seinen Fortschritt nicht sieht, geht davon aus, dass es keinen gibt.

Mach es befriedigend. Die Befriedigung muss auf Team-Ebene sichtbar sein, nicht nur individuell. Metriken, die sich in die richtige Richtung bewegen. Die Anzahl der Warnungen, die Woche für Woche sinkt. Der Dependency-Graph, der sauberer wird. Die Dokumentation, die tatsächlich die Fragen beantwortet, die eine neue Kollegin am ersten Tag stellt. Das sind keine Vanity Metrics. Das sind Belege, die das gesamte Team teilt, dass die kleinen Verbesserungen tun, wofür sie gedacht sind.

Hier eine wichtige Warnung. In dem Moment, in dem jemand außerhalb des Teams das Ganze in eine formale Tracking-Prozedur verwandelt, ist die Idee tot. Wenn eine Managerin oder ein Manager anfängt zu messen, wie viele Verbesserungen jede Entwicklerin oder jeder Entwickler diese Woche gemacht hat, hast Du aus einer Gewohnheit eine KPI gemacht und die intrinsische Motivation ist weg. Das funktioniert nur, wenn das Team das Ganze besitzt, es für sich selbst trackt und es als sein eigenes internes Signal nutzt. Die Habit-Streak am Board gehört dem Team. Sie ist keine Reporting-Metrik. Lasst es so.

Es gibt noch eine Idee von Clear, die sich besonders gut auf Teams übertragen lässt: Habit-Stacking. Der einfachste Weg, eine neue Gewohnheit aufzubauen, ist, sie an eine bestehende anzudocken. Teams haben bereits Routinen. Das Daily Standup. Das Pull-Request-Review. Die Retrospektive. Neue Gewohnheiten halten schneller, wenn sie auf diesen Routinen mitreiten. Eine „Doku-Minute" direkt nach dem Standup. Ein „Lass den Code besser zurück, als Du ihn gefunden hast"-Check im Pull-Request-Review. Drei Minuten Warning-Cleanup zu Beginn jeder Pair-Programming-Session. Die bestehende Routine trägt die neue Gewohnheit auf dem Rücken.

Genau dieser Schritt holt die 1%-Methode aus dem Selbsthilfe-Bereich und bringt sie in die Engineering-Praxis. Die Gewohnheiten sind nicht persönlich. Die Struktur ist nicht persönlich. Die Verbesserung ist nicht persönlich. Das Team besitzt sie, das Team gestaltet sie, das Team profitiert davon.

Architektur ist das, was Du jeden Tag tust

Wenn wir über Architektur sprechen, sprechen wir meistens über Entscheidungen. Welche Datenbank. Welches Kommunikationsmuster. Welches Deployment-Modell. Wie schneiden wir den Monolithen. Gehen wir auf Event-driven? Wir schreiben ADRs, wir zeichnen Diagramme, wir haben Review-Meetings. Und das alles ist wichtig.

Aber lass mich Dir eine Frage stellen. Wann ist Eure Architektur das letzte Mal wirklich schlechter geworden, weil in einem Meeting eine Entscheidung getroffen wurde?

An diesem Ort erodiert Architektur nicht. Sie erodiert an einem Mittwochnachmittag, wenn jemand eine Abkürzung baut, weil der Sprint zu rutschen beginnt. Sie erodiert an einem Freitag, wenn niemand mehr einen Test schreibt, weil das Wochenende ruft. Sie erodiert über einen ruhigen Monat, in dem ein Modul von 300 auf 1.200 Zeilen anwächst, weil jedes neue Feature dort gelandet ist und niemand stehengeblieben ist und gefragt hat, ob es da überhaupt noch hingehört. Sie erodiert, wenn eine Dependency, die vor sechs Monaten als temporär gedacht war, mittlerweile tragend ist und sich niemand mehr traut, sie anzufassen.

In keinem dieser Momente hat jemand eine schlechte Architektur-Entscheidung getroffen. In keinem dieser Momente hat überhaupt jemand eine Entscheidung getroffen. Die Dinge sind einfach passiert. Kleine Dinge. Alltägliche Dinge. Dinge, die in keinem Review und keinem ADR auftauchen.

Und trotzdem sind sie in Summe die Architektur.

Architektur ist die Summe alltäglichen Verhaltens, im gesamten Team, über Monate und Jahre.

Die Entscheidungen geben die Richtung vor. Das tägliche Verhalten entscheidet, ob wir auch tatsächlich dorthin kommen. Und wenn das tägliche Verhalten nicht zur Richtung passt, gewinnt das Verhalten. Jedes Mal. Kein Diagramm überlebt den Kontakt mit einem Team, das keine Gewohnheit hat, den Code sauber zu halten.

Genau deshalb sind die Team-Gewohnheiten aus dem vorherigen Abschnitt viel wichtiger, als sie auf den ersten Blick wirken. Eine einzelne zehnminütige Verbesserung wird keine kaputte Modulgrenze reparieren. Natürlich nicht. Aber ein Team, das die Gewohnheit hat, Grenzen wahrzunehmen, Probleme zu benennen, kleine Unordnung zu beseitigen und die Dokumentation ehrlich zu halten, wird über die Zeit eine Architektur produzieren, die fundamental leichter zu ändern ist. Nicht weil jemand in einem Meeting-Raum eine geniale Entscheidung getroffen hat. Sondern weil hunderte kleiner, alltäglicher Verhaltensweisen ungefähr in dieselbe Richtung gezeigt haben, Tag für Tag, Monat für Monat.

Weniger Hotspots in der Codebasis. Geringere Komplexität in den Modulen, die am häufigsten angefasst werden. Klarere Grenzen zwischen Komponenten. Klarere Verantwortlichkeiten. Vorhersehbarere Abhängigkeiten. Eine Dokumentation, die ein neues Team-Mitglied in der ersten Woche tatsächlich nutzen kann. Nichts davon entsteht durch eine einzige Aktion. Alles davon entsteht durch ein anhaltendes Verhaltensmuster.

In den Kampfsportarten gibt es ein Konzept, das das gut einfängt: Muskelgedächtnis. Du fängst nicht damit an, Kämpfe zu gewinnen. Du fängst damit an, einen einzelnen Schlag zu perfektionieren. Du wiederholst ihn hunderte Male, bis Dein Körper Dein Gehirn nicht mehr braucht. Dann lernst Du Katas, Abfolgen aus Schlägen und Blocks, die ineinander fließen. Auch die wiederholst Du hunderte Male. Und dann, eines Tages, gehst Du in einen Sparring-Kampf und Dein Körper macht das Richtige, ohne dass Du darüber nachdenkst. Der Schlag sitzt. Der Block ist am richtigen Ort. Nicht weil Du in dem Moment entschieden hättest, was zu tun ist. Sondern weil Du das Muster so tief trainiert hast, dass die Entscheidung schon gefallen war.

Architektur funktioniert genauso. Ein Team, das ein halbes Jahr lang täglich kleine Verbesserungen geübt hat, muss nicht mehr darüber nachdenken, ob es einen verwirrenden Namen aufräumt, einen toten Import entfernt oder eine Grenze schärft. Es macht es einfach. Das Muster ist trainiert. Die Architektur spiegelt das Training.

Und das ist der wirklich starke Effekt: Ein Team mit ausgeprägtem architektonischem Muskelgedächtnis hält nicht nur die aktuelle Architektur. Es macht zukünftige architektonische Veränderungen sicherer. Wenn der Moment für einen größeren Schritt kommt, eine Service-Extraktion, ein Modul-Split, eine Technologie-Migration, dann ist genau das Team in der Lage, ihn umzusetzen, das seit Monaten Grenzen sauber hält, Abhängigkeiten vorhersehbar und die Dokumentation ehrlich. Der große Schritt ist nicht deshalb sicher, weil ihn jemand gut geplant hat. Er ist sicher, weil der Boden, auf dem er landet, vorbereitet wurde, eine zehnminütige Verbesserung nach der anderen.

Die Zinseszinskurve

Es gibt etwas, worüber ich ehrlich sein muss. In den ersten Wochen wird sich das anfühlen, als würde nichts passieren.

Der Code wird nicht dramatisch anders aussehen. Die Metriken werden sich kaum bewegen. Die Architektur-Diagramme ändern sich gar nicht. Und irgendjemand im Team wird sagen „siehst Du, ich hab’s Dir gesagt, das funktioniert nicht."

Diese Person liegt falsch. Aber sie lügt auch nicht über das, was sie sieht. Die Zinseszinskurve hat eine Form, die Ungeduld bestraft. Die frühe Phase ist flach. Fast unsichtbar. Die Verbesserungen sind real, aber sie sind zu klein und zu verstreut, um in irgendetwas aufzutauchen, das man messen oder zeigen könnte. An genau dieser Stelle geben die meisten Teams auf. Nicht weil der Ansatz nicht funktioniert hätte, sondern weil das Feedback zu spät kam.

Das ist wie beim Laufen. Nach vier bis sechs Wochen täglichem Training fühlst Du Dich gut. Du bist schneller als am ersten Tag. Du hast eine Routine. Du fühlst Dich wie eine Läuferin oder ein Läufer. Und dann läuft Dir an einem Morgen jemand in Deinem Alter im Park entspannt davon. Plötzlich fühlt sich Dein Fortschritt nach nichts an. Du warst stolz auf Deine zehn Minuten pro Kilometer und diese Person macht sechs Minuten pro Kilometer, als sei es ein Aufwärmen. Die Versuchung aufzugeben ist riesig, weil der Vergleich Deinen eigenen Fortschritt für Dich unsichtbar gemacht hat.

Dasselbe passiert Teams. Du machst seit sechs Wochen Deine zehnminütigen Verbesserungen. Der Code ist ein Stück sauberer. Das Team fühlt sich gut damit. Und dann liefert ein anderes Team in der Firma ein großes, sichtbares Modernisierungs-Projekt aus. Neue Architektur. Neuer Tech-Stack. Eine Präsentation für die Leitung. Applaus. Eure stille, tägliche, unsichtbare Arbeit sieht im Vergleich nach nichts aus.

Das ist der Moment, der Teams trennt, die dauerhafte Gewohnheiten aufbauen, von Teams, die es einmal versucht haben. Das Team, das hier aufgibt, hat sichtbaren Fortschritt als Motivation gebraucht. Das Team, das weitermacht, hat etwas Besseres: eine Struktur, die nicht davon abhängt, wie sich das Team in dieser Woche fühlt. Die Gewohnheit läuft einfach. Genau deshalb haben wir sie als Gewohnheit gebaut.

Wenn Du dabei bleibst, biegt sich die Kurve. Nicht plötzlich, aber spürbar. So sieht es ungefähr aus in den Teams, mit denen ich bisher gearbeitet habe:

Woche 1 bis 4: Unsichtbar. Die Verbesserungen passieren, aber niemand außerhalb des Teams kann es erkennen. Die Diffs sind ein bisschen sauberer. Ein paar Namen ergeben mehr Sinn. Ein Test, der gefehlt hat, existiert jetzt. Der Wert ist real, aber nur für die Person sichtbar, die die Änderung gemacht hat. Das ist die schwerste Phase, weil sich der Aufwand sinnlos anfühlt. Ist er aber nicht.

Monat 2 bis 5: Spürbar. Das Team beginnt es zu fühlen. Code-Reviews werden schneller, weil der Code leichter zu lesen ist. Neue Kolleg:innen finden sich ein bisschen schneller zurecht. Die Anzahl der „was macht das hier eigentlich?"-Gespräche im Standup geht zurück. Nichts Dramatisches. Aber die Reibung ist geringer und das Team merkt es.

Monat 6 bis 12: Messbar. Die Metriken beginnen widerzuspiegeln, was das Team längst spürt. Warning-Counts sind sichtbar niedriger. Die Komplexitätswerte in den Modulen, die das Team am häufigsten anfasst, sind gesunken. Der Dependency-Graph hat weniger überraschende Verbindungen. Die Dokumentation deckt die Dinge ab, nach denen tatsächlich gefragt wird. Ihr könnt einen Chart auf einen Bildschirm hängen und jemandem außerhalb des Teams zeigen, dass sich etwas verbessert. Die kognitive Last im Team ist niedriger. Und falls jemand fragt, ob die zehn Minuten den Aufwand wert sind: Das Team liefert Features schneller aus, weil der Code, auf dem es aufbaut, ihm nicht mehr im Weg steht.

Monat 12 bis 24: Transformativ. Hier wird der Zinseszinseffekt schwer zu ignorieren. Die Codebasis ist nicht nur sauberer, sie ist strukturell anders als vor zwei Jahren. Grenzen sind schärfer. Module sind kleiner. Das Team bewegt sich schneller bei neuen Features, weil der Boden, auf dem es baut, solide ist. Und die großen architektonischen Schritte, die vor zwei Jahren unmöglich aussahen, eine Service-Extraktion, ein Modul-Split, eine Technologie-Migration, sind jetzt realistisch, weil die Vorbereitung in zehnminütigen Verbesserungen passiert ist.

Die Zinseszinskurve ist kein Versprechen, dass alles gut wird. Sie ist eine Beschreibung davon, wie sich kleiner, konsistenter Aufwand aufaddiert. Die Form ist immer dieselbe: flach, dann allmählich, dann steil. Die einzige Variable ist, ob das Team lange genug dabeibleibt, um den steilen Teil zu erreichen. Genau deshalb muss es eine Gewohnheit sein und kein Projekt. Keine Motivation hält zwei Jahre durch. Keine Projekt-Sponsorin, kein Projekt-Sponsor hält zwei Jahre Aufmerksamkeit. Eine Gewohnheit hält das aus.

Wie Du diese Woche anfängst

Wer schon einmal mit dem Laufen angefangen hat, kennt die Antwort auf die Frage „Wann ist der beste Zeitpunkt für eine Laufrunde?". Die Antwort ist immer: jetzt. Nicht morgen. Nicht nächsten Montag. Nicht erst, wenn Du die richtigen Schuhe gekauft hast. Jetzt.

Nach Konferenzen sage ich den Leuten normalerweise das Gegenteil. Fall nicht auf jeden Hype rein. Mach kein CDD, also kein Conference-Driven Development. Keine karrierebegrenzenden Aktionen auf Basis eines 45-Minuten-Vortrags zwischen Mittagessen und Nachmittagskaffee.

Diesmal sage ich Dir das Gegenteil. Fang an. Jetzt. Das ist kein neues Framework. Das ist keine riskante Technologie-Wette. Das sind zehn Minuten, in denen Du Code aufräumst, der Dir ohnehin gehört. Das Schlimmste, was passieren kann, ist, dass eine Variable morgen einen besseren Namen hat. Los.

Diese Woche: Morgen früh, bevor Du Slack öffnest, investierst Du zehn Minuten in eine kleine Verbesserung. Irgendeine Verbesserung. Ein besserer Name. Eine gelöschte Methode. Ein Test. Ein Absatz Dokumentation. Sag es niemandem. Bitte um keine Erlaubnis. Leg kein Ticket an. Mach es einfach. Leg eine Habit-Card auf den Schreibtisch und hak sie ab. Mach das diese ganze Woche an jedem Arbeitstag.

Diesen Monat: Sprich mit Deinem Team darüber. Zeig ihnen die Habit-Card. Erzähl, was Du gemacht hast. Wenn die anderen neugierig werden, schlag vor, dass alle es zwei Wochen lang ausprobieren. Richtet das Improvement-Ideen-Board ein, auf einem Flipchart oder in Miro, sodass niemand überlegen muss, woran zu arbeiten wäre. Startet eine Team-Streak. Trackt sie am Team-Board, nicht in einem Reporting-Tool.

Dieses Quartal: Bring das Thema in Eure Retrospektiven. Sprecht darüber, was funktioniert und was nicht. Wählt eine oder zwei Metriken aus, die für Eure Codebasis relevant sind, also Warning-Count, Komplexitäts-Score, Dependency-Anzahl, Dokumentations-Coverage, und beobachtet sie. Nicht als KPI für jemand anderen. Als Signal für das Team. Lasst das Team die Gewohnheit auf den eigenen Rhythmus zuschneiden. Manche Teams machen ihre zehn Minuten als Erstes am Morgen. Andere direkt nach dem Standup. Wieder andere als Teil des Pull Requests. Es gibt keine richtige Antwort. Es gibt nur die Antwort, mit der Euer Team auch noch nach 12 Monaten dabei ist.

Kein Framework, das eingeführt werden muss. Kein Tool, das gekauft werden muss. Kein Budget, das genehmigt werden muss. Kein Lenkungsausschuss, den Du überzeugen müsstest. Die Eintrittsbarriere sind zehn Minuten und die Bereitschaft anzufangen, bevor Du Dich bereit fühlst.

Fang morgen an

In zwei Jahren wird Eure Codebasis die Summe jeder kleinen Entscheidung sein, die Euer Team zwischen jetzt und dann getroffen hat. Das stimmt, ob Ihr morgen anfangt oder nicht. Der einzige Unterschied ist, ob die Richtung und die Haltung bewusst sind.

Du brauchst kein Modernisierungs-Projekt. Du brauchst kein Budget. Du brauchst von niemandem eine Erlaubnis. Du musst nicht auf den nächsten Planungszyklus warten, nicht auf das nächste Quartal, nicht auf die nächste ruhige Phase, die ohnehin nie kommen wird. Du brauchst zehn Minuten, eine Habit-Card und die Bereitschaft, den Code ein bisschen besser zu hinterlassen, als Du ihn vorgefunden hast.

Die Teams, die das tun, werden die Veränderung zunächst nicht bemerken. Niemand wird sie bemerken. Aber in einem Jahr werden sie auf ihre Codebasis schauen und sich fragen, wann die Arbeit damit eigentlich angefangen hat, leichter zu werden. Die Antwort wird sein: an einem ruhigen Dienstagmorgen, bevor jemand Slack geöffnet hat.

Architektur wird zu dem, was Du jeden Tag tust. Nicht zu dem, was Du einmal planst.

Fang morgen an. Zehn Minuten. Nach dem Kaffee. Vor Slack. Vor E-Mail. Vor allem anderen.