Diesen Beitrag als Podcast hören — aktiviere den Player, um die Audio-Folge zu laden.

Der Player wird von BuzzSprout (Drittanbieter) geladen und setzt Cookies.

YouTube Podcast

Hier ist ein Diagramm, das ich schon oft gezeigt habe—in Trainings, bei Konferenzvorträgen und anderswo. Es zeigt, wie sich die Marginal Cost (Grenzkosten) von Software-Features im Laufe der Zeit verändern. Und ein Vortrag von Kent Beck hat mich dazu gebracht, wieder darüber nachzudenken.

Grenzkosten eines Features

Das Diagramm unten zeigt die Marginal Cost von Software-Features und wie sie sich im Laufe der Zeit verändern.

Ein leeres Diagramm, die 2 Achsen sind Kosten und Zeit.

Wenn wir ein neues Projekt starten, auf der mythischen grünen Wiese, dann ist das Hinzufügen neuer Features billig. Aber je mehr Monate oder Jahre vergehen, desto teurer wird es. Und irgendwann scheinen wir gegen eine Wand zu fahren: Die Kosten für das Hinzufügen neuer Features steigen so schnell, dass wir kaum noch Software an unsere Nutzer ausliefern.

Aber die „Zeit”-Achse kann nicht wirklich die Zeit sein. Wenn wir die Software gerade nicht ändern, oder wenn sie wirklich „fertig” ist, wird das Hinzufügen neuer Features nicht teurer. Es sieht so aus, als würden Features mit der Zeit teurer, aber tatsächlich werden sie teurer, je mehr Änderungen wir machen. (*)

Im Diagramm von vorher ist ein Verlauf eingezeichnet: Erst steigen die kosten langsam, aber über die Zeit immer schneller.

Was ich hier gezeigt habe, ist der typische Verlauf eines „Wasserfall”- oder „Water-Scrum-Fall”-Projekts (also „Agile Theater”), bei dem wir immer unter Druck stehen zu liefern und die meiste Zeit damit verbringen, Features hinzuzufügen und die entstehenden Probleme irgendwie zu umschiffen.

Aber wir könnten auch einige Änderungen vornehmen, um die Kosten wieder zu senken…

Ich kann eine zweite Kurve zeichnen, die dieses Szenario zeigt: Jedes Mal, wenn die Kosten steigen, machen wir einige Änderungen, um sie wieder zu senken, und nicht, um neue Features hinzuzufügen.

Ein zweiter Verlauf im gleichen Diagramm: Immer, wenn die Kosten etwas steigen, sinken sie danach wieder.

Am Anfang ist das teurer, weil wir keine wertvollen Features liefern, während wir daran arbeiten, die Kosten zu senken. Aber auf lange Sicht verhindert es, dass wir gegen die Wand laufen. Oder zumindest ist die Wand hier viel weiter entfernt.

Futures vs. Features

Hier ist ein weiteres Diagramm: Meine Version einer Zeichnung, die Kent Beck während seines Konferenzvortrags Software Engineering After AI gezeigt hat. Es hat mit dem zu tun, was ich zuvor beschrieben habe, ist aber nicht dasselbe.

Ein leeres Diagramm. Die Y-Achse zeigt "futures", die X-Achse "features".

Auf der y-Achse haben wir „Futures” (also Optionen): Die verschiedenen Dinge, die wir in der Zukunft noch tun können, oder die Optionen, die uns noch bleiben. Die x-Achse zeigt die Features, die unser Produkt hat.

Wir starten mit 0 Features, und an diesem Punkt haben wir viele Optionen. Je mehr Features wir hinzufügen, desto weniger Futures haben wir. Und irgendwann sind all unsere Optionen aufgebraucht und wir können keine neuen Features mehr hinzufügen. Wir sind gegen die metaphorische Wand von vorher gelaufen.

Das Diagramm von vorher mit einem Verlauf: Je mehr Features das Produkt hat, umso weniger werden die Futures, bis sie irgendwann 0 werden.

Aber, genau wie zuvor, können wir ab und zu daran arbeiten, neue Futures hinzuzufügen. Wenn wir das richtig machen, können wir den Punkt, an dem wir die x-Achse treffen, vielleicht verschieben, möglicherweise sogar auf unbestimmte Zeit. Oder, noch besser: Wir schaffen es vielleicht, einen Verlauf zu erreichen, bei dem die Zahl unserer Futures mit der Zeit steigt.

Ein zweiter Verlauf: Immer, wenn die Features steigen und die Futures sinken, steigen danach die Futures wieder, ohne dass neue Features entstehen.

