SlideShare ist ein Scribd-Unternehmen logo
Technische Schulden
Gerrit Beine
adesso AG
Es ist mir eine große Freude, heute über technische Schulden sprechen zu dürfen.

Als ich die Zusage für den Vortrag erhielt, war ich einigermaßen überrascht, dass er als Keynote ausgewählt wurde.

Damit hatte ich nicht gerechnet.
Vorstellung
‣ Managing Consultant bei adesso
‣ Software Philosoph, nimmermüder Verbesserer,
Informatik-Vagabund
‣ Themen
‣ Agilität
‣ Software Architektur
‣ Antifragilität & Schwarze Schwäne
‣ Technical Debt & Legacy Code
‣ Software Engineering Economics
‣ Interkulturelle Aspekte von Software Engineering
‣ iSAQB e.V. Board Member, openSUSE Member,
Agile Saxony Organisator
Immer, wenn Menschen sich über die Zukunft
Gedanken machen, fällt im Hintergrund das
Schicksal lachend vom Stuhl.
Gleich vorab eine Weisheit, die das Thema technische Schulden sehr gut widerspiegelt.

Egal, wie gut wir unser Projekt planen, es kommt anders.
Ich werde heute unter anderem über diese beiden Herren sprechen.

Kennt die jemand?

Das oben ist Friedrich Hayek und das unten ist John Maynard Keynes.

Die beiden hatten sehr unterschiedliche Ansichten zum Thema Schulden, die auch für das Thema der technischen Schulden sehr interessant sind.

Und ich werde ein bisschen über die Gesetzeslage sprechen, die eine Ursache dafür ist, dass technische Schulden so wirken, wie sie derzeit wirken.

In dem Zusammenhang spreche ich dann auch noch über diese Kollegen. Lehman Brothers.

Vielleicht erinnert sich noch jemand an die, für alle anderen: deren Pleite war der Ursprung der Finanzkrise vor einigen Jahren.

Achja. Über Geld spreche ich auch noch. Auch wenn wir in der IT nur äußerst ungern über Geld sprechen.

Ganz zum Schluss erkläre ich dann noch zwei praktische Tools, die ein Management technischer Schulden erlauben.
Technische Schulden
Brauchen wir wirklich eine andere Metapher?
Die erste Frage, über die ich mir im Zusammenhang dieses Vortrags Gedanken gemacht habe, stammt aus einem Artikel, den ich vor einiger Zeit gelesen habe.

Hier wurde die These aufgestellt, dass wir den Begriff „Technische Schuld“ durch einen anderen ersetzen sollten, weil er immer zur Diskussion führt, wer schuld sei.

Ich halte das für ziemlichen Käse. „Schulden haben“ und „schuld sein“ sind zwei völlig unterschiedliche Konstrukte.

Dazu machen wir mal einen Ausflug in die Etymologie.
Ein kurzer Ausflug in die Etymologie
‣ Moralisches Konstrukt
‣ Verletzung der Interessen Anderer
‣ Verstoß gegen das Gewissen
‣ Pflicht, dem Recht zu folgen
‣ Zeitlich ungebunden
‣ Englisch: guilt
‣ Rechtliches Konstrukt
‣ Zeitlich gebunden
‣ Finanziell oder materiell verknüpft
‣ Pflicht zum Ausgleich
‣ Englisch: debt
Schuld Schulden
Im Deutschen benutzen wir den Begriff „Schuld“ für zwei völlig unterschiedliche Dinge.

Zum Einen ist da das moralische Konstrukt der Schuld, die aus einer Verletzung der Interessen Anderer oder ein Verstoß gegen das Gewissen resultiert.

Diese Schuld resultiert aus einer Pflicht dem Recht zu folgen und ist zeitlich ungebunden, es gibt aber keine Pflicht - und manchmal auch keine Möglichkeit - sie auszugleichen.

Im Englischen wird für diese Schuld der Begriff „guilt“ verwendet.

Zum Anderen haben wir die Schulden, die ein rechtliches Konstrukt darstellen.

Sie sind zeitlich gebunden und im Allgemeinen finanziell oder Material verknüpft.

Für sie besteht eine Pflicht zum Ausgleich.

Im Englischem wird für solche Schulden der Begriff „debt“ verwendet.

Beides sind zwei unterschiedliche Dinge, die nur durch einen etymologischen Unfall im Deutschen mit dem gleichen Begriff bezeichnet werden.
Zunächst ist festzuhalten:
Schulden sind nicht schlecht.
Halten wir zunächst etwas fest, dass den Schwaben unter uns schwer zu schaffen machen wird:

Schulden sind per se nicht schlecht.

Schulden sind einfach nur da.

Die Möglichkeit, Schulden zu machen, ist ein fundamentales Grundprinzip unseres Wirtschaftssystems.

Viele Dinge wären ohne das wirtschaftliche Konzept Schulden undenkbar.
Zwei Arten: Öffentliche Schulden…
Public debt is irrelevant.
— John Maynard Keynes
Aus makroökonomischer Sicht gibt es zwei Arten von Schulden:

Einerseits die öffentlichen Schulden, über die John Maynard Keynes sagte, dass sie egal seien.

Reinhard und Rogoff haben mit „This Time is Different“ ein sehr interessantes Buch über die Geschichte der öffentlichen Schulden geschrieben.

Aber alles, was wir heute in der Makroökonomie wissen, deutet darauf hin, dass Keynes nicht ganz falsch lag.

Zumindest sind sämtliche Modelle, die ihn zu widerlegen versuchten, gescheitert.
Zwei Arten: …und private Schulden
Anders schaut es mit privaten

Schulden aus…
Auf der anderen Seite stehen die privaten Schulden.

Diese sind für die Makroökonomie viel wichtiger als die öffentlichen Schulden.

Können die privaten Schulden in einer Volkswirtschaft nicht mehr bezahlt werden, bricht sie zusammen.

John Kenneth Galbraith hat mit „Eine kurze Geschichte der Spekulation“ eine sehr angenehm zu lesende Zusammenfassung der Resultate privater Schulden, die aus Spekulation resultierten, geschrieben.

Private Schulden sind also nicht egal.

Ganz im Gegenteil.
Wie passen technische Schulden da rein?
Die große Frage ist nun: Wie passen technische Schulden in dieses System?

