Technische Schulden sind der Fluch eines jeden modernen (und nicht so modernen) IT-Produkts. Wie bei einem faulen Kredit hat man Mühe, die Zinsen zurückzuzahlen, geschweige denn die Schulden zu tilgen. 

Technical Debt nimmt viele heimtückische Formen an, wie z. B. fehlende Testautomatisierung, veraltete Dokumentation, ineffizienter Code, veraltete Architektur und Sicherheitsschwachstellen aus alten Technologien. Und es interessiert die Stakeholder meistens erst dann, wenn sie beginnen die schlechte Leistung oder die lange Entwicklungsdauer und damit steigende Kosten neuer Funktionen zu hinterfragen.  Oft erreicht man den Punkt, an dem die Kosten für den Austausch des systemkritischen Produkts geringer sind als das Risiko, weitere Änderungen vorzunehmen. Muss das so sein?

Ist das auch für Agile Coaches relevant? Aus meiner Sicht absolut, da wir alle Rahmenbedingungen berücksichtigen müssen, um einen effektiven Agile Release Train oder auch ein einzelnes Team zu coachen. Oft müssen erst die technischen Hausaufgaben erledigt und die technischen Rahmenbedingungen geschaffen werden, bevor man tatsächlich iterativ inkrementell entwickeln kann. Im schlimmsten Fall beschleunigt man sonst sogar den Aufbau von technical Debt. 

Technischer Schuld vorbeugen

Wenn wir heute in klassischen Organisationen damit beginnen in kurzen Zyklen zu arbeiten — sei es ein einzelnes Scrum – oder mehrere agile Teams, die mit SAFe® arbeiten —so wird eine Kernkompetenz des Scaled Agile Framework oftmals unterschätzt: „Team and Technical Agility“.

Bereits in Scrum spricht man am Ende eines Sprints von einem „Potentially Releasable Increment“. Das heißt, dass die Teams nach 2-4 Wochen ein Stück Software bereitstellen, das so gute Qualität hat, dass man es potentiell releasen kann ohne dafür noch einen „Hardening“-Sprint (Antipattern) oder Release-Phasen von 6 Wochen zu benötigen.

In SAFe existiert hierfür die System Demo, die alle zwei Wochen eine über alle Teams integrierte Lösung bereitstellt. Das erhöht natürlich die Qualitätsanforderungen nochmals. Der Spruch „you can’t scale crappy code“ trifft es ziemlich genau.

Nur wenn wir dem Konzept von Built-In-Quality rigide folgen, können wir in so einer Geschwindigkeit liefern, sonst erhöhen sich die technischen Schulden noch viel rascher als in einem klassischen Vorgehen.

Konkret benötigt jedes agile Team heutzutage folgende Skills, für die das Scaled Agile Framework auch jeweils aussagekräftige  tiefgehende Artikel zur Verfügung stellt:

• Agile Architecture, die Software-Architektur muss zulassen, dass Systeme über die Zeit wachsen und sich verändern
• Agile Testing, ein test-first Ansatz, der weit darüber hinaus geht, nur über „Unit Tests“ zu sprechen.
• Behaviour-Driven Development (BDD): Ein weiterer Aspekt des agilen Testens, bei dem es darum geht System-Verhalten zu beschreiben und automatisiert zu testen.
• Test-Driven Development: Test schreiben, alle Tests laufen lassen, danach nur so viel Code schreiben, dass der Test grün wird und erst danach Refactoring anwenden, wenn benötigt.
• Refactoring: Der Quellcode und das System werden kontinuierlich auf Basis der neuen Anforderungen angepasst und erweitert. Auch dies erfordert, dass das System diese Veränderung zulässt und wir eine ausreichende Testabdeckung vorliegen haben, um sicherzustellen, dass man nichts durch dieses Refactoring zerstört hat.
• Spikes: Oft versucht man eine Story fertig zu machen, auch wenn noch zu viele technische Risiken dahinterliegen. SAFe® bietet hierfür das Konzept der „Enabler“, die künftige Story Umsetzung ermöglichen („enablen“) sollen. Ein Spike ist eine konkrete Ausformulierung eines Enablers um vorab wichtige Experimenten durchzuführen, sodass das Risiko mitigiert wird.

