Meditations on Agile: Velocity würfeln

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.

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

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ürfelmethode, 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.

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.

Dieser Artikel erschien zuerst in der Kolumne „Meditations on Agile“ auf JAXenter.