Was sind technische Schulden?

Im Prinzip kann man sie mit finanziellen Schulden vergleichen, daher auch die Metapher. Einfach ausgedrückt: Wenn du etwas kaufen willst, das du dir aber im Moment nicht leisten kannst, musst du dir einen Kredit aufnehmen. Deine Schulden werden somit mehr. Ähnlich verhält es sich bei der Softwareentwicklung: Wenn du möchtest, dass ein Feature sofort vom Entwicklungsteam implementiert wird, du aber nicht über die notwendigen Entwicklungsressourcen verfügst, kann das Team das Feature mit großer Wahrscheinlichkeit liefern, aber es erhöht auch mit großer Wahrscheinlichkeit die technischen Schulden.

Um die technische Schuld greifbarer zu machen, stell dir mal vor, du möchtest einen Wolkenkratzer bauen. Ein modernes, solides und langlebiges Gebäude. Du hast einen straffen Projektplan mit strikten Fristen, und dein Bauteam gibt sein Bestes, um den Plan in die Realität umzusetzen. Jedoch stellt sich heraus, dass es mit den Rahmenbedingungen nicht 100%ig klappen wird. Dein Bauteam findet aber einen Weg, das Projekt trotzdem rechtzeitig und im Rahmen des Budgets fertigzustellen. Wie? Sie lassen die Klempnerarbeiten vorerst aus. Das Fundament braucht keine Sanitäranlagen, also werden die Sanitäranlagen auf einen späteren Zeitpunkt verschoben, wenn wieder mehr Mittel zur Verfügung stehen. In diesem Fall ist der Verzicht auf die Sanitärinstallation eine technische Schuld.

Warum ist die technische Schlud ein Problem? An sich ist die technische Schuld kein Problem, aber sie kann sich zu einem projektfressenden Problem entwickeln - denke an den Alligator.

Warum kann ein Softwareprojekt an technischen Schulden scheitern?

Um auf die Metapher des Wolkenkratzers und das Worst-Case-Szenario zurückzukommen: Das Bauteam sagt dir nicht, dass die Sanitäranlagen noch nicht fertig sind. Sie haben es sogar ganz vergessen, weil sie so damit beschäftigt waren, den Zeitplan einzuhalten. Am Ende ist der Wolkenkratzer fertig, sieht toll aus und du bist zufrieden, weil alles im Budget und im Zeitplan geblieben ist. Aber wenn die erste Person auf die Toilette muss, kannst du dir vorstellen, dass die Enttäuschung groß ist. Und du kannst dir wahrscheinlich auch vorstellen, wie teuer es ist, alle Sanitäranlagen in einem "fertigen" Hochhaus zu installieren.

Das ist ein Worst-Case-Szenario, und es gibt Prozesse, um solche Fehler im Bauprozess zu vermeiden oder zumindest zu minimieren. Das Gleiche gilt auch für Softwareprojekte. Trotzdem gibt es Beispiele aus der Praxis, wo technische Schulden katastrophale Folgen hatten, sowohl im Bauwesen als auch bei Softwareentwicklungsprojekten. Wir müssen mit technischen Schulden also richtig umgehen.

Es ist vielleicht in Ordnung, die Klempnerarbeiten ein paar Wochen aufzuschieben, während die Fundamente des Wolkenkratzers gebaut wurden. Aber sie aufzuschieben und dann zu vergessen, führte in diesem Beispiel am Ende zur Katastrophe.

Vielleicht kennst du dieses Diagramm schon. Es veranschaulicht die Kosten von Änderungen in der Softwareentwicklung. Je später ein Fehler entdecken wird oder je länger Funktionen oder Verbesserungen hinausgezögert werden, die für die Grundlage des Projekts wichtig sind, desto exponentieller steigen der Aufwand und die Kosten.

Welche Anzeichen sprechen für ein schnelles Handeln?

Es ist nicht immer leicht zu erkennen, aber es gibt Anzeichen, die oft darauf hinweisen, dass etwas nicht stimmt. Manche stecken den Kopf in den Sand. So viel kann ich verraten: wie so oft ist das eine schlechte Strategie. Denn wenn du die Anzeichen ignorierst, wird alles nur noch schlimmer.

