Das Team wächst, trotzdem dauern Features länger und Releases brechen. Woran ihr Architekturerosion erkennt, was technische Schulden wirklich kosten und welche fünf Hebel die Entwicklungsgeschwindigkeit zurückbringen.
Das Team ist in zwei Jahren von vier auf zehn Entwickler gewachsen. Trotzdem dauert ein Feature, das früher in einer Woche fertig war, heute drei. Jede zweite Auslieferung bringt einen Fehler an einer Stelle mit, die niemand angefasst hat. Und im Sprint-Review heißt es immer öfter: „Wir mussten erst mal aufräumen.“
Wenn euch das bekannt vorkommt, liegt es selten an den Menschen im Team. Es liegt fast immer an dem, worauf das Team baut: an der Architektur der Software und an den Strukturen, in denen daran gearbeitet wird. Beides erodiert leise, und zwar genau dann, wenn das Unternehmen wächst.
In diesem Beitrag erklären wir, warum Entwicklungsteams an Geschwindigkeit verlieren, woran ihr es früh erkennt und welche fünf Hebel in unseren Projekten den Unterschied gemacht haben. Ein zweiter Beitrag zeigt anschließend, wie ihr technische Schulden gezielt reduziert und dauerhaft verhindert.
Das Team wächst, die Features kommen trotzdem langsamer
Mehr Entwickler bedeuten nicht automatisch mehr Durchsatz. Jede zusätzliche Person braucht Überblick über eine Codebasis, die sie nicht geschrieben hat, und Abstimmung mit allen, die parallel daran arbeiten. In ihrem Buch „Langlebige Software-Architekturen“ beschreibt Carola Lilienthal eine Erfahrungsgröße, die wir in Assessments immer wieder bestätigt sehen: Ein erfahrener Entwickler kann bei einer Änderung etwa 30.000 Zeilen Code überblicken und die Auswirkungen vorausahnen. Produktive Systeme sind um ein Vielfaches größer. Ohne eine Architektur, die diesen Überblick strukturell herstellt, arbeitet jeder Neuzugang im Blindflug, und die Erfahrenen werden zur Auskunftsstelle statt die Entwicklung maßgeblich mitzugestalten.
Dazu kommt die Koordination. Bei TRICERA energy haben wir ein Team von sieben Entwicklern übernommen, das nach dem Weggang des Lead-Entwicklers ohne klare Rollen und Abstimmungsprozesse arbeitete. Der Code war für die Verbliebenen kaum nachvollziehbar, Entscheidungen waren nicht dokumentiert. Die Lösung war kein größeres Team, sondern Struktur: ein dediziertes Weekly statt Ad-hoc-Abstimmungen, eine Zwei-Personen-Regel für alle Aufgaben und ein Team-Lead, der aus dem bestehenden Team heraus entwickelt wurde. Erst auf dieser Basis konnte das Team tragfähig auf über zehn Entwickler wachsen.
Vier Symptome, an denen ihr Architekturerosion erkennt
Robert C. Martin hat vier Symptome eines verrotteten Systems beschrieben. Sie passen erstaunlich genau zu den Fragen, die uns Geschäftsführer stellen:
- Starrheit (Rigidity): „Wieso brauchen einfache Änderungen Wochen statt Tage?“ Jede Anpassung zieht eine Kaskade weiterer Anpassungen in abhängigen Modulen nach sich. Was als kleines Refactoring beginnt, wird zum Marathon.
- Zerbrechlichkeit (Fragility): „Warum bricht bei jedem Release etwas Unerwartetes?“ Änderungen erzeugen Fehler an Stellen, die mit der Änderung nichts zu tun haben. Die Scheu vor Releases wächst, bis das Team lieber gar nicht mehr ausliefert.
- Unbeweglichkeit (Immobility): Es gibt bereits Code, der eine ähnliche Aufgabe löst, aber er bringt so viel Gepäck mit, dass niemand ihn wiederverwenden kann. Also wird kopiert. Die Codebasis wächst schneller als die Funktionalität.
- Zähigkeit (Viscosity): Für jede Aufgabe gibt es einen sauberen Weg und einen Hack. Wenn der Hack schneller geht, gewinnt er unter Zeitdruck jedes Mal.
Wenn euer Team mehr Zeit mit Firefighting als mit Features verbringt, treffen in der Regel mindestens zwei dieser Symptome zu. Das ist kein Teamproblem. Es ist das Ergebnis von technischen Schulden, die lange niemand sehen wollte.
Warum das passiert: technische Schulden und ihre Zinsen
Technische Schulden (Technical Debt) sind eine Metapher von Ward Cunningham aus dem Jahr 1992: Jede bewusst oder unbewusst suboptimale technische Entscheidung erzeugt später Mehraufwand, der Wartung und Erweiterung verzögert. Wie Schulden tragen sie Zinsen, und die werden bei jeder Änderung fällig.
Die folgende Grafik zeigt, was mit einem System im Laufe der Zeit passiert. Jede Erweiterung nimmt ein wenig neue Schuld auf (orange). Ein qualitätsbewusstes Team baut sie direkt wieder ab (teal) und bleibt so in einem Korridor geringer Schulden bei gleichbleibendem Wartungsaufwand. Fehlt die Erneuerung, steigt die Architekturerosion. Die Pfeile werden immer kürzer: Pro Zeiteinheit entsteht immer weniger Funktionalität. Oben wartet der Korridor mit hohem, unplanbarem Wartungsaufwand. Von dort führen nur noch teure Refactorings zurück, oder die Neuentwicklung, die Peter Vogel als CRAP-Cycle bezeichnet: Create, Repair, Abandon, Replace.
Lilienthal bringt die Folge für das Management auf einen Satz: „Langsam“ ist in der IT-Branche ein Synonym für „zu teuer“. Änderungen, die früher zwei Personentage brauchten, dauern auf dem aufsteigenden Ast doppelt bis dreimal so lange. Eine grobe Faustzahl aus ihren Analysen: Systeme mit guter Architektur binden für reine Wartung ein bis zwei Vollzeitentwickler pro 500.000 Zeilen Code. Wenn bei euch deutlich mehr Kapazität in Wartung fließt und kaum noch Features entstehen, ist das ein belastbares erstes Indiz für ein verschuldetes System.
Vier Ursachen spielen dabei immer wieder eine Rolle, meist in Kombination: Programmieren können viele, Architektur gelernt haben wenige. Die Erosion steigt unbemerkt, weil unter Zeitdruck Abkürzungen genommen und nie zurückgebaut werden. Systeme sind größer und komplexer, als ein Mensch überblicken kann. Und Management oder Kunden verstehen nicht, warum Qualität nach der Abnahme noch Geld kosten soll.
Warum das Team allein selten gegensteuert
Das Tückische an Architekturerosion ist, dass sie schleichend passiert und sich selbst verstärkt. In „Software Architecture: The Hard Parts“ beschreiben Neal Ford et al. den häufigsten Ursprung technischer Schulden als einen Satz, den jedes Team kennt: Wir wissen, dass das nicht gut ist, wir kommen später darauf zurück. Später kommt nie, weil Projekte in Dringlichkeit ertrinken und die wichtigen, aber nicht dringenden Prinzipien unter die Räder geraten.
Dazu kommt die Kommunikationslücke. Entwickler senden Warnsignale, aber in einer Sprache, die das Management nicht in Risiko und Geld übersetzen kann. Die Geschäftsführung sieht ein System, das läuft, und ein Team, das langsamer wird. Bis die Warnungen gehört werden, ist das System meist schon im oberen Korridor.
Genau hier braucht es jemanden, der beides spricht: die Sprache des Codes und die Sprache des Geschäfts. Das ist der Kern dessen, was wir unter System- und Software-Architektur und IT-Team-Enabling verstehen.
Was hilft: fünf Hebel für mehr Entwicklungsgeschwindigkeit
1. Geschwindigkeit messbar machen. „Agilität“ lässt sich nicht messen, ihre Bestandteile schon. Ford und Kollegen zerlegen sie in Wartbarkeit, Testbarkeit und Auslieferbarkeit, dazu Kennzahlen wie Durchlaufzeit und Kopplung zwischen Komponenten. Wer die Zeit von Commit bis Produktion, die Dauer der Pipeline und die Fehlerrate je Release kennt, kann über Geschwindigkeit sprechen, ohne zu raten. Bei Digistore24 haben wir genau so angefangen: mit einem gemeinsamen Assessment von Codebase, Docker-Builds, CI/CD-Pipelines und Cloud-Kosten, bevor eine einzige Zeile geändert wurde.
2. Architektur zur Holschuld machen. Lilienthal nennt es die Architekturdiskussion im Team: Themen werden während der Iteration gesammelt und regelmäßig gemeinsam besprochen. Dazu Pair Programming mit wechselnden Paaren, damit Architekturwissen nicht an Einzelpersonen hängt, und Live-Workshops, in denen das ganze Team seine Architektur am Bildschirm anfasst. Bei TRICERA war genau das der Weg aus der Abhängigkeit von einer Person: Architektur und Datenflüsse wurden gemeinsam dokumentiert, ein MQTT-Datenfluss vom Signal bis zum Dashboard ist heute für jeden nachvollziehbar.
3. Leitplanken statt Kontrolle. Niemand will einen Architekten, der jedem Entwickler über die Schulter schaut. Architecture Decision Records (ADRs) halten die wichtigen Entscheidungen samt Kontext und Konsequenzen in ein bis zwei Seiten fest, damit die nächste Generation im Team oder auch der KI-Agent weiß, warum etwas so gebaut ist. Fitness Functions prüfen automatisiert im Build, ob die Architektur noch eingehalten wird, etwa ob es zyklische Abhängigkeiten gibt oder ob die Schichten respektiert werden. Ford und Kollegen nennen das eine ausführbare Checkliste der wichtigen, aber nicht dringenden Prinzipien. Sie läuft bei jedem Build und lässt sich nicht aus Zeitdruck überspringen.
4. Die Pipeline entschlacken. Oft steckt ein großer Teil der verlorenen Zeit nicht im Code, sondern drumherum: in Builds, die Minuten warten, und in Images, die niemand mehr überblickt. Digistore24 fuhr rund 60.000 CI/CD-Jobs pro Monat auf einem Setup, das 15 Jahre gewachsen war. Wir haben die Docker-Builds auf ein Image pro Anwendung mit klaren Build-Targets konsolidiert, die Images auf minimale, gehärtete Basis-Images umgestellt und die rechenintensiven Jobs auf leistungsfähigere Runner verlagert. Das Ergebnis: 30 % weniger Images, die das Team pflegt, 45 % kleinere Images, 71 % kürzere Build- und CI-Workflows und 77 % geringere CI/CD-Kosten pro Monat. Jede Minute, die das Team nicht auf die Pipeline wartet, ist Entwicklungsgeschwindigkeit.
5. Struktur im Team, nicht nur im Code. Fokuszeit ist die knappste Ressource eines Entwicklungsteams. Ein festes Weekly statt ständiger Ad-hoc-Abstimmungen, eine Zwei-Personen-Regel für Änderungen und ein Team-Lead, der die interdisziplinäre Abstimmung trägt, haben bei TRICERA mehr Geschwindigkeit gebracht als jedes zusätzliche Tool. Und das Wissen bleibt im Haus. Gerd Rönsch, Engineering Manager bei Digistore24, beschreibt das so: „Das Beste ist, dass MPOWR IT sein Wissen nicht wieder mitgenommen, sondern bei uns gelassen hat. Heute entwickelt mein Team unser Setup selbst weiter, ohne dass etwas ins Wanken gerät.“
Wie wir vorgehen
Wir arbeiten in drei Phasen bei der Architekturanalyse: Aufräumen, Verbessern, Erhalten. Am Anfang steht ein Assessment, das Software, Infrastruktur und Teamprozesse als ein zusammenhängendes System betrachtet, nicht isoliert. Daraus entsteht eine Liste von Quick Wins und eine priorisierte Roadmap. In der zweiten Phase setzen wir die Verbesserungen gemeinsam mit eurem Team um, am Code, in der Pipeline und in der Zusammenarbeit. In der dritten Phase sorgen Leitplanken, Metriken und regelmäßige Architekturdiskussionen dafür, dass das Team den Korridor geringer Schulden selbst einhalten kann.
Das Ziel ist nicht, dass ihr uns dauerhaft braucht. Das Ziel ist ein Team, das wieder liefert und weiß, warum.
Jetzt Erstgespräch vereinbaren
Im nächsten Beitrag: Wie ihr technische Schulden objektiv messt, in welcher Reihenfolge ihr sie abbaut und welche Leitplanken verhindern, dass sie zurückkommen.
Quellen und weiterführende Literatur
- Carola Lilienthal: Langlebige Software-Architekturen. Technische Schulden analysieren, begrenzen und abbauen. dpunkt.verlag.
- Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani: Software Architecture: The Hard Parts. Modern Trade-Off Analyses for Distributed Architectures. O'Reilly.
- Kundenreferenz: Komplexität raus. Geschwindigkeit rein. Digistore24
- Kundenreferenz: Skalierbare IoT-Edge-Architektur für TRICERA Energy
