Meditations on Agile: Velocity würfeln

28. April 2016Gerrit Beine

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.

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.

Gerrit Beine Gerrit Beine ist Managing Consultant bei adesso. Seit 1998 unterstützt er Unternehmen in den Bereichen Software Architektur und Agile Methoden. Mit diesen Schwerpunkten ist er regelmäßig als Sprecher auf Konferenzen und hält Vorlesungen an verschiedenen Hochschulen. Er ist außerdem Autor der Kolumne "Meditations on Agile" und reflektiert über das Thema Agilität.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: