# Technische Schulden steuern: Wann Aufräumen die Lieferung beschleunigt

Autor: Marin Niehues, Niehues Consulting · Veröffentlicht: 2024-03-07 · Delivery & Steuerung
Quelle: https://www.niehuesconsulting.de/blog/technische-schulden-steuern/

Technische Schulden steuern Sie, indem Sie Aufräumen wie eine Investition mit Zinsen behandeln und nur beseitigen, was die Lieferung messbar bremst. Der Zins zeigt sich in Mehrarbeit bei jeder Änderung, in Fehlern nach Releases und in Terminen, die Teams nicht mehr zusagen mögen. Wer ihn rechnet, kann Aufräumarbeit gegen neue Funktionen abwägen wie jede andere Investition.

Dieser Beitrag zeigt, wie Geschäftsführung und Produktverantwortliche technische Schulden in die Planung holen: mit einem Rechenweg für Zins und Tilgung, einem Vierfeldmodell zur Einordnung und einer Prüfliste für die Reihenfolge.

**Aufräumen beschleunigt die Lieferung, wenn der Code, den Sie aufräumen, in den kommenden Monaten oft geändert wird. Schuldenabbau an Stellen, die niemand anfasst, kostet Kapazität und bringt keine Zeit zurück.**

## Was sind technische Schulden und warum bremsen sie die Lieferung?

Technische Schulden sind Abkürzungen in Software, die kurzfristig Zeit sparen und bei jeder späteren Änderung Mehraufwand erzeugen. Den Begriff prägte Ward Cunningham 1992 in einem Erfahrungsbericht zu einem Finanzprogramm: Eine schnelle erste Fassung gleicht einem Kredit: Ein wenig Schuld beschleunigt die Entwicklung, solange sie bald durch Überarbeitung zurückgezahlt wird, und jede unbezahlte Schuld verursacht laufend Zinsen. Der Zins entsteht, wenn Entwickler bei jeder neuen Anforderung erst verstehen müssen, wie die frühere Abkürzung wirkt, und wenn sie jede Änderung doppelt absichern, weil Tests fehlen.

Für die Lieferung zählt, wo dieser Zins anfällt. Ein Team, das ein Modul pro Monat sechsmal anfasst und jedes Mal zehn Stunden für Einarbeitung, manuelle Tests und Fehlersuche zusätzlich braucht, verliert 60 Stunden im Monat. Das ist mehr als ein Drittel einer Vollzeitstelle, und es taucht in keiner Kostenstelle als Posten auf. Sichtbar wird es als verlängerte Durchlaufzeit, als Warteschlange vor dem Test und als Zusagen, die das Team nicht mehr gibt.
Auch Systeme mit maschinellem Lernen sammeln Schulden an. Eine Forschergruppe um D. Sculley zeigte 2015 in einem viel zitierten Konferenzbeitrag, dass bei solchen Systemen das Modell nur einen kleinen Teil des Codes ausmacht und die Schulden vor allem in Datenabhängigkeiten, Konfiguration und der Anbindung an andere Systeme entstehen. Wer KI in den Betrieb bringt, übernimmt diese Verpflichtung mit.

## Woran erkennen Sie, dass technische Schulden Ihre Lieferung bremsen?

Technische Schulden bremsen die Lieferung, wenn sich vier Signale zeigen: Die Durchlaufzeit gleichartiger Änderungen wächst von Quartal zu Quartal, nach Releases steigt die Zahl der Korrekturen, Schätzungen werden regelmäßig überschritten, und erfahrene Entwickler nennen dieselben Module als Ursache. Jedes Signal lässt sich messen, ohne dass Sie den Code lesen müssen.

Die Forschung zu Softwarelieferung liefert dafür einen Rahmen. Forsgren, Humble und Kim werteten in ihrem Buch „Accelerate“ (2018) mehrjährige Befragungen aus und fanden vier Kennzahlen, die Lieferleistung beschreiben: Häufigkeit der Auslieferungen, Durchlaufzeit einer Änderung bis in den Betrieb, Anteil fehlgeschlagener Änderungen und Zeit bis zur Wiederherstellung. Teams, die bei Geschwindigkeit gut abschneiden, schneiden dort auch bei Stabilität gut ab. Geschwindigkeit und Qualität verbessern sich also gemeinsam, und das ist der stärkste Grund, Aufräumen als Lieferthema zu behandeln. Eine steigende Durchlaufzeit bei sinkender Auslieferungshäufigkeit weist auf Schulden hin, bevor jemand sie benennt. Die Zahlen zum Fluss der Arbeit erläutert der Beitrag zu [Flow Metrics](/blog/flow-metrics-durchsatz-work-progress-wartezeit/).

