- Was nötig ist, um Technical Debt als strategisches Mittel zu betrachten
- Negative Annahmen über Technical Debt erkennen und auflösen
- Die 6 Arten von Technical Debt klassifizieren und differenziert behandeln
- Das Ausmaß von Technical Debt erfassen
- So legt man Prioritäten für Technical Debt fest
How to Not Manage Tech Debt
- Vier Annahmen, die zu schlechtem Management von Technical Debt führen
Annahme #1: Technical Debt = etwas Schlechtes
- Nicht jede Technical Debt sollte als „schlecht“ eingestuft werden
- Viel besser ist es, sie zu benennen, das Ausmaß des Schmerzes zu messen und die verschiedenen Arten von Technical Debt zu klassifizieren
- Manche Arten von Technical Debt können sinnvoll sein, und jedes Team sollte Technical Debt haben
- Beispiel Twitter, das „gute Technical Debt“ hatte: erst Nutzung von Public Storage, später Entwicklung der eigenen verteilten DB Manhattan
- Fragen, um der Annahme „Technical Debt = etwas Schlechtes“ zu begegnen
- Was gewinnen wir, wenn wir diese Technical Debt jetzt bewusst aufbauen und erst nächsten Monat beheben?
- Unter welchen Umständen würde sich das Management für diese Technical Debt interessieren? Welche Informationen helfen dem CTO dabei, das Thema gegenüber dem Management zu pitchen?
- Wie kann diese Initiative mit der größeren Vision oder strategischen Richtung des Unternehmens verknüpft werden?
Annahme #2: Jede Technical Debt = komplexe Arbeit
- Wie bei jeder schwierigen Aufgabe gibt es auch bei Technical Debt verschiedene Wege, komplexe Arbeit zu bewältigen
- Gerade bei Technical Debt kann man Defined/Undefined-Aufgaben unterschiedlich angehen
- Defined = Die Aufgabe hat einen Anfang und ein Ende
- Undefined = Die Aufgabe hat einen Anfang, aber kein klares Ende
- Um der Annahme „Technical Debt = komplex“ zu begegnen
- Zuerst klar machen, ob die vorliegende Technical Debt Defined oder Undefined ist
- Bei Defined-Aufgaben sollte man die geschätzte Bearbeitungszeit verstehen und etwas Puffer einplanen
- Bei Undefined-Aufgaben sollte man die unklaren Punkte auflisten und Stakeholdern vermitteln, warum die Arbeit komplex ist und kein klares Enddatum hat, um gemeinsam den besten Weg nach vorn zu finden
- Undefined Technical Debt in leichter verdauliche Teilaufgaben zerlegen, um sie weniger komplex zu machen
- Wenn aus einer großen, komplexen Aufgabe kleinere, immer noch anspruchsvolle, aber umsetzbare Aufgaben werden, ist das Team eher motiviert, in Sprint- oder Quartalszeiträumen Teile der Technical Debt anzugehen
- Fragen, um der Annahme „Technical Debt = komplexe Arbeit“ zu begegnen
- Welche falschen Annahmen machen wir über das System?
- Welche Fragen müssten wir unbedingt stellen, wenn wir jemanden mit Erfahrung oder Vertrautheit in diesem Bereich hinzuziehen würden?
- Haben wir im Team die richtigen Leute und das nötige Wissen, um diese Aufgabe zu erledigen? Wenn nicht, wie sollten wir Wissen oder Ressourcen neu verteilen, und wann wäre der richtige Zeitpunkt, das Problem anzugehen?
- Wie erklärt man die Komplexität dieser Technical Debt am besten jemandem, der sie überhaupt nicht versteht?
Annahme #3: Technical Debt ≠ Produktarbeit
- Organisationen haben meist ein klares Bild davon, wie Produktarbeit die Unternehmensmetriken verbessert
- Bei Technical Debt fehlt dieser Zusammenhang oft
- Technical Debt rechtzeitig zu adressieren, kann für das Unternehmenswachstum entscheidend sein, auch wenn sich das nicht sofort quantifizieren lässt
- Um der Annahme „Technical Debt ≠ Produktarbeit“ zu begegnen
- Auch wenn ein bestimmter Bereich von Technical Debt nicht direkt mit Kennzahlen verknüpft ist, sollte man breiter darüber nachdenken, welche Nutzer- oder Produkterfahrung davon profitiert
- Wenn man neben den technischen Vorteilen gleichermaßen die Vorteile für Nutzer und Produkt betont, können andere leichter verstehen, warum dem Team diese Arbeit wichtig sein sollte
- Man sollte Zeit investieren, damit Business-Lead und Tech-Lead wirklich auf derselben Seite stehen
- Fragen, um der Annahme „Technical Debt ≠ Produktarbeit“ zu begegnen
- Was ist der wichtigste Grund, diese Arbeit jetzt zu machen?
- Wer muss die Wirkung dieser Arbeit verstehen, und warum sollte diese Person sich dafür interessieren?
- Was will ich eigentlich sagen? Entspricht das dem, was Stakeholder hören wollen? Wenn nicht, wie kann ich ihr Problem lösen?
- Was betrachten ich oder mein Team als ein akzeptables gegenüber einem hervorragenden Ergebnis?
- Verspreche ich bei den erwarteten Ergebnissen zu viel? Können wir die Erwartungshaltung kalibrieren, indem wir zwischen gut und großartig unterscheiden?
Annahme #4: Individueller Schmerz = organisatorischer Schmerz
- Engineers, die nah an Technical Debt arbeiten, sagen regelmäßig, dass die Arbeit daran persönlich schmerzhaft ist
- Für die Mitarbeitenden kann es sich wie das Ende der Welt anfühlen, aber der Rest der Organisation spürt diesen Schmerz oft nicht
- Das ist vor allem bei Menschen in frühen Karrierephasen verbreitet und entsteht meist aus fehlendem strategischem Gesamtkontext
- Um der Annahme „individueller Schmerz = organisatorischer Schmerz“ zu begegnen
- Wenn man auf einen hoch priorisierten Bereich von Technical Debt stößt, sollte man kurz prüfen, ob es sich um einen individuellen oder einen organisatorischen Pain Point handelt
Allgemein haben Probleme auf Organisationsebene in irgendeiner Form direkte Auswirkungen auf Kunden oder das Geschäft
- Versuche, aus der Perspektive von jemandem mit mehr organisatorischem Kontext zu denken. Es kann auch helfen, das Thema jemandem aus einem anderen Team zu erklären
- Fragen, um der Annahme „individueller Schmerz = organisatorischer Schmerz“ zu begegnen
- Wie viele Teams profitieren davon, wenn wir diese Technical Debt einordnen und beheben?
- Wann hat das Unternehmen Menschen anerkannt oder belohnt, die an Technical Debt gearbeitet haben? Um welche Art von Technical Debt ging es, und warum war sie damals nötig? Kannst du beschreiben, wie diese Person die Arbeit positioniert hat?
- Versteht mein Engineering Manager den Wert dieser Arbeit an Technical Debt? Würde er in meinem Performance Review meine Beiträge dazu aktiv vertreten?
Die 6 Arten von Technical Debt
- Maintenance debt
- Wenn das Team mit Updates der verwendeten Technologien nicht Schritt hält
- Dazu gehört auch, nach Experimentstarts / Feature-Rollouts / Rollbacks keinen Dead Code zu entfernen oder Library-Updates, Kommentare zu kontextrelevantem Code und Dokumentation von Implementierungsentscheidungen nicht zu pflegen
- Beispiel: Man experimentiert mit einer Funktion wie „log in with Spotify“ und löscht den dazugehörigen Code nach dem Abbruch nicht
- Developer efficiency debt
- Wenn ein Unternehmen keine angemessenen Tests, kein Monitoring und keine Alerting-Systeme für sein Produkt hat
- Ein typischer Schulden-Typ, bei dem Engineering-Workflows extrem ineffizient sind, Deployments/Builds Stunden oder Tage dauern und Entwickler technische Probleme nicht erkennen, bevor etwas in Produktion geht
- Beispiel: Die Organisation wächst innerhalb eines Jahres von 15 auf 50 Personen, während zu viele Experimente parallel laufen. Releases zur Behebung von in Produktion entdeckten Bugs hängen zwei bis drei Versionen hinterher. Neue Tests für das Einkaufserlebnis bleiben weiter zurück
- Stability debt
- Wenn sich verschiedene Arten von Technical Debt in einer Organisation ansammeln und dadurch die Stabilität der Infrastruktur beeinträchtigt wird
- Statt On-Call proaktiv zu managen, werden Expertinnen und Experten erst nach Auftreten eines Problems hinzugezogen oder das gesamte Team landet im On-Call
- Für Engineers und das On-Call-Rotationsteam ist das ein massives Ärgernis, während der Rest des Unternehmens das Problem kaum einordnen oder erklären kann
- Stability debt wirkt sich auch auf die Zuverlässigkeit des Produkts aus und führt damit zu Problemen, die Kunden direkt erleben
- Beispiel: Im Mobile-Team gibt es mehr iOS-Entwickler, daher wird iOS gegenüber der Android-App priorisiert. Dadurch fehlen der Android-App Produkt-Guidelines für geschäftskritische Flows, und es existiert noch schwacher Code (Kryptonite), der ursprünglich von Dritten entwickelt wurde. Wenn Android-Nutzer auf ältere Funktionen zugreifen, kommt es zu Abstürzen, was schlechte Bewertungen im Google Play Store nach sich zieht
- Security debt
- Wenn ein Tech-Stack Sicherheitslücken wie Brute-Force-Angriffe oder Datenlecks ermöglicht
- Viele Organisationen haben Security debt, weil es Menschen schwerfällt, mögliche oder auch nicht eintretende Ereignisse zu planen und zu bewerten
- Beispiel: Wegen Problemen in internen Prozessen werden Updates nicht rechtzeitig eingespielt, bekannte Schwachstellen bleiben ungepatcht und persönliche Kundendaten werden offengelegt — von kleinen Unternehmen bis hin zu Firmen wie Equifax, bei denen 140 Millionen Menschen betroffen waren
- Technical product debt
- Wenn negative Auswirkungen auf das Produkt deutlich sichtbar werden
- Das ist die am leichtesten erkennbare und am einfachsten zu behebende Form von Technical Debt, weil sie auch für Nutzer spürbar ist und alle Teams im Unternehmen sehen, dass sie Vertrieb/Umsatz beeinflusst
- Beispiel: Nutzer brauchen im Produkt mehrere Sekunden für eine bestimmte Aktion. Das kann durch verschiedene Arten von Debt entstehen, beeinträchtigt aber die zentrale Produkterfahrung
- Decision debt
- Wenn für frühere technische Entscheidungen Kosten anfallen, weil sie zu einem gewissen Prozentsatz falsch waren oder weil bei Umfang, Zeit oder Ressourcen Kompromisse eingegangen wurden
- Die häufigste Form von Technical Debt
- Beispiel: Für ein bestimmtes Experiment auf einer Website wird ein Drittanbieter eingesetzt. Nach mehreren Jahren starken Wachstums kommen nun Millionen Nutzer auf die Seite. In der Folge haben Tech-, Daten- und Produktteams jedes Mal große Mühe, wenn sie komplexe Experimente durchführen wollen.
Dadurch entsteht Decision debt, weil das Team damals einen Trade-off zwischen einem Drittanbieter und Eigenentwicklung getroffen hat. Damals war das vielleicht richtig, heute zeigt sich die Wirkung
Das Ausmaß von Technical Debt bestimmen: Acute vs. Systemic
- Wenn man die Arten von Technical Debt verstanden hat, muss man das Ausmaß der Kosten bestimmen, um es dem potenziellen Nutzen gegenüberzustellen
- Wenn Teams fragen: „Wann finden wir Zeit, an Technical Debt zu arbeiten?“, ist oft schwer einzuschätzen, ob es in Bezug auf Zeit, Nachdenken und Aufwand klein oder groß ist
- Acute Technical Debt
- Relativ kleine Technical Debt
- Beispiel: Um eine neue Funktion bereitzustellen, wurde Arbeit für eine Plattform/einen Browser mit geringer Nutzung übersprungen. Wenn sonst nichts dazwischenkommt, lässt sich das leicht innerhalb eines Tages nachholen
- Systemic Technical Debt
- Große bis sehr große Technical Debt
- Beispiel: Der CTO oder Gründer hat vor fünf Jahren eine Produktentscheidung getroffen, auf deren Grundlage über Jahre gearbeitet wurde. Eine Änderung hätte Auswirkungen auf viele verschiedene Bereiche.
Diese Technical Debt lässt sich nicht leicht beheben; Änderungen können Monate oder Jahre dauern
Technical Debt strategisch priorisieren
- Ein flexibler Ansatz für Bewertung und Priorisierung
- Confidence: Wie wahrscheinlich ist es, dass das zu einem ernsthaften Problem wird? niedrig/hoch
- Time: Wann wird das zum Problem? nicht dringend/dringend
- Impact to User: Führt Nichtstun zu Geschwindigkeits- oder Qualitätsproblemen, die der User Experience schaden? niedrig/hoch
- Sequence: Hindert es uns daran, einen wichtigen Meilenstein zu erreichen? geringe Auswirkung/blockierend
- Accumulated debt: Wie viel Debt haben wir bereits bewusst akkumuliert? wenig/viel
Strategisches Technical-Debt-Portfolio je nach Wachstumsphase des Unternehmens
- Traction:
- Vor Product-Market fit
- Engineering-Entscheidungen sollten eher auf Geschwindigkeit als auf Korrektheit, Stabilität oder Prozesse ausgerichtet sein. Viel Developer efficiency debt
- Typischerweise bedeutet das die Wahl von Full-Stack-Frameworks wie Django, Rails oder PHP, um schnell zu entwickeln
- Inflection:
- Es zeigen sich Anzeichen von PMF, und das Produkt wechselt in eine skalierbare Schleife
- Das Team erkennt, dass bestimmte Prozesse notwendig sind (Developer efficiency debt beginnt abzunehmen), während es noch zwischen internen Prozessen und User Experience balanciert, wodurch Technical product debt zunimmt
- Scale:
- Hypergrowth-Phase des Unternehmens
- Während intern ein Gleichgewicht zwischen Praktiken/Prozessen und User Experience gefunden wird, nehmen Technical product debt und Developer efficiency debt ab und stabilisieren sich
- Als Folge des sehr schnellen Wachstums nehmen Security debt, Maintenance debt und Decision debt zu
- Es gibt viele Änderungen und Anpassungen bei Testautomatisierung, Deployment-Systemen, Monitoring und Alerting, Logging und Instrumentation, Test- und Staging-Umgebungen, ETL usw.
- Expansion:
- Beginn der Sättigung. Das Geschäft wird reifer
- Durch große Mengen alten Codes und früherer Entscheidungen steigen Maintenance debt und Decision debt weiter an
- Während das Team neue Chancen für Wachstum sucht, beginnt auch Developer efficiency debt wieder zuzunehmen
- Technical product debt, Security debt und Stability debt kommen nach der vorangegangenen Phase allmählich in Balance
Tipps für das Management eines Technical-Debt-Portfolios
- Prozesse, um entstehende Technical Debt zu reduzieren
- Zwar kann das bewusste Aufbauen von Technical Debt strategisch sinnvoll sein, aber manchmal ist es richtig, schon früh Prozesse einzuführen, die die Entstehung neuer Technical Debt verhindern
- Das gilt besonders für die Phasen Inflection und Scale, in denen mit mehr Engineers eigentlich Developer efficiency debt sinken sollte
- Weniger Developer efficiency debt kann allerdings durch mehr Decision debt und Maintenance debt ersetzt werden
- Beispiele für solche Prozesse: Code-/PR-Reviews, Monitoring-Standards, QA-Freigaben sowie Tech-/Design-Reviews
- Tools, die das Entstehen bestimmter Debt-Arten verhindern
- Investitionen in grundlegende Tools können verhindern, dass bestimmte Arten von Debt überhaupt entstehen
- Besonders wichtig in der Scale-Phase: für Sicherheitsprobleme (Security debt), zur Vermeidung von Bugs mit Auswirkungen auf die User Experience (Technical product debt) und für konsistenten Code (Developer efficiency debt)
- Beispiele für solche Tools: Linter und CI/CD-Pipelines
- Sprint-Arbeit für reaktive und akute Technical Debt
- Sobald eine Organisation eine Größe erreicht, in der On-Call nötig ist, sollten On-Call-Sprints für das Löschen akuter Brände oder für reaktive Arbeit im Zusammenhang mit Technical Debt verwendet werden
- So kann die Organisation dringende Technical-Debt-Themen bearbeiten und das On-Call-Team in die Lage versetzen, aktuelle und frühere Probleme tatsächlich anzugehen
- On-Call für solche Reaktionsarbeit zu ermöglichen, ist besonders in den Phasen Scale und Expansion wichtig. Dringende Technical Debt zu bearbeiten, hilft anderen Teams dabei, neue Funktionen/Produkte zu bauen und zusätzliche Debt zu bewältigen
- Roadmap-Arbeit für proaktive und systemische Technical Debt
- Technical Debt in die Roadmap aufzunehmen, erfordert Abstimmung über viele Teams hinweg
- Beispiele für Technical Debt in der Roadmap: große Rewrites, Neujustierung von Datensystemen für stark genutzte Kundenfunktionen, Definition und Implementierung von Alerts für zentrale Pfade, Umstellung von Zahlungssystemen usw.
Wie man Technical Debt von einer Last in ein strategisches Mittel verwandelt
- Über angesammelte Technical Debt kann ein Team strategische Gesamtentscheidungen darüber treffen, welche Initiativen verfolgt werden sollen
- Denk über die typischen Annahmen zu Technical Debt nach, denen dein Team begegnet. Sprichst du dich gegen „Technical Debt = etwas Schlechtes“ oder „Technical Debt ≠ Produktarbeit“ aus? Hörst du Kolleginnen oder Kollegen zu, die glauben, „individueller Schmerz = organisatorischer Schmerz“?
- Vermeide den pauschalen Begriff „Technical Debt“. Benenne sie stattdessen als Maintenance debt, Developer efficiency debt, Stability debt, Security debt, Technical product debt oder Decision debt
- Bestimme das Ausmaß der Technical Debt, um sie weniger vage zu machen: Ist sie acute oder systemic?
- Priorisiere Technical Debt strategisch im Vergleich zu anderen Unternehmensbereichen, basierend auf Vektoren wie Confidence, Time oder Impact to User
- Lasse das Technical-Debt-Portfolio mit dem Unternehmenswachstum, den Veränderungen und neuen Anforderungen weiterentwickeln und in Balance bleiben
2 Kommentare
Ich denke, das Grundlegendste und zugleich Wichtigste ist, klar zu vermitteln: „Das ist Ihr Schmerzpunkt.“ Egal ob mit Zahlen oder auf andere Weise.
Wenn das nicht gelingt, könnte man letztlich vielleicht sogar zu dem Schluss kommen, dass es in Wirklichkeit gar keine technische Schuld war.