Modernisierung als Teamprozess

Modernisierung als Teamprozess

0:00 Wir schließen mit dem Modul, das über die Wirkung aller anderen entscheidet. Alles, was Sie in den letzten drei Tagen gelernt haben, funktioniert für eine Person an einem Tag. Ob es auch für ein Team über zwei Jahre funktioniert, hängt an anderen Fragen: Wie wird Modernisierung finanziert? Wie werden technische Schulden entscheidbar?

0:19 Wo wird das Wissen gesichert? Und woran misst man, ob es besser wird? Am Ende steht die einzige Frage, auf die es wirklich ankommt: Wird die Arbeit an diesem System leichter?

Modernisierung als Teamprozess

0:30 Der Bogen führt von der Finanzierung zur Messung. Zuerst die wichtigste organisatorische Entscheidung: Modernisierung entlang realer Änderungen statt als eigenes Projekt. Dann die Frage, wie technische Schulden entscheidbar werden, und die Hotspot-Priorisierung als Konsequenz daraus. Danach die Verankerung im Team — Regeln, Referenzen, Wissensspeicher. Dann Review-Kapazität und Metriken.

0:54 Und ein Kapitel, das ich für unterschätzt halte: die Rückschau auf Agentenfehler. Zum Abschluss die Arbeit, die den ganzen Weg noch einmal geht.

Modernisierung entlang realer Änderungen

1:03 Fangen wir mit der Finanzierungsfrage an. Sie klingt nach Management und ist in Wahrheit die technische Entscheidung mit der größten Hebelwirkung. Die verlässlichste Art zu modernisieren ist nicht das eigene Projekt, sondern die Verbindung mit der laufenden Produktarbeit. Zwei Gründe. Der erste ist praktisch: Wer ohnehin in einem Bereich arbeitet, hat den Kontext im Kopf — er muss sich nicht erst einlesen.

1:27 Der zweite ist wirtschaftlich: Die Verbesserung zahlt sich unmittelbar aus, weil sie die anstehende Änderung erleichtert. Sie müssen also nicht argumentieren, dass sich das irgendwann rechnet. Es rechnet sich in derselben Woche. Und hier ist der Gegenentwurf, den man häufiger sieht: das eigene Modernisierungsprojekt. Es konkurriert dauerhaft mit fachlichen Anforderungen und verliert diesen Wettbewerb, sobald es eng wird — und es wird immer irgendwann eng.

1:54 Der dritte Punkt beschreibt, wie es dann endet: meist zu drei Vierteln fertig. Das ist der schlechteste aller Zustände, denn Sie haben die Kosten getragen und den Nutzen nicht. Deshalb ist die Pfadfinderregel — jeden Bereich etwas besser hinterlassen, als man ihn vorgefunden hat — kein moralischer Appell. Sie ist eine Finanzierungsform.

2:14 Der zweite Punkt ist die verbreitetste Fehlinvestition und schließt an Modul eins an: Verbesserungen dort einplanen, wo niemand arbeitet. Der dritte ist die Gegenrichtung und kommt genauso vor — die Pfadfinderregel unbegrenzt auslegen und den Scope sprengen. Aus einer Fehlerkorrektur wird ein dreitägiger Umbau, und niemand hat das entschieden.

2:34 Der vierte ist die konkrete Form davon: Aufräumen mitliefern, das keinen Bezug zur anstehenden Änderung hat. Die Grenze zieht das Ziel aus Modul fünf.

Technische Schulden sichtbar und entscheidbar machen

2:44 Jetzt zur Frage, wie technische Schulden überhaupt in eine Entscheidung kommen. Und die Antwort hat mit Sprache zu tun — genauer gesagt mit Zahlen. Was nicht aufgeschrieben ist, wird nicht entschieden, sondern nur beklagt. Und zwar in der Kaffeeküche, was niemandem hilft. Technische Schulden gehören deshalb in dieselbe Liste wie fachliche Anforderungen — und, das ist der wichtigere Teil, in dieselbe Sprache.

3:08 Solange Sie über Wartbarkeit reden und die andere Seite über Umsatz, findet keine Abwägung statt. Es findet ein Missverständnis statt, das regelmäßig zugunsten der Seite ausgeht, die Zahlen nennen kann. Vergleichen Sie die drei Zeilen. „Die Abrechnung ist unwartbar“ erntet Zustimmung — und danach passiert nichts, weil niemand weiß, was das kostet.