## Welche Schulden sind vertretbar? Das Vierfeldmodell nach Fowler

Vertretbar sind Schulden, die bewusst und mit Plan zur Rückzahlung aufgenommen wurden. Martin Fowler ordnete 2009 technische Schulden entlang zweier Achsen: bewusst oder unbewusst, umsichtig oder leichtfertig. Daraus entstehen vier Felder, die verschiedene Antworten brauchen.

**Vierfeldmodell der technischen Schulden**
Kriterium | Umsichtig | Leichtfertig | Konsequenz für die Steuerung
Bewusst | Wir liefern jetzt und räumen nach dem Start auf | Für Design haben wir keine Zeit | Umsichtige Schulden mit Termin für die Tilgung im Plan eintragen, leichtfertige als Führungsthema behandeln
Unbewusst | Jetzt wissen wir, wie es richtig gewesen wäre | Was ist eine Schichtenarchitektur? | Umsichtige unbewusste Schulden sind Lernerträge und gehören in die nächste Planung, leichtfertige verlangen Qualifizierung und Prüfung im Team

Die Einordnung klärt, warum Aufräumen in manchen Organisationen scheitert. Wo bewusste Schulden ohne Termin aufgenommen werden, erreicht die Tilgung nie den Plan, weil sie keinen Auftraggeber hat. Wo Termine für Funktionen über jede Qualitätsregel gestellt werden, entstehen leichtfertige Schulden, und sie sind eine Frage der Führung.

## Wie berechnen Sie Zins und Tilgung?

Der Zins einer Schuld ergibt sich aus den Zusatzstunden je Änderung, multipliziert mit der Zahl der Änderungen pro Monat. Die Tilgung ist der einmalige Aufwand, der diesen Zins beseitigt. Teilen Sie die Tilgung durch den Zins, erhalten Sie die Rückzahlungsdauer in Monaten. Die folgende Rechnung ist illustrativ und zeigt den Weg.

**Rechenweg für drei Schulden**
Kriterium | Schuld A: Abrechnungsmodul | Schuld B: Schnittstelle zum Lager | Schuld C: Altes Berichtswesen
Änderungen pro Monat | 6 | 2 | 0,3
Zusatzstunden je Änderung | 10 | 8 | 20
Zins pro Monat in Stunden | 60 | 16 | 6
Tilgungsaufwand in Stunden | 240 | 160 | 400
Rückzahlungsdauer in Monaten | 4 | 10 | 67
Entscheidung | Sofort tilgen | In das nächste Quartal einplanen | Stehen lassen, Zins beobachten

Das Beispiel zeigt, dass der Zinssatz entscheidet und die Größe der Schuld nachrangig bleibt. Das Berichtswesen ist unschön und teuer zu beheben, aber da es kaum angefasst wird, bleibt der Zins klein. Das Abrechnungsmodul ist überschaubar und wird ständig geändert, deshalb zahlt sich die Tilgung binnen eines Quartals aus. Mit dem Stundensatz Ihres Teams multipliziert, wird aus der Rechnung ein Betrag, den Sie neben den Nutzen einer neuen Funktion legen können. Das Prinzip entspricht der Logik von [Cost of Delay](/blog/cost-of-delay/): Sie priorisieren nach den Kosten des Wartens.

Zum Zins zählen auch Fehlerkosten. Wenn ein Modul nach jeder Änderung zwei Korrekturen auslöst, gehört der Aufwand dafür in die Zusatzstunden. Setzen Sie nur Beträge an, die das Team aus eigenen Aufzeichnungen belegen kann, etwa aus dem Ticketsystem der letzten drei Monate.

## Wie viel Kapazität sollte für Aufräumen reserviert werden?

Reservieren Sie einen festen Anteil der Teamkapazität für Schuldenabbau und legen Sie ihn für jeden Planungszeitraum fest. Als Ausgangswert für die erste Planungsrunde eignet sich ein Zehntel bis ein Fünftel der Kapazität, den Sie anhand der Rückzahlungsdauer nachsteuern: Zeigt die Rechnung viele Schulden mit Rückzahlung unter einem halben Jahr, erhöhen Sie den Anteil, zeigt sie keine, senken Sie ihn. Die Größenordnung ist ein Erfahrungswert aus der Praxis der Lieferung und keine Studienzahl.

Der feste Anteil schützt vor zwei Fehlern. Der erste ist die Aufräumphase, die alle paar Jahre das ganze Team bindet und dem Geschäft nichts Sichtbares bringt, weshalb sie beim ersten Terminverzug gestrichen wird. Der zweite ist das Aufräumen nebenbei, das in jedem Sprint als erstes entfällt. Ein Anteil im Backlog, mit Eigentümer und Rechenweg, übersteht beides. Die Begrenzung gleichzeitiger Arbeit wirkt dabei in dieselbe Richtung, denn weniger parallele Vorhaben lassen Platz für Tilgung, wie der Beitrag zu [Work in Progress begrenzen](/blog/work-progress-begrenzen/) zeigt.

**Prüfliste für die Reihenfolge**
1. Wie oft wurde das Modul in den letzten drei Monaten geändert, und wie oft wird es in den nächsten drei Monaten geändert?
2. Wie viele Zusatzstunden je Änderung belegt das Ticketsystem?
3. Wie viele Korrekturen folgen im Schnitt auf eine Änderung?
4. Wie hoch ist die Tilgung, und wer im Team kann sie ohne Fachwissensverlust ausführen?
5. Welche geplante Funktion berührt das Modul, sodass sich die Tilgung mit ihr verbinden lässt?
6. Wie sieht die Definition of Done aus, die neue Schulden an dieser Stelle verhindert?

Die letzte Frage verbindet Abbau und Vorbeugung. Eine Definition of Done mit automatisierten Tests und Code-Review verhindert, dass beseitigte Schulden wiederkommen. Wie sie in der Praxis aussieht, zeigt der Beitrag zur [Definition of Done](/blog/definition-of-done/).

## Wie sprechen Sie mit der Geschäftsführung über technische Schulden?

Sprechen Sie in Stunden, Terminen und Fehlerzahlen, denn Architekturbegriffe lassen sich nicht gegen Umsatz abwägen. Die Geschäftsführung entscheidet zwischen einer Funktion, die im nächsten Quartal Umsatz verspricht, und einer Aufräumaufgabe, die das Team schneller macht. Diese Entscheidung gelingt nur, wenn beide Optionen in derselben Einheit stehen. Der Rechenweg liefert diese Einheit: Die Tilgung von Schuld A kostet 240 Stunden und gibt ab dem fünften Monat 60 Stunden pro Monat an die Lieferung zurück.

Ein Delivery Manager übernimmt in dieser Konstellation eine klare Aufgabe: Er führt die Schuldenliste mit Zins und Tilgung neben dem Funktions-Backlog, legt beide in der Quartalsplanung vor und hält die Entscheidung mit Eigentümer und Termin fest. Aus der Lieferperspektive zählt am Ende, ob Teams verlässlich zusagen können, und das hängt direkt an der Frage, wie viel Zins sie täglich bezahlen.

## Technische Schulden steuern mit Niehues Consulting

[Niehues Consulting](/) ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen und in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management arbeitet er als Delivery Manager, Projektmanager oder Product Owner und macht Schulden und Lieferleistung für die Entscheider sichtbar.

Das Vorgehen folgt dem Niehues Delivery Model. Für technische Schulden zählen drei seiner Prüffragen: Was ist der Ausgangswert, und woran messen wir den Erfolg? Welche Rollen, Entscheidungswege und Schnittstellen braucht der Betrieb? Wer verantwortet den Betrieb ab dem ersten Tag? Die Antworten legen fest, wer die Schuldenliste pflegt und wer über die Reihenfolge entscheidet. Umfang und Konditionen eines Vorhabens werden in der kostenfreien Erstberatung besprochen, die 30 Minuten dauert und über den [Kontakt](/#kontakt) vereinbart wird.

**Fazit**
Technische Schulden werden steuerbar, sobald Sie ihren Zins in Stunden pro Monat angeben und die Tilgung dagegen rechnen. Aufräumen beschleunigt die Lieferung dort, wo häufig geändert wird, und an Stellen, die niemand anfasst, bleibt der Zins klein. Ein fester Kapazitätsanteil mit Eigentümer sichert die Tilgung gegen jeden Termindruck.

**Grundlage**
- Cunningham, Ward: The WyCash Portfolio Management System, OOPSLA Experience Report, 1992
- Fowler, Martin: Technical Debt Quadrant, Fachartikel, 2009
- Sculley, D. et al.: Hidden Technical Debt in Machine Learning Systems, NIPS, 2015
- Forsgren, Nicole; Humble, Jez; Kim, Gene: Accelerate, Fachbuch, 2018

## Häufige Fragen

### Was sind technische Schulden einfach erklärt?

Technische Schulden sind Abkürzungen in Software, die heute Zeit sparen und später jede Änderung verteuern. Der Begriff stammt von Ward Cunningham aus dem Jahr 1992 und vergleicht die Abkürzung mit einem Kredit, für den ständig Zinsen anfallen. Zurückgezahlt wird mit Aufräumarbeit am Code.

### Wie messen Sie technische Schulden?

Technische Schulden messen Sie am besten über ihren Zins: Zusatzstunden je Änderung, Durchlaufzeit gleichartiger Änderungen und Korrekturen nach Releases. Diese Werte liefern das Ticketsystem und die Auslieferungsdaten. Statische Codeanalyse ergänzt das Bild, ersetzt aber nicht die Frage, wie oft ein Modul tatsächlich geändert wird.

### Wie viel Zeit sollte ein Team für Aufräumen einplanen?

Ein fester Anteil von einem Zehntel bis einem Fünftel der Teamkapazität eignet sich als Ausgangswert. Sie passen ihn an der Rückzahlungsdauer an: Viele Schulden mit Rückzahlung unter einem halben Jahr rechtfertigen einen höheren Anteil. Entscheidend ist, dass der Anteil im Plan steht und nicht bei Termindruck entfällt.

### Wann lohnt sich Refactoring?

Refactoring lohnt sich, wenn die Rückzahlungsdauer kürzer ist als der Zeitraum, in dem Sie das Modul weiter ändern werden. Als Planungsschwelle können Sie eine Rückzahlung innerhalb von sechs Monaten ansetzen, bei Code, der aktiv weiterentwickelt wird. Bei Code, der kaum angefasst wird, bleibt Refactoring ohne Wirkung auf die Lieferzeit.

### Soll man alte Systeme komplett neu bauen?

Ein Komplettneubau ersetzt die Schulden häufig durch neue und bindet das Team über lange Zeit, ohne dass Nutzer etwas davon sehen. Der Weg über schrittweise Tilgung der Stellen mit dem höchsten Zins liefert früher Wirkung. Ein Neubau kommt in Betracht, wenn die Technik keine Wartung mehr erhält oder die Tilgung aller Schulden teurer wäre als die Neuentwicklung.

### Wie überzeugen Sie die Geschäftsführung vom Aufräumen?

Überzeugen Sie mit einer Rechnung in Stunden und Terminen, die neben dem Nutzen neuer Funktionen steht. Ein Beispiel: Die Tilgung kostet 240 Stunden und gibt danach 60 Stunden im Monat zurück. Entscheider vergleichen dann zwei Investitionen mit Rückzahlungsdauer.

### Wer ist für technische Schulden verantwortlich?

Verantwortlich ist der Produktverantwortliche gemeinsam mit dem Team, weil nur er die Reihenfolge im Backlog bestimmt. Das Team liefert die Zahlen zu Zins und Tilgung, der Product Owner entscheidet über die Einplanung. Fehlt diese Verbindung, bleibt Aufräumen ein Thema, das jeder wichtig findet und niemand bezahlt.

### Haben KI-Systeme auch technische Schulden?

Ja, und zusätzlich zu den üblichen: Systeme mit maschinellem Lernen haben Schulden in Daten, Konfiguration und Überwachung. Ein Konferenzbeitrag von Sculley und Kollegen aus dem Jahr 2015 beschreibt diese Muster. Für KI-Anwendungen im Betrieb gehören sie deshalb von Beginn an in die Schuldenliste.