Schulden kennen wir alle. Wir haben bei einer Bank einen Kredit aufgenommen (monetäre Schulden), oder jemand hat uns einen Gefallen getan (moralische Schulden). In der Software-Entwicklung gibt es noch einen weiteren Schuldenbegriff: die technischen Schulden. Darunter verstehen wir ganz allgemein Abstriche in der Qualität, die im Entwicklungsprozess bewusst oder unbewusst herbeigeführt oder in Kauf genommen werden. Lassen Sie mich einige Beispiele aufzeigen:
- unzureichendes Design
- Defekte
- Verzicht auf automatisiertes Testen
- unzureichende Testabdeckung
Wir können technische Schulden anhand folgender Graphik einteilen:
- Ungewollte technische Schulden entstehen häufig versehentlich oder durch Unachtsamkeit.
- Unvermeidliche technische Schulden sind in der Regel nicht vorhersehbar. Ein Beispiel hierfür ist das Produktdesign. Wir können gerade bei der Entwicklung völlig neuartiger Produkte nicht mit Sicherheit sagen, wie sich das zu Beginn gewählte Design im Laufe der Zeit entwickeln muss oder sollte. Früh im Entwicklungsprozess getroffene Designentscheidungen müssen möglicherweise im Laufe des Produktlebenszyklus angepasst werden.
- Strategische technische Schulden sind solche, die Unternehmen bewusst in Kauf nehmen. Dies kann der Fall sein, wenn ein Release zu einem fixen Termin stattfinden muss.
Ganz gleich, aus welchem Grund technische Schulden entstanden sind, sie ziehen immer eine Reihe von Konsequenzen nach sich. Dabei gilt die Faustregel: Je höher die technischen Schulden, desto ernster die Folgen.
Konsequenzen aus technischen Schulden
Nicht vorhersehbare kritische Masse
Technische Schulden entwickeln sich nicht linear. Sie können eine ganze Zeit lang faktisch unbemerkt bleiben. Dann reicht jedoch ein einzelner zusätzlicher Defekt in der Software und das Produkt ist kaum noch beherrschbar. Der Wendepunkt dieser kritischen Masse ist nicht vorhersehbar.
Verzögerte Releases
Defekte von heute müssen morgen repariert werden. Das kostet Zeit, die in der Produkt(weiter-)entwicklung fehlt. In der Konsequenz sinkt die Velocity und der nächste Release verzögert sich. Die Wertschöpfung für den Kunden nimmt ab. Gerade in VUCA-Marktumgebungen ist dies ein erheblicher Wettbewerbsnachteil.
Steigende Support-Kosten
Eine sinkende Qualität in der Software wird mit der Zeit zu Fehlern und Performance-Einschränkungen im Produkt führen. In der Folge muss mehr Ad-hoc-Support geleistet werden, der sich als Kosten in der Bilanz niederschlägt. Auch die Kundenzufriedenheit wird unter mangelnder Qualität leiden.
Warum entstehen technische Schulden?
Wir kennen nun einige der negativen Folgen, die eine Anhäufung technischer Schulden haben kann. Und doch werden sie in der Realität nicht selten in Kauf genommen. Warum ist das so? Hier zwei Beispiele:
Fixe Deadlines
Fixe Deadlines führen nicht selten zu ungewollten und/oder strategischen technischen Schulden. Der Grund: Wir haben uns schlicht zu viel vorgenommen, bzw. die geplante Velocity konnte der Realität nicht standhalten. In solchen Situationen wird manchmal der Versuch unternommen, die Velocity durch eine Reduzierung der Test-Aktivität zu erhöhen. Umfangreiches Testen des Codes wird oftmals als zusätzliche (zeitraubende) Arbeit empfunden, vor allem, wenn die Tests nicht automatisiert sind. Ich rate an dieser Stelle streng davon ab, die Test-Aktivitäten zu reduzieren. Einerseits würden dadurch noch mehr technische Schulden aufgebaut. Andererseits wird die zukünftige Entwicklungsgeschwindigkeit bedroht, da durch fehlende Tests Probleme erst viel später entdeckt werden.
Schulden verursachen Schulden
Das Beispiel der Reduzierung der Test-Aktivitäten zeigt, dass vorhandene technische Schulden zu noch mehr Schulden führen. Ein immer größerer Anteil der Velocity muss zum Abbau oder für die Handhabung bestehender technischer Schulden aufgewandt werden.
Umgang mit technischen Schulden
Sichtbar machen
Beim Umgang mit technischen Schulden gilt als oberstes Gebot: Mache die Schulden sichtbar! Nur, wenn sowohl das Entwicklungsteam als auch das Management die Schulden erkennen, kann die notwendige Diskussion über Handlungsalternativen entstehen. Eine Möglichkeit der Sichtbarmachung ist die Quantifizierung der Fixkosten je Sprint und das Herunterbrechen auf die Story Points. Ein vereinfachtes Beispiel:
- Fixkosten des Scrum-Teams je Sprint: 20.000 Euro
- Velocity je Sprint (in Story Points): 20
- Ergebnis: Jeder Story Point “kostet“ 1.000 Euro
Sinkt die Velocity nun schuldenbedingt auf 10 Story Points je Sprint, erhöhen sich die Kosten je Punkt auf 2.000 Euro. Bei einem angenommenen Gesamtumfang des Projektes von 200 Story Points steigen die Kosten von insgesamt 200.000 Euro auf 400.000 Euro.
Sie wollen mehr über Story Points erfahren? In seinem Blogbeitrag “Story Points stellen weder Zeit, noch Menge, noch Wert dar”, beschreibt mein Kollege Conny Dethloff anschaulich die Dos und Don’ts im Umgang mit Story Points.
Als eigenes Backlog-Item erfassen
Eine ergänzende Möglichkeit, technische Schulden sichtbar zu machen, ist die Erfassung der Schulden als eigenständiges Backlog-Item. Der Product Owner muss nun entscheiden, ob im kommenden Sprint eine neue Funktionalität entwickelt oder Schuldenabbau betrieben werden soll.
Schulden vermeiden
Ist das Ausmaß der Schulden sichtbar gemacht, muss gehandelt werden. Am einfachsten ist es gewiss, ungewollte technische Schulden von vorneherein zu verhindern. Sie entstehen vielfach durch Unachtsamkeit bei der Programmierung. Das Team muss in die Lage versetzt werden, sorgfältig arbeiten zu können. Sollten fachliche Defizite zu ungewollten technischen Schulden führen, können gezielte Trainingsprogramme eingesetzt werden. Auch bewährte Praktiken, wie testgetriebene Entwicklung, Refactoring und kontinuierliche Integration helfen, ungewollten technischen Schulden vorzubeugen. Gerade Refactoring ist auch eine bewährte Möglichkeit, um bereits entstandene technische Schulden schrittweise abzubauen.
Starke Definition of Done
Auch eine starke Definition von „Fertig“ (Definition of Done) hilft technische Schulden zu vermeiden. Je granularer – und damit strenger – die gewählte Definition ausfällt, desto weniger wahrscheinlich ist die Entstehung neuer technischer Schulden.
Für den Abbau technischer Schulden gelten vier einfache Grundsätze
Grundsatz 1: Entdeckte technische Schulden werden sofort abgebaut
Sobald uns technische Schulden im Code auffallen, sollten sie umgehend abgebaut werden. Übersteigt dieser Aufwand einen vernünftigen Schwellenwert, werden die Schulden, die über diesen Schwellenwert hinausgehen, in das Backlog eingetragen und priorisiert.
Grundsatz 2: Baue die teuersten technischen Schulden zuerst ab
Diesem Grundsatz folgen wir vernünftigerweise auch bei anderen Schulden: den Bankdarlehen. Die Darlehen mit der höchsten Verzinsung werden zuerst zurückgezahlt. Was heißt das für unser Software-Produkt? Nicht jede technische Schuld zieht gleich hohe Konsequenzen nach sich. Treten z. B. viele Defekte in einem zentralen Modul unseres Produktes auf, werden die negativen Folgen größer sein als Folgen von Defekten in einem kaum genutzten Modul.
Grundsatz 3: Baue die technischen Schulden schrittweise ab
Die Wertschöpfung für den Kunden, bspw. in Form von neuen oder verbesserten Funktionalitäten, muss auch bei Vorhandensein technischer Schulden im Vordergrund stehen. Vermeiden Sie nach Möglichkeit reine „Schuldenabbau-Sprints“. Die kontinuierliche Arbeit an technischen Schulden sorgt zudem für die Sensibilisierung des Scrum-Teams. Es arbeitet sorgfältiger und vermeidet dadurch ungewollte technische Schulden.
Grundsatz 4: Nicht alle technischen Schulden müssen zwingend abgebaut werden
Zu den Umständen, in denen es sich nicht lohnt, technische Schulden abzubauen, gehören:
- ein Produkt am Ende seines Lebenszyklus
- Wegwerf-Prototypen
- sehr kurzlebige Produkte
Fazit
Technische Schulden gehören zur Realität vieler Unternehmen. Nicht immer sind den Beteiligten die Auswirkungen eines hohen „Schuldenberges“ bewusst. Machen Sie daher technische Schulden konsequent sichtbar! Ich haben Ihnen heute einige Möglichkeiten zur Eindämmung negativer Konsequenzen an die Hand gegeben. Haben Sie Anregungen und Anmerkungen zu meinem Beitrag? Teilen Sie diese gerne. Ich freue mich auf Ihre Kommentare.
Titelbild: Unsplash License, David Rangel