3:30 „Jede Änderung dauert vier Tage statt einen“ ist dieselbe Aussage in einer Form, mit der man rechnen kann. Und „zweimal Produktionsfehler in sechs Monaten“ macht daraus eine Priorisierung mit Beleg. Die Fußzeile nennt die Quelle für solche Zahlen: die Hotspots aus Modul zwei. Sie liefern Belege statt Meinungen — und sie widerlegen regelmäßig die Annahme, der hässlichste Code sei der teuerste.

3:54 Das ist eine der lehrreichsten Beobachtungen aus der Hotspot-Analyse. Teuer ist der Code, den man am häufigsten anfasst — und diese Häufigkeit steht in der Historie, nicht im Quelltext. Sie sehen einer Datei nicht an, ob sie zwanzigmal im Jahr geändert wird. Die optische Auffälligkeit korreliert damit nur schwach: Die grässlichste Klasse im Projekt ist oft die, die seit sechs Jahren niemand angefasst hat.

4:18 Wer nach Optik priorisiert, investiert also regelmäßig am Bedarf vorbei — mit guten Absichten und ohne Wirkung.

Hotspot-Priorisierung statt flächendeckender Bereinigung

4:25 Daraus folgt die Priorisierung, die sich als Einzige nachweisbar rechnet. Und zugleich die Absage an einen Wunsch, den fast jedes Team kennt. Der Wunsch, einmal gründlich aufzuräumen, ist verständlich — er verspricht ein Ende des schlechten Gefühls. Und er ist fast immer die falsche Investition, weil er Aufwand gleichmäßig verteilt, während der Nutzen sich extrem ungleich verteilt.

4:48 Die Hotspot-Sicht dreht das um: Aufwand dorthin, wo die Änderungshäufigkeit hoch und die Qualität niedrig ist. Das ist die Zuspitzung des Gedankens aus Modul eins — Legacy ist eine Beziehung — auf die Ebene des Teams und des Budgets. Vier Argumente, und das dritte ist das eigentliche. Ein großer Teil jedes Bestandssystems wird über Jahre nicht angefasst — jede Verbesserung dort ist verlorener Aufwand, und sie trägt zusätzlich das Risiko jeder Änderung.

5:15 Bei Hotspots dagegen fiele der Aufwand ohne die Verbesserung immer wieder an; die Investition zahlt sich also nachweislich zurück. Der vierte Punkt ist der für die Kommunikation nach außen wichtigste: Sie argumentieren mit der Historie Ihres eigenen Systems, nicht mit einem Qualitätsempfinden. Das überzeugt auch Menschen, die keinen Code lesen.

5:36 Der zweite Punkt ist eine wichtige Präzisierung: Häufigkeit allein genügt nicht. Eine Datei, die oft geändert wird und gut strukturiert ist, braucht nichts — sie funktioniert ja. Erst die Kombination aus Häufigkeit und niedriger Qualität ergibt einen Kandidaten. Der dritte ist praktisch: Die Auswertung veraltet, weil sich Änderungsschwerpunkte verschieben.

5:57 Und der vierte ist der Rückfall in die alte Denkweise — aus der Hotspot-Liste ein Abarbeitungsprogramm zu machen. Es ist eine Priorisierungshilfe, kein Arbeitsvorrat.

Gemeinsame Regeln und Referenzlösungen

6:08 Jetzt die Verankerung im Team. Was in den Modulen fünf und zehn für einzelne Vorhaben galt, zerfällt auf Teamebene — es sei denn, es steht an einer Stelle, die alle erreicht. Der entscheidende Satz steht in der Tagline: Ein Agent kennt die Absprache vom letzten Dienstag nicht. Er kennt nur, was im Repository steht oder was ein Check ihm entgegenhält.

6:29 Das ist eine harte Einschränkung — und zugleich eine Klarstellung, die dem Team guttut. Denn dasselbe gilt in abgeschwächter Form auch für Menschen: Die neue Kollegin war am Dienstag nicht dabei, und nach vier Wochen erinnert sich niemand mehr an die genaue Formulierung. Verankert heißt deshalb: im Repository oder in einem Check.

6:48 Die drei Zeilen stammen aus drei verschiedenen Modulen und gehören auf Teamebene zusammen. Die Refactoring-Leitplanken aus Modul fünf gelten, sobald sie hinterlegt sind — auch wenn der Auftrag sie vergisst. Die Zielmuster aus Modul zehn werden als benannte Referenzstellen im Code sichtbar, und darauf zu zeigen ist präziser als jede Beschreibung.

