Perfekt verstanden, trotzdem ungelöst: Technische Schulden halten IT-Abteilungen im Würgegriff. Um sich nachhaltig zu befreien, muss man über Abteilungsgrenzen gehen. Ein Thema für das Top-Management.
Wir stecken in einer globalen Schuldenkrise und das seit Jahrzehnten. Die Rede ist nicht von Geldschulden, sondern von technischen Schulden. Um viel Geld geht es trotzdem. Was sind diese technischen Schulden? Gemeint ist die bewusste oder unbewusste, suboptimale technische Umsetzung von Software. Dadurch kann kurzfristig die Time-to-Market der Software verkürzt werden. Allerdings muss man dann langfristig mit den Nachteilen der schwachen Umsetzung leben – man zahlt „Zinsen“, z.B. in Form von längerer Lead Time zukünftiger Features. Man geht davon aus, dass zwischen 10% und 40% der Arbeit an Software aufgrund technischer Schulden anfällt (Studien dazu finden sich u.a. hier, hier und hier ). Dieser Schuldendienst macht also einen gewaltigen Teil Ihres IT-Budgets aus.
Dabei ist das Phänomen eigentlich sehr gut verstanden. Methoden, mit technischen Schulden umzugehen, sind seit Jahren gut bekannt. Spätestens seit Robert C. Martin („Uncle Bob“) und Martin Fowler 2009 Design Payoff Line und Technical Debt Quadranten ausdiskutiert haben, war das Thema in der Theorie eigentlich durch.
In der Praxis nützt das aber alles leider nichts. Das liegt nicht an mangelnden Fähigkeiten oder mangelndem Wissen der Akteure. Es liegt daran, dass technische Schulden als primär technisches Problem verstanden werden. Anders als die Bezeichnung vermuten lässt, handelt es sich vielmehr um ein Organisationsproblem. Daher kann es auch nur als ein solches gelöst werden.
Aber schauen wir uns einmal an, wie Organisationen mit ihren technischen Schulden umgehen. Aus meiner Erfahrung kann man hier grob 4 Reifegrade unterscheiden. Ich bezeichne diese nach steigender Reife mit Level 0 bis Level 3.
Level 0: Ignoranz
Auf dem niedrigsten Reifegrad wird kein Gedanke an technische Schulden verschwendet. Die Aufnahme neuer technischer Schulden wird weder erfasst noch kontrolliert, noch deren Abbau ganz zu schweigen. Das Motto: Augen zu und durch!
Software wird einfach entwickelt bis sie nicht mehr wartbar ist und dann weggeworfen und ersetzt. Legacy gibt es nicht, weil niemand die Software übernimmt. Bei Personalwechsel wird sie einfach neu gebaut.
Diesen Reifegrad findet man selten, denn langfristig ist er kaum lebensfähig. Meistens handelt es sich um einzelne Personen, die eine sehr spezielle Software über Jahre im Alleingang entwickeln und pflegen – zum Beispiel Promovierende an Universitäten. Ebenso kommt es vor, dass Produktideen von Nichtspezialisten implementiert werden, um eine Produktidee schnellstmöglich zu validieren – ohne Rücksicht auf technische Qualität.
Ein Team oder gar eine Organisation, die dauerhaft auf diesem Niveau arbeitet, ist nur zu massiven Kosten aufrechtzuerhalten. Es gibt hier langfristig nur zwei Alternativen: Aufsteigen auf Level 1 – oder Aussteigen aus dem Software-Geschäft.
Level 1: Vermeidung
Erst ab diesem Niveau kann man überhaupt von einer echten Behandlung technischer Schulden sprechen. Diese werden in der Regel nicht weiter differenziert und generell negativ betrachtet. Man ist sich darüber im Klaren, dass man immer wieder technische Schulden aufnimmt, sieht die Verantwortung dafür aber bei externen Faktoren und Stakeholdern. Man hört häufig: Dürften wir entwickeln, wie wir wollten, hätten wir keine technischen Schulden!
Die meisten Entwicklungsteams auf diesem Niveau wissen, wo sie technischen Schulden haben und auch, was zu tun ist, um diese abzubauen. Objektiv quantifiziert oder systematisch gerankt sind sie aber in der Regel nicht. Dadurch kann der Schuldenabbau auch nicht systematisch gegenüber neuen Features oder User-Stories priorisiert werden.
Mittel der Wahl ist stattdessen, pauschal Zeitkontingente einzuräumen. Dies kann z.B. eine 80:20 Arbeitsverteilung sein, wobei das Team 80% seiner Zeit an neuen Features arbeitet und 20% für den Schuldenabbau einsetzt, nach dem Motto „Dienstag ist Schuldendienst-Tag“.
Um nicht unbeabsichtigt neue Schulden aufzunehmen, werden Quality Gates eingerichtet. Typischerweise werden hier Peer-Review sowie Mindeststandards hinsichtlich (zyklomatischer) Code-Komplexität und Testabdeckung eingeführt. Im Idealfall wird das ganze weitgehend automatisiert in die CI/CD-Pipeline integriert.
Isoliert betrachtet, könnte ein solches Entwicklungsteam seine technischen Schulden bereits dauerhaft in Schach halten. Leider wäre ein isoliertes Entwicklungsteam aber auch sinnlos. Denn Wert stiftet es erst, wenn es für teamexterne Stakeholder arbeitet. Und an dieser Schnittstelle kommt der Level-1-Ansatz dann an seine Grenzen.
Im Regelfall nämlich hat die externe Partei den Hut auf – sie bestimmt letztlich die Priorität. Die 20% Arbeitszeit für den Schuldenabbau muss dagegen eisern verteidigt werden, da dieser für teamexterne Stakeholder keinen direkten Wert stiftet. Spätestens wenn die nächste Deadline vor der Tür steht, bröckelt die Abwehrfront. Die 20%-Reserve wird für einen Sprint ausgesetzt – natürlich nur ausnahmsweise. Doch damit ist der Präzedenzfall geschaffen. Die Reserve fällt wieder und wieder, bis sie nur noch auf dem Papier existiert.
All das Tooling und der Prozess zur Vermeidung und zum Abbau der technischen Schulden zögert letztlich nur hinaus, was bereits auf Level 0 unausweichlich war: Irgendwann ist das Produkt nicht mehr wartbar und wird ersetzt. Nicht selten geschieht dies im Rahmen eines sehr teuren, teils mehrjährigen Modernisierungsprojektes.
Weil sich an der Grundproblematik durch die Modernisierung nichts ändert, ist dieses Projekt jedoch nur der Startschuss zu einem neuen Zyklus, an dessen Ende dann das nächste, noch teurere Großprojekt wartet.
Level 2: Steuerung
Auch auf diesem Niveau wird die unbeabsichtigte Neuaufnahme technischer Schulden selbstverständlich wie auf Level 1 durch Tooling und Prozesse minimiert.
Zusätzlich werden technische Schulden aber rational und differenziert betrachtet. Sie sind nicht einfach böse und zu vermeiden, sondern werden durchaus als Enabler verstanden, Business-Opportunities zu realisieren. Es gibt einen bewussten und systematischen Prozess, um zu entscheiden, ob der erwartete, durch die Schuldenaufnahme ermöglichte Businesswert die Kosten des zu erwartenden Schuldendienstes rechtfertigt.
Das Management der technischen Schulden ist dazu notwendigerweise auf handwerklich hohem Niveau. Das Ausmaß der Schulden wird regelmäßig quantifiziert, z.B. durch Messung der Technical Debt Ratio (TDR). Es braucht daher keine Sonderbehandlung a la 80:20-Verteilung mehr für die Schuldenbeseitigung. Die entsprechenden Arbeitspakete kommen einfach wie alle anderen Aufgaben ins Backlog, wo sie nach Wert und Aufwand einheitlich priorisiert werden können.
Augenscheinlich liegt jetzt ein sehr hoher Reifegrad vor. Die IT vermeidet achtlos erzeugte Tech Debt wirksam. Technische Schulden, die bewusst aufgenommen wurden, sind quantifiziert.
Wert und Kosten von Aufnahme und Abbau technischer Schulden sind so transparent wie möglich – sowohl für das Entwicklungsteam als auch für die externen Stakeholder.
Es könnte also eine wertorientierte Priorisierung nach bestem Wissen und Gewissen vorgenommen werden. Leider gelingt dies in der Praxis nicht.
Denn auch wenn die Konsequenzen der technischen Schulden nun scheinbar objektiviert sind, ist es ihre Wahrnehmung noch längst nicht. Die externen Stakeholder spüren direkt, wie eine schnelle Lösung Erfolg liefert – nicht selten in Form von Boni oder ähnlicher Incentives. Die dabei aufgenommenen technischen Schulden werden aber nur indirekt gespürt und häufig auch erst viel später, nachdem sie sich über einen längeren Zeitraum akkumuliert haben. Aus Sicht der IT ist es genau umgekehrt: Die Erfolge werden indirekt bemerkt, die technischen Schulden bereiten aber direkt Schmerzen.
Kurz gesagt sind also die technischen Schulden für die Stakeholder weniger problematisch als für die IT und die dadurch eröffneten Möglichkeiten viel attraktiver. Dadurch ergibt sich in beiden Welten letztlich doch wieder eine unterschiedliche Priorisierung. Aufgrund der natürlichen Machtdynamik setzt sich dabei im Regelfall die Business-Seite durch.
Seitens IT stellt sich auf Dauer gelernte Hilflosigkeit ein: Die Situation wird als schlecht, aber unabänderbar akzeptiert. Hält die Situation an, wird das Team irgendwann auf Level 1 zurückgehen. Denn dort erreicht es mit geringerem Aufwand dasselbe (unbefriedigende) Ergebnis.
Wenn dann zwangsläufig irgendwann die technischen Schulden Überhand nehmen, wird es richtig schlimm: Das Entwicklungsteam liefert langsamer, Fehler häufen sich und werden nur mit großer Verzögerung behoben. Es sieht aus, als sei die IT überfordert oder arbeite nicht mehr richtig. Die typischen Management-Antworten auf diese Situation sind dann wenig überraschend: Mehr Druck und mehr Personal! Beides funktioniert aber nicht. Der erhöhte Druck verschärft die Situation nur. Es werden noch mehr technische Schulden aufgebaut, um trotz bereits vorhandener Schulden schnell liefern zu können. Das Personal aufzustocken hilft auch nicht, oder im besten Fall erst mittelfristig und eignet sich nur, um zukünftige Projekte besser stemmen zu können. Ein bereits laufendes, verspätetes Projekt lässt sich mit zusätzlicher Personalstärke dagegen nicht retten. Fred Brooks verglich dies in seinem Klassiker „The Mythical Man Month“ mit dem Versuch, Feuer mit Benzin zu löschen. Fazit: „Adding manpower to a late software project makes it later.“
Ohne böse Absicht entsteht eine ungesunde Dynamik, die man als Teufelskreis der technischen Schulden bezeichnen kann.
Man steckt in der Schuldenfalle. Wie kommt man heraus? Die Antwort: Es gilt, die Grenze zwischen den Abteilungen zu überwinden. So kann man technische Schulden endlich als das verstehen, was sie in Wahrheit sind: ein Problem der Organisation.
Level 3: Vereinigung
Wie in Level 2, werden Tools und Prozesse routiniert eingesetzt, um technische Schulden zu quantifizieren und bewusst einzusetzen. Zusätzlich wird das Thema strategisch auf höchster Managementebene berücksichtigt. Es wird ein gemeinsames Ownership von geschäftlichem wie technischen Erfolg und Misserfolg gepflegt.
Dies gelingt durch Abbau der klassischen Organisationsstruktur, in der die IT-Abteilung von den Geschäftsfunktionen getrennt war. Stattdessen wird die Organisation entlang Ihrer Wertströme ausgerichtet.
Wie sieht das in der Praxis aus?
Anstelle von Teams auf der IT und der Business-Seite werden neuartige Organisationseinheiten gebildet, in denen Skills aus dem Business und der diesem Business dienenden IT vereint werden. Der Zuschnitt dieser Einheiten erfolgt nicht aufgrund historisch gewachsener Gegebenheiten, sondern auf Basis einer Wertstromanalyse auf Ebene der Gesamtorganisation.
Was die Skala der neuen Einheiten angeht, hat man im Wesentlichen zwei Optionen. Entweder werden die klassischen Abteilungen ersetzt, durch neue, kleinere Abteilungen, in denen Business- und IT-Teams gemeinsam arbeiten. Oder man realisiert die maximale Vereinheitlichung und bildet gleich gemischte IT-Business-Teams. Entscheidend ist dabei, dass innerhalb jeder Einheit gemeinsam an den exakt gleichen Zielen gearbeitet wird – mit der gleichen Incentive-Struktur.
Man kann diese Vereinheitlichung gleichberechtigt aus zwei Perspektiven verstehen: Die IT-Teams integrieren das Business. Oder: Die Business-Teams integrieren die IT. Mir gefällt die zweite Sicht besser, denn letztlich macht die Organisation keine IT. Sie macht Business. Und heutzutage macht man das eben mit IT.
Diese Praxis der business-integrierten IT wird häufig als BizDevOps bzw. Business DevOps bezeichnet, alternativ auch als Value Stream Management (VSM), oder – bei Gartner – als Fusion Teams.
Unterm Strich ist es aber nicht mehr und nicht weniger als die konsequente Fortsetzung des DevOps-Gedankens: Ein Produkt oder Service muss End-to-end verantwortet werden. Man kann Verantwortung nicht einfach an einer Abteilungsgrenze abladen.
Hat eine Organisation diesen Zustand erreicht, gehören technische Schulden nicht mehr der IT, sondern der Gesamtorganisation. Die Tools und Prozesse aus Level 2 kriegen auf einmal Grip, weil nun Erfolg und Misserfolg von allen Beteiligten gleichermaßen gespürt wird. Die technischen Schulden bereiten dem Business-Experten ebenso Schmerzen, wie der Business-Erfolg dem IT-Experten Freude bereitet.
Wie kommt man aufs höchste Level?
Die Mauer zwischen IT und dem Business zu überwinden erfordert oft nicht weniger als ein neues Selbstverständnis beider Seiten.
Da es sich um ein komplexes Unterfangen handelt, gibt es kein Kochrezept für die Umsetzung. Stattdessen empfehlen sich begrenzte Experimente. Kandidaten für so ein Experiment sind Gruppen von Business und IT-Teams, die stark voneinander abhängen, als Gruppe allerdings weitestgehend autonom im Organisationskontext agieren können.
Hier ist echtes Leadership gefragt, denn die Erfahrung zeigt, dass dies nicht alleine Bottom-Up funktioniert. Erfolgreiche derartige Initiativen brauchen Sponsoren mit Macht über Business und IT.
Diese Sponsoren müssen sehr aktiv sein und mit breiten Schultern über entsprechende Experimente wachen, um einen Rückfall in alte Muster zu vermeiden.
Eine Transformation auf dieser Ebene ist kein Spaziergang, sondern eher ein Marathon auf unbekannter Strecke. Empfehlenswerte Ansätze dazu sind die aktuell populären Flight Levels nach Klaus Leopold oder Kotters duales Betriebssystem.
Das Endergebnis ist die Mühe und Ausdauer allemal Wert. Denn wie wir gesehen haben, sind die klassischen Abteilungsgrenzen nicht nur fiktiv und ohne Mehrwert. Sie verstärken auch eines der größten IT-Probleme unserer Zeit und sind letztlich der Nährboden für die technische Schuldenkrise.