Bei technischen Schulden wird oft die Parallele zu Finanzschulden gezogen, doch bringt uns dieser Vergleich nur ein grobes Verständnis was technische Schulden eigentlich sind. Jedem leuchtet ein, dass eine reine Zahlung der Zinsen nicht genügt um seine Schulden abzubauen und um eine vollständige Tilgung herbeizuführen. Doch wie soll man mit dem Schuldenberg umgehen? Wie hoch darf er sein? Gibt es auch Investments die eine Verschuldung rechtfertigen?

Um technische Schulden ganzheitlich zu erfassen, müssen wir die Definition rund um die Schuldenfalle erweitern. In diesem Blog definieren wir technische Schuld umfassender als: alles wodurch die Entwicklung des Produkts gestört wird. Alles was die Qualität der Arbeit der Entwickler behindert und die Organisation dabei behindert produktiv zu sein, ist somit problematisch.

Technische Schulden entstehen ungewollt als auch beabsichtigt

Ein klassisches Beispiel für technische Schulden sind Entwickler die versuchen sich selbst zu überholen um asap zu liefern „Build it fast – rather than right“.
Doch wir können durchaus auch bewusst Schulden aufnehmen um eine höhere Entwicklungsgeschwindigkeit zu erhalten. Baut man jedoch diese Schulden in der Zukunft nicht ab, zahlt man hohe Zinsen, was wiederum in einer langsameren Velocity resultiert.
Genauso wie man verantwortungsbewusst oder leichtsinnig Kapital leihen kann, können Teams strategisch oder sorglos technische Schulden machen. Martin Fowler (2003) hat mit seinem Schuldenquadranten eine Möglichkeit vorgegeben wie man seine Schulden klassifizieren kann.

Mit dieser Sichtweise verliert der Begriff der Schulden plötzlich seine negative Resonanz. Wenn man die Betrachtung auf eine Investemententscheidung lenkt und versucht möglichst umsichtig mit seinen Resourcen / Kapital umzugehen, dann sind (strategische) technische Schulden eigentlich nur mehr ein Mittel zum Zweck um zum Beispiel einen Release an einem fixen Termin zu liefern. Wieviel Schulden muss/darf ich aufnehmen um meine Rendite/Velocity zu maximieren? Wie erreiche ich das Optimum aus Geschwindigkeit und Qualität?

Technische Schulden entstehen sowohl auf Team- als auch auf Organisationsebene
Dort wo Veränderung ist entstehen technische Schulden unaufhaltsam über die Zeit; sowohl auf Team als auch auf der Organisationsebene.

Indikatoren für Schulden auf Teamebene sind: niedrigere Entwicklungsgeschwindigkeit bzw. hohe Schwankungen, der Beginn von starren Zuweisungen von Aufgaben in den eigentlich cross-functional Teams; niedrige Moral und hohe Fluktuation. Die klassischen Auslöser hierbei sind fehlende Automatisierung und Testing, veraltete oder fehlende Dokumentation aber auch das vermischen von Rollen (wie z.B.: Scrum Master und Product Owner) als auch falsch ausgeführte Prozesse (ScrumBut).
Skaliert man das ganze, erkennt man hohe Schulden auf Organisationsebene durch reduzierten Output der Value Streams, schwer zu managenden Portfolios, langsame Reaktion auf Kundenwünsche und Reibung zwischen Teams und Gruppen von Menschen innerhalb der Organisation.

Umgang mit technischen Schulden

Mache den Umgang mit technischen Schulden zu einer alltäglichen Praxis. Frameworks wie SAFe helfen hierbei durch System Demos und dem Konzept der „Technical Agility“ und „Build in Quality“ die Qualitätsanforderung zu heben.

Umbenennen der „technischen Schuld“ in einen positiven Begriff wie „Produktgesundheit“. Yvette Pasqua schlug eine Strategie vor, die ihre Organisation schon früher angewandt hat, nämlich den Begriff “technische Schulden” aus dem Vokabular zu streichen und ihn durch “kontinuierliche Produktgesundheit” zu ersetzen. Wenn wir vom Begriff der Schuld sprechen, dann ist es als würden alle im Raum den Kopf einziehen bzw. folgt oftmals kurz darauf auch die zugehörige Schuld-Zuweisung. Streicht man jedoch den Begriff der Schuld aus dem Vokabular der Organisation und ersetzt ihn durch einen positiven Begriff wie Produktgesundheit, verändert sich auch der Zugang der Personen zum Thema.

Die Entwickler- First Line of Defence: Jeder Entwickler ist der Experte für seinen Code und dementsprechend liegt es auch in seiner Verantwortung die Qualität hoch zu halten. Product Owner müssen umgekehrt in ihrer Definition of Done der Stories bereits die Qualitätsmassstäbe und Strategie einfließen lassen.

Messbar machen. Einmal im Backlog erfasst ist die Gesundheit des Produkts sichtbar, der Aufwand abschätzbar und prioritisierbar. Der Product Owner kann nun entscheiden, ob im kommenden Inkrement/Sprint eine Funktionalität oder die Produktgesundheit Vorrang hat. Je nach Anwendung können auch andere Kennzahlen von Nutzen sein wie die Technical Debt Ratio (TDR = Redemiation Cost / Development Cost) wichtig ist nur hier Transparenz zu schaffen.

Produktzyklus und Risikoanalyse. Die Wiederherstellung der Produktgesundheit muss nicht zwingend auf Kosten des Fortschritts des Produkts passieren. Wenn wir die notwendigen Schritte nach Risiko und Nutzen priorisieren – also danach, welche Features für den Zweck des Unternehmens am kritischsten oder wertvollsten sind kann die Effektivität gesteigert werden. Das typische “Gut, Schnell oder Billig?” darf hierbei natürlich nicht fehlen. Man kann nur mit maximal zwei der drei Variablen ein Projekt umsetzen – also welche dürfen es sein?.

Präsentiere den Outcome der gesamten Organisation und den Stakeholdern. Kennen Sie den Geruch des Schweißes von Managern im Warteraum zur Vorstandssitzung? Er geht oftmals einher mit einer Präsentation die wochenlang überarbeitet wurde. Inhalt: Kosten des Refactoring-Projekts und Risiken bei nicht Realisierung. Klar, bei so einem Köder muss bald ein Fisch anbeißen. Leider ist dieser Fisch zu groß für unser Boot und wir werden es wohl nicht in den sichern Hafen schaffen.

Was ist schief gelaufen? Wieder wurde Schulden, Kosten und Risiken in den Fokus gerückt, wo doch Qualität/Produktgesundheit, Investments und Mehrwert für den Kunden und der Organisation im Rampenlicht stehen sollte. Der Schlüssel hierbei ist sein Produkt bestmöglich zu analysieren und zu kontrollieren, jedoch den Fokus hin zu den Begrifflichkeiten der wichtigsten Interessengruppen zu legen – Return on Investment.

Quellen:
SAFe Team and Technical Agility https://www.scaledagileframework.com/team-and-technical-agility/
Langlebige Software-Architekturen: Technische Schulden analysieren, begrenzen und abbauen, C. Lilienthal
How To Eliminate Organizational Debt, A. Dignan, https://medium.com/the-ready/how-to-eliminate-organizational-debt-8a949c06b61b
Tackling technical debt at scale https://craft-conf.com/2017/speaker/YvettePasqua