Raus aus dem Geschwindigkeitsrausch

Wäre dieses agile Velocity Diagramm eines Scrum-Teams würdig?

Mein Gefühl ist, dass nicht viele Teams (oder Manager von Teams) damit zufrieden wären. Die Velocity sinkt von Iteration zu Iteration. Das schaut nicht gut aus, oder? Was ist da nur los? Die Fortschrittsgeschwindigkeit sollte von Iteration zu Iteration doch am besten steigen oder zumindest um einen konstanten Wert in engen Grenzen pendeln. Oder?

Die Kurve des Burn-up Diagramms wird immer flacher, der Zuwachs an Story Points pro Iteration immer geringer. Oh, oh. Nicht gut.

Ok, jetzt vorläufige Entwarnung: Diese Diagramme stellen gar keinen Softwareentwicklungsfortschritt dar. Sie zeigen vielmehr meinen Fortschritt auf dem Weg zu einer Stelle an der Küste von Fuerteventura, von der aus ich ein Foto machen wollte.

Sehen Sie die Gischt in der Mitte dieses Bildes?

Diesem Punkt wollte ich möglichst nahe kommen, um mit meinem iPhone ohne Teleobjektiv ein hübsches Bild von dem Spektakel zu machen. Dafür musste ich ungefähr 100m über Lava-Untergrund zurücklegen.

Wie lange würde das dauern? Ich hatte keine Ahnung. Am Ende brauchte ich ca. 10 Minuten. Kommt Ihnen das bekannt vor? Der Scope lag vor mir – mehr oder weniger klar erkennbar. Doch ich konnte selbst hier

keine Aussage machen, wie viel Aufwand er zur Erledigung wohl brauchen würde. Natürlich habe ich Erfahrung mit der Tätigkeit, natürlich war mir auch klar, dass ich länger als auf einem Bürgersteig brauchen würde. Aber wie lange genau? Die 10 Minuten wären mir eher nicht in den Sinn gekommen.

Da ich keinen Zeitdruck hatte, bin ich einfach mal losgegangen. Anfangs war der Untergrund gut zu gehen, ich habe ca. 15m pro Minute zurückgelegt.

Doch dann veränderte sich etwas. Ich musste öfter Umwege gehen, um nicht in Wasseransammlungen zu treten. Außerdem wurde der Untergrund holpriger. Mein Fuß fand nicht mehr so gut Halt. Ich konnte meine anfängliche Geschwindigkeit nicht mehr halten.

Als ich schon dachte, es könnte nicht mehr schlimmer kommen, wurde es dann allerdings auch noch glitschig.

Eigentlich nicht so verwunderlich, oder? Aber das hatte ich nicht vorhergesehen. Die Wasseransammlungen nahmen zu und ich musste noch vorsichtiger von Fuß zu Fuß wechseln, um nicht auszurutschen. Meine Geschwindigkeit in Bezug auf das Ziel nahm weiter ab.

Zwar gewann ich unterwegs einige Erkenntnisse zu Flora, Fauna und Erosion, doch ich brauchte ganz schön lange, bis ich nahe genug an den Felsen war, um eine Aufnahme nach meinem Geschmack machen zu können.

Nach ca. 10 Minuten war ich am Ziel. Das hätte ich nicht vorhergesehen können. Ebenfalls hätte ich nicht geahnt, dass auf dem Weg meine Geschwindigkeit so unterschiedlich und quasi konsequent abnehmend sein würde.

Und was bedeutet das für die Softwareentwicklung? Nicht weniger, als dass Geschwindigkeit sich nach dem Terrain richten sollte. Geschwindigkeit kann nicht befohlen, verordnet, dekretiert werden. Oder wenn man das tut, dann steigert man offenen Auges das Risiko.

Ich hätte mir ja auch eine Vorgabe machen können: "Du brauchst jetzt nur max. 4 Minuten bis zum Felsen. Los geht's..." Dann hätte ich im Zweifelsfall auf dem zunehmend unebenen, pfützendurchzogenen und schlüpfrigen Terrain einen Sturz hingelegt oder mir den Fuß verletzt.

Oder nach der ersten Minute hätte ich sagen können: "Das war jetzt super: 15m. Das ist mein Ziel für die nächste Minute." Und so weiter. Dann wäre ich bald enttäuscht gewesen. Ich ahne, dass ich dann angefangen hätte, mehr auf die Einhaltung einer Geschwindigkeit geachtet hätte, als auf den Untergrund. Ein risikosteigerndes Verhalten.

Der Fortschritt der Softwareentwicklung ist heute zu oft eine Funktion der Lautstärke des Kunden. Stattdessen sollten wir ihn zu einer Funktion des Schwierigkeitsgrades von Anforderungen machen.

Dass der Schwierigkeitsgrad immer gleich ist, dass er womöglich monoton abnimmt, ist nicht zu erwarten. Überraschungen, Fallen, unbekannte Unbekannte lauern überall. Selbst mit einem big design up-front (BDUF) ließe sich das nicht ändern.

Also mutig den Unwägbarkeiten ins Auge sehen. Velocity ist kein zielführendes Mittel, wenn es um die saubere Erfüllung aller Anforderungen geht, also nicht nur der in Hinsicht auf Funktionalität und Effizienz, sondern auch von Korrektheit und Wandelbarkeit.

Kurzfristig mag man sich schneller bewegen können, als das Terrain eigentlich erfordert. Wenn es dann aber zum Sturz kommt, entstehen plötzlich Mehrkosten. Nachbesserungen jeder Art, weil man versucht hat, Abkürzungen zu nehmen, schränken die Produktivität am Ende stark ein.

Geschwindigkeit für die nächste Iteration vorherzusagen, ist kontraproduktiv. Bewegen Sie sich so schnell wie möglich, aber gleichzeitig so langsam wie nötig. Mehr geht einfach nicht verantwortungsvoll.

Das Velocity-Diagramm vom Anfang ist also absolut eines agilen Teams würdig.