Kolumne

Meditations on Agile: Velocity würfeln

Gerrit Beine

In dieser Folge der Kolumne „Meditations on Agile“ geht Gerrit Beine dem Dilemma nach, dass IT-Projekte mitunter zu einem Festpreis vereinbart werden – was sich mit einem agilen Vorgehen nicht so recht in Einklang bringen lässt.

Velocity würfeln

Es gibt Unternehmen, die schreiben agile Projekte „zum Festpreis“ aus. Der billigste Anbieter erhält den Zuschlag. Wer den Fehler in dieser Logik findet, darf ihn behalten. Ich werde immer wieder um Rat gefragt, wenn es darum geht, für solche Projekte einen Velocity Forecast zu machen. Man will es ja richtig machen. Das verstehe ich. Also den Willen, es richtig zu machen, nicht den Willen, es zu machen.

Konstruktive Schätzungen

Als alter DSA-Spieler habe ich für solche Fälle eine ganze Reihe von W20 (Ikosaeder für Altsprachler und Mathematiker), die ich aus der Tasche ziehe und verkünde, dass ich mit diesem Präzisions-Velocity-Forecast-Tool die Velocity des Teams präzise vorhersagen werde. Die Reaktionen darauf reichen von ungläubigen Staunen bis zu Genervtheit wegen meines nicht konstruktiven Beitrags.

Das verstehe ich natürlich. Aber wie soll ich einen konstruktiven Beitrag leisten, wenn die Aufgabenstellung nicht konstruktiv ist? Sie führt sogar absehbar zu einem Desaster. Aber das will keiner hören. Alle wollen nur hören: Die Velocity eines neuen Scrum Teams beträgt 23,68 Story Points pro Sprint bei einer Varianz von 0,75 Story Points in den ersten drei Sprints. Faszinierend ist, dass alle wissen, dass das Quatsch ist, aber es macht die Leute glücklich. Ich denke mir diese Velocity immer nur aus. Auch die Varianz erwürfele ich mit einem imaginären W0,9. Ein echter Würfel ist ja nicht konstruktiv.

Das Verkünden einer Zufallszahl mit mindestens zwei Nachkommastellen wirkt auf Leute, die nach Velocity-Forecasts fragen, wie eine warme Daunendecke auf ein Baby. Es lullt sie ein und wiegt sie in Sicherheit. Bis die Realität kommt. Die kommt garantiert, weshalb ich solche Projekt auch gar nicht machen würde. Ich empfehle immer, an solchen Ausschreibungen nicht teilzunehmen.

„Aber dann machen andere das Projekt!“

Ja, klar. Aber dann holen sich auch andere eine blutige Nase. Denn die holt man sich mit so einem Projekt definitiv.

Meditations on Agile

GerritIn der Kolumne “Meditations on Agile” reflektiert Gerrit Beine (adesso AG) über das Thema Agilität in der Softwareentwicklung. Einiges davon durchaus ketzerisch, anderes zutiefst spirituell. Die Entwicklung hängt vom Feedback ab. Typisch agil. Bisher erschienen:

Empirisch würfeln

Wir Menschen können mit Dingen, über die wir nichts wissen, nur empirisch umgehen. Das ist der Grund, warum Scrum funktioniert. Es nutzt Empirie und die Fähigkeit durch Feedback zu lernen, um ein Projekt erfolgreich zu machen. Das Problem ist, dass Scrum und auch alle anderen agilen Methoden ein Wertmodell voraussetzen. Denn dazu dienen agile Methoden: wertvolle Software zu liefern.

Solche Ausschreibungen wollen aber keine wertvolle Software, sie wollen geplante Software. Und weil wir wissen, dass geplante Software in aller Regel Mist ist, müssen wir besser planen. Und weil wir keine Ahnung haben, wie wir Wert messen sollen, messen wir Aufwand.

Aber in der agilen Welt wird der nicht mehr in Tagen gemessen, sondern in Story Points. Also müssen wir den Plan in Story Points abschätzen. In der Praxis wird dann üblicherweise eine Schätzung in Personentagen gemacht, die über eine Heuristik in Story Points umgerechnet werden, damit der Anspruch erfüllt ist. Die Präzision entspricht dabei nicht im Entferntesten meiner Würfel-Methode, aber Würfel sind ja auch nicht konstruktiv. Siehe oben.

Velocity ist kaputt

Ja, Velocity ist kaputt. Total. Velocity ist ein empirisches Maß der Produktivität eines Teams in der Vergangenheit. Was in der Zukunft passiert, sagt die Velocity nicht. Deshalb ist es auch kolossaler Blödsinn, ein Projekt über die Velocity zu steuern. Das ist, als würde man Auto nach Spritverbrauch statt nach Tacho fahren. Gut, der Vergleich hinkt, aber der Begriff Velocity ist eigentlich auch völlig falsch. Es handelt sich nicht um die Geschwindigkeit des Teams, sondern um die geleistete Arbeit, die sich aus Aufwand, Unsicherheit und Risiko zusammensetzt.

Lesen Sie auch: Was wir von Steve Jobs’ Gedanken zu Fahrrädern über Agilität lernen können…

Viel sinnvoller ist es, ein Projekt statt über Velocity über den Wert der Features zu steuern. Das wertvollste zuerst. Oder das mit dem besten Wert/Kosten-Verhältnis zuerst. Beides funktioniert. Beides führt zu guter Software. Velocity first führt nur ins Verderben.

Zur weiteren Erleuchtung empfehle ich, über dieses Thema zu meditieren.

Geschrieben von
Gerrit Beine
Gerrit Beine
Gerrit Beine ist Managing Consultant bei der adesso AG mit den Schwerpunkten Agilität und Softwarearchitektur. Er ist regelmäßig als Sprecher auf Konferenzen zu treffen und beschäftigt sich gerne mit außergewöhnlichen Fragestellungen zur Softwareentwicklung.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Meditations on Agile: Velocity würfeln"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Boeffi
Gast

… „schön“ sind auch immer wieder die zu beobachtenden Diskussionen, ob die 23,68 Story Points vielleicht doch eher eine „24“ sind, „…dann hätten wir eine realistische Chance die letzte Story auch noch für den Sprint zu committen…“ – Sehr konstruktiv … 😉

CU
Boeffi