“Team Performance Measurement” ist wirklich ein schlimmer Begriff, der in meinen Augen mit Hinsicht auf Teamproduktivität auch zu kurz greift. Doch das ist ein anderes Thema.
Was ich selbst gerne nutze, sind Basis-Flow-Metriken wie Cycle Time, Work in Progress und Throughput. Mit passender Nullmessung sind das in meinen Augen gute, erste Indikatoren für die Auswirkung von Veränderungen und eine Basis für Fragen.
Ansonsten begegnen mir Messungen tatsächlich viel zu selten. Was ich als leicht zu manipulierende Metrik schon gesehen habe, sind organisationsweite Vorgaben wie “80 % Testabdeckung in neuem Code ist Pflicht”.
“Velocity” ist noch so ein missverstandener Begriff. Je nachdem, was da zusammengezählt wird, ist der Unterschied zwischen Ordinal- und Kardinalskala halt schon wichtig.
(Und ich ärgere mich nachhaltig, dass ich an diesem Treffen nicht teilnehmen kann Bin gespannt auf die Aufzeichnung und Doku!)
“Team Performance” messen ist schon mal besser als “Individual Performance” messen.
Meist geht "“Team Performance messen” einher mit “Vergleichbarkeit mit anderen Teams” schaffen. Und dann wird meist irgendeine Output-Metrik genommen (am schlimmsten was eigentlich unvergleichbares wie story-points per sprint). Da werden dann nicht nur Äpfel mit Birnen verglichen, sondern auch ignoriert, dass “Dinge aus der Tür schaffen” kein Geschäftsziel ist.
Wenn man dann viele Pferdeäpfel und faulige Birnen aus der Tür schafft hilft das dann zwar der Team-Performance-Metrik, aber weder den Kunden noch dem Business.
“Team performance” messen ist erst dann sinnvoll, wenn man weiss, was “wertvolle Arbeit” ist und wie man das messen kann. Und welchen Einfluss der Kontext des Teams auf die Arbeit des Teams hat.
Die Velocity wollte ich auch gerade nennen. Ich erlebe es gerade, dass man anhand von Story Points in einer SAFe Umgebung pro ART (Agile Release Train) die Summe der Story Point erfasst, aufgeschlüsselt in Features/Epics, Enabler, technical debt etc.
Auf meine Rückfrage, was wir mir dieser Messung erfassen möchten, habe ich nur die Antwort bekommen, die Solution Train Ebene braucht diese Daten. Den Sinn und Zweck weiß ich bis heute nicht…
Das ist lustig. Ein ehemaliger Kunde rechnet ex-post Zeit / Story Points um damit ex-ante aus geplanten und geschätzten User Stories Zeitaufwand zu prognostizieren. Ordinal- und Kardinalskala war kein Argument, mit dem man hätte durchdringen können.
Verabschiedet Euch von unscharfen Bewertungen – Objektive Metriken sind der Schlüssel zur Vermeidung von Statusmelonen!
Metriken dienen als Maßstäbe zum Vergleich und zur Bewertung von Eigenschaften, Zuständen, Qualität, Komplexität. Dabei unterscheiden wir zwischen subjektiven (geprägten), objektiven (wertfreien), qualitativen (in Zeichen) und quantitativen (in Zahlen) Eigenschaften.
Objektive Metriken, die auf festgelegten, vereinbarten und akzeptierten Standards basieren, ermöglichen einen klaren Vergleich. Messen bedeutet, die Ergebnisse mit dem Standard zu vergleichen, zu interpretieren, zu diskutieren, zu visualisieren.
Meine Metrik hebt sich ab, denn sie wird regelbasiert in Echtzeit errechnet, ohne manuellen Eingriff. Sie ist leicht erfassbar und motiviert. Daraus habe ich die Erkenntnis gewonnen: Gute Metriken bieten Orientierung und erleichtern das Reporting. Es ist Schluss mit vagen Einschätzungen und Manipulation – ich setze auf meine klare, objektive Metrik für eine präzise Bewertung meiner Projekte!
Um die Frage zu beantworten:
a) wir benutzen Metriken, aber nicht um Team Performances zu messen. Der wichtigste Indikator ist für mich die Idle Time, um daraus Rückschlüsse auf organisatorische Defizite zu ziehen.
b) klar habe ich das schon erlebt. Und führt dazu, das Schaffen von Wert für den Kunden aus dem Fokus gerät.
Ich finde, das Schätzen in den seltensten Fällen hilfreich ist, insbesondere - und das ist meistens der Fall - man Dinge schätzen soll, die man noch nie gemacht hat.
Insbesondere machen Metriken dann keinen Sinn, wenn sie zum Kontrollieren von Time, Budget und Scope fürs Management dienen soll.
Deshalb meine Empfehlung: da wo es Sinn macht und sich das Team selbst verbessern kann, aber bitte nicht außerhalb des Teams verwenden.
Velocity ist wirklich ein Universaltalent. Ich musste “lernen”, dass die Velocity auch die Frage beantwortet, ob ein neues Teammitglied voll integriert ist im Team und wie sehr die Person die Performance steigert. Dauert es beispielsweise zu lange mit der Performancesteigerung, dann ist die Probezeit des Mitarbeiters gefährdet.
Mein Vorschlag, nicht auf die jeweilige Jira-Berechnung am Sprint-Ende zu warten, sondern jederzeit eine genauso zuverlässige Aussage zu erhalten, in dem man dieses Tool (https://spinthewheel.app/) verwendet, kam merkwürdigerweise nicht gut an.
Mein Vorschlag für einen Einstieg ins Messen sind die bereits vorgeschlagenen “DORAs” und noch die vier Kanban Metriken Cycle Time, Work In Progress, Throughput und Work Item Age. Die “Kanbans” sind auch sehr hilfreich, wenn man “nur” Scrum macht und nicht Scrumban oder Kanban. Ein regelmässiger Team-Health-Check kann auch nicht schaden, auch wenn dieser von einigen als zu wenig “objektiv gemessen” gesehen wird.
Team Performance Measurement ist effektiv, wenn klar definiert ist, was unter “Performance” zu verstehen ist. Im Kontext eines typischen Scrum Teams könnte dies bedeuten:
Erreichung des Sprintziels
Erfüllung des Produktziels
Einhaltung der Vorgaben aus der Roadmap
Eine klare Definition von “Performance” ist für die Messung essenziell. Laut GPT-4 umfasst “Performance” die Effizienz und Wirksamkeit, mit der Aufgaben oder Funktionen erfüllt werden.
In vielen Unternehmen wird “Performance” oft als “Durchsatz”, also die Menge der bearbeiteten Backlog-Einträge, oder als Grad der Erfüllung von Lieferversprechen definiert.
Die Effektivität eines Teams zu messen, was selten geschieht, würde bedeuten, den Grad der Wirksamkeit anhand des gesteigerten Geschäftswertes und Kundennutzens zu bewerten. Dies ist prinzipiell leicht möglich, wird aber oft nicht angestrebt.
Stattdessen konzentriert man sich auf die Zählung von Story-Points und die Beobachtung der Velocity, in der Hoffnung, dass die Produktkennzahlen auch ohne eine gezielte Beeinflussung zufriedenstellend sein werden.
Sobald Zahlen im Spiel sind, werden diese missbraucht!
Die Story Points - ein sehr hilfreiches Mittel, um vergleichend zu schätzen (größer/kleiner als…) und absolut untauglich, um die Leistung des Teams zu bewerten.
Selbst bei genormten Metriken (z.B. ISO/IEC 20926 IFPUG), um die Funktionalität von Software zu messen, kommt es oft bei der Interpretation und Verwendung zu haarsträubenden Ergebnissen. Das ist aber noch ein ganz anderes Thema. Allerdings habe ich die Erfahrung gemacht, dass diese Methoden - richtig eingesetzt - sehr gut für eine grobe Zeit- und Budgetschätzung geeignet sind.
Und was ist Teamperformance? Schnell neue Funktionen liefern? hohe Qualität liefern? Wartbarkeit liefern? Besonders bei SCRUM besteht die Gefahr, dass man sich zu sehr auf die zu liefernde Funktionen konzentriert und die Gesamtarchitektur vernachlässigt wird. Allerdings gibt es das natürlich auch in nicht-agilen Projekten.
Ich mag auch keine Schätzungen. Verstecken sie doch häufig das Drängeln „wie lange dauert´s denn noch!“ oder „warum wird’s jetzt noch teurer!“. Und sie binden auch wertvolle Kapazität. Dann wird aus Zeit- und Kostengesichtspunkten irgendetwas erfunden – analog zu Statusmelonen.
Verschärfend kommt hinzu, dass man auf die Schätzung zur Unzeit an den unpassendsten Gelegenheiten angesprochen wird „Sie haben doch versprochen…“. Ach ja. Erkläre dann mal den Unterschied zwischen einer Schätzung (Unschärfe) und einer Doktorarbeit (Präzision).
Lieber mag ich das Verstehen der Aufgaben – dafür muss auch gearbeitet werden. Jepp – ist aber zielführender! Die Umsetzung vieler Projekte, beispielsweise Datenmigration oder Software-Modernisierung, ist ein hochkomplexes Vorgehen, das viele Abhängigkeiten birgt und meist mit vielschichtigen Fehlersituationen behaftet ist. Bei Analyse und Fehlerbehebung sind regelmäßig unvorhergesehene Aufgaben zu lösen sowie Fehler zweiter oder dritter Ordnung zu entstören. Daher ist es nach meiner Erfahrung nicht zielführend und effektiv, Aufgabenpakete zu detailliert zu planen und dazu Restaufwände zu schätzen. Als Impulse: „“Roadmap oder „Wie esse ich einen Elefanten?“.
Vielmehr ist es essentiell, ein Rahmenwerk oder Vorgehensmodell parat zu haben, das Richtung und Leitplanken vorgibt sowie die Zielerreichung sicherstellt und eine Metrik mitgibt. Ich habe eine solches Modell mit Metrik entwickelt und mehrfach in unterschiedlichen Projekten in der Praxis erprobt.
Die Metrik wird regelbasiert ermittelt (da kann keiner rumpfriemeln und „optimieren“) und stellt die Abarbeitungsgeschwindigkeit dar. Das Modell ermöglicht auch Simulationen zur Folgenabschätzung bei typischen Fragen, die schwer bis unmöglich belastbar zu beantworten sind. Beispielsweise „Können wir nicht noch dieses Feature bis zu GoLive mitmachen?“. Am besten „aufwandsneutral“! Oder, zumindest in zeitlicher Auswirkung „Was können wir weglassen, um den Produktivsetzungstermin noch zu erreichen?“.
Diese Metrik ist zwar kein anerkannter Standard aber ehrlich und nachvollziehbar. Die daraus abgeleitete Projektendeprognose mit Schätzgütebewertung tut ihr übriges. Und, sie motiviert und spart viele unnötige Diskussionen. Glückliche Teams sind performante Teams
Eine kleine Einordnung, weil die “DORA-Metriken” hier schon mehrmals genannt wurden.
Welche meint ihr denn? Ich vermute mal die alten Bekannten:
Change lead time
Deployment frequency
Change failure rate
Failed deployment recovery time
Diese sind nur ein kleiner Teil der Betrachtungswinkel, die der 2023er Accelerate State of DevOps Report aufführt. Genau genommen beschreiben diese Metriken lediglich die Software Delivery Performance.
Der Report behandelt zusätzlich noch Operational Performance, Employee Well-Being, Organizational Performance und Team Performance. Letztere erklärt als “the ability for an application or service team to create value, innovate, and collaborate”.
Mit etwas Abstand zu meiner ursprünglichen Frage und mit den ganzen Infos, Erfahrungen und Posts von euch, spielen für mich diese 2 Punkte eine entscheidende Rolle. Und hängen auch unweigerlich miteinander zusammen.
a) Was bedeutet Wert für die unterschiedlichen Parteien? Je nach Rolle, Aufgabe, Job der Person, kann die Definition bzw. das Verständnis von Wert natürlich sehr unterschiedlich sein. Ebenso wie die Beweggründe (im Sinne von Jobs to be done), die zum Bedürfnis des Messens führen.
Mit die größte Herausforderung ist es, trotz dieser Gemengelage so etwas wie einen Konsens (oder zumindest eine vernünftige Schnittmenge) der gewünschten „Wertmessung“ zu erreichen. Dazu braucht es gegenseitiges Verständnis, und einen Perspektivenwechsel, vermutlich gepaart mit etwas Fachwissen für SW-Entwicklung.
b) tritt ein, wenn a) nicht erreicht werden kann .
Dann kommt es früher oder später zu “play the system”.
Und ein Szenario ist mir noch in den Kopf gekommen:
Was tun, wenn alle mit “play the system” glücklich sind?
Das Team liefert schön brav, die Zahlen, um die es gebeten wird. Und hat so seine Ruhe.
Die “Empfänger” bekommen das, was sie gefordert haben. Zur weiteren Verarbeitung.
Antwortdestilat “a” ist wohl entscheidend. Der Missbrauch der Metriken ist (für mich) meist das größte Problem (siehe Velocity als Benchmark für Teams untereinander). Wichtiger als die Frage “Welche” sollte also erst mal “Wofür” sein - “welche” kommt dann später.
Und wenn alle “mit dem Spielen glücklich sind” klingt ein wenig so wie bei meinem letzten Mutterkonzern - “Ja, wir sollen offiziell alle Scrum machen, aber im Endeffekt organisiert sich jedes Team selbst wie es passt”
@svenk ein großes “DANKE” für den Hinweis auf den fast schon größten aller “Dumfugtümer”: “Story Points per Sprint”. Ich sehe das so oft. Kompletter Nonsense…
Ich gehe diesen “Master-Sinnlos-KPI” dann direkt so an, dass bis dato alle Organisationen, mit denen ich gearbeitet habe, diesen dann fallen lassen:
Letzten Sprint habt ihr eine Steinmauer für den Garten angelegt. Dafür hattet ihr Maurer, Tiefbauer und Gartengestalter im Einsatz.
Diesen Sprint habt ihr die Gartenhütte als Ziel. Also kommen jetzt die Tiefbauer (letzter Sprint auch dabei!) und die Zimmerleute zum Einsatz (letzter Sprint…ihr ahnt es…nicht dabei). So…und die Leistung beider Teams wollt ihr vergleichen… den Rest spare ich mir.
Können wir jetzt vernünftig arbeiten?
Ich habe folgendes Beispiel erlebt, bei dem der „Wert“ ziemlich einfach und klar zu messen war. Sofern man (das Team) den Hintergrund kannte.
Der Vertrieb spricht mit dem Kunden. Der Kunde (ein sehr wichtiger) wünscht sich ein bestimmtes Feature. Er fragt den Vertrieb, bis wann er den mit diesem Feature rechnen könne.
Der Vertrieb (verhält sich vorbildlich) sagt, das könne er nicht sagen, aber er kläre das gerne mit der Softwareentwicklung ab.
Das tut er auch. Er fragt beim Product Owner (Team), wann den das gewünschte Feature des Kunden umgesetzt sein wird.
Wichtig: Er erklärt, dass es ihm (in dem Fall Kunde und Vertrieb) nicht um ASAP geht, sondern um ein verlässliches Datum. Der Kunde möchte mit dem Datum planen. Verlässlichkeit gehe an der Stelle vor Schnelligkeit.
“Feature Complete” in X Sprints = 100 % Wert
“Feature != Complete” in X Sprints = ? Wert. Aus Sicht des Kunden vermutlich 0.
Das wäre ein Beispiel für eine imho sehr einfache und sinnvolle Metrik.
Für das Team aber nur nachvollziehbar, wenn es diesen Austausch mit dem Vertrieb und/oder Kunde gibt, und die Hintergründe klar sind.
Bin gespannt auf die Aufzeichnung und Doku!)