Von Zeit zu Zeit werden wir hinzugezogen, um ein bestehendes Projekt zu retten, bei dem die folgenden Indikatoren zu lange ignoriert wurden und die technischen Schulden letzten Endes zu erdrückend wurden. Einige dieser Projekte mussten leider abgebrochen und neu begonnen werden, weil es keine Möglichkeit gab, das Projekt für weniger als die Kosten einer kompletten Neuentwicklung zu retten. Das kommt selten vor, aber es kommt vor. Und ich bin sicher, dass du diese Situation gerne vermeiden möchtest. Konzentrieren wir uns also auf die Indikatoren, die das Schlimmste verhindern können. Dann gebe ich dir Tipps und Werkzeuge an die Hand, mit denen du dein Projekt wieder auf Kurs bringen kannst.

Deadlines werden regelmäßig nicht eingehalten

Eines der offensichtlichsten Anzeichen ist, dass neue Funktionen oder Änderungen länger dauern als erwartet. Je größer das Projekt ist, desto langsamer wird die Implementierung. Und das ist nicht allein die Schuld der Entwickler:innen, dies ist normalerweise das Ergebnis vieler verschiedener Faktoren und Rollen.

Neue Features zerstören bestehende Funktionalität

Ein weiterer Indikator ist, dass neue Features bestehende Funkionalität zerstören. Dies wiederum führt zu mehr Zeit und Aufwand, um diese Probleme zu beheben und die neue Funktionalität zu implementieren.

Fehlende Motivation

Ein Indikator auf der emotionalen Seite: Der Enthusiasmus und die Motivation der Entwickler:innen, die am Projekt oder an neuen Funktionen arbeiten, lässt nach.

Die Hauptursache für technische Schulden

Bevor wir uns der Frage zuwenden, wie mit technischen Schulden umgegangen werden soll, müssen wir das Kernproblem verstehen. Unserer Erfahrung nach - so irrational es auch klingen mag - geben die meisten Menschen nur ungern zu, dass sie Schulden haben. Seien es finanzielle oder technische Schulden. Als Entwickler:in gibt man nur ungern zu, dass man eine Funktion nicht rechtzeitig oder nicht richtig implementiert hat. Als Projektmanager:in gibt man nur ungern zu, dass man eine Deadline nicht einhalten kann. Und als CEO möchtest du der Presse nicht mitteilen, dass sich dein brillantes neues Produkt verzögert hat.

Um zu verhindern, dass technische Schulden zu einem völligen Scheitern des Projekts führen, ist daher ein proaktives Schuldenmanagement unerlässlich. Es is kein Problem, finanziell oder technisch verschuldet zu sein, solange man sich dessen bewusst ist, entsprechend handeln kann und in der Lage ist, die anfallenden Zinsen zu zahlen (beachten Sie, dass diese exponentiell mit der technischen Schulden steigen).

Der richtige Umgang mit technischen Schulden

Das Management technischer Schulden in Softwareentwicklungsprojekten ist mit dem Qualitätsmanagement, der Unternehmens- und Teamkultur, dem Anforderungsmanagement sowie dem Projekt- und Teammanagement verbunden. Es würde den Rahmen dieses Blogposts sprengen, hier ins Detail zu gehen. In unserer Web Development Masterclass widmen wir die erste Woche diesem Thema. Wenn du also lernen möchtest, wie du proaktiv mit technischen Schulden umgehen kannst und Tipps und Tricks aus über 15 Jahren Erfahrung in der Entwicklung von Webanwendungen und SaaS-Lösungen für Unternehmen und Teams jeder Größe erhalten möchtest, dann ist die Web Development Masterclass vielleicht genau das richtige für dich.

Ich werde aber versuchen, dir schon jetzt möglichst viele Ansatzpunkte zu vermitteln, die du sofort anwenden kannst.

Sichere Umgebung

Schaffe ein sicheres Umfeld, in dem die Mitarbeiter:innen regelmäßig über bevorstehende Herausforderungen, spontane Änderungen und plötzlich auftretende Probleme sprechen können. Ohne dafür verurteilt zu werden. Wenn du mit deinem Team eine tägliche Besprechung hast, dann nutze diese, um das Team zu ermutigen, offen über aufgetretene Hindernisse zu sprechen. Je früher jeder über Probleme, mögliche Verzögerungen oder unvorhergesehene Hindernisse Bescheid weiß, desto besser kann damit umgegangen werden.

Technische Schulden dokumentieren

Richte ein System zum Sammeln von Aufgaben und User Stories über technische Schulden ein, damit Projektleitung und Entwicklungsteams immer auf dem Laufenden sind und sie nicht vergessen. Jeder kennt das Feature Backlog und offensichtliche Front-End Bugs. Aber technische Schulden werden oft übersehen, weil sie nicht offensichtlich sind. Man sieht sie oft erst, wenn es zu spät ist. Deshalb ist Dokumentation so wichtig.

Die Zinsen bezahlen

Sobald du die ersten beiden Punkte umgesetzt hast, ist es an der Zeit die technischen Schulden sukzessive abzubauen. Adaptiere den Projektplan, damit technischen Schulden sukzessive abgebaut werden können, bevor das Pojekt live geht oder die nächste Version veröffentlicht wird. Eine Möglichkeit ist zum Beispiel spezielle Sprints für Refactorings und den Abbau der technischen Schulden zu reservieren. Wenn ihr nicht mit Sprints arbeitet, könnt ihr z.B. auch alle zwei Monate eine Woche dafür reservieren. Oder vielleicht gibt es pro Sprint einen Tag um technische Schulden zu adressieren. In der Realität funktioniert dieser Ansatz oft leider nur mäßig gut. Denn wenn es so viel Zeit im Sprint gäbe würden ja von vorn herein keine technischen Schulden aufgebaut werden.

Reflektieren und anpassen

Als Entwicklungsteam sollte man regelmäßig reflektieren und anpassen. Was ist im letzten Sprint oder in den letzten Wochen gut gelaufen, was ist nicht gut gelaufen und wie können diese Punkte verbessert werden. Auch in Hinblick darauf, was ihr in den letzten zwei Wochen erreichen wolltet und was tatsächlich erreicht wurde. Gibt es eine Diskrepanz zwischen diesen beiden Werten? Wenn ja, versucht, den nächsten Sprint oder die nächsten zwei Wochen unter Berücksichtigung dieser Fehleinschätzung zu planen. Ihr könnt und sollt ehrgeizige Pläne machen, aber ihr solltet auch regelmäßig über die Ergebnisse reflektieren und Anpassungen vornehmen, damit der Fahrplan realistisch bleibt.

Gewohnheiten und Prozesse

Prozesse finden, definieren und optimieren, das ist die Devise. Ich spreche nicht von Prozessen um der Prozesse willen. Ich spreche von Richtlinien und Gewohnheiten. Welche Aufgaben sind besonders mühsam und wiederholen sich regelmäßig? Git es eine Möglichkeit diese Aufgaben zu vereinfachen oder zu automatisieren?

Ich höre oft das Argument, dass Prozesse Kreativitätskiller sind. Ich bin anderer Meinung. Prozesse, die dabei helfen, wiederkehrende und langweilige Aufgaben ohne viel Nachdenken zu erledigen, setzen geistige Kapazitäten für die kreativen und schwierigen Herausforderungen frei. Diese Herausforderungen machen oft den Spaß, den Enthusiasmus und die Motivation in der Softwareentwicklung aus.

Einige Beispiele, die geändert werden können um sie weniger anstrengend zu machen: Klare Regeln für die täglichen Stand-ups (Zeitrahmen, was besprochen werden sollte). Klare Regeln für Code-Reviews (wer ist für die Code-Reviews verantwortlich, legt Review-Zeiten fest und macht es zu einer täglichen Gewohnheit - z.B. nach dem Morgenkaffee oder dem täglichen Stand-up und nach der Mittagspause). Klare Regeln für den Code-Stil, Definition of Ready, Definition of Done.

Qualitätskontrollen automatisieren

