In Kürze: Velocity und Goodhart’s Law
Stellen Sie sich vor, der Vorgesetzte Ihres Teams besteht darauf, dass ein erfolgreiches Team seine Velocity regelmäßig verbessert. Wie könnten Sie als Team diese seltsame, unangemessene Forderung erfüllen, ohne mehr zu arbeiten? Wie können Sie Velocity und Goodhart’s Law versöhnen, sollte dies möglich sein?
Ich führe diese Übung mit meinen Teilnehmern an Scrum Master- und Product Owner-Einsteigerkursen durch, um ihnen zu helfen, über die heikle Natur der Erfolgsmessung, der Metriken und natürlich des Goodhartschen Gesetzes nachzudenken: „Wenn eine Messgröße zu einem Ziel wird, hört sie auf, eine gute Messgröße zu sein.“
Für den folgenden Artikel habe ich Vorschläge aus mehr als 50 Kursen zusammengetragen, wie man die Velocity „am besten“ manipulieren kann.
Warum Velocity eine problematische Metrik ist
Bevor wir uns auf die Vorschläge einlassen, lassen Sie uns analysieren, warum Velocity eine heikle Metrik ist:
- Teamspezifischer Charakter: Velocity ist von Natur aus spezifisch für jedes Team und wird von den einzigartigen Schätzungspraktiken, Arbeitsprozessen und individuellen Fähigkeiten beeinflusst.
- Fehlende Vergleiche: Die Verwendung von Velocity zum Vergleich verschiedener Teams kann irreführend sein, da eine höhere Velocity nicht unbedingt auf eine höhere Produktivität oder Effizienz schließen lässt.
- Unterschiedliche Definitionen: Jedes Team kann Story Points anders definieren, was teamübergreifende Vergleiche ungültig macht.
- Kontraproduktives Verhalten: Eine Überbetonung der Geschwindigkeit kann dazu führen, dass Schätzungen aufgebläht werden, um die Zahlen zu erhöhen, oder dass man sich auf einfache Aufgaben konzentriert, anstatt einen echten Wert zu liefern.
Schließlich untergräbt der Rückgriff auf die Velocity für umfassendere Vergleiche oder Leistungsbewertungen die Kernprinzipien von Scrum und kann der Moral und Effektivität des Teams schaden.
Daher sollte ein Team seine Velocity – wenn überhaupt – nur intern verwenden, um den Fortschritt zu planen und zu verfolgen.
Die Übung zur Manipulation der Velocity
Das Szenario sieht folgendermaßen aus: Der Vorgesetzte Ihres Teams ist davon überzeugt, dass ein erfolgreiches Scrum-Team in der Softwareentwicklung seine Velocity von Sprint zu Sprint stetig erhöht. Ihre Aufgabe als Team ist einfach: Finden Sie Wege, die es dem Scrum-Team ermöglichen, eine regelmäßige Steigerung der Velocity zu erreichen, ohne dass Sie auf der Ebene der Teammitglieder mehr arbeiten müssen.
Die Manipulation der Velocity ohne Ihre Arbeitsbelastung zu erhöhen
Werfen wir nun einen Blick auf 13 Möglichkeiten, die Velocity zu manipulieren:
Schätzen Sie Story Points und schätzen Sie diese erneut
- erhöhen Sie die Schätzung der Punkte von Sprint zu Sprint systematisch.
- Bewerten Sie die Story Points von bereits abgeschlossenen Aufgaben neu und erhöhen Sie diese nachträglich nochmals.
User-Stories aufteilen
- Brechen Sie größere Aufgaben in kleinere auf und weisen Sie jedem kleineren Teil einen größeren Anteil an Story Points zu.
- Unterteilen Sie bestehende Aufgaben in noch kleinere Teile und schaffen Sie so noch granularere Aufgaben.
Nicht entwicklungsbezogene Arbeit einbeziehen
- Bewerten Sie Bugs und die Behebung technischer Schulden mit Story Points.
- Berechnen Sie die Komplexität abgeschlossener Forschungsarbeiten, indem Sie Story Points für Spikes oder Rechercheaufgaben vergeben.
- Beziehen Sie routinemäßige Wartungs- oder Verwaltungsaufgaben mit ein und schätzen Sie diese ein.
Steigern Sie die Geschwindigkeit durch das Erstellen von Scheinaufgaben
- Fügen Sie dem Sprint Scheinaufgaben hinzu, die keine tatsächliche Arbeit erfordern.
- Erfinden Sie (reale) Aufgaben, die für das Produkt nicht wesentlich sind, aber schnell erledigt werden können.
Automatisieren Sie reguläre Aufgaben, aber verbuchen Sie sie als manuell erledigt
- Automatisieren Sie sich wiederholende Aufgaben, aber erfassen Sie sie so, als ob sie manuell erledigt worden wären.
Anpassen der Definition von Erledigt (DoD)
- Senken Sie die Qualitätsstandards oder lockern Sie die DoD, um Aufgaben schneller abzuschließen.
- Passen Sie die DoD an, um mehr Aufgaben als erledigt zu melden, auch wenn sie nicht vollständig abgeschlossen sind.
- Simulieren Sie technische Schulden bei der Erledigung von Aufgaben.
Verlängern Sie die Sprintdauer
- Verlängern Sie die Dauer von Sprints, um die ausgewiesene Velocity zu erhöhen.
Überlappende Sprints
- Arbeiten Sie an Aufgaben, die sich über mehrere Sprints erstrecken, und rechnen Sie diese komplett auf jeweils alle Sprints an.
Anpassen der Berechnung der Velocity
- Ändern Sie die Methode zur Berechnung der Velocity, z. B. durch die Verwendung eines gleitenden Durchschnitts über weniger Sprints.
- Fügen Sie Puffer oder Eventualpunkte in die Planung ein, die als zusätzliche Velocity erscheinen, wenn sie nicht genutzt werden.
Fokussieren Sie sich auf einfache Erfolge für die Velocity
- Priorisieren Sie einfachere Aufgaben, die schnell und einfach erledigt werden können.
- Wählen Sie nur einfache Aufgaben aus, um eine schnelle Erledigung zu gewährleisten.
Nicht erledigte Arbeit als abgeschlossen melden
- Markieren Sie unerledigte Aufgaben als abgeschlossen, um die gemeldete Velocity zu erhöhen.
Erstellen Sie User Stories aus kleineren Aufgaben
- Erstellen Sie Arbeitsaufgaben aus unbedeutenden Aufgaben, um die Anzahl der abgeschlossenen Aufgaben zu erhöhen.
- Wandeln Sie unbedeutende Aufgaben in Stories um und schätzen Sie sie erneut.
Aufgaben-Recycling
- Führen Sie Aufgaben wieder ein, die in früheren Sprints bereits vorhanden waren, aber nicht geschätzt wurden.
Ein Hinweis zur Vorsicht: Diese Methoden können zwar technisch gesehen die gemeldete Velocity erhöhen, aber sie können gleichzeitig die Integrität und Transparenz des Scrum-Prozesses gefährden. Die langfristigen Auswirkungen auf die Moral des Teams, die Produktqualität und das Vertrauen der Stakeholder müssen unbedingt berücksichtigt werden. Idealerweise wäre es vorteilhafter, mit den Stakeholdern über realistische Maßstäbe für den Erfolg von Scrum zu sprechen und ihre Erwartungen daran auszurichten, wie z. B. die Lieferung wertvoller Inkremente und die Aufrechterhaltung eines nachhaltigen Arbeitstempos.
Untergraben Sie stattdessen nicht die Kernprinzipien von Scrum!
Zusätzliche Überlegungen zur Gaming Velocity
Auch wenn die Velocity im Kontext eines einzelnen Teams eine nützliche Kennzahl sein kann, ist es wichtig, ihre Grenzen zu kennen und sie mit Bedacht einzusetzen::
- Kontext spielt eine Rolle: Velocity sollte immer im Kontext der spezifischen Umstände des Teams interpretiert werden, einschließlich der Größe des Teams, der Erfahrung und der Art der zu erledigenden Arbeit.
- Ergänzende Metriken: Sich nur auf die Velocity zu verlassen, kann irreführend sein. Ergänzen Sie sie mit anderen Messgrößen wie Kundenzufriedenheit, Qualität der Ergebnisse und Moral des Teams, um ein ganzheitliches Bild der Teamleistung zu erhalten.
- Fokus auf Ergebnisse: Das ultimative Ziel eines jeden Scrum-Teams ist es, Werte zu liefern. Konzentrieren Sie sich auf Ergebnisse und deren Auswirkungen auf der Kundenseite und nicht nur auf den Output. Eine hohe Velocity ohne wertvolle Ergebnisse ist bedeutungslos.
- Kontinuierliche Verbesserung: Nutzen Sie die Velocity als Instrument zur kontinuierlichen Verbesserung und nicht als striktes Ziel. Überdenken Sie Schwankungen und verstehen Sie die zugrunde liegenden Ursachen, um Prozesse und Effizienz zu verbessern.
- Kommunikation und Transparenz: Sorgen Sie dafür, dass alle Beteiligten die Nuancen der Velocity verstehen. Eine klare Kommunikation kann Missverständnissen und unrealistischen Erwartungen vorbeugen.
- Vermeiden Sie Druck: Hoher Druck zur Erhöhung der Geschwindigkeit kann zu Burnout und sinkender Qualität führen. Halten Sie ein nachhaltiges Tempo ein und stellen Sie das Wohlbefinden der Teammitglieder in den Vordergrund.
Wenn Sie diese Überlegungen berücksichtigen, können Teams und Unternehmen die Velocity effektiv nutzen und gleichzeitig die Fallstricke des „Spielens“ mit dieser Kennzahl vermeiden.
Schlussfolgerung
Während die Velocity für die interne Teamplanung und die Verfolgung des Fortschritts hilfreich ist, wird sie problematisch, wenn sie für ernsthafte Anwendungen wie den Vergleich verschiedener Teams verwendet wird. Die Übung, die ich mit meinen Studenten durchführe, zeigt, wie leicht die Geschwindigkeit manipuliert werden kann, und verdeutlicht die Fallstricke, wenn man sich zu sehr auf diese Kennzahl verlässt. Das Goodhartsche Gesetz besagt: „Wenn ein Maß zu einem Ziel wird, ist es kein gutes Maß mehr. (Siehe oben.) Dies gilt insbesondere für die Velocity, die Teams zu kontraproduktivem Verhalten verleiten kann, z. B. zu überhöhten Schätzungen und zur Konzentration auf Aufgaben mit geringem Aufwand.
Schließlich sollte die Geschwindigkeit ein Werkzeug für den internen Gebrauch bleiben, das den Fortschritt eines Teams anzeigt, ohne zu einem Maßstab für Leistungsvergleiche zu werden. Wenn Unternehmen die Grenzen und das Missbrauchspotenzial von Velocity verstehen, können sie die Falle des „Spielens mit Velocity“ vermeiden. Konzentrieren Sie sich stattdessen darauf, einen tatsächlichen Wert zu liefern.
Übrigens, wenn ich das Spiel mit Managern spiele, wissen sie selbstverständlich, wie das Manipulieren der Velocity funktionieren könnte.
Wie messen Sie den Erfolg Ihres Teams? Teilen Sie es uns bitte in den Kommentaren mit.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 42.000 Abonnenten anschließen.