Agile Metriken – Mythos oder Wahrheit?

Große Konzerne genauso wie kleine Unternehmen nutzen Scrum und Co. für ihre Projekte – diese reichen von kleinen Vorhaben für ein Team von drei Leuten bis hin zu weit verzweigten Produktfamilien, die mehrere Teams an verschiedenen Standorten parallel entwickeln. Mit welchen Metriken kann man in agilen Projekten Erfolg messen und vergleichen, und was sind diese Metriken wirklich wert?

In Pocket speichern vorlesen Druckansicht
Lesezeit: 18 Min.
Von
  • Peter Götz
  • Uwe M. Schirmer
Inhaltsverzeichnis

Agile Methoden sind aus den Firmen und Projekten dieser Welt nicht mehr wegzudenken. Auch große Konzerne nutzen Scrum und Co. für ihre Projekte – diese reichen von kleinen Vorhaben für ein Team von drei Leuten bis hin zu weit verzweigten Produktfamilien, die mehrere Teams an verschiedenen Standorten parallel entwickeln. Mit welchen Metriken kann man in agilen Projekten Erfolg messen und vergleichen, und was sind diese Metriken wirklich wert?

Mit der immer noch zunehmenden Verbreitung agiler Methoden wie Scrum oder Kanban wächst in vielen Unternehmen der Wunsch, die Leistungen von Teams zu messen und zu vergleichen. Das ist an sich nicht Schlechtes. Ohne Vergleiche kann man den Fokus kaum auf die richtigen Prozesse und Tools setzen, Optimierungsbedarf erkennen oder Verbesserungen umsetzen und bewerten. Zu diesem Zweck gibt es eine Vielzahl Metriken.

Nach der Erfahrung der Autoren kommt es jedoch leider häufig vor, dass Metriken eingesetzt werden, "weil man das so macht", ohne vorher darüber nachzudenken, ob die Metrik im eigenen Kontext wirklich Sinn ergibt. Ein Beispiel hierfür ist die oft anzutreffende Unart, Teams anhand der "gelieferten" Story Points miteinander zu vergleichen, ohne zu berücksichtigen, dass ein Story Point keine feste Größe ist, sondern höchst individuell durch das Team vergeben und bewertet wird. Durch dieses sinnlose Messen und Vergleichen werden wichtige Mechanismen agiler Vorgehensweisen ausgehebelt, und es entsteht ein Klima, in dem Teams versuchen, die gewünschten Messwerte zu liefern und nicht mehr das beste Produkt.

Der Artikel stellt ein paar Metriken vor und gibt eine Bewertung ihrer Wirksamkeit und Sinnhaftigkeit. Dabei leistet er keine vollständige und abschließende Übersicht, vielmehr wollen die Autoren ein paar Metriken etwas genauer unter die Lupe nehmen. Die Beschreibung und Bewertung der einzelnen Metriken berücksichtigt folgende Frage:

  • Was wird erfasst?
  • Wie wird gemessen?
  • Wann wird gemessen?
  • Wer erfasst die Daten für welche Zielgruppe?

Die Scrum Adherence misst, in welchem Umfang ein Scrum-Team oder eine Organisation die Regeln von Scrum befolgt. Teilweise wird das Befolgen der Regel auch feiner abgestuft, um eine qualitative Aussage treffen zu können. Den Rahmen für die Messung und die Bewertungsgrundlage bilden dabei der von Ken Schwaber und Jeff Sutherland verfasste und stetig weiter entwickelte Scrum Guide, der die Grundlagen von Scrum – die Rollen, Events und Artefakte sowie ihr Zusammenspiel – beschreibt.

Tests zum Erfassen der Scrum Adherence gibt es viele. Der erste bekannte Vertreter war der sogenannte "Nokia Test". Er besteht aus ein paar Fragen, die Bas Vodde bei Nokia Siemens Networks Scrum-Teams stellte. Bekannt wurde der Test in der Version von Sutherland, der ihn als "ScrumButt Test" um eine Bewertungsskala für die einzelnen Fragen erweitert hat. In ihm werden Fragen zu den folgenden Themengebieten gestellt:

  • Iterationen
  • Testing
  • Spezifikationen ermöglichen
  • Product Owner
  • Product Backlog
  • Schätzungen
  • Burndown
  • Disruption
  • Team

Ein weiterer Test, inhaltlich näher am aktuellen Scrum Guide, ist der Scrum Adherence Index von Francesco Lomonaco und Christian Lapointe. Auch hier werden Fragen zur Einhaltung der Scrum-Regeln gestellt, der Test ist jedoch umfangreicher und damit aussagekräftiger als der relativ einfache ScrumButt Test. Geprüft werden jeweils mehrere Fragen zu den folgenden Themen:

  • Events
    Sprint
    Daily
    Sprint Planning
    Sprint Review
    Sprint Retrospective
    Backlog Refinement
  • Rollen
    Product Owner
    Development Team
    Scrum Master
  • Artefakte
    Product Backlog
    Sprint Backlog
    Increment
    Definition of Done

Allen Tests gemein ist, dass es sich um mehr oder weniger einfache Checklisten handelt, die das Scrum-Team ausfüllen muss. Häufig werden sie an markanten Punkten während einer Entwicklung durchgeführt, um zu prüfen, ob ein Team in der eigenen Scrum-Implementierung noch nach den Regeln spielt oder nicht – zum Beispiel beim Wechsel in ein neues Release oder bei übergeordneten Audits zur Bewertung des Vorgehens.

Die Scrum Adherence erfasst häufig das Team selbst, manchmal auch externe Scrum-Coaches, obwohl die ausschließliche Betrachtung von außen mehr als fragwürdig ist. Die Zielgruppen können vielfältig sein. Vom Team, das wissen möchte, in welchen Bereichen es sein eigenes Scrum noch verbessern kann, bis hin zu außenstehenden Stakeholdern, die wissen möchten, wie Scrum innerhalb eines Teams, einer Gruppe von Teams oder der gesamten Organisation gelebt wird.

Abschließend lässt sich sagen, dass die Messung der Scrum Adherence ein einfaches und kostengünstiges Werkzeug ist, um die eigene Implementierung von Scrum zu überprüfen. Mit ihr lassen sich die Bereiche in der Teamarbeit aufzeigen, die sich – mit Blickrichtung auf das Framework – noch verbessern lassen. Sie sollte jedoch nicht überbewertet werden. Die Diskussionen innerhalb eines Teams, die sich aus der Beschäftigung mit seinen Inhalten – etwa im Rahmen einer Retrospektive – ergeben, sind aus Sicht der Autoren wertvoller als die erreichte Punktzahl.