Kennzahlen für Scrum-Teams

In den meisten Firmen kommt auf Scrum Mentor*innen dieselbe Frage zu: wie gut ist Dein Team? Und wie messen wir das? In diesem Artikel beschreibe ich, warum diese Frage völlig nachvollziehbar finde, aber keine Details zu den Teaminterna liefere, sondern auf die Wertschöpfung für das Unternehmen fokussiere. In diesem Zusammenhang stelle ich die KPIs vor, die ich für diese Betrachtung nutze.

Wertschöpfung und Management

In einer Firma ist das Management für die Abläufe und Organisation der Arbeit zuständig. Dies kann bei kleineren Firmen noch unkompliziert sein, bei größeren aber zu einer echten Herausforderung werden.

Hybride Organisationen

In den meisten Firmen werden wir sowohl Projekte als auch Scrum-Teams vorfinden.

In einer projektorientierten Welt gehört das Management von Abteilungen zu den Standardaufgaben der Führungskräfte. Neben dem Tagesgeschäft gibt es Projekte, die meist durch Projektleiter*innen begleitet werden. Die Arbeit von Abteilungen wird über KPIs (Key Performance Indicators) gemessen, Anpassungen führen Abteilungsleiter*innen durch. Dasselbe gilt auch für die Verteilung von Arbeit, die in einer Abteilung anfällt.

Bei Scrum schaut das anders aus: die fachliche Priorisierung übernehmen Product Owner*innen, die Umsetzung erfolgt durch das Scrum Team. Es gibt Scrum Mentor*innen, die das Team bei seiner Arbeit unterstützen und bei komplexeren Störungen (auch „Impediments“ genannt) aktiv werden.

Die besondere Rolle der Scrum Mentor*innen erlaubt eine große Nähe zum Team. Auf diese Weise können sie trotz hoher Dynamik auf das Team einwirken. Dies ist für disziplinarische Führungskräfte nicht möglich, da sie durch ihre Position stets einen hohen Einfluss auf Diskussionen haben.

Dieses Setup hat für klassische Führungskräfte den Nachteil, dass sie die Innenperspektive des Scrum-Teams nicht kennen können. Scrum Mentor*innen haben deshalb die Aufgabe, für sie eine sinnvolle Perspektive zu schaffen. Für diese Aufgabe ist es wichtig, die Innenperspektive des Teams auszublenden. Das Scrum-Team verhält sich also wie eine unteilbare Einheit (Holon-Perspektive1).

Die KPIs, die ich hier betrachte, zeigen daher immer die Außenperspektive eines Scrum-Teams.

Abhängigkeiten zwischen Projekten und Scrum-Teams

Abhängigkeiten bedeuten Abstimmungsaufwand, deshalb sind die ersten relevanten KPIs die Indikatoren für diese Aufwände. Es geht also um einen Überblick über die Interdependenzen2 agiler Teams (vgl. folgende Grafik).

Ich konnte in vielen Firmen hybride Ansätze zur Entwicklung von Software und Hardware beobachten. Das Beispiel zeigt eine Konstellation, in der verschiedene Scrum-Teams voneinander abhängig sind (grüne Pfeile). Dies entspricht nicht dem Ideal von Scrum-Teams, funktioniert aber in vielen Firmen, um Komplexität zu reduzieren. Die Leistungen der Scrum-Teams werden von Projekten in den Teams gneutzt (orange Pfeile). Die rote Umrandungen markieren einen typischen Konflikt in Firmen: ein Projekt hat Probleme zu liefern. Das Projektmanagement kommuniziert, dass das Plattform-Team (ein Scrum-Team) zu lange für die Auslieferung ihrer Komponenten benötigt.

Die Anzahl der operativen Einheiten (abgekürzt NOU, engl. number of operational units) – also andere Scrum-Teams und Projekte, mit dem ein Team in Kontakt steht – ist die erste KPI. Jede Abhängigkeit bedeutet Abstimmung, Koordination und Arbeitsaufwände. Je höher die Abhängigkeiten, desto höher ist der Abstimmungsaufwand.

Ebenso relevant ist die Zahl von Stakeholder*innen (abgekürzt NoS, engl. number of stakeholders), die mit Anforderungen auf das Team zukommen und damit die Bearbeitungszeit und -reihenfolge der einzelnen Aufgaben beeinflussen.

Die Durchlaufzeit (englisch „throughput“) ist die Zeit vom Auftragseingang bis zur Fertigstellung der Aufgabe. Die Durchlaufzeit ist sehr stark von der NOU und NoS abhängig.

Die letzte KPI ist sog. Liegezeit (englisch „idle time“): die Zeit vom Auftragseingang bis zum konkreten Beginn der Bearbeitung.

KPIs nutzen

Ziel jeder Organisation ist es, ihre Aufgaben so gut und schnell wie möglich zu erledigen. Damit ist die Durchlaufzeit die wichtigste KPI. Wichtig: die Erfassung dieser Zahl ist immer relevant. Jede Veränderung, die zur Anpassung anderer KPIs führt, sollte sich auch bei der Durchlaufzeit bemerkbar machen – im besten Fall, dass diese reduziert wird.

Und so könntendie KPIs im oben gezeigten Beispiel aussehen. Zunächst ist die Beschwerde damit objektiv belegbar, da die Throughput in der Tat sehr hoch ist. Auffällig ist die Idle Time, die durchschnittlich 5 Tage beträgt, und damit den Hauptanteil des Throughputs ausmachen. Die Ursachen für diese lange Liegezeit wird im Text im Detail diskutiert.

Projekte und Scrum

Der Unterschied zwischen Scrum und Projekten führt zu gewissen Problemen bei der Zusammenarbeit. Ein agiles Team geht davon aus, dass unvorhergesehene Herausforderungen auftreten. Veränderungen sind sozusagen eingebaut. In der Regel muss aber das Projektmanagement Veränderungen dokumentieren und in Projektpläne einarbeiten. Je mehr Veränderungen auftreten, desto höher ist die Wahrscheinlichkeit für Projektverzögerungen.

Projekte sollten deshalb als Stakeholder (siehe NoS) und nicht als operative Partner (siehe NOU) in Erscheinung treten. Insgesamt sollten Scrum-Teams nur wenig bis keine Projekte als Stakeholder oder operative Partner haben, um ihre volle Effektivität entfalten zu können.

Welche Abhängigkeiten haben die Scrum-Teams untereinander?

Scrum-Teams sind umso effektiver, je autonomer sie arbeiten können. Eine erhöhte Effektivität eines Scrum-Teams sollte sich in der Verringerung der Durchlaufzeit bemerkbar machen.

Die erste Möglichkeit ist, die Anzahl der externen Zuarbeiten zu reduzieren. Dies ist der Gedanke der crossfunktionalen Teams. Spezialist*innen, die regelmäßig Arbeiten zuliefern, sollten ins Team integriert werden. Je höher die NOU, desto wahrscheinlicher ist es, dass eine Integration Sinn macht.

Natürlich ist eine Integration nur begrenzt möglich. Denn der Kommunikationsaufwand im Scrum-Team steigt exponenziell mit der Zahl seiner Mitglieder. Für solche Fälle müssen Teams geschaffen werden, die in ihrer Kommunikation und ihrem Aufgabengebiet so weit wie möglich voneinander getrennt werden können3.

Autonomie pur?

Auch wenn es schön wäre, die Autonomie von Teams zu maximieren (was bedeutete, dass NOU = 0 wäre), der Weg dorthin ist ebenso komplex wie die Arbeit in den Teams selbst.

Und so gibt es Teams, die an sog. Querschnittsfunktionen arbeiten (z.B. IAM, Logging, Operations, Monitoring, etc.). Diese Teams müssen die Liege- und Durchlaufzeit optimieren, um dauerhaft operabel zu bleiben. Teams, die schnell auf Anforderungen ihrer Stakeholder reagieren können, zeichnen sich durch einen niedrigen Throughput und äußerst niedrige Liegezeiten aus. Dies ist nur machbar, wenn diese Teams an möglichst wenig Themengebieten und Applikationen (sog. Domänen) arbeiten. Je weniger Domänen ein Team hat, desto geringer wird auch die Anzahl der Stakeholder (NoS) sein.

