In jeder Debatte über technische Schulden tauchen dieselben Fragen auf: Wie entstehen sie? Wie bauen wir sie ab? Welche Strategien helfen? Diese Diskussionen bleiben aber fast immer innerhalb der Technik-Bubble. Was fehlt, ist die Perspektive des Projektmanagements und des Controllings. Die Fragen, die eigentlich gestellt werden müssten: Warum lässt ein Projektbudget technische Schulden überhaupt zu? Warum priorisiert das Management neue Features statt Stabilität? Warum wird der Abbau immer wieder verschoben?

Warum technische Schulden unsichtbar bleiben

Die Antwort liegt in einer grundlegenden Eigenschaft technischer Schulden: Sie sind nicht sichtbar. Nicht für das Management, nicht für das Controlling, oft nicht einmal für den Kunden.

Menschen reagieren auf das, was sie sehen und anfassen können. Ein überquellender Briefkasten wird geleert, ein tropfender Wasserhahn repariert, ein Müllsack im Flur weggeräumt. Das passiert automatisch, weil das Problem offensichtlich ist und das Wegschauen Unbehagen verursacht.

Veraltete Abhängigkeiten, fehlende Tests oder eine gewachsene Architektur erzeugen kein solches Unbehagen. Sie sind für niemanden außerhalb der Entwicklung sichtbar. Der Code funktioniert weiterhin. Die Anwendung läuft. Der Kunde merkt nichts. Warum also Geld ausgeben, um etwas zu reparieren, das von außen betrachtet nicht kaputt ist?

Die Analogie zu Finanzschulden

Bei Finanzschulden funktioniert der Tilgungsmechanismus, weil er eingebaut ist: Du nimmst einen Kredit auf, zahlst Zinsen, und der Druck zur Rückzahlung ist real und messbar. Bei technischen Schulden fehlt dieser Mechanismus vollständig.

Die Schulden wachsen still. Jeden Monat ein wenig mehr. Und irgendwann werden die Auswirkungen spürbar, aber auf eine Art, die sich schwer einem einzelnen Ursache-Wirkungs-Zusammenhang zuordnen lässt.

Features dauern doppelt so lange wie früher. Bugs treten häufiger auf und sind schwerer zu lokalisieren. Neue Teammitglieder brauchen Wochen statt Tage für die Einarbeitung. Release-Zyklen werden länger, weil jede Änderung unerwartete Seiteneffekte produziert. Das Team wird vorsichtiger und frustrierter.

Jedes einzelne dieser Symptome hat auch andere mögliche Erklärungen. Deshalb ist es so schwer, den kausalen Zusammenhang zwischen technischen Schulden und den beobachteten Problemen herzustellen. Und deshalb wird die Ursache so selten adressiert.

Niemand kann genau vorhersagen, wann der Kipppunkt erreicht ist. Aber wenn er erreicht ist, kostet die Sanierung ein Vielfaches dessen, was die laufende Pflege gekostet hätte. In manchen Fällen wird die Sanierung wirtschaftlich unmöglich, und das einzige verbleibende Mittel ist ein Neubau, mit all den Risiken und Kosten, die das mit sich bringt.

Warum der Abbau immer wieder verschoben wird

Das Muster ist in fast jedem Projekt gleich: Das Team weiß, dass technische Schulden existieren. Die Schulden stehen möglicherweise sogar im Backlog. Aber wenn es um die Priorisierung geht, gewinnen neue Features. Immer.

Das hat rationale Gründe. Ein neues Feature hat einen sichtbaren Geschäftswert: Der Kunde hat es angefragt, der Vertrieb braucht es, das Management erwartet es. Die Reduktion technischer Schulden hat keinen sichtbaren Geschäftswert, zumindest nicht kurzfristig. Sie macht vorhandene Dinge besser, aber sie erzeugt kein neues Feature, das man vorzeigen kann.

Dazu kommt: Wer vorschlägt, Sprint-Kapazität für den Abbau technischer Schulden zu reservieren, muss erklären, warum. Und diese Erklärung erfordert technisches Verständnis auf Seiten des Empfängers. „Die Architektur ist gewachsen und muss refactored werden“ ist für das Controlling keine handlungsleitende Information. „Wir verlieren jeden Monat 20 Stunden Entwicklerzeit durch Workarounds, die nach einem Refactoring entfallen würden“ dagegen schon.

Technische Schulden sichtbar machen

Der Weg, technische Schulden aus der Technik-Bubble zu holen, führt über die Sprache des Managements.

In Euro rechnen: Nicht in Story-Points, nicht in „technischem Risiko“, sondern in tatsächlichen Kosten. Wie viele Stunden pro Monat gehen für die Arbeit mit veraltetem Code drauf? Wie oft verzögern sich Features wegen technischer Altlasten? Was kostet ein Ausfall, wenn die fragile Stelle bricht? Diese Zahlen sind schätzbar, auch wenn sie nicht exakt sind. Eine grobe Schätzung in Euro ist für das Management handlungsleitender als eine präzise Beschreibung des technischen Problems.

Regelmäßig berichten: Technische Schulden gehören in den Projektbericht, nicht nur in die Sprint-Retrospektive. Wenn das Controlling sieht, dass jeden Monat 20 Stunden in Workarounds fließen, wird der Business Case für die Sanierung nachvollziehbar. Die Schulden sind dann kein abstraktes Technikproblem mehr, sondern ein bezifferter Kostenfaktor.

Kontinuierlich tilgen statt auf den großen Wurf warten: Der große Refactoring-Sprint, der alles auf einmal löst, kommt in der Praxis selten zustande, weil er schwer zu rechtfertigen ist und das Projekt für Wochen blockiert. Wirkungsvoller ist es, in jedem Sprint einen festen Anteil der Kapazität für technische Pflege zu reservieren. 10 bis 20 Prozent sind eine Größenordnung, die das Feature-Tempo nicht spürbar bremst, aber über Monate und Jahre einen erheblichen Effekt hat.

Fazit

Technische Schulden verschwinden nicht durch Ignorieren. Sie wachsen, und sie kosten: in Entwicklungsgeschwindigkeit, in Qualität, in Motivation des Teams und letztlich in Euro. Der Unterschied zwischen Teams, die technische Schulden im Griff haben, und solchen, die daran scheitern, liegt selten im Budget. Er liegt darin, ob jemand die Schulden sichtbar macht, in der Sprache des Managements beziffert und konsequent in kleinen Portionen tilgt.