Developer Velocity

Developer Velocity – die Geschwindigkeit eines einzelnen Entwicklers

Das englische Wort „Velocity“ heißt ins Deutsche übersetzt Geschwindigkeit bzw. Schnelligkeit. In agilen Frameworks wie bspw. Scrum gilt die Velocity als internes Maß zur Geschwindigkeitsmessung von Entwicklungen im Team. Sie basiert häufig auf realisierten Story Points und hilft bei der Planung von Sprints. Die Developer Velocity ist ein individuelles Maß, das den Blick auf die Geschwindigkeit eines einzelnen Teammitglieds lenkt.¹

Der Scrum Guide und die Developer Velocity

Die Planung von Sprints mithilfe der Velocity ist in vielen Organisationen üblich. Im Scrum Guide, der Scrum mit seinen Spielregeln beschreibt, tauchen jedoch weder Velocity noch Developer Velocity als Begriff auf. Verantwortlichkeiten bzw. Accountabilitys werden hingegen im Guide ausführlich erläutert.² Zwischen den Verantwortlichkeiten (Scrum Master, Product Owner und Developer) und auch zwischen den Entwicklern selbst gibt es keine Hierarchien. Damit werden im Wesentlichen zwei Ziele verfolgt:

• Entscheidungen sollen auf Basis fachlicher Kriterien getroffen werden.
• Und die Verantwortung liegt im Team und nicht bei einzelnen Teammitgliedern.

Wenn der Scrum Guide explizit die Verantwortung des Teams betont, wieso sollte es dann richtig sein, die Developer Velocity als individuelles Geschwindigkeitsmaß beim Sprint Planning zu berücksichtigen? Im Idealfall verfügen die Teammitglieder über unterschiedliche Fähigkeiten und Kenntnisse, wobei die Leistung des Teams maßgeblich von der Kombination dieser Fähigkeiten abhängt. Verfügt bspw. ein Mitarbeiter nicht über benötigte Kenntnisse, so ist das Team als Ganzes gefordert, ihn bei der Tätigkeit zu unterstützen und seine Fähigkeiten zu erweitern.³

Der Umgang mit anspruchsvollen Entwicklungsaufgaben

Immer wieder lässt sich in Organisationen beobachten, dass die Geschwindigkeit und auch die Leistung einzelner Entwickler miteinander verglichen werden. Häufig sind erfahrene Entwickler schneller als weniger erfahrene Kollegen. Dies kann dazu führen, dass anspruchsvolle Entwicklungsaufgaben regelmäßig den besten und erfahrensten Entwicklern übertragen werden.

• Ein tieferes Verständnis der Codebasis und der Systemarchitektur,
• sowie mehr Erfahrung bei der Lösung komplexer Probleme,
• bei der Realisierung von zentralen Anforderungen und
• der Arbeit mit dem Technologie-Stack

sind valide Gründe für ein solches Vorgehen. Oftmals ist es sogar das Team selbst, dass einem konkreten Teammitglied die anspruchsvolle Aufgaben überträgt, da es so entsprechendes Fachwissen nutzen kann, um zügig hochwertige Lösungen zu entwickeln.

Es gibt jedoch auch potenzielle Nachteile, wenn die anspruchsvollen Aufgaben stets einzelnen Entwicklern zugewiesen werden:

• Es entstehen Wissenssilos, in denen nur einige wenige Entwickler ein tiefes Verständnis für bestimmte Teile der Codebasis oder des Systems haben. Dies kann es dem Team erschweren, effektiv zusammenzuarbeiten, Wissen zu teilen und ein gemeinsames Verständnis für das System als Ganzes zu entwickeln.
• Es entstehen Abhängigkeiten, die spätestens dann ins Auge fallen, wenn gleichzeitig mehrere anspruchsvolle Aufgaben anstehen, jedoch zu dem Zeitpunkt bspw. wegen Urlaub, Krankheit oder mangelnden Kapazitäten nicht genügend Wissensträger im Team vorhanden sind.
• Werden schwierige Aufgaben stets demselben Entwickler zugewiesen, könnte auch die Burnout-Gefahr steigen.
• Zu guter Letzt begrenzt ein solches Vorgehen die fachlichen Entwicklungsmöglichkeiten der anderen Teammitglieder, was zudem auch zu Unmut und Demotivation führen kann.

Letztendlich hängt der beste Ansatz vom spezifischen Kontext und den Zielen des Teams und der Organisation ab. In manchen Fällen kann es sinnvoll sein, die anspruchsvollsten Aufgaben den besten und erfahrensten Entwicklern zu übertragen, während es in anderen Fällen effektiver sein kann, die Arbeit gleichmäßiger zu verteilen und allen Teammitgliedern die Möglichkeit zu geben, ihre Fähigkeiten und ihr Fachwissen zu entwickeln.

Geht es nach Frameworks wie Scrum, dann ist die gleichmäßige Verteilung von Aufgaben oftmals erstrebenswert, insbesondere da die Velocity als team-internes Hilfsmittel zur Planung und Risikokontrolle gilt. Wer Teams einer Organisation durch den Vergleich untereinander, basierend auf geplanten oder realisierten Story Points anzutreiben versucht, tut sich keinen Gefallen. Dies führt über kurz oder lang zu einer Inflation der Schätzungen. Bei der Developer Velocity gilt das Gleiche.

Impuls zum Diskutieren:

Velocity ist ein Ergebnis und kein Ziel!

Hinweise:

Haben Sie vielleicht Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] In manchen Publikationen werden Developer Velocity und Velocity synonym verwendet. Dies ist zwar grundsätzlich möglich, jedoch wenig sinnvoll, da es eher zur Begriffsverwirrung beiträgt als Klarheit schafft. Handelte es sich um die Geschwindigkeit des Teams müsste es wohl auch Developers Velocity heißen.
[2] Scrum Accountability
[3] Im Zuge des Sprint Plannings 2 diskutieren die Entwickler, „wie“ die vereinbarten Anforderungen umgesetzt werden sollen. Hier kann es sinnvoll sein, dass der Scrum Master bei Bedarf Hinweise liefert, wenn das Team wiederholt die wichtigsten Aufgaben dem besten Entwickler überlässt.

Hier finden Sie eine englischsprachige empirische Analyse zu Produktivität von Softwareentwicklern.

Und hier finden Sie ergänzende Informationen aus unserem t2informatik Blog: