Was sind Technische Schulden (Technical Debt)?

Technische Schulden sind Design- oder Implementierungsentscheidungen, die zukünftige Änderungen verteuern oder erschweren. Der Begriff geht auf Ward Cunningham (1992) zurück: Er verglich unvollständigen oder suboptimalen Code mit einem Kredit – er ermöglicht zunächst schnelle Lieferung, verlangt jedoch „Zinsen“ in Form erhöhter Wartungs- und Anpassungskosten, wenn er nicht zeitnah getilgt wird. 

Arten von technischer Schuld: 

• Code-Schulden (unsauberer, redundanter oder komplexer Code).

• Architektur-Schulden (ungeeignete oder überholte Strukturen, enge Kopplung).

• Test-Schulden (fehlende oder instabile Tests).

• Build-/Deploy-Schulden (manuelle oder fragile Pipelines).

• Dokumentationsschulden (fehlende oder veraltete Doku).

Ökonomisches Modell: 

• Principal (Hauptschuld): Aufwand, die bessere Lösung jetzt zu implementieren.

• Interest (Zinsen): wiederkehrende Zusatzkosten, z. B. längere Entwicklungszeit, mehr Defekte.

• Interest Rate (Zinssatz): steigt in Codebereichen, die häufig geändert werden („Hotspots“).

Intent & Qualität der Entscheidung (Fowler-Quadrant): 

• Absichtlich vs. unbeabsichtigt × umsichtig vs. leichtsinnig → vier Typen.

• „Absichtlich-umsichtig“ kann nützlich sein (bewusste Markteinführung trotz Kompromiss).

• „Unabsichtlich-leichtsinnig“ führt fast immer zu Problemzinsen.

– „Technische Schulden = Bugs“ – Fehler sind Defekte; Schulden betreffen die Wartbarkeit und Evolvierbarkeit des Systems. 

– „Tools liefern die ganze Wahrheit“ – SonarQube/SQALE schätzen v. a. Maintainability-Schulden (Code Smells), lassen Architektur-, Test- oder Build-Schulden jedoch oft unsichtbar. 

– „Alles neu schreiben löst es“ – Big-Bang-Rewrites verlagern Schulden häufig nur; risikoärmer sind inkrementelle Ansätze (z. B. Strangler-Pattern). 

Business-Effekt: 

• Eine groß angelegte Studie über 39 kommerzielle Codebasen zeigte: „Low-Quality“-Code enthielt bis zu 15× mehr Defekte und Bearbeitung von Issues dauerte im Schnitt 124 % länger.

• Die Autoren betonen: Korrelation, keine Kausalität – Ergebnisse gelten für diese Stichprobe, nicht universell.

• Andere Fallstudien berichten gemischte oder sogar keine Effekte auf Durchlaufzeiten, je nach Kontext und Messmethode.

Fazit: Technische Qualität ist Business-relevant, aber die Wirkung ist kontextabhängig – Organisationen müssen eigene Messungen durchführen. 

Ein Finanzdienstleister identifizierte einen Hotspot-Service (häufig geändert, hoher Komplexitätswert). Folge: lange Durchlaufzeiten, Fehler in Releases. Durch Hotspot-Analyse und Untersuchung zeitlicher Kopplung wurden Abhängigkeiten sichtbar. Das Team extrahierte eine kleinere Komponente, ergänzte Tests und CI-Checks. Ergebnis: verkürzte Cycle Times und geringere Fehlerquote im betroffenen Wertstrom. 

A. Sichtbar machen & bewerten 

• Debt-Register (Items mit Principal/Interest), Heatmaps für Hotspots, Architektur-Reviews.

• Tools (SonarQube, SQALE) nutzen – aber nur als Teilindikator.

B. Priorisieren nach Ökonomie 

• Schulden nach Cost of Delay (CoD)/WSJF und Hotspot-Score priorisieren.

• Bewusste Schulden mit Tilgungsplan versehen.

C. Tilgen im Fluss 

• Kontinuierliches Refactoring im laufenden Betrieb.

• Architektur-Enabler explizit planen.

• Strangler-Pattern für Legacy-Systeme einsetzen.

D. Qualitätsroutinen & Definition of Done 

• TDD, automatisierte Tests, CI/CD, Code-Reviews.

• Definition of Done explizit mit Refactoring/Tests erweitern.

E. Wirkung messen 

• Kombination aus Maintainability-Metriken (z. B. Sonar) und Flow-Metriken (Lead-/Cycle Time, Defektdichte, Change Failure Rate).

Wichtig: Ratings sind Indikatoren, kein absolutes Urteil. 

• Baseline erstellen: Debt-Register + Hotspot-Map.

• Ökonomisch priorisieren: WSJF × Hotspot-Score → Top-Items.

• Tilgung in Cadence: fixe Refactoring-Slots oder Enabler in jedem PI/Sprint.

• Architektur-Schulden gesondert managen: Schnitt, Abhängigkeiten, Observability.

• Wirkung messen: Fokus auf Outcomes (z. B. kürzere Cycle Time, weniger Defekte), nicht nur „Stunden investiert“.

Wir sehen technische Schulden als strategisches Risiko im Portfolio. Unser Vorgehen: 

• Sichtbarkeit herstellen (Debt-Register, Hotspot-Analyse).

• Ökonomisch priorisieren (CoD, WSJF).

• Verbindliche Kapazität sichern (Refactoring-/Enabler-Slots).

• Inkrementell tilgen und messen.

Wo organisatorische Policies Schulden verstärken (z. B. starre Freigaben, fehlende Plattform-Capabilities), kombinieren wir die Arbeit mit Organisational Debt, Living Strategy (Priorisierung, Strategy Sprints) und Living Transformation® (3-Monats-Kadenz, Capa-/Prio-Events). So entsteht ein ganzheitlicher Schuldenabbau, der Technik und Organisation verbindet. 

Den Zielkonflikt zwischen Geschwindigkeit und Stabilität, aus dem technische Schulden häufig entstehen, und die ökonomische Priorisierung mit WSJF behandelt das Leading SAFe® Training aus Sicht der Führung.

Weiterführende Begriffe & Quellen 

• Ward Cunningham: Debt Metaphor (1992).

• Martin Fowler: TD-Quadrant.

• SEI/CMU – Managing Technical Debt (Kruchten, Nord, Ozkaya).

• Systematische Reviews (Li, Avgeriou u. a., 2015).

• Hotspots & Temporal Coupling (Tornhill/CodeScene).

• SonarQube/SQALE – Maintainability Debt Ratio.

Empirische Business-Impact-Studien – Korrelation zw. Qualität, Defekten & Cycle Time; Kontext beachten.

• Definition of Done (DoD)

• Living Strategy

• Sprint (bzw. eine Iteration)

• Weighted Shortest Job First (WSJF)

• Cost of Delay (CoD)