Das Problem mit technischen Schulden
Technische Schulden sind wie finanzielle Schulden: Ein bisschen ist normal und sogar sinnvoll. Zu viel davon bringt das ganze System zum Stillstand.
Die Metapher ist treffend, weil sie den Zinseszins-Effekt beschreibt. Eine schnelle Lösung spart heute Zeit, kostet aber morgen mehr. Und übermorgen noch mehr. Irgendwann verbringt das Team mehr Zeit damit, um die Schulden herumzuarbeiten, als mit der eigentlichen Feature-Entwicklung.
Das Problem ist nicht, dass technische Schulden existieren. Das Problem ist, dass die meisten Teams keinen Plan haben, sie abzubauen.
Warum „20% für Tech Debt" nicht funktioniert
Der beliebteste Ansatz – „wir reservieren 20% unserer Kapazität für technische Schulden" – scheitert in der Praxis fast immer. Die Gründe:
Keine Priorisierung: 20% der Zeit werden auf willkürlich gewählte Verbesserungen verteilt, statt auf die Schulden, die den größten Impact haben. Das Ergebnis: viel Aktivität, wenig Wirkung.
Kein Commitment: Sobald ein Feature dringend wird (und Features werden immer dringend), werden die 20% gestrichen. Nach drei Sprints ist der Plan vergessen.
Keine Messbarkeit: Niemand kann sagen, ob die investierte Zeit tatsächlich etwas verbessert hat. Ohne Messung gibt es kein Accountability.
Ein besserer Ansatz: Das Schulden-Inventar
Schritt eins ist ein vollständiges Inventar. Nicht im Kopf, nicht auf Sticky Notes, sondern als dokumentierte, priorisierte Liste.
Für jeden Eintrag erfassen wir vier Dimensionen:
Impact auf die Entwicklungsgeschwindigkeit: Wie sehr verlangsamt diese Schuld das Team? Gemessen in geschätzter Zeit pro Sprint, die durch Workarounds verloren geht.
Risiko: Was passiert, wenn wir nichts tun? Sicherheitslücken? Datenverlust? Performance-Degradation? Oder „nur" Frustration?
Aufwand zur Behebung: Wie viele Personentage brauchen wir für den Fix? Hier hilft eine T-Shirt-Size-Schätzung (S/M/L/XL).
Abhängigkeiten: Blockiert diese Schuld andere Arbeiten? Oder ist sie isoliert?
Die Priorisierungsformel
Aus diesen vier Dimensionen berechnen wir einen einfachen Score:
Priorität = (Impact × Risiko) / Aufwand
Schulden mit hohem Impact und Risiko bei niedrigem Aufwand kommen zuerst. Das sind die „Quick Wins", die sofort spürbare Verbesserung bringen und Momentum erzeugen.
Am anderen Ende stehen Schulden mit niedrigem Impact und hohem Aufwand. Diese werden bewusst akzeptiert – nicht ignoriert, aber dokumentiert und auf „later" gesetzt.
Integration ins Tagesgeschäft
Der Schlüssel zum erfolgreichen Schuldenabbau ist die Integration in den normalen Entwicklungsprozess – nicht als separates Projekt, sondern als Teil jeder Aufgabe.
Die Boy-Scout-Regel: Jeder Pull Request hinterlässt den Code besser, als er ihn vorgefunden hat. Nicht als großes Refactoring, sondern als kleine, inkrementelle Verbesserung. Ein besserer Variablenname hier, ein extrahiertes Interface dort.
Feature-gebundener Schuldenabbau: Wenn ein Feature-Branch einen Bereich des Codes berührt, der technische Schulden hat, wird der Schuldenabbau Teil des Features. Nicht optional, sondern als Teil der Definition of Done.
Dedizierte Schulden-Sprints: Statt 20% jeder Woche ein ganzer Sprint pro Quartal. Fokussiert, geplant, mit klaren Zielen und messbaren Ergebnissen. Das ist effektiver als permanente Hintergrundarbeit.
Refactoring-Strategien, die funktionieren
Großflächige Refactorings scheitern häufig, weil sie zu lange dauern und zu viele Teile des Systems gleichzeitig betreffen. Besser sind gezielte Strategien:
Strangler Fig Pattern: Neue Funktionalität wird in einer sauberen Architektur gebaut. Alte Funktionalität wird schrittweise migriert, Stück für Stück, bis das alte System leer ist und abgeschaltet werden kann. Kein Big Bang, kein Risiko.
Branch by Abstraction: Eine Abstraktionsschicht wird zwischen dem alten und dem neuen Code eingezogen. Beide Implementierungen existieren parallel. Der Switch geschieht per Feature-Flag. Wenn die neue Implementierung stabil ist, wird die alte entfernt.
Parallel Run: Kritische Systemteile werden neu gebaut und parallel zum bestehenden System betrieben. Die Ergebnisse werden verglichen. Erst wenn die neue Implementierung nachweislich korrekt ist, wird umgeschaltet.
Schulden verhindern, statt abbauen
Langfristig ist Prävention effektiver als Abbau. Einige Maßnahmen, die nachweislich helfen:
Architektur-Reviews vor der Implementierung: 30 Minuten Design-Diskussion sparen Tage an Refactoring. Nicht jedes Feature braucht ein Review, aber alles, was bestehende Architektur verändert, sollte vorher besprochen werden.
Automatisierte Qualitäts-Gates: Linting, Type-Checking, Test-Coverage-Thresholds, Dependency-Audits – alles, was automatisch prüfbar ist, sollte automatisch geprüft werden. In der CI-Pipeline, nicht optional.
Dokumentierte Architekturentscheidungen: Architecture Decision Records (ADRs) halten fest, warum eine Entscheidung getroffen wurde. Das verhindert, dass spätere Entwickler unwissentlich gegen die Architektur arbeiten.
Wie man Stakeholdern den Wert erklärt
Der häufigste Grund, warum technische Schulden nicht abgebaut werden, ist nicht technisch. Es ist politisch. Stakeholder sehen den Wert nicht.
Die Sprache, die funktioniert, ist die Sprache der Geschäftsergebnisse:
Nicht „Wir müssen die Datenbank refactoren", sondern „Die aktuelle Datenbankstruktur begrenzt unsere Release-Geschwindigkeit auf zwei Features pro Monat statt vier."
Nicht „Der Code ist unlesbar", sondern „Neue Entwickler brauchen aktuell drei Monate, um produktiv zu werden. Nach dem Refactoring sind es vier Wochen."
Nicht „Wir haben technische Schulden", sondern „Die Wartungskosten steigen pro Quartal um 15%. Ohne Gegenmaßnahmen überschreiten sie in sechs Monaten die Feature-Entwicklungskosten."
Fazit
Technische Schulden sind unvermeidlich. Aber sie sind managebar – wenn man sie als das behandelt, was sie sind: eine Geschäftsentscheidung, die regelmäßige Aufmerksamkeit erfordert.
Der Schlüssel ist nicht Perfektion, sondern System. Ein dokumentiertes Inventar, eine klare Priorisierung, integrierter Abbau im Tagesgeschäft und präventive Maßnahmen. Das klingt nach viel Aufwand, ist aber deutlich weniger als die Alternative: ein System, das unter dem Gewicht seiner Schulden zum Stillstand kommt.