Wert mehr als Komplexität

Wie misst ein agiles Softwareteam - gar eines, das Scrum einsetzt - eigentlich seinen Fortschritt? In Erinnerung sind mir da noch burn-down und burn-up Charts, in denen Story Points aufgetragen werden. Ist das aber wirklich hilfreich und zeitgemäß?

Interessanterweise kommen Story Points im Scrum Guide ja nicht mehr vor. Der erwähnt zwar noch burn-down Diagramme für den "forecast" - auch der Begriff "estimation" ist aus dem Guide gestrichen -, doch was da heruntergebrannt wird, ist nicht benannt. Eine "velocity" findet ebenfalls keine Erwähnung mehr.

Damit hängen zumindest Scrum-Teams ein bisschen in der Luft, oder? Die Quelle der Wahrheit gibt keine Guidance.

Natürlich hält sich die Praxis der Story Point Schätzung hartnäckig und auch die Velocity steht in den meisten Scrum-Teams, die ich kenne, ganz oben auf der Beobachtungsliste. Konstante Geschwindigkeit ist das Ideal - auch wenn man inzwischen mit wissendem Blick betont, dass Geschwindigkeitsunterschiede normal seien.

Komplexität kaschiert Aufwand

Die Velocity ist die Zahl der Story Points, die pro Sprint umgesetzt wurden. Und Story Points stehen für eine Einschätzung der Komplexität einer umzusetzenden Anforderung, wie sie von den Entwickler eingeschätzt wird.

Eine vom Product Owner präsentierte Anforderungen wird diskutiert und dann wird in einem mehr oder weniger komplizierten Schätzverfahren eine Komplexität dafür bestimmt. Die Komplexität ist ganz bewusst keine Schätzung eines Umsetzungsaufwands oder einer Umsetzungsdauer. Agile Entwickler lassen sich zu einer Zeitschätzung nicht mehr herab; dass die daneben liegen muss, weiß doch jeder. Auf solche ein Spiel lassen sie sich nicht mehr ein.😤

Sie versprechen nur noch, dass sie eine bestimmte Menge an Anforderungsinkrementen mit einer bestimmten Komplexitätssumme in einer festgelegten Zeit umsetzen.😉

Auch wenn Story Points keine genaue Dauer für eine Umsetzung angeben, ist allen Beteiligten natürlich klar, dass die mit der Dauer positiv korrelieren. Mehr Story Points für eine Anforderung bedeuten längere Umsetzungsdauer. Ob 8 Story Points im Vergleich zu 5 Story Points nun genau 60% länger dauern oder nur 30% oder 100% oder mal so und mal so, das würde kein agiler Entwickler definieren wollen. Eine Komplexität von 8 ist eben nur höher als eine von 5. Und eine von 13 ist mehr höher im Vergleich zu 8 als 8 im Vergleich zu 5. Ich denke, darüber gibt es keinen Zweifel.

Alles andere würde auch keinen Sinn ergeben. Denn der PO will ja eine Idee bekommen, ob die Anforderung A in der Umsetzung wohl länger dauern wird als die Anforderung B. Denn wenn das so ist, könnte das für ihn ein Signal sein, A vorzuziehen - oder A zu verschieben.

Eine Komplexitätsschätzung ist also eine verbrämte Aufwandsschätzung. Und ein Diagramm, das Komplexitätswerte darstellt, stellt also Aufwände dar.

Was sagt dann ein Velocity Chart aus? Dass man in einer Periode eine Komplexität bewältigt, gar überwältigt und niedergerungen hat.💪Entwickler sind eben Helden! Jeden Tag schauen sie dem Komplexitätsmonster unerschüttert ins Auge!👹

Das klingt irgendwie gut - nur was bedeutet das wirklich? Hat das einen Wert? Wenn ja, für wen?

Wie gesagt: Sich die Komplexitätsfrage zu stellen, ist eine gute Sache. Um sie beantworten zu können, muss man mit dem Product Owner ins Gespräch kommen. Im Gespräch erkundet man die Anforderungen. Alle werden sich darüber klarer. Wo man große Komplexität erkennt, mit der große Unklarheit und Unverlässlichkeit in der Umsetzung einhergehen, kann man sich um Reduktion schon im Vorfeld bemühen.

Das ist alles super! Nur warum diese Werte tracken?

It's the focus, stupid!