7:08 Und die dritte ist laut Fußzeile die wirksamste und die am häufigsten vergessene: eine ausführbare Regel, die das jeweils Alte in neuem Code verhindert. Ohne sie endet keine Migration. Der erste Punkt ist der häufigste: Regeln in einem Wiki ablegen, das kein Agent liest — und ehrlich gesagt auch kaum ein Mensch. Der zweite ist ein Wartungsproblem: Referenzstellen, die inzwischen selbst umgebaut wurden, führen in die Irre.

7:33 Der dritte ist die Übertreibung: Ein Check, der zu streng ist, wird umgangen statt befolgt — dieselbe Logik wie beim Freigabemodell aus Modul elf. Und der vierte ist die stille Erosion: Absprachen, die nirgends nachlesbar sind, gelten nach einem halben Jahr nicht mehr.

Wissen sichern: Karten, Entscheidungen, Testbeispiele

7:49 Jetzt zu dem, was in diesen drei Tagen entstanden ist und was davon bleiben sollte. Vier Speicher lohnen die Pflege — und einer gehört ausdrücklich nicht dazu. Modernisierung erzeugt vor allem eines: Wissen. Und dieses Wissen ist wertvoller als der geschriebene Code, weil es teuer erarbeitet wurde und sonst mit den Beteiligten geht.

8:08 Das ist die praktische Antwort auf das Problem aus Modul eins — dass Wissen mit Menschen das Haus verlässt. Sie können das nicht verhindern, aber Sie können dafür sorgen, dass ein Teil davon im System bleibt. Vier Dinge lohnen die Mühe, und alle vier sind bei Ihnen schon entstanden. Alle vier stammen aus diesem Seminar. Die Systemprofile aus Modul zwei — und das Wort gepflegt ist wichtig, denn einmal erstellt veralten sie wie jede Dokumentation.

8:35 Die Entscheidungsnotizen aus Modul neun, die begründen, warum ein Weg gewählt wurde. Die Characterization Tests aus Modul vier, die nicht unbemerkt veralten können. Und das Unknowns Register, dessen offene Einträge die Landkarte für das nächste Vorhaben bilden. Die Fußzeile nennt, was nicht dazugehört: der Chatverlauf. Er ist Arbeitsmaterial, kein Wissensspeicher — niemand liest die Gespräche vom letzten Quartal noch einmal.

9:02 Auf diesen Punkt komme ich noch einmal zurück, weil er die Wissenssicherung grundlegend verändert. Ein Test wird ausgeführt. Wenn er nicht mehr stimmt, wird er rot — er kann Sie nicht stillschweigend belügen. Jede andere Dokumentationsform kann das: Ein Wiki-Artikel, ein Diagramm, ein Kommentar können falsch werden, ohne dass irgendetwas passiert.

9:22 Der dritte Punkt ist die Form: Ein Test beschreibt Verhalten in prüfbarer Weise. Und der vierte die Konsequenz — wer ihn liest, sieht das System, wie es ist, nicht wie es einmal gemeint war.

Review-Kapazität und Metriken für den Fortschritt

9:34 Jetzt der Engpass, der sich durch das ganze Seminar zieht — und die Frage, wie man Fortschritt zeigt, wenn sich nach außen nichts ändert. Die Prüfkapazität ist der Engpass, und bei Umbauten wirkt sie schärfer als bei neuen Funktionen. Der Grund steht in der Tagline: Man muss verstehen, was vorher war. Eine neue Funktion können Sie gegen die Anforderung prüfen. Einen Umbau können Sie nur gegen den Vorzustand prüfen — und den kennt nicht jeder.

10:00 Beim Fortschritt kommt ein zweites Problem dazu: Nach außen ändert sich nichts, das ist ja das Wesen einer Umstrukturierung. Umso wichtiger sind Zahlen, die das Team selbst beobachtet. Die ersten drei Hebel gelten für jede Prüfsituation: weniger gleichzeitig, kleinere Einheiten, mehr Automatisierung. Interessanter sind Schritt vier und fünf, die Besonderheit für Umbauten. Geben Sie die Prüfung an die Person, die den Bereich kennt — nicht an die, die gerade Zeit hat.

10:28 Die Fußzeile erklärt, warum: Bei einer Verhaltensänderung fällt ein Fehler in den Tests auf. Bei einem Umbau fällt er nur einem Menschen auf, der den vorherigen Zustand beurteilen kann. Und wenn dieses Wissen im Team fehlt, bauen Sie es vor dem Umbau auf, nicht danach. Diese fünf Größen beantworten fünf verschiedene Fragen — deshalb lohnt es sich, sie nebeneinander zu betrachten. Die Fundstellenzahl aus Modul zehn beantwortet den Migrationsstand.

