Technische Schulden sind agile Schulden

Moin.

Escape the Feature Factory: Stefan Mintert

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Unter dem Begriff "technische Schulden" verdecken wir heute eine der größten Dummheiten der zeitgenössischen Softwareentwicklung. Die Ursachen sind mehrschichtig. Sie reichen von einfachem Missverstehen des Begriffs über fehlende Verantwortung bis zu Cargo-Cult-Agilität.

In diesem Beitrag fange ich mit dem Missverständnis an: Was sind technische Schulden in der agilen Softwareentwicklung?

Bei meinen Kunden begegnet mir überwiegend das folgende Begriffsverständnis: Technische Schulden sind freiwillig in Kauf genommene Defizite in einer Software, die nach außen nicht oder nur sehr eingeschränkt sichtbar sind. Darunter fallen vor allem Defizite auf Code-Ebene, die man später korrigiert (Schulden zurückzahlen). Entwickler, die gerne Clean Code entwickeln, wollen keine technischen Schulden in ihrem Quellcode. Man nimmt technische Schulden auf, um beispielsweise ein umfangreiches neues Feature in einem Sprint umsetzen zu können, während es bei sauberer Implementierung länger dauern würde. Quick & Dirty eben.

Doch diese Erklärung stimmt nicht mit der ursprünglichen Bedeutung überein. In einem Video von 2009 erklärt Ward Cunningham, der den Begriff geprägt hat, was er ursprünglich bedeutete und wie er zustande kam. Wer seinen Ausführungen zuhört, wird bemerken, dass Cunningham das Wort Schulden in einem Projekt wählte, in dem das Team eine Finanzsoftware entwickelte. Cunningham hat von Schulden gesprochen, um einen Begriff zu verwenden, mit dem der Auftraggeber vertraut ist und weil er glaubte, dass es im Finanzkontext eine gute Metapher sei. Tatsächlich halte ich die Metapher aus heutiger Sicht für völlig unpassend, denn sie trägt inzwischen zu schwerwiegenden Problemen bei. Die Idee, Quellcode zu irgendeinem Zeitpunkt bewusst schlechter zu schreiben, als man kann, hält Cunningham für völlig abwegig. Ich stimme ihm zu. Doch wenn er das nicht meinte, was war denn eigentlich gemeint?

In der agilen Entwicklung schreibt man die Software (so gut man kann!) auf Basis des jeweils aktuellen Verständnisses des Problems und der Aufgabenstellung. Beides kann sich bei einer agilen Vorgehensweise schnell ändern – beispielsweise bereits nach einer Iteration. Vielleicht, weil der Kunde seine Meinung geändert hat. Vielleicht, weil sich der Markt verändert hat. Vielleicht, weil Stakeholder überraschendes Feedback gegeben haben.

Was auch immer der Grund ist, die Software der zurückliegenden Iteration ist eventuell keine optimale Lösung mehr für die neue Situation. Das Delta zwischen dem aktuellen Stand der Software und dem neuen Problemverständnis nannte Cunningham Schulden. Diese Schulden sind aber keineswegs technischer Natur, sondern haben ausschließlich mit dem unvollständigen Problemverständnis zu tun, das bei komplexen Aufgaben in der agilen Entwicklung dazugehört. Es handelt sich auch nicht um Schulden, die man bewusst eingeht. In dem Moment, in dem man programmiert, geht man davon aus, dass man die Software ordentlich entwickelt. Was auch sonst? Andernfalls wären Ideen wie Continuous Delivery völliger Blödsinn. Wer will schon regelmäßige Produktinkremente veröffentlichen, die technische Defizite enthalten? Wer also bewusst schlechte Qualität produziert, handelt bestimmt nicht im agilen Sinn.

Schlimmer noch: Ändert sich das Problemverständnis (z.B. nach einem Sprint), ist es absolut notwendig, dass der Quellcode so "clean" wie möglich ist; also frei von dem, was wir heute technische Schulden nennen. Habe ich nämlich erst einmal eine Software schlechter entwickelt, als ich eigentlich in der Lage bin, muss ich nach einem Sprint nicht nur mit dem neuen Problemverständnis kämpfen, mir stehen meine Altlasten auch noch im Weg.

Auf diese Weise werden technische Schulden zu einer Last für die Agilität, und sie führen - wenn man nicht aufpasst - zum technischen Bankrott; einem Zustand, in dem es günstiger ist, die nächste Iteration from scratch zu entwickeln, als die mit Schulden belastete Software umzubauen. Abriss und Neubau.

Für das, was Cunningham ursprünglich meinte, schlage ich den Begriff Agile Kurskorrektur vor. Dabei denke ich an die Navigation auf Segelbooten. Ohne in die Details gehen zu wollen: Es gibt verschiedene Faktoren, die Einfluss auf den Kurs eines Bootes haben. Wind, Strömung, Deviation des Kompasses können eine Rolle spielen. Durch eine Standortbestimmung kann man etwaige Abweichungen feststellen und eine Kurskorrektur vornehmen. Das halte ich für eine sehr gute Metapher für die agile Entwicklung.

Was kann das Entwicklerteam tun, um technische Schulden zu verhindern?

Diese Frage verdient mehr Raum, als ich in nur einem Blogbeitrag geben kann. Deshalb wird das Thema auch in Zukunft immer wieder mal an dieser Stelle auftauchen. Trotzdem möchte ich kurz auf die Frage eingehen.

Zunächst einmal ist anzumerken, dass dominante Stakeholder oder patriarchalische Product Owner, Team-Leiter oder Ähnliche, die das Team zwingen, schnell neue Features zu entwickeln, neue technische Schulden einzugehen oder vorhandene Altlasten liegenzulassen, eine hervorragende Voraussetzung, um aus technischen Schulden einen technischen Bankrott zu machen. Hier ist das Entwicklerteam in der Verantwortung, denn das Ausmaß der technischen Altlasten kennt niemand besser.

Wer in einem Team arbeitet, das von seinem Boss als agil bezeichnet wird, darf sich meiner Meinung nach darauf berufen, Mitspracherecht zu haben und Verantwortung zu tragen. Eine wichtige Art und Weise, dieses Recht und diese Verantwortung auszuüben, lässt sich in einem Wort zusammenfassen: Nein. Soll heißen: Wenn ich als Entwickler oder Team erkenne, dass jemand von mir/uns Blödsinn verlangt, ist Nein die richtige Antwort.

Und was ist, wenn die Story wirklich zu groß für einen Sprint ist?

Ich habe Teams erlebt, die ohne Scham Tickets der folgenden Art in ihrem Backlog hatten: "Großes Feature, Teil 1", "Großes Feature, Teil 2", "Großes Feature, Teil 3", "Großes Feature, Teil 4", "Großes Feature, Teil 5" und so weiter. Jedes Ticket entsprach dem Arbeitsvolumen eines bestimmten Entwicklers in einem Sprint. Auf meine Frage, aus wie vielen Teilen das Feature denn besteht, bekam ich die Antwort: "Das wissen wir doch vorher nicht, wir arbeiten agil." Es sei erwähnt, dass all diese Tickets durch ein Refinement und ein Planning gegangen sind.

Jeder, der bis hierhin gelesen hat, wird mir zustimmen, dass so eine Vorgehensweise weder mit ordentlicher agiler Arbeitsweise noch mit einem ordentlichen plan-getriebenen Ansatz etwas zu tun hat.

Was hier gefehlt hat, ist wenigstens der Versuch zum fachkundigen Story-Splitting. Ich halte Story-Splitting für eine Kunst, in der sich außerordentlich wenige Teams üben. Sie geben viel zu früh auf und leiern Glaubenssätze der Art "Das geht nicht anders", "Das kann man nicht verkleinern", "Das Feature ist eben so groß" und "Kleiner hat’s keinen Value mehr" herunter.

Mein Rat lautet an dieser Stelle ganz klar: Wenn das Ticket nicht in den Sprint passt,

1. klärt, was "Delivering Value" für Euch bedeutet,
2. übt Story-Splitting und
3. macht keine technischen Schulden.

Abschließend: Eins hat der Begriff "technische Schulden" mit "finanziellen Schulden" gemein: Es ist in den meisten Fällen gut, sie schnell wieder abzubauen.

Im Gegensatz zu finanziellen Schulden zweifle ich aber an, dass technische Schulden einen nennenswerten Nutzen in der agilen Entwicklung haben. Wenn man sie regelmäßig macht, ist es ein Zeichen für ein Defizit an anderer Stelle.

Tschüss. Stefan

(rme)