Für mich ist nur eine Motivation plausibel: Indem man Story Points nicht nur schätzt, sondern auch verspricht, die niederzuringen in einem Zeitraum, setzt man sich ein Ziel. Dieses Ziel soll fokussieren. Dieses Ziel soll einen sense of urgency induzieren. Wer versucht ist, einer Ablenkung nachzugeben im Verlauf eines Sprints, der wird durch das Commitment auf eine zu erreichende Velocity zurück ins Glied geholt. Und je größer die zu bewältigenden Story Points, desto dringlicher ist der Fokus! Hohe Komplexität kommt mit großer Unklarheit; da zählt jede Minute im Sprint.

Am Ende einer Periode kann man dann schauen, inwiefern der Fokus geglückt ist. Wurde die angepeilte Gesamtkomplexität bewältigt? Wenn nein, wo hat es gehakt? Oder war sogar Luft nach oben?

Auf eine solche Retrospektive finde ich wunderbar. Man nimmt sich etwas vor und schaut am Ende, ob man es geschafft hat. Indem man sich etwas vornimmt, sich ein Ziel setzt, wird die Fokussierung befördert. Im Zweifelsfall weiß man immer, wo Aufmerksamkeit investiert werden sollte.

Warum aber die Story Points zur Fokussierung benutzen? Reicht es nicht, die auch aus den Story Points abgeleiteten Anforderungen zu tracken? Am Anfang einer Periode stehen 10 Anforderungen zur Diskussion. Die werden in der Komplexität geschätzt. Dadurch werden daraus 12 Anforderungen. Von diesen 12 Anforderungen nimmt man sich für die Periode 7 vor. Fertig.

Nachdem man sich für diese 7, das Sprint Backlog, entschieden hat, ist es doch egal, warum man das getan hat. Entweder man schafft alle 7 oder nicht. Am Ende der Periode kann man dann auf sein digitales Team-Kerbholz 7 oder auch nur 5 oder gar 8 Kerben machen und diese Anzahl einer Summe hinzufügen für eine kummulierende Darstellung.

Wenn man den Plan unter- oder übererfüllt, dann kann man gern darüber reflektieren und dabei auch die Komplexitätsschätzungen heranziehen. "Bei welcher Anforderung haben wir die Komplexität wieder zu niedrig eingeschätzt?" ist dabei wahrscheinlich die häufigste Frage.

Ein Tracking der Komplexitätssumme jedoch braucht es dafür nicht. Das ist nicht nur nicht hilfreich, das ist sogar missweisend.

Fortschritt nur mit Wert

Softwareentwicklung soll kundenorientiert sein. Wert soll für den Kunden geschaffen werden. Wo ist der in einer Komplexitätsschätzung zu finden? Welche Wertentwicklung hat eine Software, wenn die Velocity stets ähnlich ist?

Korreliert Wert mit Komplexität positiv? Höchstens schwach, würde ich sagen. So schwach, dass ein Diagramm, das die Entwicklung heldenhafter Komplexitätsbewältigung zeigt, nicht mit einer kundenorientierten Wertschaffung verwechselt werden darf.

Wert ≠ Komplexität

Was soll also ein Kunde davon halten, wenn ein Team in dieser Periode mehr und in der nächsten weniger und dann wieder etwas mehr Komplexität bewältigt?

Nichts!

Komplexität interessiert den Kunden nicht. Oder sie interessiert ihn nur indirekt, wenn er eine Antwort auf die Frage will: "Wann bekomme ich das Features, das mir sehr wertvoll erscheint?"

Entwickler geben darauf mit ihren Komplexitätsangaben keine Antwort, selbst wenn die mit Aufwand positiv korrelieren. Für eine so konkrete Prognose braucht es andere Mittel. Ich empfehle: Vorhersagen basierend auf historischen Daten. Aber das ist ein anderes Thema.

Jeder Kunde kann unmittelbar den Fortschritt der Zeit spüren. Die kostet ihn nämlich gewöhnlich Geld auf die eine oder andere Weise, solange die Software noch zu wünschen übrig lässt:

• Entweder der Kunde gibt für die Softwareentwicklung Geld aus.
• Und/oder der Kunde kann einen Wert der Software noch nicht realisieren, weil ihre Feature fehlen.

Wert entsteht im Auge des Kunden

Nur der Kunde kann einer Software Wert beimessen. Ihr Produzent - Product Owner und Entwickler - können nur vermuten, was nach Auslieferung für den Kunden werthaltig sein könnte. Das ist sogar der Hauptantrieb hinter der Agilität! Dem Kunden soll möglichst zügig nach Äußerung einer Idee für eine werthaltige Veränderung eine Umsetzung präsentiert werden, um zu überprüfen, ob die Hypothese des Kunden - denn mehr ist es nicht - stimmig ist.

