Suche
Neue Betriebswirtschaftslehre für Softwareentwicklung

Technische Schulden in der Softwareentwicklung: weniger ist mehr

Gerrit Beine

© iStock / freelancebloke

Die spektakuläre Pleite von Lehman Brothers ist nun sieben Jahre her. An der Frage, ob die Finanzwelt aus diesem Ereignis etwas gelernt hat, scheiden sich die Geister. Eine andere Frage, die mindestens ebenso spannend ist, wurde aber bislang gar nicht gestellt: Was hat die Softwareentwicklung aus der Pleite von Lehman Brothers gelernt? Eine Frage von zugegebenermaßen nicht geringer Größe, deren Antwort notwendigerweise umfangreich ausfallen muss. Als Informatiker möchte ich mich der Antwort mit einer weit verbreiteten Methode aus der Softwareentwicklung nähern: divide and conquer.

Am 29.05.2009 geschah in Deutschland etwas, das kaum ein Softwareentwickler bemerkt hat, obwohl es seine Arbeit direkt betraf. An diesem Tag wurde der § 248 HGB geändert, sodass es ab sofort möglich war, die Aufwände für die Entwicklung von Software in einem Unternehmen als nicht materiellen Vermögensgegenstand in dessen Bilanz zu aktivieren. Auch wenn – oder gerade weil – sich nur wenige Softwareentwickler, die ich kenne, für die Feinheiten der Bilanzbuchhaltung interessieren, möchte ich kurz erläutern, was diese Änderung genau bedeutet: Kapitalgesellschaften sind verpflichtet, zweigeteilte Bilanzen zu erstellen.

CaH8F2YWEAAkDgX.jpg_largeIT Leadership und Lean Business ist der JAX-Track dieser Woche, den wir mit Hintergrundartikeln, Videos und Interviews auf JAXenter vorstellen.
Bisher erschienen:

.Divide: Software aus Sicht des Ökonomen

Eine Seite sind die so genannten Aktiva, die andere Seite wird als Passiva bezeichnet. Historisch betrachtet stehen auf der Aktivseite Vermögensgegenstände, die liquidierbar sind, also verkauft werden können. Die Passivseite beinhaltet im Wesentlichen Kapitalpositionen wie die Einlagen der Gesellschafter oder Kredite, die das Unternehmen aufgenommen hat. Eine solche Bilanz ist ein Aspekt, wenn es darum geht, Unternehmen zu bewerten.

Eine sehr einfache, wenn auch naive Betrachtung der Bilanz kann sein, dass ein Unternehmen mit hohen Werten auf der Aktivseite ein großes Anlagevermögen besitzt, sowohl an materiellen Gütern als auch an immateriellen Vermögensgegenständen. Software, die den Regeln des § 248 HGB genügt, ist ein solcher immaterieller Vermögensgegenstand.

Aus Sicht des Ökonomen ist eine Software – aus der Perspektive der Bilanz – also besonders wertvoll, wenn ihre Erstellung teuer war, was im Sinne dieses Paragraphen gleichbedeutend damit ist, dass viel Aufwand geleistet wurde, um sie zu erstellen. Das ist natürlich nur eine vereinfachte Darstellung. Aber da die Aufwandsbewertung in der Praxis durchaus angewendet wird, möchte ich sie nutzen, um die Gefahr einer solchen Bewertung von Software zu zeigen.

Divide: Technische Schulden und Aufwand

Fragt man Softwareentwickler danach, was technische Schulden sind, bekommt man viele verschiedene Erklärungen. Eine wissenschaftliche oder formale Definition gibt es bisher nicht. Zuerst wurde der Begriff von Ward Cunningham verwendet, um den Zusammenhang zwischen Entscheidungen während der Softwareentwicklung und den ökonomischen Auswirkungen auf die Software für Nicht-Softwareentwickler deutlich zu machen.

Die Definition des Begriffs umfasst je nach Umfeld das Nichtdurchführen oder Aufschieben bestimmter Handlungen, wie das Erstellen von Dokumentation oder Tests oder Investitionen in Infrastruktur. Oft werden aber auch die Verwendung von Antipatterns, ein schlechter Programmierstil oder das Ignorieren von Coding-Standards als technische Schuld betrachtet. Zu komplizierte Lösungen, wie sie hin und wieder durch Overengineering entstehen, und Softwareerosion werden ab und an ebenfalls zu den technischen Schulden gezählt.

