Technische Schulden im agilen Prozess abbauen

Softwareentwicklung ist ein Wettlauf gegen die Zeit. Aber oft fühlt es sich so an, als würden wir mit Bleigewichten an den Füßen rennen. Jedes neue Feature dauert länger als das letzte, jeder Bugfix reißt drei neue Löcher auf.

Willkommen in der Welt der technischen Schulden (Technical Debt).

Wenn du als Entwickler versuchst, Zeit für Refactoring zu bekommen, hörst du oft

„Dafür haben wir jetzt keine Zeit, das Business braucht Feature X.“

Das Problem: Das Business versteht nicht, dass es bereits Zinsen zahlt – und zwar in Form von sinkender Geschwindigkeit und steigender Instabilität.

In diesem Guide erfährst du, wie du technische Schulden im agilen Prozess nicht nur verwaltest, sondern sie so kommunizierst, dass selbst der Feature-getriebenste Product Owner versteht, warum wir sie abbauen müssen.

Die Metapher: Zinsen zahlen für schnellen Code

Der Begriff „Technische Schulden“ stammt von Ward Cunningham (einem der Väter des Agilen Manifests). Der Begriff ist genial, weil er ein technisches Problem in eine Sprache übersetzt, die das Management versteht: Geld.

Wenn wir eine „Quick and Dirty“-Lösung bauen, um eine Deadline zu halten, nehmen wir einen Kredit auf. Das ist okay, solange wir es bewusst tun. Aber wie bei jedem Kredit gibt es Zinsen.

Die Zinsen: Das ist der Mehraufwand, den wir bei jedem zukünftigen Ticket haben, weil wir um den hässlichen Code herumschreiben müssen.

Die Tilgung: Das ist das Refactoring, um den Code wieder sauber und wartbar zu machen.

Das Problem: Wenn wir nur Kredite aufnehmen und niemals tilgen, ist das Team irgendwann technisch insolvent. Wir verbringen 90 % der Zeit mit Bugfixes und Zinszahlungen und haben 0 % Zeit für Innovation.

Der Technical Debt Quadrant (nach Martin Fowler)

Um Tech Debt zu managen, musst du wissen, welche Art von Schulden du hast. Martin Fowler unterteilt sie in vier Quadranten.

• Umsichtig & Beabsichtigt: „Wir müssen jetzt releasen und nehmen die Schulden bewusst in Kauf. Wir räumen es danach auf.“ (Der „gute“ Kredit).
• Leichtfertig & Beabsichtigt: „Wir haben keine Zeit für Design, schlamp einfach irgendwas hin.“ (Der gefährliche Kredit).
• Leichtfertig & Unbeabsichtigt: „Was ist eigentlich ein Design-Pattern?“ (Das Team weiß es nicht besser – hier hilft nur Training).
• Umsichtig & Unbeabsichtigt: „Jetzt, wo wir fertig sind, wissen wir, wie wir es hätten bauen sollen.“ (Unvermeidlich – man lernt beim Coden).

Warum „Refactoring-Sprints“ meistens scheitern

„Lass uns die nächsten drei Sprints Vollgas geben und danach machen wir einen Refactoring-Sprint.“ Das ist die größte Lüge der Softwareentwicklung. Refactoring-Sprints scheitern fast immer aus zwei Gründen:

• Priorisierung: Sobald der Refactoring-Sprint ansteht, kommt ein „Prio-1-Kundenwunsch“ rein. Das Management wird den Sprint ohne direkten Business-Value immer als Erstes streichen.
• Isolation: Refactoring ohne Kontext ist schwer zu rechtfertigen. Code zu säubern, der sowieso nicht mehr angefasst wird, ist Verschwendung.

Daher: Refactoring muss ein kontinuierlicher Prozess sein, kein Event. Wenn du Tech Debt erst im „Großen“ abbauen willst, ist es meistens schon zu spät.

Die Boy Scout Rule: Code sauberer verlassen als vorgefunden

Die einzige nachhaltige Strategie gegen Tech Debt ist die Boy Scout Rule (Pfadfinder-Regel).

„Hinterlasse den Code immer ein Stück sauberer, als du ihn vorgefunden hast.“

Das bedeutet für deinen Sprint:

Wenn du ein Bug-Ticket bearbeitest, räumst du die hässliche Methode daneben gleich mit auf. Dieses „Micro-Refactoring“ kann auch Teil deiner Definition of Done (DoD) sein. Du fragst nicht um Erlaubnis für Unit-Tests oder sauberes Benennen von Variablen – das ist dein professioneller Standard. Wenn du Refactoring als integralen Bestandteil der Story-Schätzung betrachtest, wird es für das Management unsichtbar (und damit unantastbar). Es ist einfach die Art, wie ihr arbeitet.

Tech Debt im Backlog visualisieren

Manchmal sind die Schulden so groß, dass die Boy Scout Rule nicht mehr ausreicht. Wenn ihr eine ganze Architektur-Komponente austauschen müsst, braucht ihr Sichtbarkeit.

Der Trick mit den „Roten Tickets“

Packt technische Schulden als echte Items ins Product Backlog. Markiert sie farblich (z.B. Rot). Für die Benennung ein kleiner Kniff. Nennt den Task nicht „Refactoring der Datenbank-Klasse“ (Der PO hört nur: „Gold-Plating“) sondern nennt ihn „Risiko-Minimierung: Reduktion der Latenz und Behebung von Fehlern im Checkout-Prozess“. Sobald eine technische Schuld eine eigene Karte im Backlog hat, muss der PO sich aktiv entscheiden: „Ignoriere ich dieses Risiko (und zahle weiter hohe Zinsen) oder investiere ich in die Zukunft?“

Verhandlungsstrategien mit dem Product Owner

Als Entwickler neigen wir dazu, technisch zu argumentieren („Die Kopplung ist zu hoch“). Dein PO denkt aber in Opportunitätskosten. Um Zeit für Tech Debt zu bekommen, musst du seine Sprache sprechen. Dazu gibt es mehrere Argumente, die du hervorbringen kannst.

Das Zeit-Argument: „Wenn wir diese Komponente jetzt nicht aufräumen, werden alle zukünftigen Features in diesem Bereich doppelt so lange dauern. Wir verlieren unsere Time-to-Market.“

Das Risiko-Argument: „Dieser Code-Abschnitt ist extrem instabil. Wenn wir ihn nicht stabilisieren, riskieren wir unvorhersehbare Systemausfälle in der Hochsaison.“

Das Rekrutierungs-Argument: „Gute Entwickler wollen nicht in einer Müllhalde arbeiten. Wenn wir die Qualität ignorieren, wird es schwerer, neue Leute zu finden oder die aktuellen zu halten.“

Tipp: Nutze die Retrospektive, um die Schmerzen durch Tech Debt messbar zu machen. Zeig auf, wie viele Story Points ihr im letzten Sprint durch „Zinszahlungen“ (unnötiges Debugging) verloren habt.

Fazit: Qualität ist eine ökonomische Entscheidung

Technische Schulden sind unvermeidbar, aber sie dürfen nicht unkontrolliert wachsen. Ein agiler Prozess ist kein Freibrief für Schlamperei. Im Gegenteil: Nur wer seinen Code sauber hält, bleibt langfristig agil. Lerne, Tech Debt nicht als „Problem der Entwickler“ zu sehen, sondern als ein wirtschaftliches Risiko für das Produkt. Wer seine Zinsen nicht zahlt, wird irgendwann von der Konkurrenz überholt, die schneller liefern kann, weil ihr Code sie nicht behindert.

Schau als nächstes, was du noch im Entwickler Guide Agile für Entwickler für dich findest.