Nicht alles ist in Zahlen messbar

Wesentlicher Bestandteil agiler Methoden ist das kontinuierliche Messen von den Dingen, die man macht. Die Ergebnisse der Messungen oder deren Interpretation sind eine wichtige Grundlage für die kontinuierliche Verbesserung. Über unterschiedliche Metriken lassen sich viele Dinge messen, aber eins lässt sich nicht ohne Weiteres messen: Die Steigerung der Effizienz von Teams.

Nun wird der eine oder andere sagen, dass sich dafür doch hervorragend die Velocity – also die durchschnittliche (in der Regel mit Story Points gemessene) Geschwindigkeit von Teams heranziehen lässt. Anhand dieser relativen Schätzung und einer positiven durchschnittlichen Entwicklung der Storypoint-Zahl pro Sprint ließe sich die Steigerung der Effizienz eines Teams ablesen. Mittlerweile glaube ich, dass das so nicht ohne Weiteres stimmen kann und ein wenig förderlicher Ansatz ist. Die Betrachtung der (Steigerung von) Effizienz von Teams anhand einer gemessenen Velocity halte ich für Verschwendung.

Kein Vakuum

Die Velocity als Gradmesser für die Effizienz(steigerung) eines Teams würde nur funktionieren, wenn ein Team in einem Vakuum völlig losgelöst von einer sich ständig verändernden Umgebung existieren würde. Äußere Umstände dürften keinen Einfluss auf die Ergebnisse eines Teams haben. In einem komplexen Umfeld aber ist genau die Erkenntnis, dass Teams sich nicht von sich unvorhersehbar verändernden Umgebungen lösen können, ein Grund, warum wir agil arbeiten: Wir wollen schnell auf Veränderungen reagieren können.

Wenn Faktoren der Umgebung außerhalb des Einflussbereichs eines Teams einen Einfluss auf den Output des Teams hat, dann sind unkontrollierbare Rahmenbedingungen mit verantwortlich für die Effizienz eines Teams und nur weil ein Team mehr Story Points schafft, lässt sich davon ohne Betrachtung der Rahmenbedingungen keine Effizienzsteigerung des Teams ablesen bzw. hat diese Zahl einen sehr geringen Wert und damit eine nahezu unwichtige Aussagekraft. Ich kann also aus der Summe der erreichten Storypoints pro Iteration einen Durchschnitt errechnen und eine Trendlinie ableiten, wie sich dieser Durchschnitt verändert. Die positive wie negative Veränderung hängt aber nicht nur vom Team ab und damit verliert die isolierte Trendlinie ihren Wert.

Hinzu kommt, dass auch ein immer effizienter arbeitendes Team nicht zwingend einen immer höheren Wert erzeugt. Ein Team kann problemlos hocheffizient Dinge tun, die keinen Nutzen bringen.

Am Ende ist der Versuch, die Effizienz eines Teams in Zahlen auszudrücken, ein eher klassisches Modell. Das ist der Versuch, einem komplexen Zustand (die Zusammenarbeit eines Teams in einem sich ständig verändernden Umfeld) mit einer Lösung zu begegnen, die sich dafür nicht eignet. Der Wert ist gering, weil die Zahl an sich zu wenig Information bietet. Natürlich lassen sich erreichte Storypoints in einer Iteration in Diskussionen mit anderen Werten vergleichen um eine Diskussionsgrundlage zu haben. Natürlich lässt sich daraus auch eine durchschnittliche Geschwindigkeit als Planungsgrundlage ableiten. Die Steigerung der Effizienz kann ich davon aber nicht zuverlässig ableiten.

Was tun?

Was kann man also tun, wenn man wissen will, ob ein Team sich verbessert? Man kann und sollte mit dem Team und/oder einem Beobachter oder Unterstützer des Teams (zum Beispiel Scrum Master, Teamleiter) sprechen. Hierdurch gewinnt man nicht nur einen besseren, ehrlicheren und inhaltsreicheren Eindruck, sondern direkt eine Grundlage, um bei der Steigerung der Effizienz eines Teams zu unterstützen.  Es werden Hindernisse deutlich, die eine effiziente Zusammenarbeit innerhalb des Teams verhindern und auf der Basis kann man an der Umgebung gearbeitet werden, die Konzentration und Fokussierung ermöglicht, die Verantwortungsübernahme fördert und den Fokus des Erfolgs auf das Produkt und nicht die Effizienz eines Teams legen.

Natürlich kann man die Performance eines Teams betrachten. Für die Veränderung von Effizenz eines Teams sollten weitere Faktoren betrachtet werden, die Esther Derby in ihrem Beitrag Assessing Team Improvement gut auf den Punkt bringt:

Stabilität und Zusammensetzung: Teams sollten so (interdisziplinär) zusammengesetzt sein, dass sie ihre Aufgaben unabhängig fertig bekommen können. Die Veränderungen der Mitarbeiter der Teams sollten sich im Rahmen halten. Wie sehr verändert sich also die Team-Stabilität?

Wie Arbeit ins Team gelangt: Der Umfang und Inhalt der Arbeit sollte für den definierten Zeitrahmen und die Aufstellung des Teams passend sein. Das Team sollte sich die Aufgaben selbst formulieren und die Arbeit eigenständig organisieren können. Die Aufgaben sollten dabei einen deutlichen Kundenfokus haben und ausreichend klar formuliert sein. Wie kommt die Arbeit ins Team und welchen Fokus hat sie?

Abhängigkeiten zwischen Teams: Abhängigkeiten zwischen unterschiedlichen Teams sollten möglichst nicht vorhanden oder so gering wie möglich sein. Wie sehr muss sich ein Team mit anderen Teams abstimmen?

Produkt-Vision und Team-Mission: Es sollte eine klar formulierte (Produkt-)Vision geben, in die alle Aufgaben des Teams klar einzahlen. Das Team braucht zudem einen klaren Auftrag, der in die Vision einzahlt. Wie gut kann das Team Vision und Mission wiedergeben und berücksichtigen?

Passende Planung: Die geplanten Aufgaben müssen einen Umfang haben, der vom Team bewältigt werden kann. Schafft das Team die geplanten Aufgaben zuverlässig?

Fazit

Die Performance von Teams ist wichtig und lässt sich verbessern. Dafür reicht der Blick auf das Team alleine nicht aus. Dinge zu messen ist ein wesentlicher Bestandteil agiler Methoden, aber nicht alles lässt sich messen bzw. nicht jede Messung erzeugt für sich eine nachhaltig verwertbare Information. Die alleinige Messung der vermeintlichen Effizienz von Teams mittels einer durch Storypoints gemessenen Velocity der gelieferten Features allein erzeugt keinen verlässlichen Wert.

(Das verwendete Bild ist von Dirk Vorderstraße – vielen Dank!)

8 Comments