Neben allen diesen verschiedenen Definitionen zur Natur technischer Schulden ist es interessant, dass ihre Wirkung sehr gleichförmig ist: Technische Schulden wirken primär als Aufwandstreiber. Es ist aufwändiger, eine Software weiterzuentwickeln, die technische Schulden beinhaltet, als eine Software ohne solche. Und je länger die technischen Schulden bestehen, desto stärker wirken sie sich aus. An dieser Stelle gibt es also durchaus eine Äquivalenz zwischen finanziellen Schulden, die sich durch Zinsen vermehren, und den technischen Schulden, deren Beseitigung immer aufwändiger und damit teurer wird.

Nun kann aber Software betriebswirtschaftlich nach dem Aufwand ihrer Erstellung bewertet werden. Eine Software mit hohem Erstellungsaufwand ist in dieser Betrachtung wertvoller, weil teurer, als eine Software mit niedrigem Erstellungsaufwand. Ein Schelm, wer nun auf die Idee kommt, dass Software mit technischen Schulden aufgrund ihres höheren Aufwands zur Weiterentwicklung wertvoller ist als Software ohne technische Schulden. Allerdings erlaubt die betriebswirtschaftliche Logik genau diesen Weg. Mehr noch: Die Software mit technischen Schulden hat einen höheren Wertzuwachs als Software ohne, wenn in beiden Fällen eine ähnliche Weiterentwicklung stattfindet.

Kommt dieser Mechanismus zur Anwendung und wird als immaterieller Vermögenswert betrachtet, können erstaunliche Parallelen zur Geschichte der Bank Lehman Brothers entdeckt werden. Diese spektakuläre Pleite der Bank im Jahr 2008 war unter anderem die Folge einer sehr interessanten Bewertung von Krediten. Weltweit wurden damals Kredite für Eigenheime von Banken in Wertpapiere verpackt und veräußert. Auf diese Weise entstanden aus faktischen Schulden Vermögenswerte, ebenso wie es der § 248 des HGB für Software erlaubt. Solange die Kredite bedient wurden, war das auch kein Problem. Das wurde es erst, als Kredite ausfielen und die vermeintlichen Vermögenswerte plötzlich offenbarten, was sie in Wirklichkeit waren: Schulden. Da mit Software prinzipiell ähnlich verfahren werden kann, besteht auch hier die Gefahr, dass Schulden – technische Schulden – als Vermögenswert betrachtet werden und eines Tages ihr wahres Gesicht zeigen.

An dieser Stelle wird deutlich, warum es so wichtig ist, von technischen Schulden als solchen zu sprechen. Betriebswirtschaftlich sind sie nämlich ein Werttreiber, solange Aufwand das Maß der Dinge ist und es keine Möglichkeiten für eine andere ökonomische Bewertung von Software gibt.

Divide: Schulden, Schulden und Schulden

Aus ökonomischer Sicht können wir zwei Arten von Schulden unterscheiden. Es gibt die privaten Schulden, zu denen die Kredite von Individuen und Unternehmen gehören, und die öffentlichen Schulden, die Kredite von Staaten. Ökonomen streiten sich seit mehr als hundert Jahren, ob diese beiden Arten wirklich unterschieden werden sollten und dürfen oder nicht. John Maynard Keynes sagte dazu einmal sehr klar: „Public debt is irrelevant“. Ob er Recht hat oder nicht, kann aufgrund der Natur des Gelds nie endgültig entschieden werden, aber es deutet einiges darauf hin, dass er nicht grundlegend irrte. Allerdings gilt diese Irrelevanz, die Keynes öffentlichen Schulden attestiert, nicht für private Kredite.

Wo befinden sich in diesem ökonomischen Modell die technischen Schulden? Sollten sie als private Schulden betrachtet werden? Dann dürfte Software nicht in den Aktiva der Bilanz erscheinen. Oder sind sie, wie Keynes über die öffentlichen Schulden sagte, irrelevant und alles ist in bester Ordnung? Weder noch! Technische Schulden in Software sind ein Konstrukt, das ökonomisch bisher gar nicht beschrieben werden kann. Das liegt daran, dass technische Schulden eben nicht durch das Leihen von Geld entstehen. Außerdem besteht ein Bezug zu Geld allenfalls indirekt, und eine Messung ist extrem kompliziert. Es gibt technische Schulden, die tatsächlich als eine legale Form der Bilanzfälschung betrachtet werden können, weil sie reine Aufwandstreiber sind und eine Software, die nach ihrem Erstellungsaufwand bilanziert wird, erheblich wertvoller erscheint, als es der Realität entspricht. Andererseits gibt es technische Schulden, auf die die von Keynes beschriebene Irrelevanz öffentlicher Schulden zutrifft. Sie verschwinden im Laufe der Zeit von allein.

Technische Schulden passen nicht in die bekannte Aufteilung privater und öffentlicher Schulden aus der Ökonomie. Ihre Natur ist grundlegend anders. Deshalb hinterfragt auch niemand, wieso sie den Wert der Aktiva steigern können. Wie sie dennoch bewertet und in eine betriebswirtschaftlich korrekte Relation zu Geld gebracht werden können, soll im Folgenden erklärt werden.

Conquer: Backlog, Story Points und Kosten des Nichthandelns

Was die meisten agilen Teams sehr gut beherrschen, ist das Schätzen von User Stories oder anderen Backlog Items in der abstrakten Einheit Story Points. Es gibt im Netz ausreichend viele hervorragende Quellen, die erklären, was Story Points sind, wie man sie einsetzt und wie sie ermittelt werden können. Für die Betrachtung technischer Schulden ist es ausreichend zu wissen, dass Story Points Informationen über die aus Aufwand, Unsicherheit und Risiko bestehende Größe eines Backlog Items liefern. Anhand des Verhältnisses dieser Größe des Backlog Items und seines Business Values kann ein Product Owner sehr gut priorisieren und sicherstellen, dass wirklich wertvolle Software entwickelt wird. Letzten Endes drücken Story Points die Kosten für die Realisierung einer Funktionalität aus.

Die Kosten von technischen Schulden wirken aber nicht nur, wenn sie beseitigt werden, sondern auch – möglicherweise vor allem dann – wenn sie nicht beseitigt werden. Sie müssen also anders betrachtet werden. Eine Schätzung für die Größe der Beseitigung einer technischen Schuld kann ein agiles Team wie für jedes andere Backlog Item auch liefern. Um die technische Schuld aber bewerten zu können, muss der Business Value transparent gemacht werden, der entsteht, wenn sie beseitigt wird. An dieser Stelle kann ein Konstrukt helfen, das etwas Querdenken erfordert: die Kosten des Nichthandelns. Die dahinterstehende Frage lautet: Was kostet es uns, wenn wir diese technische Schuld nicht beseitigen?

Ich habe diese Frage schon einigen Teams gestellt und die Antwort ist zunächst immer: Woher sollen wir das wissen? Und tatsächlich lässt sich diese Frage auf direktem Weg für die meisten technischen Schulden nicht beantworten. Es ist aber möglich, sie anders zu stellen. Dazu benötigt man eine Übersicht des aktuellen Backlogs, normalerweise für zwei bis drei Sprints in die Zukunft und idealerweise mit geschätzten und verstandenen Backlog Items. Mit den Augen des Teams auf dieses Backlog gerichtet, stelle ich die Frage: Wie viel kleiner wird unser Backlog, wenn wir diese technische Schuld beseitigen?

Die Antwort darauf lasse ich Teams mit Magic Estimation oder Planning Poker ermitteln. Die meisten Teams schätzen erstaunlich schnell übereinstimmende Werte. Diese Werte liefern die Antwort auf die Frage nach den Kosten des Nichthandelns. Der Product Owner kann nun die technischen Schulden in einem Diagramm wie in Abbildung 1 einordnen, wobei die X-Achse die Kosten für die Beseitigung repräsentiert und die Y-Achse die Kosten des Nichthandelns.

Abb. 1: Kosten von technischen Schulden

Abb. 1: Kosten von technischen Schulden