All diese Kompetenzen werden heute von „Software Engineers“ erwartet, die mehr sind als nur „Coder“. Wenn wir agil arbeiten und zum Beispiel ein Stream Aligned Team aufsetzen möchten, dann benötigen wir hochqualifizierte Engineers, die genau diese Praktiken verstehen und umsetzen. 

Von Agile Coaches und Scrum Mastern erwarten wir heutzutage umfangreiches Wissen über diese Praktiken, sonst fehlt ein wesentlicher Teil des Coachings.

Nur so vermeiden wir technische Schuld und vor allem auch den raschen Aufbau technischer Schuld über agile Vorgehensweisen.

Strategie für bestehende Technische Schuld 

Gratulation, Sie haben technische Schulden? Ab jetzt haben Sie die Wahl zwischen einer teuren Lösung um neue Funktionalität hinzuzufügen oder einer günstigen „Augen zu und durch“ Variante. Zweite Lösung wird leider oft präferiert und führt nur zu noch mehr technischen Schulden.

Was sind die meisten Gründe für technische Schulden?

In einem Artikel von DZone wird eine Studie des Software Engineering Institute erwähnt, die 1319 Entwickler gefragt hat, was aus Ihrer Sicht die Gründe dafür sind:

Deckt sich diese Beobachtung mit ihrer Wahrnehmung? Was sind bei Ihnen die Gründe? Schlecht qualifizierte Entwickler, die von sich aus den Shortcut über der guten Lösung wählen? Markt-Druck? Druck vom Fachbereich, der mehr Features will und kein Verständnis für refactoring hat? Falsche Architektur?

Erster Schritt: Technical Debt transparent und quantifizierbar machen

Ein Technical Debt Backlog kann dabei helfen konkret quantifizierbar und messbar zu machen, wie viel Aufwand bereits in die Beseitigung von technischen Schulden geht.

Capacity Allocation

Planen Sie in jedem Fall eine gewisse Kapazität Ihres Backlogs dafür ein, „Enabler“ Stories ohne Diskussion machen zu können.

So vermeiden Sie unnötige Diskussionen mit dem Fachbereich oder den Business Stakeholdern warum gewisse technische Dinge getan werden müssen. 

Wenn die benötigte Kapazität zu hoch wird kann man dann auch darüber diskutieren, warum das geschieht. Also auch hier gilt es, transparent zu sein und ständig zu beobachten ob zum Beispiel Bugs und die Behebung von technischen Schulden verhältnismäßig die Überhand übernimmt gegenüber Neuentwicklungen.

Just do your Job as an Engineer

Eine sehr persönliche Meinung von mir als Agile Coach und ehemaliger Software Engineer ist, dass es in der Verantwortung jedes Entwicklers und Team-Mitglieds liegt gute Qualität zu liefern und nicht zu viele Kompromisse einzugehen. Jeder Entwickler ist der Experte für seinen Job. Das Team an sich benötigt ein gut abgestimmtes Qualitäts-Verständnis und ist in der Verantwortung dies auch durchzusetzen. Leider lassen die Teams oft zu schnell zu, dass man Kompromisse und Shortcuts in der Qualität eingeht. 

Conclusio

Technical Agility ist ein Kernkonzept in SAFe. Mit einem Test-First Mindset, verhindert SAFe den Aufbau von mehr Technical Debt und unterstützt proaktiv den Abbau von Technical Debt.

Gleichzeitig fördert SAFe über die Kombination von IT- und den für Business verantwortlichen Rollen auf allen Ebenen den ständigen Dialog auf Augenhöhe. IT ist nicht der “Lieferant” für Business. Wir sitzen alle im gleichen Boot. Stellen wir sicher, dass es gut schwimmt. 😉