Technische Schulden im agilen Prozess abbauen

Survival-Kit für Entwickler Teil 5 von 8 Zur Übersicht

Softwareentwicklung ist ein Wettlauf gegen die Zeit. Oft fühlt es sich an, als würdest du 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.

Wenn du Zeit für Refactoring bekommen willst, hörst du oft:

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

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

Die Metapher: Zinsen zahlen für schnellen Code

Der Begriff stammt von Ward Cunningham, einem der Väter des Agilen Manifests. Er 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 in Ordnung, solange wir es bewusst tun. Nur gibt es wie bei jedem Kredit Zinsen.

Die Zinsen sind der Mehraufwand bei jedem zukünftigen Ticket, weil du um den hässlichen Code herum arbeiten musst.

Die Tilgung ist das Refactoring, das den Code wieder wartbar macht.

Wenn ein Team nur Kredite aufnimmt und nie tilgt, ist es irgendwann technisch insolvent. Dann gehen neunzig Prozent der Zeit für Bugfixes und Zinszahlungen weg und null Prozent bleiben für alles andere.

Der Technical Debt Quadrant nach Martin Fowler

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

Umsichtig und beabsichtigt ist der gute Kredit: „Wir müssen jetzt releasen und nehmen die Schulden bewusst in Kauf. Wir räumen danach auf.“

Leichtfertig und beabsichtigt ist der gefährliche: „Wir haben keine Zeit für Design, schlamp einfach irgendwas hin.“

Leichtfertig und unbeabsichtigt heißt, das Team weiß es nicht besser. Da hilft nur Training.

Umsichtig und unbeabsichtigt ist unvermeidlich: „Jetzt, wo wir fertig sind, wissen wir, wie wir es hätten bauen sollen.“ 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 eine der größten Lügen der Softwareentwicklung, und sie scheitert aus zwei Gründen. Priorisierung: Sobald der Refactoring-Sprint ansteht, kommt ein Prio-1-Kundenwunsch rein, und ein Sprint ohne direkten Business-Value wird immer als Erstes gestrichen. Isolation: Code zu säubern, der sowieso nicht mehr angefasst wird, ist Verschwendung.

Refactoring muss ein kontinuierlicher Prozess sein, kein Event. Wer technische Schulden erst im Großen abbauen will, ist meistens zu spät.

Die Boy Scout Rule

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

Für deinen Sprint heißt das: Wenn du ein Bug-Ticket bearbeitest, räumst du die hässliche Methode daneben gleich mit auf. Dieses Micro-Refactoring kann Teil eurer Definition of Done sein.

Du fragst nicht um Erlaubnis für Unit-Tests oder für sauber benannte Variablen. Das ist dein professioneller Standard. Und wenn das Refactoring in der Story-Schätzung steckt, wird es für das Management unsichtbar und damit unantastbar. Es ist einfach die Art, wie ihr arbeitet.

Technische Schulden im Backlog sichtbar machen

Manchmal sind die Schulden so groß, dass die Boy Scout Rule nicht reicht. Wenn eine ganze Architektur-Komponente ausgetauscht werden muss, braucht ihr Sichtbarkeit.

Packt technische Schulden als echte Items ins Product Backlog und markiert sie farblich. Bei der Benennung liegt der Kniff: „Refactoring der Datenbank-Klasse“ hört der PO als Gold-Plating. „Risiko-Minimierung: Latenz und Fehler im Checkout-Prozess“ hört er als Geschäftsproblem. Sobald eine technische Schuld eine eigene Karte hat, muss er sich aktiv entscheiden, ob er das Risiko ignoriert oder investiert.

Verhandeln mit dem Product Owner

Als Entwickler argumentieren wir technisch: die Kopplung ist zu hoch. Dein PO denkt in Opportunitätskosten. Um Zeit zu bekommen, musst du seine Sprache sprechen.

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

Risiko: „Dieser Abschnitt ist extrem instabil. Ohne Stabilisierung riskieren wir Ausfälle in der Hochsaison.“

Rekrutierung: „Gute Entwickler wollen nicht in einer Müllhalde arbeiten. Wenn wir die Qualität ignorieren, wird es schwerer, Leute zu finden und zu halten.“

Nutze die Retrospektive, um den Schmerz messbar zu machen. Zeig, wie viel Zeit im letzten Sprint für unnötiges Debugging draufgegangen ist. Das sind die Zinsen, in Stunden.

Nebenbei: Warum Schätzdruck überhaupt zu technischen Schulden führt, steht in Story Points sind Unsinn?

Qualität ist eine ökonomische Entscheidung

Technische Schulden sind unvermeidbar. Unkontrolliert wachsen dürfen sie nicht. Ein agiler Prozess ist kein Freibrief für Schlamperei, sondern das Gegenteil: Nur wer seinen Code sauber hält, bleibt lieferfähig.

Nimm dir für diese Woche eine Sache vor: Leg eine Karte für die technische Schuld an, die dich am meisten bremst, und schreib den Titel in der Sprache deines POs. Damit fängt die Diskussion an.