Diese Methode, insbesondere die Schätzung der Kosten des Nichthandelns, benötigt einige Übung. Deshalb sollte sie zunächst in drei bis vier aufeinanderfolgenden Sprints als Trockenübung durchgeführt werden. Das Team hat auf diese Weise die Gelegenheit, sich an diese Art der Betrachtung technischer Schulden zu gewöhnen. Außerdem wird noch etwas viel Wichtigeres entdeckt: Die Positionen der technischen Schulden im Diagramm verändern sich. Weder die Kosten für ihre Beseitigung noch die Kosten des Nichthandelns bleiben konstant (Abb. 2). Das ist ein wesentlicher Unterschied zu normalen Backlog Items, die konstante Größen haben. Fünf Story Points sind immer fünf Story Points, aber die technische Schuld wird unter Umständen teurer.

Abb. 2: Veränderliche Positionen der Kosten in Sprints

Abb. 2: Veränderliche Positionen der Kosten in Sprints

Aus diesem Grund sollten die technischen Schulden auch in jedem Sprint neu betrachtet werden. Der Product Owner kann die Bewegung der technischen Schulden beobachten und anhand ihrer Vektoren (Abb. 2) entscheiden, ob das Team sie beseitigen soll oder nicht. Interessant sind dabei die Muster, die für die Vektoren entstehen. Es gibt technische Schulden, bei denen sehr klar ist, dass ihre Beseitigung einen Gewinn für das Projekt darstellt. Bei einigen ist das nicht so klar, sie sollten nicht angegangen, sondern eine Weile beobachtet werden. Wieder andere werden immer teurer; was ihre Beseitigung angeht, bringen dem Projekt aber gar nichts. Solche technischen Schulden können einfach ignoriert werden. Und dann gibt es noch Fälle, die von ganz allein verschwinden. In diesem Fall gilt Keynes’ Aussage zur Irrelevanz öffentlicher Schulden auch für technische Schulden.

Wird eine solche Betrachtung technischer Schulden genutzt, haben Product Owner und Team einige Vorteile. Die Diskussion über technische Schulden wird objektiviert. Es geht nicht mehr um State-of-the-Art- oder Framework-Versionitis, sondern darum, ob das Projekt von der Beseitigung der technischen Schuld profitieren. Gleichzeitig wird durch die kontinuierliche Betrachtung die Existenz der technischen Schulden immer wieder bewusst gemacht, sodass sie nicht in Vergessenheit geraten. Die Kosten des Nichthandelns erzeugen einen gewissen Druck, nicht immer nur Funktionalität hoch zu priorisieren. Die absoluten Profis unter den Product Ownern, mit denen ich gearbeitet habe, sind so weit gegangen, dass sie die Kosten des Nichthandelns der technischen Schulden und den Business Value von anderen Backlog Items in einem Diagramm dargestellt haben und auf diese Weise nur noch den Wert der Backlog Items betrachtet haben.

Conquer: Das Project Balance Sheet

Die Kosten des Nichthandelns liefern ein gutes Werkzeug, um technische Schulden mit einem Business Value zu versehen und gegenüber anderen Backlog Items zu priorisieren. Um diese Bewertung endgültig in die Welt der Betriebswirtschaft zu überführen, nutze ich noch eine andere Leihgabe aus der Betriebswirtschaft: eine Bilanz für Softwareprojekte. In Abbildung 3 ist eine solche Projektbilanz dargestellt. Sie ist sehr einfach zu erstellen und zu pflegen.

Abb. 3: Bilanz für Softwareprojekte

Abb. 3: Bilanz für Softwareprojekte

Auf der linken Seite befinden sich die realisierten Features, die alle eine Bewertung hinsichtlich ihres Business Value haben. Diese Bewertung kann in Form der Cost of Delay erfolgen, als Net Present Value oder auf andere Weise ermittelt werden. Die realisierten Features sind die Aktiva des Projekts. Die rechte Seite enthält den realen Wert und die technischen Schulden.

Die Ermittlung der Werte ist sehr einfach. Angenommen ein Feature „kostet“ acht Story Points und hat einen Business Value von 160. Weil eine Messe ist, soll das Feature möglichst schnell realisiert werden. Das Team schlägt eine Lösung vor, bei der die Implementierung des Features für „nur“ zwei Story Points geschehen kann. Damit würde aber eine technische Schuld aufgenommen werden. Der Product Owner ist einverstanden, und das Feature wird entsprechend umgesetzt. Jetzt erscheint auf der linken Seite der Bilanz das realisierte Feature mit einem Business Value von 160. Auf der rechten Seite wird das Feature aber aufgeteilt, und zwar im Verhältnis 2:6. Damit wird ein Business Value von 40 dem realisierten Wert zugeschrieben und ein Business Value von 120 den technischen Schulden. Der Mechanismus entspricht also exakt dem einer ordentlichen Unternehmensbilanz: Es wird deutlich, wie viel Anlagevermögen auf der linken Seite mit Eigenkapital (realer Wert) und mit Fremdkapital (technische Schulden) finanziert wurden.

So eine bilanzielle Betrachtung bringt für ein Projekt einige Vorteile: Zunächst wird deutlich, dass technische Schulden nicht generell etwas Schlechtes sind. Wie Fremdkapital für das Unternehmen, erlauben sie dem Projekt, Funktionen bereitzustellen, die andernfalls nicht hätten realisiert werden können. Außerdem liefern sie einen wichtigen Indikator für die Gesundheit des Projekts. Das Verhältnis von realem Wert und technischen Schulden gemessen am Business Value sollte nie zu stark in Richtung der technischen Schulden neigen. Zwar lassen sich keine pauschalen Aussagen hinsichtlich der Verteilung machen, aber bei einem Anteil technischer Schulden von 80 Prozent am realisierten Business Value sollte man anfangen, über die Priorisierung nachzudenken.

Fazit

Auch wenn öffentliche Schulden irrelevant sind – technische Schulden sind es nicht. Durch die wachsende Bedeutung von Software werden sie in Zukunft ebenfalls bedeutender. Es ist somit unumgänglich, betriebswirtschaftliche Modelle zu entwickeln, die diese Form von Schulden beschreiben und mit ihren Wirkungen umgehen können. Dazu muss sich aber die Softwareentwicklung von ihrem starken inhaltlichen Fokus auf die Natur der technischen Schulden lösen und sich stärker mit der ökonomischen Wirkung auseinandersetzen. Denn Software wird auch in Zukunft nicht ohne technische Schulden realisiert werden können. Vielmehr wird in Zukunft immer öfter die Frage nach einer akzeptablen Größenordnung beantwortet werden müssen.

Verwandte Themen:

Geschrieben von
Gerrit Beine
Gerrit Beine
Gerrit Beine ist Managing Consultant bei der adesso AG mit den Schwerpunkten Agilität und Softwarearchitektur. Er ist regelmäßig als Sprecher auf Konferenzen zu treffen und beschäftigt sich gerne mit außergewöhnlichen Fragestellungen zur Softwareentwicklung.
Kommentare
  1. Michael2016-06-07 21:47:52

    Hallo Gerrit,

    vielen Dank für den super Artikel. Allerdings ist Deine Schlussfolgerung, dass technische Schulden den immateriellen Wert einer Software und damit den Bilanzwert einer Kapitalgesellschaft erhöhen können, m.E. nicht wirklich zutreffend.

    Im Gegenteil, technische Schulden werden ja zunächst aufgenommen, um ein Feature schneller, günstiger, etc. zu bekommen. Bilanziell wirksam ist aber nach meinem Verständnis der Thematik gerade auch nur die Schaffung neuer Funktionen. Wartung und Optimierung bestehender Funktionen lässt sich m.W. nach eben genau nicht bilanziell »aktivieren«.

    Technischen Schulden haben nun in meiner Erfahrung aber genau die lähmende Auswirkung auf Pflege, Wartung, Betrieb und Weiterentwicklung der einmal schnell "dahin entwickelten" Software und tun somit aus buchhalterischer Sicht richtig weh, da sie als Ausgaben voll gegen das Ergebnis gehen und nicht zumindest noch etwas Gutes für die Bilanz tun.

    Natürlich trifft es zu, dass eine neue Funktion, die in einen Systemstack voll technischer Schulden implementiert werden muss, auch aufwendiger ist. Aber erfahrungsgemäß ersticken diese Organisationen dann doch eh i.d.R. in einem Wartungs- und Betriebsanteil von mehr 70% so dass die Neuentwicklung gar nicht mehr so zu Buche schlägt. Und in so einem Umfeld wird dann ja auch noch viel schneller nach "Abkürzungen", etc. gesucht, also die nächste technische Schuld aufgenommen...

    Viele Grüße
    Michael

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.