In Deutschland lieben wir Geschwindigkeit. Und Vorhersagbarkeit. Idealerweise bis auf die zweite Stelle nach dem Komma. Deswegen mögen wir auch den agilen Begriff der „Velocity“. Ja, ein Team, das nimmt so richtig Fahrt auf, wird gigantisch produktiv, und erledigt viel mehr in viel kürzerer Zeit. Auf dass die Time-to-Market ordentlich glüht. Doch leider gibt es da ganz viele Missverständnisse, die ich im Folgenden besprechen möchte. Mein Eindruck ist nämlich, dass die Velocity oftmals für andere Zwecke genutzt wird.
Was also ist die Velocity?
Die Velocity ist zunächst einmal die Summe der Story Points aus den erreichten Sprint Backlog Items einer Iteration. Mehr nicht.
Das lassen wir zunächst mal kurz setzen. Wir atmen tief durch und unterdrücken den nun aufkommenden Reflex „Kann das Team nicht noch ne Schippe drauf legen?“. „Die müssten doch jetzt von Sprint zu Sprint schneller werden, ihre Velocity sollte steigen?“
Ganz schlau wird noch hinzugefügt: „Bis sich die Velocity dann einpendelt, nicht wahr? Gesetz der großen Zahlen, und so?“
Die Kanban-Experten mögen mir verzeihen, dass ich nicht gleich mit einer Monte-Carlo-Simulation als Gegenentwurf komme.
Einfache Lösungen?
Jedenfalls, ganz so einfach ist es dann doch nicht.
Denn in der Welt der Softwareentwicklung haben wir es auch mit Unknown Unknowns und Known Unknowns zu tun. Nicht überall wird diszipliniert mit Spikes (in Timeboxen statt Story Points) gearbeitet, um den Blick für zukünftige Backlog-Items zu schärfen. Schließlich müssen ja Feature um Feature Ergebnisse „produziert“ werden, die Time-to-Market gibt den Takt vor.
Manchmal stellt man auch gemeinsam in der Nachbetrachtung fest, dass eine User Story – nun, da es weitere Erkenntnisse gibt – doch einen anderen Punktwert gehabt hätte.
[smartblock id=“7056″]Überraschende Ereignisse
Jedenfalls ist es so, dass es auch Überraschungen gibt, mit denen das Team vorher nicht hat rechnen können. Zumindest nicht in der Exaktheit oder gar Präzision, wie wir das gerne hätten.
Das führt dazu, dass eine Velocity (also die Summe der erreichten Punkte in einer Iteration) von Iteration zu Iteration schwanken kann. Nach oben, wie nach unten.
Warum sich die Velocity verändert, ist Gegenstand einer gemeinsamen Reflektion – die kann in emergenten Systemen immer nur retrospektiv sein. Der Grund könnten technische Probleme sein. Oder die „Nebenaufträge“, die am Backlog vorbei ins Team gekippt wurden. Vielleicht gab es auch nicht gut vorbereitete User Stories. Oder oder.
Kommunikation ist wichtig
„Kann das Team nicht noch eine Schippe drauf legen?“ – „Hey klar, können wir. Aber bei dem komischen Monolithen und den vielen Abhängigkeiten geht einfach nicht mehr.“, denkt sich der Entwickler – und verzichtet darauf, es dem Manager zu erklären. Denn der versteht das doch sowieso nicht (eine weitere Denkfalle).
Die Forderung nach mehr Effektivität (und auch Effizienz) ist legitim, unternehmerisch auch sinnvoll. Doch ist sie in solchen Momenten auch hilfreich? „Hey, Eure Velocity schwankt. An welchen Stellen braucht es Verbesserung?“, ist möglicherweise hilfreicher.
Hier sind alle gefragt, zu einem gemeinsamen Dialog zu kommen. Innerhalb des Teams im Rahmen der Retrospektiven, und auf übergeordneten Flug-Ebenen im Rest der Organisation.
Instrument zur Selbstkontrolle
Wenn wir glauben, dass das Denken die Richtung bestimmt, und es in der (agilen) Produktentwicklung um die Wertschöpfung für den Endanwender geht, dann benötigen wir andere Kennzahlen als Gradmesser für den Erfolg eines Produkts.
Die Velocity ist also in erster Linie ein Selbst-Kontroll-Instrument für das Produktentwicklungsteam. Und kein Performance-Gradmesser oder gar eine KPI zum Vergleich zwischen Teams.
Deine Herausforderungen
Möchtest Du mit mir in einem kurzen Telefonat Deine Herausforderungen in Bezug auf Agile Teamstruktur & Management sowie der technologischen Ausgestaltung in Deiner Organisation diskutieren? Dann vereinbare einen kostenfreien telefonischen Beratungstermin mit mir!
Unsere Serie Agile Missverständnisse
Schreibe einen Kommentar