Technical debt: Was es ist und wie man damit umgeht

Stell dir Folgendes vor: Dein Team liefert Sprint für Sprint neue Features, doch jeder Sprint fühlt sich schwerer an als der vorherige. Kleine Änderungen kosten plötzlich Tage. Bugs tauchen immer wieder auf. Und irgendwo im Team fällt der Satz: „Ja … das ist technical debt.“ Aber was meinen wir damit eigentlich wirklich? Und vielleicht noch wichtiger: Was macht man damit?

Was ist technische Schuld?

Technical Debt ist eigentlich eine überraschend hilfreiche Metapher. Zu Deutsch, technische Schuld, entsteht in dem Moment, in dem man sich als Team für eine schnelle Lösung statt für die beste Lösung entscheidet. Man gewinnt kurzfristig Zeit, macht sich aber Schulden. Und wie bei jeder Schuld zahlt man dabei Zinsen.
Diese Zinsen zahlt man nicht in Form von Geld, sondern als:

• zusätzliche Arbeit
• Frustration
• Verzögerung

Um dies zu veranschaulichen, verwende ich das folgende Beispiel:

Du baust ein kleines Boot, um das Wasser zu überqueren. Das gefällt dir gut, also möchtest du es auch für andere Zwecke nutzen. Du möchtest mehr Personen oder zusätzliche Ladung mitnehmen oder längere Strecken zurücklegen. Dafür ist das Boot jedoch zu leicht und sinkt fast, also bringst du zusätzliche Luftkissen an. Dadurch fährt es langsam, und das Steuern kostet viel Mühe. Das kostet zusätzliche Zeit und Treibstoff und lässt sich erst lösen, wenn das Boot strukturell verbessert wird.

Es ist wichtig zu beachten, dass technische Schulden nicht per se schlecht sind. Manchmal sind sie sogar eine bewusste und vernünftige Entscheidung. Man muss etwas schnell live schalten, eine Frist ist unumgänglich oder man möchte erst herausfinden, ob etwas überhaupt einen Wert hat. Das kann völlig in Ordnung sein, solange man sich bewusst ist, dass man Schulden aufbaut, und vereinbart, wann man diese wieder abbaut.

Und genau da geht es oft schief.

Wie entsteht technische Verschuldung in der Praxis?

Theoretisch ist technische Verschuldung eine bewusste Entscheidung. In der Praxis entsteht sie oft schleichend.
Häufige Ursachen sind:

• Kurzfristiges Denken aufgrund knapper Fristen
• Sich ändernde Anforderungen der Stakeholder
• Der Einsatz neuer Technologien ohne ausreichende Kenntnisse
• Das Überspringen von Tests, „weil wir jetzt wirklich liefern müssen“

Das klassische Beispiel ist diese schnelle Demo. Schnell eine Verknüpfung erstellen, schnell etwas zusammenbasteln. „Das räumen wir später schon auf.“ Nur: „Später“ kommt selten von selbst. Und ehe man sich versieht, besteht der Code aus einer Ansammlung unvollendeter Verknüpfungen aus der Vergangenheit.

Welche Auswirkungen hat Technical Debt?

Technische Schuld bremst dein Team aus. Jede Änderung kostet mehr Zeit, da zunächst geklärt werden muss, wie das Ganze ursprünglich gedacht war. Das spüren vor allem die Entwickler: Die Wartung wird teurer und das Beheben von Fehlern fühlt sich an wie Jenga spielen: Man zieht einen Block heraus und an anderer Stelle stürzt etwas ein. Im Extremfall bist du nur noch mit der Wartung beschäftigt und kommst nicht mehr dazu, Neuerungen umzusetzen.Auf lange Sicht kann technische Verschuldung das Produkt sogar instabil machen, und dann hat man wirklich ein Problem.

Auf lange Sicht zeigt sich noch ein weiterer Effekt: Frustration. Teams beschäftigen sich immer mehr mit Reparaturen, anstatt Mehrwert zu schaffen. Das ist verhängnisvoll für die Motivation, die Vorhersehbarkeit und letztendlich auch für dein Produkt.

Technische Schulden sind also kein abstraktes IT-Problem. Es handelt sich um ein Produktproblem. Und damit um eine Verantwortung des gesamten Scrum-Teams.

Wie geht man damit sinnvoll um?

Der erste Schritt ist einfach, aber entscheidend: Machen Sie technische Schulden sichtbar.

• Dies kann unter anderem durch folgende Maßnahmen geschehen:
• Regelmäßige Code-Reviews
• Automatisierte Tests
• Tools, die Komplexität, Wartbarkeit und Risiken transparent machen

Aber es reicht natürlich nicht aus, Probleme nur sichtbar zu machen. Man muss auch etwas damit anfangen. In Scrum gibt es dafür einen ganz logischen Zeitpunkt: die Sprint-Retrospektive. Das ist der ideale Ort, um gemeinsam zu besprechen:

• Wo gibt es technische Schulden?
• Welche Auswirkungen hat das?
• Was werden wir dagegen tun?

Nicht, um sich zu beschweren, sondern um bewusste Entscheidungen zu treffen. Das Ergebnis dieser Sitzung kann direkt in das Backlog aufgenommen werden, um dort priorisiert zu werden.

Technische Schulden in Agile und Scrum

Scrum basiert auf Unsicherheit. Wir wissen nicht alles im Voraus. Deshalb überprüfen und passen wir uns in jedem Sprint an. Technische Schulden fügen sich genau in diese Denkweise ein, vorausgesetzt, man geht bewusst damit um. Das bedeutet, dass technische Schulden im Product Backlog aufgeführt werden sollten, wodurch sie transparent werden. Auf diese Weise kann der Product Owner gemeinsam mit dem Team Abwägungen treffen.

Überlegungen wie: Investieren wir jetzt in neue Funktionen oder sorgen wir zuerst dafür, dass das Produkt stabiler wird? Das lässt sich übrigens ganz einfach umsetzen, indem man in die Akzeptanzkriterien einer Story, die technische Schulden verursacht, folgenden Punkt aufnimmt: „Es wurde eine neue User Story zur Beseitigung der technischen Schulden erstellt“.

Refactoring als fester Bestandteil deiner Arbeit

Refactoring spielt dabei eine große Rolle. Kleine, kontinuierliche Verbesserungen am Code, ohne dass sich die Funktionalität ändert. Stell dir das so vor: In jedem Sprint ein bisschen aufräumen, statt einmal im Jahr einen großen Putz, der nie wirklich fertig wird.

Ein nützliches Hilfsmittel dabei ist die 80/20-Regel: Oft verursacht ein kleiner Teil des Codes den größten Teil der Probleme. Darauf solltest du deine Aufmerksamkeit richten.

Mehr erfahren