Folgen sie dem Modell der öffentlichen Schulden oder dem der privaten Schulden?

Die Antwort ist: Weder - noch.

Technische Schulden folgen keinem der beiden Modelle, sondern funktionieren auf eine ganz andere Weise.

Machen wir einen kleinen Ausflug in die Gesetzgebung, um herauszufinden, warum das so ist…
Es begab sich am 29.5.2009…
Selbst geschaffene immaterielle
Vermögensgegenstände des Anlagevermögens
können als Aktivposten in die Bilanz
aufgenommen werden. Nicht aufgenommen
werden dürfen selbst geschaffene Marken,
Drucktitel, Verlagsrechte, Kundenlisten oder
vergleichbare immaterielle
Vermögensgegenstände des Anlagevermögens.
Es begab sich am 29.5.2009 als der §248 HGB eine fundamentale Änderung erfuhr.

Seit diesem Tag ist es möglich, „selbst geschaffene immaterielle Vermögensgegenstände“ in Unternehmensbilanzen zu aktivieren.

Software ist so ein „selbst geschaffener immaterieller Vermögensgegenstand“.
Das passt ganz hervorragend zu diesen Kollegen:
Warum das ein Problem ist?

Ganz einfach: diese Gesetzesänderung folgt dem Weg, der zur Pleite von Lehman Brothers geführt hat.

Kennt ihr noch die Geschichte dazu?

Ich beschreibe das hier mal ganz einfach, die Wirklichkeit ist natürlich viel komplizierter:

Die Kollegen von Lehman Brothers hatten Kredite - also Fremdkapital - die gebündelt waren, als Wertpapiere gekauft und diese als Vermögensgegenstände in die Unternehmensbilanz aufgenommen.

Als die Kredite ausfielen - private Schulden, die nicht zurückgezahlt werden konnten, Galbraith grüßt - gingen Vermögensgegenstände von Lehman Brothers plötzlich in nichts auf.

Die Bilanz ging kaputt und die Bank ging pleite.
Die Bilanz
Aktiva Passiva
Vermögens-
gegenstände
Eigenkapital
Fremdkapital
Software
steht hier!
Schauen wir uns mal so eine Bilanz an.

Auf der rechten Seite stehen die sogenannten Passiva.

Im Wesentlichen sind das Eigenkapital und Fremdkapital.

Auf der linken Seite stehen die Vermögensgegenstände.

Und eben auch der Wert der Software.

Nur wie entsteht dieser Wert?
Betriebswirtschaftliche Logik
‣ Software zu bewerten ist schwer.
‣ Also wird bewertet, was bewertet werden kann: der
Aufwand der Erstellung der Software.
‣ Technische Schulden sind ein Aufwandstreiber:

Je mehr technische Schulden, desto mehr Aufwand.
‣ Je höher der Aufwand, desto wertvoller die Software.
‣ Na, wer kennt das Ende…?
Der Wert von Software ist relativ schwer zu ermitteln.

Also versucht man, den Wert auf die einfachste mögliche Weise zu ermitteln.

Und das ist bei Software die Zeit, die für ihre Erstellung benötigt wurde.

Wir nennen das in der Regel den Aufwand.

Unser Problem mit den technischen Schulden ist, dass diese ein Aufwandstreiber sind.

Das bedeutet, mehr technische Schulden führen zu mehr Aufwand.

Und je höher der Aufwand für die Erstellung der Software, desto wertvoller ist sie.

Im Prinzip ist das der gleiche Mechanismus, der auch zur Pleite von Lehman Brothers geführt hat:

Etwas, das eigentlich negativ wirkt, wird als Vermögensgegenstand bewertet.

BWL ist halt keine exakte Wissenschaft.
Das ist der Grund, warum es in vielen
Unternehmen kein ökonomisches
Verständnis für technische Schulden gibt.
Dieser Bug in der wirtschaftlichen Betrachtung von Software ist der Grund, warum es kein ökonomisches Verständnis für die Entwicklung von Software gibt.

Und warum es keine validen Wertmodelle gibt, die Software korrekt erfassen können.
Ja, und nun…?
Was machen wir nun mit diesem Wissen?

Aufgeben?

Eine neue BWL erfinden?

Alle Softwareunternehmen auf den Pfad von Lehman Brothers schicken?

Einfach keine Schulden mehr machen?
Wir brauchen technische Schulden!
Der Punkt ist: Keine technischen Schulden zu machen, ist keine Option.

Wir benötigen technische Schulden ebenso wie wir die Möglichkeit finanzieller Schulden benötigen.
‣ Technische Schulden helfen uns, Software schnell
auf den Markt zu bekommen.
‣ Technische Schulden helfen uns, Entscheidungen auf
den letztmöglichen Zeitpunkt zu verschieben.
‣ Technische Schulden helfen uns, Projekte zu
realisieren, die wir sonst nicht geschafft hätten.
‣ Je mehr wir uns in der Softwareentwicklung
bemühen, technische Schulden zu vermeiden, desto
mehr technische Schulden produzieren wir.
Technische Schulden erlauben uns, Software ökonomisch zu entwickeln.

Wir können unter Umständen mit einer Software früher auf dem Markt sein, wenn wir technische Schulden in Kauf nehmen.

Für Softwareentwickler ist das nicht so angenehm, für ein Unternehmen kann das sehr wichtig sein.

Wir können technische Schulden nutzen, um Entscheidungen in die Zukunft zu verschieben.

Heute keine perfekte Lösung zu bauen, sondern mit der unperfekten Lösung Zeit erkaufen um Neues zu lernen und mehr über die wirklich perfekte Lösung zu erfahren ist nur möglich, wenn wir technische Schulden in Kauf nehmen.

Technische Schulden können uns auch helfen, Projekte überhaupt zu realisieren, die unter anderen Umständen unmöglich gewesen wären.

Zeitlich, finanziell - oder auch nur, weil wir einen Prototypen bauen wollen.

Das waren allen Beispiele für das bewusste Aufnehmen technischer Schulden.

Ein Kuriosum, das mir in vielen Projekten begegnet ist, ist die Tatsache, dass technische Schulden eine selbsterfüllende Prophezeiung sind.

Je mehr wir uns bemühen, sie zu vermeiden, desto mehr von ihnen entstehen.

Wir können uns nicht bewusst gegen sie entscheiden.
Tools für technische Schulden
Ich hatte ja ganz am Anfang versprochen, dass ich noch zwei Tools vorstelle, um mit technischen Schulden umzugehen.

Hier kommen sie nun.
Technische Schulden ökonomisieren
Story Points
Do

Nothing

Cost
Das erste ist relativ einfach.

Wir benutzen ein XY-Diagramm bei dem wir auf der X-Achse die Aufwände darstellen, die bei der Beseitigung einer technischen Schuld entstehen.

Auf der Y-Achse tragen wir das ab, was ich als die Kosten des Nicht-Handelns bezeichne.

Die X-Achse können die meisten Teams recht gut schätzen, Das Prinzip ist das gleiche wie beim Schätzen von User Storys.

Das Schätzen der Y-Achse ist etwas schwieriger. Hier benötigen Teams in der Regel etwas Übung.

Die Frage, die ich ihnen üblicherweise stelle ist: Um wie viel kleiner wird das Backlog, wenn wir diese technische Schuld begleichen?

Nach drei, vier Sprints klappt das dann in der Regel mit dem Schätzen der „Do Nothing Costs“.
Technische Schulden ökonomisieren
Story Points
A
B
C
D
E
Do

Nothing

Cost
Die technischen Schulden positionieren sich dann im Diagramm auf verschiedenen Stellen.

Alles oberhalb der diagonalen Linie ist interessant, weil hier Nichtstun teurer ist, als die Beseitigung der technischen Schuld.

Wichtig ist, dass man diese Betrachtung regelmäßig wiederholt.

Ich mache das mit meinen Teams in jedem Sprint, und es entwickeln sich recht interessante Bewegungsmuster.

Einige technische Schulden werden immer teurer, andere werden günstiger.

Manchmal verschwinden sie sogar komplett, ohne dass irgend etwas getan werden muss.

Leider führt das nicht dazu, dass man sie - wie Keynes die öffentlichen Schulden - als irrelevant betrachten kann.
Technische Schulden bilanzieren
A
BV: 100
8 SP
B
BV: 150
5 SP
C
BV: 50
8 SP
D
BV: 208
13 SP
E
BV: 80
3 SP
Ein zweites Werkzeug ist eine Bilanzierung technischer Schulden.

Dazu benötigen wir eine Schätzung für den Business Value und den Aufwand für alle Backlog Items, die in einem Projekt bearbeitet werden.
Technische Schulden bilanzieren
C
BV: 50
8 SP
D
BV: 208
13 SP
Business Value Project Value
C
BV: 50
8 SP
D
BV: 80
5 SP
D
BV: 128
8 SP
Summe = 258 Summe = 258
Eigen

kapital
Fremd-

kapital
Für die realisierten Features trägt man nun den Business Value auf der linken Seite der Bilanz und einen Project Value (mir fiel bisher kein besserer Begriff dafür ein) auf der rechten Seite ein.

Hat man bei der Realisierung eines Features technische Schulden in Kauf genommen, wird das Feature auf der linken Seite mit seinem kompletten Business Value bilanziert.

Auf der rechten Seite wird aber der Business Value entsprechend des investierten Teilaufwands gewichtet.

Den Teilaufwand können Teams recht gut benennen, das Verhältnis für den Business Value ergibt sich dann automatisch.

Diese Bilanz hilft uns dann, zu erkennen wie viel unseres Business Value tatsächlich geschaffen wurde und wie viel davon mit Schulden belastet ist.

Da diese Schulden irgendwann einmal zurückgezahlt werden müssen, sollte auch die Bilanz kontinuierlich gepflegt werden.
Fazit
Keynes, Hayek & Lehman Brothers
‣ Technische Schulden werden nur in Ausnahmefällen
irrelevant!
‣ Technische Schulden erledigt man nicht durch noch
mehr technische Schulden!
‣ Technische Schulden sind ökonomische, keine
technischen Entscheidungen!
‣ Technische Schulden zurückzahlen lohnt nur dann,
wenn sie auch Zinsen kosten.
Fassen wir zusammen:

Technische Schulden sind alles andere als irrelevant, die üblichen ökonomischen Modelle erfassen sie aber nicht korrekt.

Es ist nicht möglich, technische Schulden durch andere oder mehr technische Schulden zu erledigen, wie das bei öffentlichen Schulden möglich ist.

Fundamental ist die Erkenntnis, dass technische Schulden keine technische Entscheidung sind, sondern eine betriebswirtschaftliche.

Das irritiert viele Softwareentwickler und noch mehr irritiert es Nicht-ITler.

Was bei der gesamten Debatte auch bedacht werden sollte ist, dass es sich nur lohnt, technische Schulden abzutragen, wenn sie tatsächlich Geld kosten.

Die oftmals geführte State of the Art-Debatte ist dabei weder hilfreich noch zielführend.
Noch ein paar Tipps zum Schluss…
‣ Macht technische Schulden im Backlog sichtbar!
‣ Quantifiziert den Business Value technischer
Schulden!
‣ Bewertet technische Schulden realistisch, um
Vertrauen zu schaffen.
‣ Schaut nicht zu weit und nicht zu kurz voraus, um
unabsichtliche technische Schulden zu vermeiden.
‣ Und: Müll im Code ist keine technische Schuld!
Ein paar Tipps habe ich noch für euch:

Macht eure technischen Schulden sichtbar.

Beispielsweise als Backlog Items im Product Backlog.

Beschäftigt euch mit dem Business Value der technischen Schulden und bewertet sie realistisch.

Wenn ihr über Business Value sprecht, könnt ihr auch Nicht-ITler erreichen.

Eine realistische Bewertung schafft Vertrauen und zeigt Kompetenz über die Software hinaus.

Es nützt nichts, zur Vermeidung technischer Schulden in die Zukunft schauen zu wollen.

Solve today’s problems today and tomorrow’s problems tomorrow.

Und: Nicht alles, was wie Müll ausschaut ist eine technische Schuld.

Seid ehrlich zu euch selbst und macht eure Hausaufgaben beim Coden.
Vielen Dank!
Gerrit Beine
adesso AG

Weitere ähnliche Inhalte

Ähnlich wie Technische Schulden - mit Notizen

Formen technischer schuld und wie man sie adressiert
Formen technischer schuld und wie man sie adressiertFormen technischer schuld und wie man sie adressiert
Formen technischer schuld und wie man sie adressiert
Dominik "Dodo" Dopplinger
 
München vdi hochschule v.20 8 10 2013 share
München vdi hochschule v.20 8 10 2013 shareMünchen vdi hochschule v.20 8 10 2013 share
München vdi hochschule v.20 8 10 2013 share
Jürgen Lauber
 
Newsletter 3 - Kernkompetenzen
Newsletter 3 - KernkompetenzenNewsletter 3 - Kernkompetenzen
Newsletter 3 - Kernkompetenzenemotion banking
 
Die Architektur, die man kann
Die Architektur, die man kannDie Architektur, die man kann
Die Architektur, die man kann
Johann-Peter Hartmann
 
Occupyfrankfurt analyse eurokrise
Occupyfrankfurt analyse eurokriseOccupyfrankfurt analyse eurokrise
Occupyfrankfurt analyse eurokriseSai Tam
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce Organisationsstrukturen
Björn Schotte
 
WorkingProducts MONTHLY - Transformation geht nur über Strukturen
WorkingProducts MONTHLY - Transformation geht nur über StrukturenWorkingProducts MONTHLY - Transformation geht nur über Strukturen
WorkingProducts MONTHLY - Transformation geht nur über Strukturen
Conny Dethloff
 
Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software Analytics
Markus Harrer
 
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kannVorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
Tammo van Lessen
 
Blockchain: How the bitcoin technology can change the public sector
Blockchain: How the bitcoin technology can change the public sectorBlockchain: How the bitcoin technology can change the public sector
Blockchain: How the bitcoin technology can change the public sector
Capgemini
 
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Markus Harrer
 
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
Competence Books
 
Awesome Banking Jam III
Awesome Banking Jam IIIAwesome Banking Jam III
Awesome Banking Jam III
figo GmbH
 
Recht für Gründer
Recht für GründerRecht für Gründer
Recht für Gründer
Henning Krieg
 
Produktentwicklung - Von der Natur lernen
Produktentwicklung - Von der Natur lernenProduktentwicklung - Von der Natur lernen
Produktentwicklung - Von der Natur lernen
Conny Dethloff
 
Sharing Geschäftsmodelle - Hype oder Realität?
Sharing Geschäftsmodelle - Hype oder Realität?Sharing Geschäftsmodelle - Hype oder Realität?
Sharing Geschäftsmodelle - Hype oder Realität?
Patrick Stähler
 
Execio.co - Bank als Plattform oder was von den Banken über bleibt
Execio.co - Bank als Plattform oder was von den Banken über bleibtExecio.co - Bank als Plattform oder was von den Banken über bleibt
Execio.co - Bank als Plattform oder was von den Banken über bleibt
figo GmbH
 

Ähnlich wie Technische Schulden - mit Notizen (17)

Formen technischer schuld und wie man sie adressiert
Formen technischer schuld und wie man sie adressiertFormen technischer schuld und wie man sie adressiert
Formen technischer schuld und wie man sie adressiert
 
München vdi hochschule v.20 8 10 2013 share
München vdi hochschule v.20 8 10 2013 shareMünchen vdi hochschule v.20 8 10 2013 share
München vdi hochschule v.20 8 10 2013 share
 
Newsletter 3 - Kernkompetenzen
Newsletter 3 - KernkompetenzenNewsletter 3 - Kernkompetenzen
Newsletter 3 - Kernkompetenzen
 
Die Architektur, die man kann
Die Architektur, die man kannDie Architektur, die man kann
Die Architektur, die man kann
 
Occupyfrankfurt analyse eurokrise
Occupyfrankfurt analyse eurokriseOccupyfrankfurt analyse eurokrise
Occupyfrankfurt analyse eurokrise
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce Organisationsstrukturen
 
WorkingProducts MONTHLY - Transformation geht nur über Strukturen
WorkingProducts MONTHLY - Transformation geht nur über StrukturenWorkingProducts MONTHLY - Transformation geht nur über Strukturen
WorkingProducts MONTHLY - Transformation geht nur über Strukturen
 
Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software Analytics
 
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kannVorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
Vorsicht Schuldenfalle - Was die IT aus der Finanzwelt lernen kann
 
Blockchain: How the bitcoin technology can change the public sector
Blockchain: How the bitcoin technology can change the public sectorBlockchain: How the bitcoin technology can change the public sector
Blockchain: How the bitcoin technology can change the public sector
 
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
Software Analytics - Datenanalysen in der Softwareentwicklung (BigDataMeetup)
 
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
Digitaler Wandel - jetzt machen, aber wie?! - Competence Book Teil 2
 
Awesome Banking Jam III
Awesome Banking Jam IIIAwesome Banking Jam III
Awesome Banking Jam III
 
Recht für Gründer
Recht für GründerRecht für Gründer
Recht für Gründer
 
Produktentwicklung - Von der Natur lernen
Produktentwicklung - Von der Natur lernenProduktentwicklung - Von der Natur lernen
Produktentwicklung - Von der Natur lernen
 
Sharing Geschäftsmodelle - Hype oder Realität?
Sharing Geschäftsmodelle - Hype oder Realität?Sharing Geschäftsmodelle - Hype oder Realität?
Sharing Geschäftsmodelle - Hype oder Realität?
 
Execio.co - Bank als Plattform oder was von den Banken über bleibt
Execio.co - Bank als Plattform oder was von den Banken über bleibtExecio.co - Bank als Plattform oder was von den Banken über bleibt
Execio.co - Bank als Plattform oder was von den Banken über bleibt
 

Mehr von Gerrit Beine

Auf Lesereise mit Frit und Fred
Auf Lesereise mit Frit und FredAuf Lesereise mit Frit und Fred
Auf Lesereise mit Frit und Fred
Gerrit Beine
 
Mastering Cargo Cult
Mastering Cargo CultMastering Cargo Cult
Mastering Cargo Cult
Gerrit Beine
 
Conway’s Law & Soziologie in der Software-Architektur
Conway’s Law & Soziologie in der Software-ArchitekturConway’s Law & Soziologie in der Software-Architektur
Conway’s Law & Soziologie in der Software-Architektur
Gerrit Beine
 
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wird
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wirdBeyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wird
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wird
Gerrit Beine
 
Mastering Cargo Cult - Dunning, Kruger & die Agile Bias Curve
Mastering Cargo Cult - Dunning, Kruger & die Agile Bias CurveMastering Cargo Cult - Dunning, Kruger & die Agile Bias Curve
Mastering Cargo Cult - Dunning, Kruger & die Agile Bias Curve
Gerrit Beine
 
Gut genug - Rahmenbedingungen für agile Architekturen
Gut genug - Rahmenbedingungen für agile ArchitekturenGut genug - Rahmenbedingungen für agile Architekturen
Gut genug - Rahmenbedingungen für agile Architekturen
Gerrit Beine
 
Beyond Agile – Ungewissheit mit der Real Option Theory meistern
Beyond Agile – Ungewissheit mit der Real Option Theory meisternBeyond Agile – Ungewissheit mit der Real Option Theory meistern
Beyond Agile – Ungewissheit mit der Real Option Theory meistern
Gerrit Beine
 
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...
Gerrit Beine
 
Backlog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Backlog Priorisierung mit Cost of Delay & Monte Carlo SimulationenBacklog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Backlog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Gerrit Beine
 
Der hyperbolische Thread-Koeffizient
Der hyperbolische Thread-KoeffizientDer hyperbolische Thread-Koeffizient
Der hyperbolische Thread-Koeffizient
Gerrit Beine
 
Broken by Design
Broken by DesignBroken by Design
Broken by Design
Gerrit Beine
 
Vom Projektleiter zum Product Owner
Vom Projektleiter zum Product OwnerVom Projektleiter zum Product Owner
Vom Projektleiter zum Product Owner
Gerrit Beine
 
Antifragilität
AntifragilitätAntifragilität
Antifragilität
Gerrit Beine
 
Agile Coach zu werden ist nicht schwer...
Agile Coach zu werden ist nicht schwer...Agile Coach zu werden ist nicht schwer...
Agile Coach zu werden ist nicht schwer...
Gerrit Beine
 
Scaled, Distributed, Agile - Produktentwicklung auf neuen Wegen
Scaled, Distributed, Agile - Produktentwicklung auf neuen WegenScaled, Distributed, Agile - Produktentwicklung auf neuen Wegen
Scaled, Distributed, Agile - Produktentwicklung auf neuen Wegen
Gerrit Beine
 
NTFS On Disk Structure
NTFS On Disk StructureNTFS On Disk Structure
NTFS On Disk Structure
Gerrit Beine
 
Semistrukturierte Daten in relationalen Datenbanken
Semistrukturierte Daten in relationalen DatenbankenSemistrukturierte Daten in relationalen Datenbanken
Semistrukturierte Daten in relationalen Datenbanken
Gerrit Beine
 
Volltextsuchen in RDBMS (2004)
Volltextsuchen in RDBMS (2004)Volltextsuchen in RDBMS (2004)
Volltextsuchen in RDBMS (2004)
Gerrit Beine
 
Budgeting in the Era of Agile
Budgeting in the Era of AgileBudgeting in the Era of Agile
Budgeting in the Era of Agile
Gerrit Beine
 
Beyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
Beyond Agile - Antifragilität in der Software-Entwicklung - mit NotizenBeyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
Beyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
Gerrit Beine
 

Mehr von Gerrit Beine (20)

Auf Lesereise mit Frit und Fred
Auf Lesereise mit Frit und FredAuf Lesereise mit Frit und Fred
Auf Lesereise mit Frit und Fred
 
Mastering Cargo Cult
Mastering Cargo CultMastering Cargo Cult
Mastering Cargo Cult
 
Conway’s Law & Soziologie in der Software-Architektur
Conway’s Law & Soziologie in der Software-ArchitekturConway’s Law & Soziologie in der Software-Architektur
Conway’s Law & Soziologie in der Software-Architektur
 
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wird
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wirdBeyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wird
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wird
 
Mastering Cargo Cult - Dunning, Kruger & die Agile Bias Curve
Mastering Cargo Cult - Dunning, Kruger & die Agile Bias CurveMastering Cargo Cult - Dunning, Kruger & die Agile Bias Curve
Mastering Cargo Cult - Dunning, Kruger & die Agile Bias Curve
 
Gut genug - Rahmenbedingungen für agile Architekturen
Gut genug - Rahmenbedingungen für agile ArchitekturenGut genug - Rahmenbedingungen für agile Architekturen
Gut genug - Rahmenbedingungen für agile Architekturen
 
Beyond Agile – Ungewissheit mit der Real Option Theory meistern
Beyond Agile – Ungewissheit mit der Real Option Theory meisternBeyond Agile – Ungewissheit mit der Real Option Theory meistern
Beyond Agile – Ungewissheit mit der Real Option Theory meistern
 
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...
 
Backlog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Backlog Priorisierung mit Cost of Delay & Monte Carlo SimulationenBacklog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Backlog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
 
Der hyperbolische Thread-Koeffizient
Der hyperbolische Thread-KoeffizientDer hyperbolische Thread-Koeffizient
Der hyperbolische Thread-Koeffizient
 
Broken by Design
Broken by DesignBroken by Design
Broken by Design
 
Vom Projektleiter zum Product Owner
Vom Projektleiter zum Product OwnerVom Projektleiter zum Product Owner
Vom Projektleiter zum Product Owner
 
Antifragilität
AntifragilitätAntifragilität
Antifragilität
 
Agile Coach zu werden ist nicht schwer...
Agile Coach zu werden ist nicht schwer...Agile Coach zu werden ist nicht schwer...
Agile Coach zu werden ist nicht schwer...
 
Scaled, Distributed, Agile - Produktentwicklung auf neuen Wegen
Scaled, Distributed, Agile - Produktentwicklung auf neuen WegenScaled, Distributed, Agile - Produktentwicklung auf neuen Wegen
Scaled, Distributed, Agile - Produktentwicklung auf neuen Wegen
 
NTFS On Disk Structure
NTFS On Disk StructureNTFS On Disk Structure
NTFS On Disk Structure
 
Semistrukturierte Daten in relationalen Datenbanken
Semistrukturierte Daten in relationalen DatenbankenSemistrukturierte Daten in relationalen Datenbanken
Semistrukturierte Daten in relationalen Datenbanken
 
Volltextsuchen in RDBMS (2004)
Volltextsuchen in RDBMS (2004)Volltextsuchen in RDBMS (2004)
Volltextsuchen in RDBMS (2004)
 
Budgeting in the Era of Agile
Budgeting in the Era of AgileBudgeting in the Era of Agile
Budgeting in the Era of Agile
 
Beyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
Beyond Agile - Antifragilität in der Software-Entwicklung - mit NotizenBeyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
Beyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
 

Technische Schulden - mit Notizen

  • 1. Technische Schulden Gerrit Beine adesso AG Es ist mir eine große Freude, heute über technische Schulden sprechen zu dürfen. Als ich die Zusage für den Vortrag erhielt, war ich einigermaßen überrascht, dass er als Keynote ausgewählt wurde. Damit hatte ich nicht gerechnet.
  • 2. Vorstellung ‣ Managing Consultant bei adesso ‣ Software Philosoph, nimmermüder Verbesserer, Informatik-Vagabund ‣ Themen ‣ Agilität ‣ Software Architektur ‣ Antifragilität & Schwarze Schwäne ‣ Technical Debt & Legacy Code ‣ Software Engineering Economics ‣ Interkulturelle Aspekte von Software Engineering ‣ iSAQB e.V. Board Member, openSUSE Member, Agile Saxony Organisator
  • 3. Immer, wenn Menschen sich über die Zukunft Gedanken machen, fällt im Hintergrund das Schicksal lachend vom Stuhl. Gleich vorab eine Weisheit, die das Thema technische Schulden sehr gut widerspiegelt. Egal, wie gut wir unser Projekt planen, es kommt anders.
  • 4. Ich werde heute unter anderem über diese beiden Herren sprechen. Kennt die jemand?
 Das oben ist Friedrich Hayek und das unten ist John Maynard Keynes. Die beiden hatten sehr unterschiedliche Ansichten zum Thema Schulden, die auch für das Thema der technischen Schulden sehr interessant sind. Und ich werde ein bisschen über die Gesetzeslage sprechen, die eine Ursache dafür ist, dass technische Schulden so wirken, wie sie derzeit wirken. In dem Zusammenhang spreche ich dann auch noch über diese Kollegen. Lehman Brothers. Vielleicht erinnert sich noch jemand an die, für alle anderen: deren Pleite war der Ursprung der Finanzkrise vor einigen Jahren. Achja. Über Geld spreche ich auch noch. Auch wenn wir in der IT nur äußerst ungern über Geld sprechen. Ganz zum Schluss erkläre ich dann noch zwei praktische Tools, die ein Management technischer Schulden erlauben.
  • 5. Technische Schulden Brauchen wir wirklich eine andere Metapher? Die erste Frage, über die ich mir im Zusammenhang dieses Vortrags Gedanken gemacht habe, stammt aus einem Artikel, den ich vor einiger Zeit gelesen habe. Hier wurde die These aufgestellt, dass wir den Begriff „Technische Schuld“ durch einen anderen ersetzen sollten, weil er immer zur Diskussion führt, wer schuld sei. Ich halte das für ziemlichen Käse. „Schulden haben“ und „schuld sein“ sind zwei völlig unterschiedliche Konstrukte. Dazu machen wir mal einen Ausflug in die Etymologie.
  • 6. Ein kurzer Ausflug in die Etymologie ‣ Moralisches Konstrukt ‣ Verletzung der Interessen Anderer ‣ Verstoß gegen das Gewissen ‣ Pflicht, dem Recht zu folgen ‣ Zeitlich ungebunden ‣ Englisch: guilt ‣ Rechtliches Konstrukt ‣ Zeitlich gebunden ‣ Finanziell oder materiell verknüpft ‣ Pflicht zum Ausgleich ‣ Englisch: debt Schuld Schulden Im Deutschen benutzen wir den Begriff „Schuld“ für zwei völlig unterschiedliche Dinge. Zum Einen ist da das moralische Konstrukt der Schuld, die aus einer Verletzung der Interessen Anderer oder ein Verstoß gegen das Gewissen resultiert. Diese Schuld resultiert aus einer Pflicht dem Recht zu folgen und ist zeitlich ungebunden, es gibt aber keine Pflicht - und manchmal auch keine Möglichkeit - sie auszugleichen. Im Englischen wird für diese Schuld der Begriff „guilt“ verwendet. Zum Anderen haben wir die Schulden, die ein rechtliches Konstrukt darstellen. Sie sind zeitlich gebunden und im Allgemeinen finanziell oder Material verknüpft. Für sie besteht eine Pflicht zum Ausgleich. Im Englischem wird für solche Schulden der Begriff „debt“ verwendet. Beides sind zwei unterschiedliche Dinge, die nur durch einen etymologischen Unfall im Deutschen mit dem gleichen Begriff bezeichnet werden.
  • 7. Zunächst ist festzuhalten: Schulden sind nicht schlecht. Halten wir zunächst etwas fest, dass den Schwaben unter uns schwer zu schaffen machen wird: Schulden sind per se nicht schlecht. Schulden sind einfach nur da. Die Möglichkeit, Schulden zu machen, ist ein fundamentales Grundprinzip unseres Wirtschaftssystems. Viele Dinge wären ohne das wirtschaftliche Konzept Schulden undenkbar.
  • 8. Zwei Arten: Öffentliche Schulden… Public debt is irrelevant. — John Maynard Keynes Aus makroökonomischer Sicht gibt es zwei Arten von Schulden: Einerseits die öffentlichen Schulden, über die John Maynard Keynes sagte, dass sie egal seien. Reinhard und Rogoff haben mit „This Time is Different“ ein sehr interessantes Buch über die Geschichte der öffentlichen Schulden geschrieben. Aber alles, was wir heute in der Makroökonomie wissen, deutet darauf hin, dass Keynes nicht ganz falsch lag. Zumindest sind sämtliche Modelle, die ihn zu widerlegen versuchten, gescheitert.
  • 9. Zwei Arten: …und private Schulden Anders schaut es mit privaten
 Schulden aus… Auf der anderen Seite stehen die privaten Schulden. Diese sind für die Makroökonomie viel wichtiger als die öffentlichen Schulden. Können die privaten Schulden in einer Volkswirtschaft nicht mehr bezahlt werden, bricht sie zusammen. John Kenneth Galbraith hat mit „Eine kurze Geschichte der Spekulation“ eine sehr angenehm zu lesende Zusammenfassung der Resultate privater Schulden, die aus Spekulation resultierten, geschrieben. Private Schulden sind also nicht egal. Ganz im Gegenteil.
  • 10. Wie passen technische Schulden da rein? Die große Frage ist nun: Wie passen technische Schulden in dieses System? Folgen sie dem Modell der öffentlichen Schulden oder dem der privaten Schulden? Die Antwort ist: Weder - noch. Technische Schulden folgen keinem der beiden Modelle, sondern funktionieren auf eine ganz andere Weise. Machen wir einen kleinen Ausflug in die Gesetzgebung, um herauszufinden, warum das so ist…
  • 11. Es begab sich am 29.5.2009… Selbst geschaffene immaterielle Vermögensgegenstände des Anlagevermögens können als Aktivposten in die Bilanz aufgenommen werden. Nicht aufgenommen werden dürfen selbst geschaffene Marken, Drucktitel, Verlagsrechte, Kundenlisten oder vergleichbare immaterielle Vermögensgegenstände des Anlagevermögens. Es begab sich am 29.5.2009 als der §248 HGB eine fundamentale Änderung erfuhr. Seit diesem Tag ist es möglich, „selbst geschaffene immaterielle Vermögensgegenstände“ in Unternehmensbilanzen zu aktivieren. Software ist so ein „selbst geschaffener immaterieller Vermögensgegenstand“.
  • 12. Das passt ganz hervorragend zu diesen Kollegen: Warum das ein Problem ist? Ganz einfach: diese Gesetzesänderung folgt dem Weg, der zur Pleite von Lehman Brothers geführt hat. Kennt ihr noch die Geschichte dazu? Ich beschreibe das hier mal ganz einfach, die Wirklichkeit ist natürlich viel komplizierter: Die Kollegen von Lehman Brothers hatten Kredite - also Fremdkapital - die gebündelt waren, als Wertpapiere gekauft und diese als Vermögensgegenstände in die Unternehmensbilanz aufgenommen. Als die Kredite ausfielen - private Schulden, die nicht zurückgezahlt werden konnten, Galbraith grüßt - gingen Vermögensgegenstände von Lehman Brothers plötzlich in nichts auf. Die Bilanz ging kaputt und die Bank ging pleite.
  • 13. Die Bilanz Aktiva Passiva Vermögens- gegenstände Eigenkapital Fremdkapital Software steht hier! Schauen wir uns mal so eine Bilanz an. Auf der rechten Seite stehen die sogenannten Passiva. Im Wesentlichen sind das Eigenkapital und Fremdkapital. Auf der linken Seite stehen die Vermögensgegenstände. Und eben auch der Wert der Software. Nur wie entsteht dieser Wert?
  • 14. Betriebswirtschaftliche Logik ‣ Software zu bewerten ist schwer. ‣ Also wird bewertet, was bewertet werden kann: der Aufwand der Erstellung der Software. ‣ Technische Schulden sind ein Aufwandstreiber:
 Je mehr technische Schulden, desto mehr Aufwand. ‣ Je höher der Aufwand, desto wertvoller die Software. ‣ Na, wer kennt das Ende…? Der Wert von Software ist relativ schwer zu ermitteln. Also versucht man, den Wert auf die einfachste mögliche Weise zu ermitteln. Und das ist bei Software die Zeit, die für ihre Erstellung benötigt wurde. Wir nennen das in der Regel den Aufwand. Unser Problem mit den technischen Schulden ist, dass diese ein Aufwandstreiber sind. Das bedeutet, mehr technische Schulden führen zu mehr Aufwand. Und je höher der Aufwand für die Erstellung der Software, desto wertvoller ist sie. Im Prinzip ist das der gleiche Mechanismus, der auch zur Pleite von Lehman Brothers geführt hat: Etwas, das eigentlich negativ wirkt, wird als Vermögensgegenstand bewertet. BWL ist halt keine exakte Wissenschaft.
  • 15. Das ist der Grund, warum es in vielen Unternehmen kein ökonomisches Verständnis für technische Schulden gibt. Dieser Bug in der wirtschaftlichen Betrachtung von Software ist der Grund, warum es kein ökonomisches Verständnis für die Entwicklung von Software gibt. Und warum es keine validen Wertmodelle gibt, die Software korrekt erfassen können.
  • 16. Ja, und nun…? Was machen wir nun mit diesem Wissen? Aufgeben? Eine neue BWL erfinden? Alle Softwareunternehmen auf den Pfad von Lehman Brothers schicken? Einfach keine Schulden mehr machen?
  • 17. Wir brauchen technische Schulden! Der Punkt ist: Keine technischen Schulden zu machen, ist keine Option. Wir benötigen technische Schulden ebenso wie wir die Möglichkeit finanzieller Schulden benötigen.
  • 18. ‣ Technische Schulden helfen uns, Software schnell auf den Markt zu bekommen. ‣ Technische Schulden helfen uns, Entscheidungen auf den letztmöglichen Zeitpunkt zu verschieben. ‣ Technische Schulden helfen uns, Projekte zu realisieren, die wir sonst nicht geschafft hätten. ‣ Je mehr wir uns in der Softwareentwicklung bemühen, technische Schulden zu vermeiden, desto mehr technische Schulden produzieren wir. Technische Schulden erlauben uns, Software ökonomisch zu entwickeln. Wir können unter Umständen mit einer Software früher auf dem Markt sein, wenn wir technische Schulden in Kauf nehmen.
 Für Softwareentwickler ist das nicht so angenehm, für ein Unternehmen kann das sehr wichtig sein. Wir können technische Schulden nutzen, um Entscheidungen in die Zukunft zu verschieben. Heute keine perfekte Lösung zu bauen, sondern mit der unperfekten Lösung Zeit erkaufen um Neues zu lernen und mehr über die wirklich perfekte Lösung zu erfahren ist nur möglich, wenn wir technische Schulden in Kauf nehmen. Technische Schulden können uns auch helfen, Projekte überhaupt zu realisieren, die unter anderen Umständen unmöglich gewesen wären. Zeitlich, finanziell - oder auch nur, weil wir einen Prototypen bauen wollen. Das waren allen Beispiele für das bewusste Aufnehmen technischer Schulden. Ein Kuriosum, das mir in vielen Projekten begegnet ist, ist die Tatsache, dass technische Schulden eine selbsterfüllende Prophezeiung sind. Je mehr wir uns bemühen, sie zu vermeiden, desto mehr von ihnen entstehen. Wir können uns nicht bewusst gegen sie entscheiden.
  • 19. Tools für technische Schulden Ich hatte ja ganz am Anfang versprochen, dass ich noch zwei Tools vorstelle, um mit technischen Schulden umzugehen. Hier kommen sie nun.
  • 20. Technische Schulden ökonomisieren Story Points Do
 Nothing
 Cost Das erste ist relativ einfach. Wir benutzen ein XY-Diagramm bei dem wir auf der X-Achse die Aufwände darstellen, die bei der Beseitigung einer technischen Schuld entstehen. Auf der Y-Achse tragen wir das ab, was ich als die Kosten des Nicht-Handelns bezeichne. Die X-Achse können die meisten Teams recht gut schätzen, Das Prinzip ist das gleiche wie beim Schätzen von User Storys. Das Schätzen der Y-Achse ist etwas schwieriger. Hier benötigen Teams in der Regel etwas Übung. Die Frage, die ich ihnen üblicherweise stelle ist: Um wie viel kleiner wird das Backlog, wenn wir diese technische Schuld begleichen? Nach drei, vier Sprints klappt das dann in der Regel mit dem Schätzen der „Do Nothing Costs“.
  • 21. Technische Schulden ökonomisieren Story Points A B C D E Do
 Nothing
 Cost Die technischen Schulden positionieren sich dann im Diagramm auf verschiedenen Stellen. Alles oberhalb der diagonalen Linie ist interessant, weil hier Nichtstun teurer ist, als die Beseitigung der technischen Schuld. Wichtig ist, dass man diese Betrachtung regelmäßig wiederholt. Ich mache das mit meinen Teams in jedem Sprint, und es entwickeln sich recht interessante Bewegungsmuster. Einige technische Schulden werden immer teurer, andere werden günstiger. Manchmal verschwinden sie sogar komplett, ohne dass irgend etwas getan werden muss. Leider führt das nicht dazu, dass man sie - wie Keynes die öffentlichen Schulden - als irrelevant betrachten kann.
  • 22. Technische Schulden bilanzieren A BV: 100 8 SP B BV: 150 5 SP C BV: 50 8 SP D BV: 208 13 SP E BV: 80 3 SP Ein zweites Werkzeug ist eine Bilanzierung technischer Schulden. Dazu benötigen wir eine Schätzung für den Business Value und den Aufwand für alle Backlog Items, die in einem Projekt bearbeitet werden.
  • 23. Technische Schulden bilanzieren C BV: 50 8 SP D BV: 208 13 SP Business Value Project Value C BV: 50 8 SP D BV: 80 5 SP D BV: 128 8 SP Summe = 258 Summe = 258 Eigen
 kapital Fremd-
 kapital Für die realisierten Features trägt man nun den Business Value auf der linken Seite der Bilanz und einen Project Value (mir fiel bisher kein besserer Begriff dafür ein) auf der rechten Seite ein. Hat man bei der Realisierung eines Features technische Schulden in Kauf genommen, wird das Feature auf der linken Seite mit seinem kompletten Business Value bilanziert. Auf der rechten Seite wird aber der Business Value entsprechend des investierten Teilaufwands gewichtet. Den Teilaufwand können Teams recht gut benennen, das Verhältnis für den Business Value ergibt sich dann automatisch. Diese Bilanz hilft uns dann, zu erkennen wie viel unseres Business Value tatsächlich geschaffen wurde und wie viel davon mit Schulden belastet ist. Da diese Schulden irgendwann einmal zurückgezahlt werden müssen, sollte auch die Bilanz kontinuierlich gepflegt werden.
  • 24. Fazit
  • 25. Keynes, Hayek & Lehman Brothers ‣ Technische Schulden werden nur in Ausnahmefällen irrelevant! ‣ Technische Schulden erledigt man nicht durch noch mehr technische Schulden! ‣ Technische Schulden sind ökonomische, keine technischen Entscheidungen! ‣ Technische Schulden zurückzahlen lohnt nur dann, wenn sie auch Zinsen kosten. Fassen wir zusammen: Technische Schulden sind alles andere als irrelevant, die üblichen ökonomischen Modelle erfassen sie aber nicht korrekt. Es ist nicht möglich, technische Schulden durch andere oder mehr technische Schulden zu erledigen, wie das bei öffentlichen Schulden möglich ist. Fundamental ist die Erkenntnis, dass technische Schulden keine technische Entscheidung sind, sondern eine betriebswirtschaftliche. Das irritiert viele Softwareentwickler und noch mehr irritiert es Nicht-ITler. Was bei der gesamten Debatte auch bedacht werden sollte ist, dass es sich nur lohnt, technische Schulden abzutragen, wenn sie tatsächlich Geld kosten. Die oftmals geführte State of the Art-Debatte ist dabei weder hilfreich noch zielführend.
  • 26. Noch ein paar Tipps zum Schluss… ‣ Macht technische Schulden im Backlog sichtbar! ‣ Quantifiziert den Business Value technischer Schulden! ‣ Bewertet technische Schulden realistisch, um Vertrauen zu schaffen. ‣ Schaut nicht zu weit und nicht zu kurz voraus, um unabsichtliche technische Schulden zu vermeiden. ‣ Und: Müll im Code ist keine technische Schuld! Ein paar Tipps habe ich noch für euch: Macht eure technischen Schulden sichtbar. Beispielsweise als Backlog Items im Product Backlog. Beschäftigt euch mit dem Business Value der technischen Schulden und bewertet sie realistisch. Wenn ihr über Business Value sprecht, könnt ihr auch Nicht-ITler erreichen. Eine realistische Bewertung schafft Vertrauen und zeigt Kompetenz über die Software hinaus. Es nützt nichts, zur Vermeidung technischer Schulden in die Zukunft schauen zu wollen. Solve today’s problems today and tomorrow’s problems tomorrow. Und: Nicht alles, was wie Müll ausschaut ist eine technische Schuld.
 Seid ehrlich zu euch selbst und macht eure Hausaufgaben beim Coden.