Apropos Zeit: Dieses Diagramm enthält sie nicht! Die Zeit ist implizit: Wenn wir den Linien folgen, ist jeder neue Punkt auf dieser Linie ein späterer Zeitpunkt. Aber wir können uns frei entlang der Achsen bewegen: Wir können auch Features entfernen und dabei unsere Futures vermehren oder verringern.

Was jedes Diagramm dir sagt

Das erste Diagramm—das, das ich in der Vergangenheit verwendet habe—gibt uns einen Hinweis auf Zeit und Aufwand. Wir müssen Änderungen vornehmen, um die Kosten zu senken, und so vergeht Zeit. Außerdem sind Kosten für viele Menschen in der Softwareentwicklung vielleicht enfacher verständlich als “Futures”.

Aber ich hatte auch einen „Heureka”-Moment, als ich Kent Becks Vortrag auf YouTube gesehen habe: Die Optionen, die uns noch bleiben, sind ein Teil des Werts unseres Produkts, und das gilt auch für die Features. Allein die Möglichkeit, sich entscheiden zu können, hat einen Wert. Und wenn wir unsere Optionen vermehren, sinken die Kosten für die zukünftige Entwicklung. In Kent Becks Visualisierung sagen also beide Achsen etwas über den Wert der Software aus! (Wenn du mehr über Optionen und Wert lesen willst, das Buch Commitment kann ich sehr empfehlen)

Beides hängt zusammen: Wenn wir unsere Futures verbessern/Optionen hinzufügen, sinken die Kosten für neue Features. Oder, anders ausgedrückt: Die Kosten von Features zeigen uns ungefähr, wie viele Optionen uns noch bleiben.

Was beide Diagramme nicht sagen, ist, wieviel wir kurzfristig „verlieren”, während wir daran arbeiten Optionen hinzuzufügen und die Margianl Cost von Features zu senken. Während wir daran arbeiten, liefern wir keine Features. Wenn wir annehmen, dass fertiggestellte Features ein ungefähres Maß für geschaffenen Wert sind (**), dann schaffen wir kurzfristig weniger sichtbaren Wert, aber langfristig mehr.

Ich habe schon eine Zeit lang über verschiedene Möglichkeiten nachgedacht, das zu zeigen. Wenn mir je eine gute einfällt, schreibe ich dazu einen Folgebeitrag hier.

Und die Diagramme sagen auch nicht, warum es auf jeden Fall eine gute Idee ist, diese beiden Phasen zu trennen. Wenn du mehr darüber wissen willst, gibt dir Kent Becks Buch Tidy First? einige Ideen, um loszulegen.

Wie kannst du es nutzen?

Ich habe mit Kunden gearbeitet, bei denen es normal war, dass manche Dinge ewig dauerten, und niemand hat das in Frage gestellt. Das Problem dabei ist: Sobald man an diesem Punkt ist, ist nichts mehr billig oder einfach. Weiterzumachen wie gewohnt ist teuer, aber von diesem Berg wieder herunterzuklettern ist teuer und schwierig.

Wenn du noch nicht so weit bist, schau dir diese Diagramme an. Versuche, ehrlich einzuschätzen, wo du stehst. Überlege, was du tun kannst, um die Marginal Cost ein bisschen zu senken. Und dann priorisiere es und fang an zu arbeiten.

Oh, und wenn deine Reaktion ist: „Wir nutzen KI, das ist uns jetzt egal”: Ich bin mir ziemlich sicher, dass es immer noch wichtig ist, an der Vermehrung von Optionen zu arbeiten und die Feature-Kosten niedrig zu halten, oder vielleicht sogar wichtiger denn je. Aber das ist auch ein Thema für ein zukünftiges Blog-Post.

(*) Ich habe erklärt, dass die x-Achse nicht „Zeit” sein kann, aber sie kann auch nicht einfach „Änderungen” sein: Je komplizierter die Software wird, desto seltener werden Änderungen. Also ist es wieder „Zeit”, aber nur solange wir Änderungen machen? Oder so etwas wie „Changetime”? Wenn mir je eine gute Erklärung einfällt, schreibe ich sie hier auf.

Das erste Diagramm, aber die Zeit-Achse ist neu beschriftet: "time" ist durchgestrichen, darunter steht "changes", das ist aber auch durchgestrichen und darunter steht "changetime?"

(**) Das gilt nicht für jedes Feature—manche bringen keinen Wert, manche verringern sogar den Wert des Produkts. Aber im Durchschnitt sollten deine Features wertvoll sein.