Technisches Schulden Szenario 2: Die Feature Fabrik

Das nächste Szenario wie technische Schulden aufgebaut werden, dreht sich um den Begriff "Feature Fabrik". Wenn Du einen Software Engineering Hintergrund hast, bin ich sicher, dass Du auch schon mit diesem Begriff konfroniert wurdest und Dir das nachfolgende Szenario vermutlich bekannt vorkommt.

Dies ist bereits der zweite Artikel, der sich mit Szenarien befasst, in welchen technische Schulden aufgebaut werden. Wenn Du in den ersten Artikel interessiert bist, klicke auf den nachfolgenden Link (der Artikel ist momentan nur in englisch verfügbar). 👇

Technical Debt Scenario #1: Starting without any architectural vision

The team is working on a new software product. The only thing the team wants is to start coding. How can technical debt already cause?

workingsoftware.devPatrick Roos

Table of Contents

• Szenario
• Was ist das Problem?
• Wie kannst Du dieses Problem verhindern?
• Fazit

Szenario

🕑  Planning Sprint 5

👩‍💻 🧑‍💻 👨‍💻 Entwickler: Hey Product Owner, wir sollten ein paar technische Aufgaben ins Sprint Backlog einplanen. Zum Beispiel dauert unsere Build-Pipeline vom Frontend auf dem Development-Branch über 45 Minuten. Und ja, unsere Test-Coverage auf bestehenden Funktionalitäten ist auch nicht gerade gut. Es wäre gut, wenn wir im Backlog Aufgaben hätten um diese technischen Themen zu adressieren. Das sollten wir sobald wie möglich tun.

🧑‍💼 Product Owner: Ihr wisst wie's läuft. Ihr kennt unseren Sponsor. Wir bekommen ernsthafte Probleme wenn wir nicht an Story X und Story Y arbeiten. D.h. wir haben keine Zeit für irgendwelche technischen Aufgaben.

👩‍💻 🧑‍💻 👨‍💻  Entwickler: Aber...

🧑‍💼 Product Owner: Kein aber...! Lass uns den Sprint beginnen.

🕑  Sprint Review 5

🧑‍💼 Product Owner: Liebe Review-Teilnehmer. Wir haben die beiden Story X und Y erledigt. Gerne präsentieren wir Euch heute diese beiden Stories.

👩‍💻 🧑‍💻 👨‍💻  Die Entwickler präsentieren die beiden User Stories. Die Review-Teilnehmer sind zufrieden.

🕑  ... Sprint 5...10...

🕑  Planning Sprint 10

🧑‍💼 Product Owner: So ich habe Euch Story Z vorgestellt. Könnt Ihr schätzen wie lange ihr habt, am besten gleich in Stunden?

👩‍💻 🧑‍💻 👨‍💻  Die Entwickler schätzen: Wir haben 40h für die Story Z.

🧑‍💼 Product Owner: W-T-F! 40 Stunden für diesen einfachen Screen? Dieser besteht ja einfach aus ein paar Eingabefeldern und ein paar Buttons. Das kann einfach nicht sein. Ich verstehe nicht warum Ihr so lange habt um solche Screens umzusetzen. Ich bin nicht zufrieden mit Eurer Performance. Wir müssen das mit dem Geldgeber besprechen.

Was ist das Problem?

Es gibt leider Stakeholder, die erwarten vom Produktteam in einer unmöglichen Geschwindigkeit neue Features. In der Regel haben solche Personen kein technisches Wissen (oder noch problematischer "technisches Pseudowissen") und auch kein Verständnis für technische Themen.

In einem greenfield Produktentwicklungsansatz kann der straff Feature-getriebene Ansatz für ein paar Sprints funktionieren; wie Du vielleicht auch aus dem obigen Szenario erkennen kannst. Wenn Du aber die aufgelaufenen technischen Themen nicht aktiv adressierst, wird der technische Schuldenberg von Sprint zu Sprint grösser. Die Team-Velocity wird zwangsläufig immer schlechter und so kommt es, dass der Product Owner oder ein anderer Stakeholder mit dem folgenden Satz konfrontiert: "Ich verstehe nicht, wieso es so lange dauert das neue Feature X umzusetzen. Das sollte doch einfach und schnell umsetzbar sein, nicht?".  Was sagst dann?

Wie kannst Du dieses Problem verhindern?

Aus meiner Sicht gibt es zwei Herausforderungen in diesem Szenario:

• Kommunikation von technischen Schulden ggü. Stakeholder welche kein technisches Verständnis haben
• Aktives Management von technischen Schulden

Grundsätzlich gibt es keine einfache Lösung um das oben skizzierte Problem zu adressieren. Ich versuche Dir mögliche Lösungsansätze aufzuzeigen.

Nimm technische Schulden auf, aber explizit und mache die Schulden transparent

Technische Schulden sind vergleichbar mit finanziellen Schulden. Wenn Du mit der Kreditkarte zahlst oder Dir ein Haus kaufst, schuldest Du Geld einer Bank. Mit den Schulden kommen automatisch die Zinsen für die Schulden, welche Du kontinuierlich bezahlen musst. Du musst sicherstellen, dass deine Schulden sowie die daraus resultierenden Zinsen angemessen sind und tragbar bleiben.

Das Problem mit technischen Schulden ist, dass diese oft nicht direkt sichtbar sind und langsam, aber kontinuierlich steigen. Ein Beispiel ist, die Build-Zeit von einem Frontend, welche immer länger dauert und erst dann zum richtigen Problem wird, bei 45 Minuten Build-Zeit auf einem Development-Branch. Ein weiteres Beispiel sind eingesetzte Fremdkomponenten, welche kritische Sicherheitslücken aufweisen oder auch ein verpasster Upgrade auf einen nächsten Major Release. Mit den technischen Schulden steigen somit auch die Zinsen die man zahlt; in Form von Zeit, Geld oder Risiken.

Um diese Problematik zu adressieren, empfehle ich Dir als ersten Schritt die bisher er bekannten technischen Schulden sichtbar zu machen.

Wie kannst Du technische Schulden sichtbar machen?

Als erstes, sammle - gemeinsam mit dem Team - alle bisher bekannten technischen Schulden und kreiere daraus eine technische Schuldenliste.

Diese Liste sollte folgende Attribute beinhalten:

• Schuld-Id
  Id der identifizierten technischen Schuld
• Datum
  Datum an welchem man die technische Schuld entdeckt hat oder eingegangen ist
• Gemeldet von
  Die Person, welche die technsiche Schuld identifiziert resp. gemeldet hat
• Name
  Ein kurzer, sprechender Titel der technischen Schuld
• Beschreibung
  Eine kurze Beschreibung der technischen Schuld
• Auswirkungen, Risiken, Kosten
  Beschreibe hier die Auswirkungen, die resultierenden Risiken sowie die anfallenden Kosten durch diese eingegangene technische Schuld.
• Mögliche Lösungsstrategien
  Skizziere hier mögliche Lösungsstrategien, welche die technische Schuld minimieren, die Risiken minimieren oder generell lösen.
• Datum der letzten Prüfung dieser technischen Schuld
  Wann hat das Team das letzte Mal die technische Schuld thematisiert und entsprechend eingeordnet?

Folgend zeige ich anhand des Praxisbeispiel "Langsamer Frontend-Build" wie man eine technische Schuld entlang vom oben aufgezeigten Schema explizit machen kann.

• Schuld-Id: 1
• Datum: 28.08.2021
• Gemeldet von: Patrick
• Name: Langsamer Frontend build
• Beschreibung:
  Der Build von unserem (monolithischen) Frontend dauert ca. 45 Minuten auf dem Development-Branch.
• Auswirkungen, Risiken, Kosten der Schuld
  ❗ Die lange Build-Zeit verlangsamt deutlich das Build- und Test-Feedback ggü. dem Entwickler. Dieser muss mindestens 45 Minuten pro Build warten, bis er das Feedback erhält: Baut das Feedback? Integriert es mit parallel entstandenden Funktionalitäten? Laufen die Integrations- und E2E-Tests durch?
  ❗️ Lokales produktives Bauen dauert ebenfalls 45 Minuten. Dies macht der Entwickler lokal nicht mehr, da es zu lange dauert. Somit werden Integrationsfehler erst im CI-Build erkannt.
  ❗️ Verlangsamt die Auslieferung von einem Hotfix (mind. 45 Minuten)
• Mögliche Lösungsstrategien
  💡 Eine erste Analyse hat gezeigt, dass das Build-System durch verschiedene Massnahmen auf mindestens 10 Minuten optimiert werden kann; jedoch müssen dafür ca. 10 PT investiert werden.
  💡 Ein Workaround wäre eine zeitintensive Build-Option zu deaktivieren. So könnte man die Build-Zeit auf ca. 20 Minuten reduzieren. Jedoch würde die Ladezeit der Webanwendung um knapp eine Sekunde erhöht werden. (Aufwand 2 PT)
• Letzte Prüfung dieser technischen Schuld: noch nicht

Kontinuerliches Reporting von neuen technischen Schulden

Das Pflegen der oben aufgebauten Liste mit technischen Schulden ist in der Verantwortung des ganzen Teams. D.h. wenn eine Software-Entwicklerin oder ein Software-Entwickler eine technische Schuld entdeckt, soll sie oder er diese in die gemeinsame Schuldenliste eintragen.

Ein möglicher Scrum-Event für die kurze Besprechung von neuen entdeckten technischen Schulden aus dem letzten Sprint ist die Sprint Retrospektive. Der Scrum Master könnte Beispielsweise diese Besprechung als fixer Agendapunkt hinzufügen.

Priorisiere die technischen Schulden entlang der Dringlichkeit basierend auf der daraus resultierenden Gewichtung

Wenn Du gemeinsam mit dem Produktteam die Liste der technischen Schulden kontiniuerlich pflegst, erhält das Team automatisch eine gute Basis für die Priorisierung. Wie priorisiert man technische Schulden?

Ein guter Ansatz um technische Schulden zu priorisieren ist die "Weighted Shortest Job First" (WSJF) Formel.

Diese Formel enthält die folgenden Faktoren:

User business value

• Was ist der relative Wert für den Kunden oder auch für das Unternehmen?
• Würden die Nutzer die Erledigung dieser technischen Schuld vorziehen (z.B. werden damit bestimmte nicht-funktionale Anforderungen adressiert)?
• Wie beinflusst diese Schuld den Revenue-Stream der Unternehmung?
• Erfahren wir eine negative Auswirkung wenn wir diese technische Schuld später adressieren?

Time criticality

• Gibt es eine fixe Deadline bis wann diese Schuld zurückbezahlt werden muss?
• Würden Kunden zu einer anderen Lösung abspringen wenn wir diese Schuld nicht lösen?
• Gibt es Mitarbeiter, die sich eine anderen Job suchen, wenn wir diese technische Schuld nicht zeitnah adressieren?
• Gibt es Meilensteine auf dem kritischen Pfad, welche die Auflösung dieser Schuld voraussetzen?
• Was ist der Impact von dieser Schuld auf die Kunden- und Mitarbeiterzufriedenheit?

Risk mitigation/opportunity enablement

• Adressiert die Auflösung dieser Schuld spezifische, bekannte Risiken?
• Unterstützt die Auflösung dieser Schuld die Geschwindigkeit einer Auslieferung von einem zukünftigen Release?
• Eröffnet die Adressierung dieser Schuld neue (Business-) Opportunitäten?

Duration

• Wie lange wird es dauern, diese technische Schuld zu adressieren resp. zurückzuzahlen?

Sämtliche Faktoren sollen selbstverständlich relativ zueinander geschätzt werden. Dazu kann beispielsweise die Fibonacci-Folge verwendet werden.

