Übermäßige technische Schulden sind fast immer ein Versäumnis des technischen Managements

Ein erfahrenes und eingespieltes Team mit einem hohen Maß an Vertrauen und gegenseitigem Respekt von Entwicklung und Produktmanagement / Product Owner sowie der notwendigen Seniorität und Erfahrung kann dies sicher leisten. Viele - wenn nicht sogar die meisten - Teams sind aber nicht so weit.

Es fehlt an Seniorität und Erfahrung. Einzelne Entwickler haben das Gefühl, keine Refactorings durchführen zu dürfen. Alles ist so dringend, dass Refactoring-Themen einfach immer wieder hinten runterfallen. Es werden die falschen Stellen bearbeitet. Es werden Refactorings durchgeführt, die die Codequalität nicht verbessern. Die technischen Schulden sind einfach zu groß für ein einzelnes Team. Die Komplexität der Aufgabe erschlägt.

Die Liste, warum ein Team nicht selbst in der Lage sein kann, technische Schulden abzubauen, ließe sich noch beliebig verlängern.

In solchen Situationen nur auf die Eigenverantwortung zu setzen ist fatal.

Hier muss sich das technische Management seiner Verantwortung bewusst sein. Es muss den Abbau der Altlasten selbst vorantreiben und den Themen den notwendigen Raum geben.

Was bedeutet das genau?

• Eine klare technische Richtung vorgeben. Nur wenn das Ziel bekannt ist, kann man in der täglichen Arbeit darauf hinwirken. Das heißt, es muss jedem klar sein, wo sich das System hin entwickeln soll, wie gute Lösungen für wiederkehrende Probleme aussehen und wo im System was umgesetzt wird. Je klarer die technische Richtung, desto besser kann sich ein Team daran orientieren. Dabei kann die technische Richtung sowohl aus dem Team selbst kommen, als auch von außen, z.B. durch das technische Management oder einen Architekten vorgegeben sein.

• Teams ermutigen und unterstützen. Dringend ist, was zwei Beine hat und in der Tür steht. Gerade wenn ein Team einen dominanten Product Owner mit einer wirklich überzeugenden Vision hat, kann es passieren, dass es dem Druck nachgibt und - statt ein Gleichgewicht zwischen Weiterentwicklung und Pflege des Code zu finden - nur noch so schnell wie möglich neue Features umsetzt. Hier ist es wichtig, das Team dabei zu unterstützen eine Stimme zu finden. Dazu muss sich das gesamte Team (inkl. Produktmanagement) des Problems der technischen Schulden bewusst werden. Als nächstes können dann weitere Schritte abgeleitet und mit in die Umsetzung genommen werden. Damit das funktioniert, braucht ein Team in dieser Situation Unterstützung. Das kann ein Scrum Master sein, erfahrene Entwickler aus anderen Teams oder auch das technische Management selbst.

• Mentoring / Coaching jüngerer Mitarbeiter. Um technische Schulden abzubauen braucht es, gerade bei Systemen die über viele Jahre gewachsen sind, Erfahrung, Geduld und eine Prise Mut. Zum einen ist nicht unbedingt jedes Refactoring per se eine Verbesserung, zum anderen muss man das System gut genug kennen, um alle (oder zumindest die meisten) Abhängigkeiten abschätzen zu können. Zu guter Letzt ist Refactoring eine Tätigkeit, die gewisse Fähigkeiten erfordert, die man einfach einüben muss. Pair Programming, Code Reviews oder einfach nur das gemeinsame Durchdenken eines Refactorings helfen unerfahrenen Kollegen dabei, sich in das System einzufinden und auch hier schneller einen Beitrag leisten zu können.

• Delegieren lernen. In vielen Fällen hängen komplexe Refactorings an einzelnen, erfahrenen Mitarbeitern. Diese werden dann schnell zum Engpass des gesamten Unternehmens. Es ist also entscheidend auch komplexere Themen zu delegieren. Das ist einfacher gesagt als getan. Gerade wenn sich jemand sehr gut in einem System auskennt, ist es sehr schwer Verantwortung abzugeben. Insbesondere, wenn der Aufwand der Übergabe am Anfang größer ist, als es schnell selbst zu erledigen. Wichtig ist, sich bewusst zu sein, dass es nicht darum geht die Aufgabe schnell zu erledigen. Es geht vielmehr darum, unerfahrenere Entwickler darin auszubilden komplexere Refactorings in Zukunft selbst und eigenverantwortlich durchführen zu können.

• Wenn die Altlasten zu groß sind, kann es ggf. sinnvoll sein, technische Produktmanager zu benennen, die den Themen die notwendig Dringlichkeit geben und sie - analog zu den fachlichen Themen - gegenüber dem Management vertreten. Das schafft nicht nur einen besseren Überblick über die Themen, sondern ermöglicht es auch, sie sinnvoll zu priorisieren und so die Refactorings und Umbauten mit dem größten Nutzen zuerst anzugehen.

Gerade in langlebigen Systemen sind technische Schulden und Altlasten allgegenwärtig. Die Kunst ist es, nicht nur technische Schulden kontinuierlich abzubauen und dabei das Gleichgewicht mit der Weiterentwicklung zu halten, sondern auch immer die momentan relevantesten Schulden zu erkennen und an genau diesen zu arbeiten. Das ist natürlich alles andere als einfach. Aber wie sieht die Alternative aus?