Teams, deren NOU und NoS hoch sind, arbeiten häufig in zentralen und hochkomplexen Domänen. Neben der operativen Herausforderung müssen diese Teams viel Zeit in die Verwaltung der Abhängigkeiten investieren. Der Abstimmungsaufwand wird sich in diesen Fällen negativ auf den Throughput auswirken, wenn unterschiedliche Stakeholder in Konkurrenz zueinander stehen. Dies macht sich darin bemerkbar, dass Tickets recht lange im Product Backlog bleiben (Liegezeit), bis sie in den Sprint genommen werden.

Mit Hilfe der Durchlaufzeit, der Liegezeit, der NOU und der NoS ergeben sich plausible Gründe, die den Aufbau neuer Teams rechtfertigt und den Erfolg der Maßnahmen meßbar macht.

Die Rolle des Managements

KPIs sind nur nützlich, wenn diese regelmäßig beobachtet und durch die Organisation bewertet werden. Dies ist die Aufgabe des Managements, u.a. auch deshalb, weil Veränderungen der Teams notwendig sein können.

Die Führung von Scrum-Teams ist eine komplexe Aufgabe. Führungskräfte und Scrum Mentor*innen sollten deshalb in den regelmäßigen Austausch gehen, um Innen- und Außenperspektive in Einklang zu bringen. KPIs helfen dabei, Eindrücke zu untermauern oder zu widerlegen. Aber nicht jede Veränderung oder Schwankung in den KPIs ist es wert, Veränderungen vorzunehmen.

Zusammenfassung

Dieser Artikel behandelt Kennzahlen für Scrum-Teams. Da diese in einem dynamischen Umfeld arbeiten, macht es keinen Sinn, die Innenperspektive zu betrachten. Stattdessen gibt es gute KPIs, die für die Bewertung des Teamnutzens relevant sind:

FragenIndizien/Messungen
Anzahl der operativen Einheiten (number of operational units = NOU)Je höher diese Zahl, desto höher sind die möglichen Wartezeiten bis zur Erfüllung einer Aufgabe
Zahl von Stakeholder*innen (NoS)Anzahl der Personen, die mit Anforderungen auf ein Team zukommen
Liegezeit (idle time)Wie lange ist die Zeit zwischen Bekanntmachung und konkrete Bearbeitung einer Aufgabe?
Durchlaufzeit (throughput)Die Zeit vom Auftragseingang bis zur Fertigstellung der Aufgabe

KPIs funktionieren nicht generisch. Es ist wichtig, dass KPIs nicht nur erhoben, sondern auch regelmäßig vom Managment und Scrum Mentor*innen ausgewertet werden. Denn auch die Anpassung von Teams ist ein iterativer Prozess und hängt von vielen internen wie externen Faktoren ab. Zu agilen Teams gehört damit auch ein agiles Management.

  1. Ein Holon ist ein Konzept, das vom Philosophen und Schriftsteller Arthur Koestler in den 1960er-Jahren entwickelt wurde. Es beschreibt eine Einheit, die sowohl als eigenständiges Ganzes existiert als auch als Teil eines größeren Systems fungiert. Der Begriff kombiniert die griechischen Worte „holos“ (Ganzes) und das Suffix „-on“ (Teil von etwas Größerem) und wird genutzt, um Strukturen zu beschreiben, die in Hierarchien von „Ganzen-Teilen“ organisiert sind. ↩︎
  2. Interdependenz beschreibt die wechselseitige Abhängigkeit zwischen zwei Einheiten. Es geht hierbei nicht nur um die Frage, wer bei wem was anfragt, sondern auch darum, wie gut die Beziehung zwischen den Einheiten ist und wie mit Störungen, Missverständnissen und anderen Herausforderungen umgegangen wird. Es geht also um die Gesamtheit aller technischen und sozialen Abhängigkeiten. ↩︎
  3. Im Buch und der zugehörigen Site zu Team Topologies gibt es eine ausführliche Abhandlung darüber, in welcher Form Teamschnitte gemacht werden können. ↩︎