Leave a Comment
  1. Hi Julian,

    zurück zum Ausgangspunkt: ich bin mir halt nicht sicher, ob die Messung der Performance eines Teams (und damit der Effizienz und deren Veränderung) in Zahlen messen lässt bzw. ob diese Zahlen einen wirklichen Wert haben. Spannender finde ich da den Vorschlag von Esther Derby. Ob es Team-Vision und Team-Mission gibt und wie sie heißt, das lässt sich beispielsweise nicht wirklich messen.

    Ob eine Fußballmannschaft effizient ist oder sich verbessert, wird doch an den tatsächlichen Ergebnissen gemessen – also müsste man sich anschauen, wie erfolgreich ein Gesamt-Entwicklungsteam ist – wie gut das Ergebnis dabei aber ist, ist in unserer komplexen Welt aber lange nicht mehr nur abhängig vom Team, sondern zum Beispiel vom richtigen Zeitpunkt, um etwas an den Markt zu bringen.

    Spontane Idee: Das Team ist ja für die Auslieferung in definierter Qualität zuständig. Also könnte man vielleicht besser messen, wie viel Zeit ein Team braucht um etwas zum Kunden auszuliefern und wie viele Bugs es gibt und wenn diese Werte gut sind, gut bleiben oder sich verbessern, wäre das eine Aussage über die Effizienz des Teams?

    Viele Grüße
    Daniel

    1. Hi Daniel,

      am Ende hängt eine mögliche Messung der Performance davon ab, was das Team erreichen will.

      Wenn der Fokus auf Qualität liegt, ergibt eine Messung der Bug-Anzahl auf jeden Fall Sinn.
      Wenn der Fokus auf der Lieferung eines definierten Umfangs liegt, dann kann man dafür die durchschnittliche Anzahl der erledigten Stories messen.

      Unabhängig davon was im Endeffekt gemessen wird, meine ich, dass eine Messung immer individuell für jede Team-/Projekt-Konstellation ist. Die gemessenen Werte sind also nur im jeweiligen Kontext relevant und nicht 1:1 übertragbar.

      Schlussendlich soll eine Messung der Performance/Effizienz nur einen Indikator geben, ob das Team bis zum Zeitpunkt X, Ergebnis Y in Qualität Z liefern kann oder nicht. Dafür kann man eine messbare Meta-Angabe entwickeln, muss man aber nicht unbedingt. 🙂

      Viele Grüße,
      Julian

  2. Hi Daniel,

    vielen Dank für einen guten Artikel 🙂

    Ich stimme Dir zu, dass sich die Velocity sich nicht für eine Messung der Team-Effizienz eignet. Schon allein deswegen, da es sich um eine relative Schätzgröße handelt, die sich von Mal zu Mal ändern kann. Dadurch könnte ein Team seine Effizienz “steigern”, indem einfach die Schätzungen höher ausfallen.

    Meiner Ansicht nach ist der erzeugte Wert die Grundlage einer Effizienzmessung. Ich betrachte Effizienz als das Verhältnis von erzeugtem Wert zur eingesetzten Arbeit. Bei gleichbleibendem Zeiteinsatz (z.B. in einem Sprint) findet eine Steigerung der Effizienz nur dann statt, wenn ein höherer Wert als vorher erzeugt wird.

    Wie der erzeugte Wert gemessen wird, steht dann wieder auf einem anderen Blatt 😉

    Viele Grüße,
    Julian

    1. Hallo Julian,

      vielen Dank für deinen Beitrag, den ich gerne so unterschreibe. Zwei Fragen finde ich dann spannend:

      1. Wie würdest du den Wert messen?
      2. Ist bei einem nach Wert priorisiertem Vorgehen eine kontinuierliche Steigerung des Werts überhaupt möglich?

      Wenn ich also im ersten Sprint den höchsten Wert erzeuge (und so sollte es rein theoretisch ja sein), kann ich im zweiten Sprint keinen höheren Wert erzeugen, oder?

      1. Hallo Daniel,

        die Messung des erzeugten Werts ist, meiner Ansicht nach, individuell von Projekt zu Projekt unterschiedlich. Wichtig ist, dass sich die Kriterien anhand derer der Wert einer Story bemessen wird, sich im Projektverlauf nicht ändern bzw. nur so ändern, dass ein Vergleich vorher/nachher möglich ist.

        Ein mögliches Beispiel für die Definition des Werts einer Story wäre Folgendes:
        – Der Product Owner trifft bei jeder Story eine Einschätzung über den Wert der Story für den Endkunden und eine Einschätzung über den Wert für die Stakeholder in der Einordnung (niedrig/mittel/hoch). Beide Werte sind gleich gewichtet.
        – Die Einordnung wird dann auf ein Zahlenschema übertragen, z.B. niedrig = 1, mittel = 3, hoch = 5
        – Die Storypoints definieren die technische Komplexität der Story
        – Für die Ermittlung des Werts wird dann eine Formel definiert: (Wert für Endkunden + Wert für Stakeholder)/Storypoints
        – Der resultierende Wert wird als Maß für den Wert der Story verwendet
        – Bei diesem Beispiel wird Stories mit hohem Wert für Endkunden und Stakeholder und geringer technischer Komplexität ein insgesamt höherer Wert zugesprochen als Stories mit hohem Wert für Endkunden und Stakeholder und hoher technischer Komplexität

        Um auf Deine zweite Frage einzugehen: Bei einem rein nach Wert priorisierten Vorgehen wäre keine kontinuierliche Steigerung des Werts möglich. In meinem ursprünglichen Kommentar ging es aber auch nicht um eine kontinuierliche Steigerung des erzeugten Werts, sondern um eine kontinuierliche Steigerung der Effizienz (Erzeugter Wert/eingesetzte Zeit). Auch hierbei stoße ich natürlich an Grenzen, weil der erzeugbare Wert pro Sprint theoretisch immer kleiner wird und für eine Steigerung der Effizienz immer weniger Zeit eingesetzt werden dürfte. Ich meine die Zielsetzung besteht darin pro Sprint den höchstmöglichen Wert zu erzeugen.
        Mit einer gleichbleibend hohen Effizienz kann man auch mal zufrieden sein 😉

        Meiner bisherigen Erfahrung nach ist jedoch ein rein nach Wert priorisiertes Vorgehen in der Theorie zwar gewünscht, aber in der Praxis selten machbar (z.B. weil rechtlich relevante Themen mit geringem Wert für den Endnutzer umgesetzt werden müssen).

        Wenn Du entsprechende Beispiele hast, wo das möglich war, lasse ich mich gerne vom Gegenteil überzeugen. 🙂

        Viele Grüße,
        Julian

        1. Hallo Julian,

          vielen Dank für dein umfassendes Feedback. Die Idee der Errechnung von Effizienz klingt erst mal charmant und die Idee, dabei Kunde und Stakeholder zu berücksichtigen und einfache Zahlen zu summieren könnte helfen bei Entscheidungen.

          In unserer Diskussion könnte man Effizienz dann mit Wirtschaftlichkeit gleichsetzen, oder? Die Wirtschaftlichkeit kann man errechnen, indem man den “Ertrag” durch den Aufwand teilt – bei dir wäre das der in Zahlen formulierten durch den PO angenommene Wert geteilt durch die technische Komplexität von Aufgaben.

          Bei dem Wert gehe ich mit, ich würde aber entsprechend der Berechnung von Wirtschaftlichkeit nicht die “technische Komplexität”, sondern den Aufwand betrachten – siehe dazu auch meinen neuen Blog-Beitrag “Schätzen nach Aufwand”.

          Wenn wir aber mit den Annahmen vom Product Owner in Sachen “Wert” und mit Annahmen des Teams in Sachen “Aufwand” arbeiten, dann können wir damit bestenfalls eine Effizienz annehmen und sie nicht bestimmen. Ob ein Team effizient gearbeitet hat, kann man bei obiger Wirtschaftlichkeitsbetrachtung nur retrospektiv betrachten und dazu bräuchte man den tatsächlich benötigten Aufwand und den tatsächlichen Wert (zum Beispiel Klick- oder Bounce-Rates im Online-Umfeld oder tatsächliche Verkäufe oder Ähnliches).

          Welchen Wert hat die Betrachtung der gemessenen Entwicklung eines “angenommenen Werts/Ertrags” bei Betrachtung des zur Erreichung benötigten “angenommenen Aufwands”? Liefert das wirklich Aufschluss über die Effizienz eines Teams, kann man das so messen?

          Ich glaube, dass man die Effizienz eines Teams ganz anders betrachten sollte. Bei einem Software-Entwicklungsteam könnte man die Anzahl der neu aufkommenden und gelösten Bugs betrachten oder die Durchlaufzeit von Aufgaben, die durchschnittliche Größe von Themen oder Ähnliches. Was könnte es da noch geben und was hältst du von dieser Idee?

          Viele Grüße
          Daniel

          Ergänzung: Da wir uns nicht im Luftleeren Raum bewegen, gibt es meistens Dinge, die auf den ersten Blick keinen Nutzen für den Kunden bringen und trotzdem gemacht werden müssen – da stimme ich dir zu. Diese Dinge solle man aber zumindest kritisch hinterfragen und den Aufwand dafür so weit es geht reduzieren.

          1. Hi Daniel,

            langsam wird die Diskussion komplex 😉

            Du hast recht damit, dass sich die Formeln für Wirtschaftlichkeit und Effizienz stark gleichen. Der Unterschied besteht für mich darin, dass Wirtschaftlichkeit mit konkreteren Werten arbeitet.

            Ich glaube ich muss nochmal “sauber” zwischen Effizienz und Story-Wert trennen.

            Eine Effizienz-Betrachtung findet für mich eigentlich völlig selbstverständlich retrospektiv statt. Da ich ohnehin erst im Nachhinein den im Sprint erzeugten Wert messen kann. Der von mir in den vorherigen Kommentaren genannte Story-Wert dient eher zur Entscheidung welche Stories im kommenden Sprint bearbeitet werden. Mit dem möglichen Umfang eines Sprints hilft leider weder die Effizienz-Messung noch die Einschätzung des Story-Werts weiter. Da muss man sich weiterhin auf Story-Points verlassen. 😉

            Beim Wert einer Story würde ich auch lieber mit konkreten Werten arbeiten, aber das ist leider, meiner Erfahrung nach, eine Variable, die sich nur in seltenen Fällen konkret ausdrücken lässt. Gerade bei komplexen IT-Projekten gibt es so viele unterschiedliche Komponenten und Aspekte, dass sich ein einheitliches Maß für Wert kaum definieren lässt.

            Bei der Berechnung des angenommenen Werts einer Story kann man natürlich auch mit einem geschätzten Aufwand arbeiten. Deine Idee ist dahingehend sogar besser, da man den tatsächlichen Aufwand im Nachhinein in der Regel besser messen bzw. in Zahlen ausdrücken kann, als die tatsächliche Komplexität. Man könnte damit auch einen Abgleich machen: Angenommener Wert einer Story vs. tatsächlicher retrospektiver Wert. Werde ich mal in meinem Controlling berücksichtigen 🙂

            Andere Möglichkeiten zur Effizienz-Messung gibt es natürlich Einige. Ich glaube allerdings, dass es bei Messung der Effizienz weniger auf einen “konkreten” Effizienz-Wert ankommt, als auf das Delta zwischen den Messungen. So lange meine genutzten Variablen gleich bleiben, kann ich über die Differenz eine etwaige Verbesserung/Verschlechterung der Effizienz feststellen.
            Woran man die Effizienz schlussendlich festmacht, kann man dann je nach Projektumfeld entscheiden.

            Viele Grüße,
            Julian

Schreibe einen Kommentar zu Julian Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert