Codovation

Das Thema technische Schuld hat sich durch agile Prinzipien und Entwicklungsmethoden nicht positiv verändert – es ist allenfalls sichtbarer geworden. Ich würde sogar soweit gehen zu sagen, dass durch fehlerhafte Implementierungen agiler Methoden, die ausschließlich die opportune Entwicklung kurzfristig wirkender Features im Fokus haben, die Situation schlimmer geworden ist. Präventive Maßnahmen wie TDD , Pair Programming und kontinuierliches Refactoring sind zwar (zumindest in der agilen Landschaft) gut angenommen und gelebt, dennoch gibt es keine allgemein akzeptierten Ansätze zur nachhaltigen Entwicklung großer Softwaresysteme, die über plakative Aussagen und generische Appelle hinausgehen. So fordert beispielsweise das Craftsmenship-Manifesto nicht nur funktionierende sondern auch sehr gut entwickelte Software zu liefern; tiefer geht es dann aber nicht und auf Antworten oder gut adaptierbare Erfahrungen bleiben Mangelware . Und so ist  Software ohne einen größeren Berg technischer Schulden selten aufzufinden – vielleicht sogar utopisch.

In der Arbeit mit agilen Teams beobachte ich bezogen auf den Umgang mit eben dieser technischen Schuld einige Aspekte bzw. Einflussfaktoren:

• Es gibt ein recht hohes Bewusstsein über die Existenz der Schulden und die Notwendigkeit diese zu reduzieren.
• Wenigen  ist wirklich klar wer die eigentliche Verantwortung zur Reduktion der Schulden trägt – das Team, die IT Führungskräfte, der Produkt Owner, vielleicht sogar der Scrum Master?
•  Es fällt schwer die Arbeit zur Reduktion der technischen Schulden zu planen und eine Strategie zu definieren. Hier sehe ich vor allem den Grund darin, dass technische Aufgaben nicht in den definierten und gelebten agilen Entwicklungsprozess einfließen und damit zum Randthema werden
• Product Owner oder Produktmanager verstehen den Benefit und damit die Notwendigkeit zur Behebung und Reduktion der technischen Schulden nicht und wehren sich daher gegen eine Berücksichtigung dieses Aspekts in der Planung von Release- und Produktroadmaps.
• Die Themen und konkreten Ziele sind nicht dokumentiert und ausgearbeitet, sondern liegen bestenfalls fragmentiert in individuellen Dokumentationen, eher aber in den Köpfen der Beteiligten vor. Im schlechtesten Fall, haben die Treiber bestimmter Themen das Team oder gar das Untenehmen bereits verlassen.

Ohne jedes einzelne der oben genannten Themen komplett berücksichtigen zu können, habe ich mit meinem derzeitgen Team versucht einen pragmatischen Ansatz zu finden, der eine agile (iterative, priorisierte, fokussierte) Reduktion der vorhandenen Schulden ermöglicht und sich nahtlos in den bestehenden Entwicklungsprozess (Kanban) integrieren lässt. Letztendlich übernimmt an dieser Stelle das Team die Aufgaben eines Product Owner für die eigene Sache. Der eigentliche Product Owner durchläuft  für die in seinem Fokus stehenden Produkt- Features ganz ähnliche Arbeitsprozesse.

1. Schritt: Product Owner involvieren und zum Supporter für die Sache machen

Der erste Schritt in einem solchen Prozess ist oft die Sensibilisierung des Produktverantwortlichen für das Thema „Technische Nachhaltigkeit“. Glück für alle Teams, die bereits einen technikaffinen und im agilen Sinne differenzierteren Product Owner haben – hier genügt es nämlich oft die Themen zu nennen und zu helfen die richtige Priorisierung zu finden. Für alle anderen kann sich hier ein echter Show-Stopper verbergen. Ein gebetsmühlenartiger Appell an die Gesamtproduktverantwortung und der damit einhergehenden Fokussierung auch auf das Thema Nachhaltigkeit und Stabilität ist hier sicher oft nicht die richtige Wahl. Das Team sollte hier versuchen an das „WIR“ zu erinnern, dafür also dass er nicht der Auftraggeber für das Team ist, sondern selbst Teil des Teams und in dieser Rolle eher als SME (Subject Matter Expert) und / oder Verwalter und Analyst der Produktanforderungen verschiedener Produkt-Stakeholder und Auftraggeber agiert. Es kann sicher auch hilfreich sein, ihm die Sicherheit zu geben, dass die Generierung von Nutzen und das stetige Wachstum des Produkts oberste Priorität bleiben – nur eben sowohl im kurzfristigen (Performance) als auch im langfristigen (Health) Sinne.

Je nachdem wie stark der Produkt Owner in den Entwicklungsprozess eingebunden ist, kann es durchaus sinnvoll sein, ihm verschiedenen Optionen zur Bearbeitung der technischen Schulden zu skizzieren und ihn in die Diskussion über die besten Ansätze einzubeziehen.

Den meisten Product Ownern wird diese Situation sehr bekannt vorkommen, da sie mit ihren Stakeholdern den ganzen Tag nichts anderes machen: Für Themen werben und begeistern, die agile Herangehensweise rechtfertigen und versuchen jeden Anforderer näher an das Umsetzungsteam zu holen und damit das WIR zu stärken (bzw. zu formen). Diese gemeinsame Herausforderung kann durchaus die geeignete Trägerenergie für das Vorhaben sein.

2. Schritt: Inventarisieren und strukturieren der bekannten Themen

Sobald ein (wenn auch verhaltenes) „OK“ vom Product Owner eingeholt werden konnte geht es darum die technischen Themen und Probleme zu inventarisieren und in eine die individuelle System- und Projektlandschaft abbildende Struktur zu überführen.

Wichtig: In diesem Schritt kommt es nicht so sehr auf die komplette Durchdringung aller Themen und auch nicht auf 100%ige Vollständigkeit an. Vielmehr geht es darum die richtige Struktur zu finden, die wichtigsten Themen zu identifizieren und in diese Struktur zu überführen. Vor allem geht es darum die Themen aus den Köpfen zu holen und ein gemeinsames Bild der vorhandenen technischen Probleme zu entwickeln.

Wir haben dafür die Namen sämtlicher Applikationen  (neue als auch zu betreuende) auf Moderationskarten geschrieben untereinander auf ein  Whiteboard gepappt. Im nächsten Schritt haben wir aus sämtlichen Dokumentationen (alte Spezifikationen, Wikis, JIRA, Code-Dokumentation) bekannte ToDos  zusammengetragen, auf Post-Its übertragen und neben die betroffenene Applikation angebracht.

Dieses Board stand gut sichtbar für mehrere Tage im Teambereich und jedes einzelne Teammitglied hatte die Aufgabe das Board selbständig zu vervollständigen (neue To-Dos, Ändern der Beschreibungen, Umstrukturieren etc.) so dass wir mit einem möglichst vollständigen Portfolio der existierenden technischen Schuld in den nächsten Schritt gehen konnten.

3. Schritt: Agiles priorisieren und schätzen der Arbeitspakete

Nachdem alle Themen aufgenommen, weitgehend verstanden und strukturiert vorliegen, ist es wichtig die einzelnen Tasks untereinander zu priorisieren. Dazu werden Zahlen benötigt: Ertrag und Kosten. Allerdings lassen sich diese Werte bekanntermaßen für IT Projekte bzw. Aufgaben nur sehr schwer oder gar nicht ermitteln. Auch Qualitätsmetriken wie die zyklomatische Komplexität, Testabdeckung oder Abhängigkeitstiefen sind nur bedingt nutzbar, da prinzipiell für die präventive Qualitätssicherung gedacht wir uns aber über bereits vorhandene Schulden unterhalten.

Wir sind einen Schritt zurückgegangen und haben uns gefragt, was wir eigentlich erreichen wollen: Es geht primär gar nicht darum nach außen bestimmte Aufwände und Kosten sichtbar zu machen oder die Umsetzungsdauer genau zu bestimmen. Da wir uns einig darüber waren, dass alle ermittelten und nun durch Post-It-Notes repräsentierte To-Dos wichtig und relevant waren, brauchten wir nur noch geeignete Maßzahlen, um die ToDos in eine sinnvolle Reihenfolge zu bringen. Es geht also um den Vergleich entlang zweier Dimensionen (Nutzen/Kosten), die alle Beteiligten verstehen und die die einzelnen Aufgaben / Themen untereiander vergleichbar machen.

Wir haben eigene Einheiten gebildet, die an die Semantik der realen Dimensionen angelegt waren und uns die Möglichkeiten agiler Schätzmethoden nutzbar machten.

Auf der X-Achse haben wir den Aufwand anhand von Tierbildern (Ameise, Hamster, Hund, Esel, Elefant) abgebildet. Wir haben uns im ersten Schritt gegen die Verwendung von Story-Points geeinigt. Diese nutzen wir, um Feature-Stories zu schätzen. Aufgaben zur Abarbeitung technischer Schuld sind aber oft nur bedingt mit reinen Feature-Stories vergleichbar. Story Points hätten hier vermutlich zu unnötigen Diskussionen und Verständniskonflikten geführt.

Auf der Y Achse zeichneten wir den Nutzen der Arbeitspakete ab. In diesem Fall haben wir uns für eine eigene Währung (Tech-Dollars) entschieden. Wir wollten eine imaginäre Größe haben, die ausdrückt welchen relativen Anteil der Gesamtschuld wir durch die Beseitigung eines Themas tilgen können. Um hier nicht über Kleinstunterschiede diskutieren zu müssen haben wir – angelehnt an die Fibonacci-Reihe, die auch für die Schätzung von Story Points verwendet wird – die Beträge 1, 5, 20, 50 und 200 verwendet.

Um nicht beide Dimensionen in der Diskussion zu vermischen haben wir Aufgabe für Aufgabe zunächst die Position auf der Y-Achse bestimmt und noch offene Fragen über Kontext und Scope der Items geklärt.

Im letzten Schritt haben wir dann für jede einzelne Zeile die Aufwände (in Größe) geschätzt – wobei der Fokus auf den relativen Unterschieden und nicht auf die konkreten Werte jedes einzelnen Items lag. Die Aufwände (vorliegend in Tier-Größen) haben wir – allein für die Berechenbarkeit letztendlich dann wieder auf Zahlen heruntergebrochen (1-3-8-13-20).

Am Ende hatten wir dann eine Matrix mit von jedem Teammitglied verstandenen ToDos zur Abarbeitung der technischen Schuld. Die Positionierung in der Matrix gibt uns im nächsten Schritt wertvolle Hinweise für eine effektive Strategie.

4. Schritt: Analyse der vorliegenden Daten und ableiten der richtigen Strategie

Zunächst haben wir jedes einzelne Item als Story in unser Trackingsystem JIRA überführt und als „Technical-Debt-Item“ markiert. Um eine sinnvolle Ordnung in die über 30 neuen Stories zu bringen und die  richtigen Schlüsse hinsichtlich einer Strategie zu ziehen, haben wir ein Diagramm erstellt, welches den Gesamtaufwand und die Tilgung der Schulden zueinander in Bezug setzt. Daraus ist folgende Übersicht entstanden:

Auf der Y-Achse ist die Gesamtschuld dargestellt. Die Rote Linie zeigt die Größer der Tilgung verteilt über den Aufwand. Die Verteilung der Aufwände auf der X-Achse ergibt sich wiederum aus der Summe der Aufwandspunkte pro Punkt-Kategorie. Dies ist zwar nur eine von vielen möglichen Tilgungsplänen, aber er macht auf jeden Fall eines deutlich: Die Masse der wahrgenommen Schuld lässt sich durch relativ wenig Aufwand beheben. Dieses Wissen führt im Team zu mehr Fokus, da ohne diese Einschätzung nur zwei Aspekte tatsächlich bedacht worden sind: 1. Die große und unklare Menge der ToDos und 2. die größe und Unbezwingbarkeit einzelner ToDos. Jetzt haben wir eine Möglichkeit geschaffen, dass jeder genau die nächsten Schritte im Fokus hat und dabei das Gesamtziel nicht aus den Augen verliert.

Die Visualisierung der Schulden und die Ableitung eines möglichen Tilgungsplans – auch wenn er nur anhand imaginärer, durch das Bauchgefühl bestimmten Wertgrößen erstellt wurde – gibt dem Team die Möglichkeit sich auf die wichtigen Aspekte zu konzentrieren und die Schuld Schritt für Schritt und vor allem zielgerichtet abzutragen. Ein wichtiger Nebeneffekt dabei ist: Die erstellte Übersicht ist auch ein Hilfsmittel zur Kommunikation mit dem Product Owner – ein Mittel, das ihn mit ins Boot holt indem er die Transparenz über Umfang und Relevanz der Themen erhält.

5. Schritt: Integration in den existierenden Entwicklungsprozess – die Schulden abbauen.

Die Inventarisierung und Interpretation der vorhandenen technischen Schulden ist letztendlich zwar ein wichtiger aber nur kleiner Schritt. Den längsten Weg muss das Team zurücklegen um die ermittelten Schulden dann auch tatsächlich abzubauen. Das erfordert Disziplin und oft (bezogen auf den ProductOwner) viel Konsensfähigkeit.

Neben den Visualisierungen für den eigentlichen Feature-Entwicklungsprozess (bei uns Kanban) haben wir eine weites Chart in unserem Team-Raum aufgehängt: Ein Burndown-Chart, welches die Abtragung der ermittelten Gesamtschulden über die Zeit (Einheit Kalenderwochen) darstellt. Mit dem Product Owner haben wir vereinbart, dass die größeren Technical-Debt-Stories ( > 3 Punkte) mit in den Featureplanungsprozess aufgenommen werden und damit den kompletten Workflow durchlaufen.

Die eher kleinen Stories (1-3 Punkte) werden durch die Entwickler spontan und ohne viel Planungs-Overhead weggeschafft. Für derartige Aufgaben steht jedem Entwicklerteam ein 20% Zeitpuffer zur Verfügung.

Da zu jeder Zeit neue Items entdeckt werden und zur ermittelten Gesamtschuld hinzukommen kommen können, verständigte das Team sich darauf diese Themen zunächst im Wiki zu sammeln, wenn sie nicht extrem wichtig sind – in solchen Fällen handelt es sich wohl eh wahrscheinlich um Bugs. Die gesammelten Items werden in einem Quartals-Review überprüft und wenn nötig auf die Restschuld addiert. Die dann entstandenen Tasks durchlaufen dann erneut die hier beschriebenen Schritte. Verbesserungen am Prozess werden wenn nötig in den 2-wöchigen Retrospektiven entschlossen. Mindestens aber zum genannten Quartals-Review werden wir den Prozess genau unter die Lupe nehmen und anpassen.

Fazit

Die Anhäufung technischer Schuld ist normal – auch wenn präventive Maßnahmen gerade durch agile Entwicklungsprozesse und –prinzipien dem Problem heute eine ganze Menge entgegenzusetzen haben. Dennoch lohnt es sich einen Schritt weiter zu gehen und nicht nur über die Schulden zu reden und sich der Unmöglichkeit der Abtragung machtlos gegenüber zu stellen. Genau wie der Product Owner für Features hat hier das Team eine Bring-Schuld. Aufgaben müssen strukturiert, analysiert und vor allem Transparent gemacht werden. Damit sinkt meiner Meinung nach auch die Hürde sich der Schuld dann tatsächlich auch anzunehmen.

Wie geht Ihr denn mit technischer Schuld um? Gibt es Erfahrungen mit anderen Ansätzen? Gern auch Feedback, falls jemand den hier beschriebenen Ansatz probiert hat.