BLOG
Technische Schulden meistern – SAFe®-Prinzipien einfach anwenden
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.
Bei TechTalk sehen wir Software als Werkzeug, das in den Händen von Menschen und Teams das Potenzial hat, wahre Veränderungen zu bewirken.
Wir bringen nicht nur mehr als drei Jahrzehnte praktische Erfahrung in der Softwareentwicklung mit, sondern zeichnen uns auch durch unsere tiefe Verwurzelung in agilen Methoden und unsere ganzheitliche Projektumsetzung aus. Dabei verstehen wir uns nicht nur als Berater, sondern als Partner auf Augenhöhe für unsere Kund:innen, mit denen wir echte Wirkung in der Zusammenarbeit erzielen. Auf dieser Grundlage haben wir unsere Tipps zusammengestellt.
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:
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.
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.
Unserer Erfahrung nach und auch belegt durch wissenschaftliche Studien ist eines der Hauptprobleme die „Wahl der Architektur“. Sofware Systeme entwickeln sich und die Lösung für das ursprüngliche Problemverständnis muss nicht mehr die gleiche Lösung für das aktuelle Problem sein. Daher ist es unerlässlich, dass diese Lücke zwischen aktueller Entwicklung und Architektur möglichst klein bleibt und aktiv gemanaged wird.
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?
Erfahren Sie, wie Sie agile Arbeitsweisen in Ihrem Unternehmen erfolgreich einführen und begleiten. Das Training richtet sich an Führungskräfte und Verantwortliche, die den Wandel praktisch gestalten und ihr Team fit für SAFe® machen wollen – inklusive Vorbereitung auf die offizielle Zertifizierung.
Ein Technical Debt Backlog kann dabei helfen konkret quantifizierbar und messbar zu machen, wie viel Aufwand bereits in die Beseitigung von technischen Schulden geht.
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.
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.
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.
Erfahren Sie, wie Sie agile Arbeitsweisen in Ihrem Unternehmen erfolgreich einführen und begleiten. Das Training richtet sich an Führungskräfte und Verantwortliche, die den Wandel praktisch gestalten und ihr Team fit für SAFe® machen wollen – inklusive Vorbereitung auf die offizielle Zertifizierung.
„*“ zeigt erforderliche Felder an
Building Software & Teams that matter.
Trainings mit echter Wirkung.
TechTalk GmbH
Leonard-Bernstein-Straße 10, 1220 Wien