Das Entwicklungsteam vermutet, der Kunde vermutet ebenfalls. Softwareentwicklung ist eine komplexe Angelegenheit. Geradlinig ist der Weg zu einem werthaltigen Produkt nicht.

Und was ist Wert für den Kunden? Ich glaube, das lässt sich auf einen Begriff zusammendampfen:

Nur Gewinnzuwachs stellt für den Kunden Wert dar.

Wenn der Kunde heute 30.000€ pro Monat Gewinn ohne eine Software macht, dann möchte er morgen mit einer Software z.B. 15% mehr Gewinn machen, also 34.500€. Ob die Software hilft, den Umsatz zu erhöhen oder die Kosten zu reduzieren, ist dabei egal.

Hier ein Beispiel für eine solche Situation für eine Periode von 3 Jahren:

Ausgehend von einer solchen Vorstellung von Gewinnzuwachs durch eine Software, ist der Kunde bereit, erstens Geld für die Software auszugeben und zweitens auf die Softwarelieferung zu warten.

Er könnte Beispielsweise bereit sein, 270.000€ für eine Software auszugeben. Diesen Preis würde ein Gewinnzuwachs nach 60 Monaten (5 Jahren) wieder einspielen. Danach würde der Gewinn wirklich realisiert.

Ob das eine zu lange Wartezeit ist, sei dahingestellt. Es geht mir um die prinzipielle Rechnung.

Wenn die Softwareentwicklung im Wasserfall über 18 Monate stattfinden würde, sähe die Gewinnentwicklung so aus ab Auftragsvergabe:

Zuerst hat der Kunde 18 Monate lang Kosten von 15.000€ pro Monat zu tragen; 50% seines monatlichen Gewinns investiert er für den späteren Gewinnzuwachs.

Nach Auslieferung der Software fallen die Entwicklungskosten weg und jeden Monat liegt der Gewinn um 15% höher als ohne Software. Der Kunde hat sein Ziel erreicht! (Dass es nie so einfach ist, ist mir klar. Prinzipiell sollte es aber so funktionieren.)

Alle umgesetzten Anforderungen zusammen haben für den Kunden einen Wert von 4.500€ pro Monat.

Dieser Wert ist für den Kunden interessant. Nichts sonst. Wer ihm diesen Wert schneller liefert, ist für ihn attraktiver als Entwicklungspartner.

Natürlich hat der Kunde die Befürchtung, dass sich die Lieferung solch wertvoller Software verzögern könnte. Er will deshalb über den Fortschritt der Entwicklung informiert werden. Wie kann das geschehen? Was kann ihm ein Softwareteam als Metrik nennen, die für den Kunden relevant ist?

Solange der Kunde nichts in die Hand bekommt, solange führ ihn kein Wert entsteht, sind alle Metriken abstrakt. Er lässt sich notgedrungen auf sie ein. "Wir haben schon 25% der Anforderungen umgesetzt!" klingt gut - ist aber auch untauglich, solange der Kunde davon nichts hat. "Wir sind schon mit der Anbindung des Buchhaltungssystems fertig!" ist auch nicht hilfreich, solange der Kunde davon nichts hat. "Wir haben schon Meilenstein 1 mit den Anforderungen A und B und C erreicht!" fällt letztlich auch in die Kategorie "heiße Luft", solange der Kunde nichts davon hat.

Mit "davon haben" meine ich, dass die Software bei ihm im Einsatz ist und schon Gewinnzuwachs produziert. Nur dann ist für den Kunden Wert hergestellt.

Das hat die Agilität erkannt und bemüht sich genau darum:

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Das Ideal agiler Softwareentwicklung sieht dann so aus:

Nicht erst nach der geplanten Projektlaufzeit von 18 Monaten wird etwas wertvolles geliefert, sondern ständig. Im Beispiel gibt es jeden Monat ein Release, das die Software ein bisschen werthaltiger macht.

• Ab dem 3. Monat kann der Kunde schon kleine und dann wachsende Gewinnzuwächse realisieren.
• Am Ende ist der erwünschte Gewinnzuwachs sogar übertroffen. Das ist möglich, weil der Kunde durch frühzeitigen Einsatz Erkenntnisse gewinnen konnte, wie die Software für ihn noch wertvoller gestaltet werden könnte.

Der Wertzuwachs ist natürlich nicht linear. Am Anfang fehlt es noch an Voraussetzungen für große "Wertsprünge", dann können die gemacht werden - und nach etwas mehr als der halben Projektlaufzeit sind ca. 80% des späteren Gesamtwertes erreicht.

Das ist, was den Kunden interessiert. Er will sehen, wie sich seine Ausgaben in Wert verwandeln. Wie viel mehr Gewinn lässt ihn die Software schon realisieren? Wenn die Kurve "Wert kummuliert" kontinuierlich steigt, wenn sie sogar steil steigt, dann ist der Kunde glücklich.

Fortschritt gibt es für den Kunden nur, wenn Software für ihn werthaltiger geworden ist.

Flacht die Kurve ab oder wächst der Wert gar nicht oder - auch das ist möglich - sinkt er sogar, dann ist der Kunde unglücklich.

Wenn die Agilität also kundenorientiert sein will, dann sollte sie sich doch daran messen, ob sie Wert für den Kunden produziert. Oder? Alles andere ist irrelevant.

Und wenn der Product Owner einen Anlass für das Gespräch mit Entwicklern sucht, dann kann er die Wertentwicklung heranziehen. Gemeinsam lässt sich darüber reflektieren, warum Wert gesunken ist - das wäre eine Regression - oder warum die Kurve nur so schwach steigt. Warum dauert es so lange, bis wieder etwas an den Kunden geliefert wird, das der als wertvoll erachtet?

Fazit

Scrum ist von den Ideen der Lean Production inspiriert. Und die ist darauf aus, flüssige, konfliktfreie Produktion herzustellen. Was ist es also, das in einem agilen oder gar Scrum-Prozess hergestellt werden soll?

Das kann nur Wert sein. Etwas anderes kann "valuable software" nicht meinen. Und Wert entsteht nur und ausschließlich im Auge des Kunden. Konkret ist das ein Zuwachs an Gewinn auf die eine oder andere Weise. Je früher er den realisiert, desto besser.

Agile Softwareentwicklung, die nicht den Fokus auf die Entwicklung von Wert legt und deshalb die Wertproduktion protokolliert, geht am Kern der Agilität vorbei. Wert ist wichtiger als Komplexität. Deshalb im Stile des agilen Manifests:

Wert mehr als Komplexität

Komplexitätseinschätzung hat ihren Platz in der Softwareentwicklung; mehr verdient es jedoch der Wert, dass sie sich daran ausrichtet.

Dass für die Lieferung von Wert Komplexität bewältigt werden muss, ist unbenommen. Einen Orden verdient jedoch nicht der, der Komplexität wie versprochen in einer Periode niederringt, sondern der, der einen bestimmten Wert zuverlässig liefert.

Dass es nicht einfach ist, den Wert von Software als Ganzes oder eines Inkrements zu bestimmen, steht auf einem anderen Blatt. Es bleibt die Aufgabe der Softwareentwicklung, die Wertproduktion zu optimieren. Dafür muss sie sich halt anstrengen, Wert greifbar zu machen. Das halte ich für eine wirklich lohnende Mühe.

Als Kunde würde ich jedenfalls lieber mit einem Softwareteam arbeiten, das mir ein Diagramm der Entwicklung des angepeilten Wertes meiner Software zeigt, als eines, auf dem eine obskure Komplexität getrackt wird.

P.S. Nicht realisierter Wert durch nicht-inkrementelle Entwicklung

Der Nachteil einer verzögerten Auslieferung von Wert lässt sich übrigens auch an den Beispieldaten ablesen. Ein nicht-inkrementelles Vorgehen wie im Wasserfall ist dafür ein extremes Beispiel. Doch auch bei bemüht agilem Vorgehen kann es immer wieder dazu kommen, das etwas eigentlich für den Kunden Werthaltiges (noch) nicht übergeben wird.

Die Summe des markierten Bereichs ist 46.150€. Dieser Gewinnzuwachs konnte bei agiler Entwicklung schon "unterwegs" bis Projektende vom Kunden realisiert werden:

Das Vorgehen nach Wasserfall verwehrt dem Kunden diesen Gewinnzuwachs. Es lässt ihn auf die Software warten. Die 46.150€ stellen deshalb cost of delay (CoD) dar, die durch eine big bang Auslieferung entstehen.

Der zentrale Wertmaßstab für die agile Softwareentwicklung ist daher CoD. Alles Bestreben agilen Vorgehens sollte auf die Minimierung von CoD gerichtet sein.