10:56 Die Änderungsdurchlaufzeit zeigt, ob die Arbeit gewirkt hat. Fehler- und Rückrollrate zeigen, ob sie sicher war. Die Teststabilität zeigt, ob das Netz aus Modul vier trägt. Und die Entwicklung der Hotspots zeigt, ob sich die Struktur tatsächlich beruhigt. Die Fußzeile ist die wichtige Warnung: Keine dieser Zahlen taugt als Vorgabe von außen.

11:17 Als Vorgabe werden sie erreicht statt erfüllt — und dann messen sie nichts mehr.

Rückschau auf Agentenfehler und das Backlog

11:22 Vorletztes Kapitel, und es geht um das Lehrreichste, was in einem Team mit agentischen Werkzeugen passiert: die misslungenen Läufe. Sie verpuffen, wenn niemand sie ansieht. Eine kurze, regelmäßige Rückschau genügt — zwanzig Minuten im Monat. Wo hat ein Agent etwas produziert, das erst spät auffiel? Was hat gefehlt? Wichtig ist die Haltung dabei: Es geht nicht darum, Werkzeuge zu bewerten, sondern Arbeitsanweisungen zu verbessern.

11:50 Und es gibt eine Gegenrichtung, die genauso dazugehört und fast nie stattfindet — nämlich die Frage, welche Regel sich erledigt hat. Beides zusammen hält das Regelwerk lebendig. Die Antwort lautet fast nie „das Werkzeug ist schlecht“. Sie lautet: Es fehlte ein Nicht-Ziel. Oder eine Invariante. Oder eine Repository-Regel. Oder ein ausführbarer Check.

12:13 Das ist der eigentliche Ertrag — jeder misslungene Lauf liefert einen konkreten Kandidaten für die nächste Leitplanke, und der ist belegt statt ausgedacht. Der dritte Punkt ist die Gegenrichtung: Welche Regel hat im letzten Vierteljahr nichts verhindert? Die kann weg. Denn ein Regelwerk, das nur wächst, wird irgendwann ignoriert — und ist dann vollständig wirkungslos.

12:37 Vier Felder, und Sie erkennen sie alle wieder: Anlass aus Modul fünf, Ziel beobachtbar formuliert, Voraussetzungen — meistens ein Testnetz oder Beobachtbarkeit —, und das Risiko mit der Umkehrbarkeit aus Modul drei. Die Fußzeile nennt die wichtigste Eigenschaft dieser Liste: Jeder Eintrag muss für sich abschließbar sein und Nutzen hinterlassen, auch wenn danach lange nichts folgt.

12:59 Denn das ist der Normalfall. Modernisierung läuft neben der Produktarbeit, in Abschnitten, mit Unterbrechungen. Eine Liste, die das aushält, führt weiter als ein Plan, der Durchhalten voraussetzt.

Abschlussarbeit: Verstehen, absichern, verändern

13:11 Zum Schluss gehen Sie den ganzen Weg noch einmal — an einem System, das Sie nicht kennen. Und die Bewertung folgt anderen Kriterien, als Sie vielleicht erwarten. Sie bekommen ein realitätsnahes System: lückenhafte Dokumentation, Testlücken, eine veraltete Abhängigkeit und einen fachlichen Änderungswunsch. Also ungefähr das, was Sie am ersten Arbeitstag in einem neuen Projekt vorfinden.

13:34 Und jetzt der Punkt, auf den es ankommt — bewertet werden nicht die Patchgröße und nicht die Menge des erneuerten Codes. Bewertet werden die Qualität der Analyse, die Sicherheit der Schritte und die Belastbarkeit der Nachweise. Ein kleiner, belegter Fortschritt schlägt einen großen ungeprüften. Das ist die Kernaussage dieser drei Tage in einem Satz.

13:55 Die fünf Etappen sind das Seminar im Zeitraffer: erkunden und Belege von Vermutungen trennen, Risiken bestimmen und absichern, Ziel und Grenzen festlegen, umkehrbar planen und umsetzen, prüfen und dokumentieren. Achten Sie darauf, dass Sie in Etappe fünf nicht nur den Patch abliefern. Zum Ergebnis gehören auch die offenen Risiken und die nächsten Modernisierungsschritte — das ist Ihr Modernisierungs-Backlog für das zweite Vorhaben.

14:19 Und damit sind wir am Ende: Sie haben jetzt einen Weg, der von der ersten Erkundung bis zur belegten Änderung trägt. Viel Erfolg damit im eigenen Bestand.