Sobald ihr de die Prozesse identifiziert habt, kommt der nächste Schritt. Prozesse, die klar definiert sind und keinen Spielraum für kreative Änderungen benötigen, können mit hoher Wahrscheinlichkeit automatisiert werden. Zum Beispiel die Einführung von Code Formattern, damit sich ein einheitlichen Code-Stil durch das Projekt zieht. Der Code ist dadurch leserlicher und verständlicher.

Manuelles Testen kann vermutlich reduziert werden. Stattdessen sollte ein automatisiertes Testsystem inklusive Tests etabliert werden. Dies ist eine enorme Zeitersparnis für Entwicklungsteams. Nicht nur weil eine Menge manueller Tests eingespart werden können, sondern auch weil Refactoring und Entwicklungsgeschwindigkeit beibehalten werden können. Selbst wenn das Projekt wächst. Warum ist das so? Große Softwareentwicklungsprojekte haben oft die Problematik, dass bestehende Features nicht mehr funktionieren, wenn neue Funktionen hinzufügt oder Dinge verändert werden. Ohne automatisierte Tests weiß man jedoch nicht, ob durch die Änderung an einer anderen Stelle etwas nicht mehr funkioniert, weil man eigentlich jedes Mal, wenn man Code hinzufügt oder ändert, das gesamte Softwareprojekt manuell testen müsste.

Durch automatisierte Tests, die während der Entwicklung einfach durchzuführen sind, weiß man sofort, wenn und vor allem was nicht (mehr) funktioniert. Es ist daher viel einfacher, Änderungen vorzunehmen. Und es ist viel zufriedenstellender, wenn eine neue Funktion implementiert wurde und man sicher sein kann, dass keine der anderen 378 vorhandenen Funktionen dadurch beeinflusst wird. Und weil man diesen "Beweis" aus allen 623 bestehenden Tests hat, ist die Qualität des gesamten Systems definiert.

Okay, ich könnte noch viel mehr über Tools erzählen, aber ich denke, du weißt, worum es geht: Automatisierung spart dem Entwicklungsteam Zeit, steigert die Zufriedenheit und hält die Qualität und Entwicklungsgeschwindigkeit hoch.

Die Vorteile eines guten Umgangs mit den technischen Schulden

Wenn du dich für ein proaktives Management der technischen Schulden entscheiden, wirst du in vielerlei Hinsicht belohnt. Ob Projektmanager:in oder Entwickler:in, du wirst das Gefühl haben, die Kontrolle zu haben. Und die hast du auch. Es warten keine Alligatoren unter der Wasseroberfläche auf dich. Du kennst sie und kannst mit ihnen umgehen, um den Fluss sicher zu überqueren.

Kontrolle, Werkzeuge und automatisierte Prozesse nehmen viel mühsame Arbeit ab. Und Richtlinien und Gewohnheiten führen zu weniger mentalem Aufwand. Das führt letztlich zu mehr Zufriedenheit bei allen Beteiligten.

Eine Kultur, in der Probleme und Fehleinschätzungen angesprochen werden können, ohne dass man dafür an den Pranger gestellt wird, in der lösungsorientiert gedacht wird, führt zu mehr Begeisterung für das Erreichen von gemeinsamen Zielen..

Technische Schulden sind nichts, wofür man sich schämen muss. Sie kommen in jedem Projekt von Zeit zu Zeit vor. Wenn du mir ein Projekt ohne technische Schulden zeigen kannst, ist es wahrscheinlicher, dass die Beteiligten sich dessen nicht bewusst sind, als dass es tatsächlich keine technischen Schulden gibt. Der Schlüssel liegt also nicht darin, technische Schulden zu vermeiden, sondern sie zu managen und bewusst zu reduzieren.

Wenn du mehr über den Umgang mit technischen Schulden, Qualitätsmanagement, Projekt- und Teammanagement in SaaS- und Webapplikationsentwicklungsprojekten erfahren möchtest: ich bin der Kursleiter der Web Development Masterclass, in der wir viele weitere Dinge und Details technologieunabhängig behandeln. Die Web Development Masterclass ist für Entwickler:innen, Team- und Projektleiter:innen. In diesem 4-wöchigen Live-Online-Kurs lernst du viele praktische Tipps und Tricks. Weitere Details unter Web Development Masterclass

Happy coding!

An der Web Development Masterclass teilnehmen