Nach dem das Cost of Delay im Verhältnis zur Duration für jede technische Schuld gerechnet wurde, hat man eine priorisierte Liste sortiert nach den gewichtigsten, aber aufwandsärmsten technischen Schuld. Die Erledigung der am höchsten priorisierten technischen Schulden kann man nun im kommenden Sprint einplanen.

Kontinuierliche Bewertung und Planung der ermittelten technischen Schulden

Die Liste mit den technischen Schulden sollte vom ganzen Produktteam kontinuierlich durchgegangen werden.

Ein guter Fixpunkt ist beispielsweise ein monatliches Meeting, um die geführten technischen Schulden zu bewerten. An diesem Meeting geht man timeboxed entlang der Priorisierung durch die technischen Schulden und bewertet diese im aktuellen Kontext erneut. Dabei werden die oben aufgezeigten Gewichtungsfaktoren geprüft: Business Value, Zeitkritikalität, Mitigierung von Risiken, Opportunitäten sowie die Dauer für die Behebung von technischen Schulden. So werden ggf. einige technische Schulden aufgrund von aktuellen Gegebenheiten repriorisiert.

Beim Durchgehen jeder Schuld definiert das Team der Umgang mit der jeweiligen technischen Schuld:

• Sollen wir weiterhin die Zinsen für die aufgenommene technische Schuld bezahlen? Wenn ja, behalte die technische Schuld weiterhin auf der Liste.
• Sollen wir die Schuld zurückzahlen? Wenn ja, plane das Zurückzahlen der Schuld im nächsten Sprint ein.
• Sollen wir eine Umschuldung durchführen? Wenn ja, plane einen Workaround ein, um die Schuld zu lösen oder zu minimieren. Achtung: Mit dem Workaround nimmst Du aber eine andere technische Schuld auf. Nimm diese direkt auf die Liste auf.

Eine gute Daumenregel ist, ca. 10 - 20% vom Sprint-Backlog für die Behandlung von technischen Schulden zu verwenden.

Das oben gezeigte Entscheidungsschema unterstützt das Team beim expliziten Umgang mit technischen Schulden. Zusätzlich hilft es in der Kommunikation ggü. verschiedenen Stakeholder. Das Produktteam kann jederzeit aufzeigen, welche technischen Schulden bestehen, welche aktiv angegangen werden und für welche Schulden man die Zinsen bezahlt.

Fazit

Schulden sind nicht schlecht per se. Aber übermäßige Schulden und die daraus resultierenden kumulierten, übermäßige Zinsen sind problematisch. Technische Schulden können mit finanziellen Schulden verglichen werden. Dokumentiere die aufgenommenen Schulden sichtbar und mache sie dadurch explizit, kommuniziere die Ursachen, Kosten sowie Risiken; bewerte die technischen Schulden kontinuierlich im Produkt-Kontext und zahle sie kontinuerlich ab.

Ich habe schon oft erlebt, dass man Entwicklungteams mit "Fabriken" verglichen hat. Oder eine "Fabrik" als Zielbild von Produktteams skizziert hat. In der Software-Produktentwicklung sind die meisten Herausforderungen komplex oder kompliziert (vgl. Cynefin-Framework). In einer "Fabrik" löst man repetitiv einfache Probleme. Daher denke ich, dass diese Fabrikmetapher im Zusammenhang mit Engineering-Teams fehl am Platz ist. Wenn Du diese Metapher aber trotzdem hörst, erhälst Du eine Möglichkeit einen Mindset-Wechsel herbeizuführen: Von einer "Feature-Fabrik" Denkweise zu einer richtigen Produkt-Denke. Die Herbeiführung eines solchen Organisationschange - nur schon von der Denkweise - können noch nicht entdeckte oder aktivierte Kräfte freisetzen.

Oder: Hast Du jemals einen leidenschaftlichen Fliessbandmitarbeiter in einer Fabrik gesehen?