Wie Du mit mehr Fokus die Performance Deines Scrum-Teams steigern kannst

Scrum! Scrum? Naja, so was Ähnliches.

Jeder, der Software entwickelt, macht Scrum. Nein, das stimmt nicht ganz, aber der Siegeszug der agilen Methoden (und damit maßgeblich auch die Verbreitung von Scrum) ist seit vielen Jahren überall spürbar. Spricht man mit Softwareproduktfirmen oder schaut in entsprechende Statistiken, so setzen mehr als zwei Drittel aller Unternehmen heute auf diese agile Methodik als strukturgebendes Rahmenwerk für die Zusammenarbeit ihrer Teams. Eine Einführung in Scrum kann man hier finden.

Aber: Jeder, der Scrum macht, macht es etwas anders. Manche folgen streng den Vorgaben („do it by the book“) und andere sehen die Scrum-Vorgaben eher als Orientierung und bedienen sich der Methodik so wie es eben gerade passt oder nützlich erscheint. Das Spektrum an Scrum-Varianten ist groß und es wächst noch immer stetig.

Fragt man die Manager in Softwareproduktfirmen, so sind (trotz Scrum) bei weitem nicht alle zufrieden. Vielen fehlt Planbarkeit, langfristige strategische Ziele werden aus den Augen verloren, das Pflegen und die Durchführung der Scrum-Events nimmt einigen zu viel Zeit in Anspruch, obwohl genau diese Meetings Fokus und Zeit schaffen sollen. Und anderen dauert schlichtweg alles zu lange. Entwickler sind auch 2023 noch immer eine knappe und teure Ressource. Der Wunsch, mehr aus den Teams herauszuholen, mehr Features zu liefern und so schneller voranzukommen, ist allgegenwärtig. Etwas zu verbessern gibt es schließlich immer – selbst wenn es schon ganz ok läuft. Schauen wir uns an, was das für Scrum Master und Product Owner in ihren täglichen Aufgaben bedeutet.

In diesem Blogartikel erfährst Du…

… warum mit Scrum nicht automatisch an den wichtigsten Themen gearbeitet wird,

… warum Fokus entscheidend für einen gelungenen Scrum-Prozess ist,

und Du erhältst 2 Tipps, um Eure Scrum-Performance mit den richtigen Metriken zu messen.

Warum mit Scrum nicht automatisch an den wichtigsten Themen gearbeitet wird

Wie viel Purpose repräsentiert ein Story Point?

Sehr viele Scrum-Teams messen ihre Team Velocity und schätzen Story Points für ihre Tickets, um die Performance des Teams irgendwie sichtbar zu machen oder Anhaltspunkte zu haben, wenn es darum geht Optimierungspotential zu identifizieren. Gleichzeitig fragen Mitarbeitende zunehmend, was genau ihr Beitrag ist bzw. verlieren die Motivation, wenn unklar ist, wofür sie arbeiten. Der sogenannte „Purpose“ wird immer wichtiger und rückt immer mehr in den Vordergrund. Wirksamkeit ist heute nicht mehr optional, sondern zwingend notwendig.

Doch was haben Team Velocity und Story Points mit Purpose und Wirksamkeit zu tun? Wie kann man Scrum so einsetzen, dass alle möglichst viel auf das Unternehmensziel einzahlen? Wie kann man die tägliche Arbeit eines Produktteams an einer langfristigen Mission ausrichten? Was muss man messen, um wirklichen Fortschritt zu erkennen?

Diese Fragen beschäftigen Scrum Master, Product Owner und Product Manager gleichermaßen. Selbst Entwickler (mit einem sehr technischen Fokus) fragen sich früher oder später welchem Zweck ihre Arbeit dient und was genau ihr Beitrag ist. Doch je weiter die „High-level Mission“ eines Unternehmens und die tägliche Arbeit auseinander liegen, desto schwieriger ist es, diese Brücke zu schlagen. Erfolgreiche Produktfirmen schaffen aber genau das – unter anderem, indem sie viel Bewusstsein für das Thema schaffen und hier Zeit investieren. Je genauer die Mitarbeitenden wissen auf welches Ziel sie hinarbeiten müssen und wie messbarer Fortschritt aussieht, desto größer ist die Wahrscheinlichkeit für den Erfolg eines Softwareprodukts.

Doch wie genau geht das?

Am Anfang jeder Unternehmung steht die Mission

Fortschritt oder Erfolg sind immer eine Definitionssache und liegen im Auge des Betrachters – zumindest, wenn es kein klar definiertes Ziel gibt. Um die Entwicklung eines Unternehmens zu steuern, steht die zentrale Frage „Was wollen wir als Firma erreichen?“ im Mittelpunkt. Dahinter verbirgt sich sogar eine noch wichtigere Frage: „Warum wollen wir genau das erreichen?“ (siehe auch Start with WHY – Simon Sinek).

Die Antwort auf diese Frage ist die Mission eines Unternehmens. Daran soll sich das Handeln der gesamten Organisation ausrichten – von der Geschäftsführung bis zu den Mitarbeitenden in den Teams. Wichtig ist, dass die Mission eines Unternehmens immer „nach außen“ gerichtet ist. Sie muss eine Veränderung der Welt beschreiben. Nach innen gerichtete Mission Statements (z.B.: „Wir wollen Experten für Logistiksoftware sein“) sind schwerer mit Geschäftserfolg in Verbindung zu bringen. Man kann genau dieser Experte für eine Hand voll kleiner Speditionen sein oder Software liefern, die den Güterverkehr ganzer Länder bewältigt. Besser wäre z.B. das Mission Statement „Wir wollen Unternehmen dabei helfen ihre Logistik zu automatisieren“.

Meist sind Mission Statements sehr ambitioniert und oft allgemein. Das liegt in der Natur der Sache, aber macht die Verbindung zur täglichen Arbeit schwerer. Je breiter ein Mission Statement formuliert wird, desto größer ist die Lücke hin zu individuellen Aufgaben.

Schauen wir uns dazu am besten ein (fiktives) Beispiel an: Ulli ist Product Owner. Ulli hat früher auch Software entwickelt, arbeitet aber seit vielen Jahren in der PO-Rolle. Ulli arbeitet für „Have-a-Seat“ – eine Plattform und App zur Vermittlung von autonomen Fahrzeugen. Die Mission von Have-a-Seat ist es, Anbieter von autonomen Taxidiensten mit Fahrgästen zusammen zu bringen und so den Besitz eines eigenen Autos komplett überflüssig zu machen.

Die Gründerin von Have-a-Seat hat eine grüne Stadt im Kopf, in der unzählige Bäume die ehemaligen Parkplätze zurückerobert haben. Fast unbemerkt fahren die autonomen Taxis durch die wenigen verbleibenden Straßen und holen Menschen ab. Abends treffen sich die Taxiflotten zum gemeinsamen Laden am Solarpark außerhalb der Stadt, werden gereinigt und die Minibar im gekühlten Handschuhfach wird mit Snacks und Getränken befüllt.

Ulli kennt diese Geschichte, denn sie wird wie ein Mantra bei Have-a-Seat ständig wiederholt. Die Mission („Städte autofrei und grün machen“) ist allen klar. Wenn Ulli aber vor dem Backlog sitzt und entscheiden muss, was das Team im nächsten Sprint machen soll, hilft das Bild von der grünen Stadt nur bedingt weiter. Auch die Nordsternmetrik, die bei Have-a-Seat „Anzahl der gebuchten Fahrten“ lautet, ist zu weit entfernt von den kleinteiligen Aufgaben mit denen Ulli konfrontiert ist. Trotzdem holt Ulli sich diese Metrik regelmäßig ins Gedächtnis, um die Frage „Warum machen wir das eigentlich gerade?“ zu beantworten.

Strategieframeworks sind das Bindeglied zwischen der Mission und den Scrum-Sprints

Um komplexe Aufgaben zu bewältigen, ist es unabdingbar, das große Ganze in kleinere handhabbare Teile zu zerlegen. Scrum nutzt Sprints, um große Entwicklungsaufgaben in verdaubare Inkremente zu zerlegen. Statt ein großes Ungetüm aus dem Boden zu stampfen, soll Stück für Stück funktionierende Software entstehen, die in jedem Sprint ein kleines Stück wächst und gedeiht. Innerhalb jedes Sprints zeigt die Team Velocity, wie viel ein Team schaffen kann. Man hat also einen Indikator dafür, wie groß das Stück ist, was pro Sprint zum Softwareprodukt dazukommt. So weit, so gut.

Die Herausforderung, mit der aber alle Beteiligten konfrontiert sind, ist die Auswahl der richtigen Themen für den nächsten Sprint. An welcher Stelle soll angebaut werden? Welche Features sind wichtig? Welche nicht?

Hier hört Scrum oft auf und andere Methoden bzw. Frameworks kommen ins Spiel, um die Verbindung zu langfristigeren Zielen herzustellen. Beispielsweise werden Strategie-Frameworks wie „Objectives and Key Results“ (OKRs) genutzt, um eine Brücke zu den High-level Zielen herzustellen. Diese werden typischerweise in Intervallen von 3 bis 12 Monaten festgelegt.

Springen wir nochmal in unsere Ulli-Story: Auch bei „Have-a-Seat” gibt es OKRs. Beispielsweise könnte es folgendes Key Result geben: „Wir wollen im Q1 2024 in den 10 größten deutschen Städten 100.000 Fahrten vermitteln”. Das ist schon konkreter als „Städte autofrei und grün machen“, aber noch immer relativ weit weg von Ullis täglichen Themen. Selbst ein Sprintziel lässt daraus nicht einfach ableiten. Ob die Tickets für den nächsten Sprint darauf einzahlen, ist nicht einfach zu sagen. Was brauchen wir also, um sicherzustellen, dass Ullis Scrum-Team an Dingen arbeitet, die Have-a-Seat erfolgreich machen?

Um die große Lücke zwischen kleinteiligen Entwicklungsaufgaben und einer langfristigen Mission zu überbrücken, braucht es mehr Stützpfeiler. Oder anders ausgedrückt, wir müssen die einzelnen Ziele (oder Teilergebnisse) weiter zerlegen. Wir müssen die Frage beantworten, was erreicht werden muss, um 100.000 Fahrten in den 10 größten deutschen Städten zu vermitteln.

Mögliche (fiktive) Teilziele könnten hier sein:

• Steigerung der Anzahl angemeldeter Nutzer in den 10 Städten auf insgesamt 50.000
• Reduzierung der Antwortzeit bei der Suche nach einem verfügbaren Fahrzeug auf unter 3 Sekunden
• Reduzierung der Zeit von der Anforderung eines Taxis bis zum Eintreffen auf unter 10 Minuten
• Reduzierung der Fahrten, bei denen ein Problem auftritt auf unter 1% (z.B. Batterieladung reicht nicht bis zum Zielort aus)
• Reduzierung der Anfragen beim Kundensupport auf unter 1 pro 1.000 angemeldete Benutzer pro Tag
• Erhöhung der Kundenzufriedenheit in den 10 Städten auf 90%

Hier handelt es sich bei allen Teilzielen um Änderungen an Metriken, die direkt das Verhalten von Nutzern widerspiegeln. Positive Änderungen an diesen Metriken stehen in direktem Zusammenhang mit höherem Geschäftserfolg. Wenn Ullis Team sich daran orientiert, könnten sie sicher sein, dass das Team an den richtigen Themen arbeitet.

Die Mission muss über mehrere Ebenen zerlegt werden

In der Realität müssen solche Teilziele meist noch weiter zerlegt werden. Es braucht eine hierarchische Aufteilung, die auf der feinsten Ebene z.B. aus Sprintzielen bestehen kann. So kommt es zwangsläufig dazu, dass eine gewünschte Änderung an einer Business-Metrik in konkrete Aufgaben zerlegt werden muss. Beispielsweise könnte Ulli den Punkt „Reduzierung der Antwortzeit bei der Suche nach einem verfügbaren Fahrzeug auf unter 3 Sekunden“ in „Erstellung eines skalierbaren Services für die Fahrzeugsuche“ und „Durchführung von Performance-Tests für die Fahrzeugsuche“ aufteilen.

Auf welcher Hierarchieebene der Übergang von gewünschten Ergebnissen (z.B. Key Results) zu Aufgaben erfolgt, ist hier nicht entscheidend. Wichtig ist, dass es von jeder Aufgabe einen klaren Pfad „hinauf“ zur Unternehmensmission gibt. Es entsteht eine Nachverfolgbarkeit: Von „Woran arbeite ich gerade?“ hin zu „Warum arbeite ich gerade daran?“.

Sind wir endlich da?

Bei der Zerlegung der Unternehmensmission in kleine handhabbare Häppchen haben wir versucht Teilziele zu definieren, die auf Metriken basieren. Bei der Auswahl der Metriken haben wir uns darauf konzentriert, Metriken zu wählen, die den Grad der Veränderung an der Welt ausdrücken. Das war Absicht, um sicherzustellen, dass das Unternehmen wirksam ist. Aber wie stehen diese Metriken im Verhältnis zu den üblichen Scrum Metriken wie zum Beispiel Team Velocity und Story Points?

Während Business-Metriken direkt den Erfolg des Unternehmens adressieren (z.B. Anzahl von Nutzern, Anzahl von Fahrten, konsumierte Snacks aus der Minibar), spiegeln Team Velocity bzw. abgearbeitete Story Points „nur“ die Abarbeitungsgeschwindigkeit eines Teams wider. Arbeitet ein Team an Themen, die aktuell keinen oder nur einen kleinen Einfluss auf die Mission haben, so nützt auch eine hohe Geschwindigkeit nichts („if you dig a hole and it's in the wrong place, digging it deeper isn't going to help“).

Natürlich ist es auch nicht ideal, wenn ein Team sehr langsam in die richtige Richtung läuft. In diesem Fall braucht es zwar sehr lange bis es ankommt, aber zumindest ist die Arbeit an der richtigen Stelle investiert. Man kann die Performance von Scrum Teams also primär dadurch verbessern, dass immer für alle sichtbar gemacht wird, welche Themen aktuell wichtig sind und wie ihre Arbeit auf genau diese Themen einzahlt. Die oben genannte Hierarchie von Teilzielen ist eine Möglichkeit das zu erreichen.

Ohne eine Orientierung hin zur Mission des Unternehmens sind die Metriken Team Velocity oder abgearbeitete Story Points wenig aussagekräftig. Sie sind zwar einfach zu erfassen und auszuwerten, aber am Ende zählt für den Erfolg eines Softwareprodukts, wie erfolgreich es in Bezug auf die Nutzer bzw. Kunden ist. Darum sind kundenorientierte Metriken so viel relevanter. Scrum-Teams müssen sich zwangsläufig darauf konzentrieren und auch ihren Erfolg daran messen.

Sehr beliebt ist auch die Erfassung von Prozess-Metriken. So ist es beispielsweise sehr verlockend auszuwerten, wie gut die Schätzungen der Teams sind (egal ob in Story Points oder in Tagen). Auch hier gilt: Bessere Schätzungen bringen ein Unternehmen nicht schneller vorwärts. Sie erhöhen zwar die Planbarkeit, aber bei Softwareprodukten spielt die Planbarkeit oft eine untergeordnete Rolle (im Gegensatz zu Softwareprojekten).

Warum Fokus entscheidend für einen gelungenen Scrum-Prozess ist

Ulli hat aber noch ein ganz anderes Problem. Die Hierarchie der Ziele von Have-a-Seat ist ziemlich groß. Für jedes komplexe Produkt entsteht zwangsläufig eine große Menge von Teilzielen und Aufgaben. Ulli und das Team müssen also entscheiden, was zuerst bearbeitet wird. Typischerweise gibt es aber nicht genau ein wichtiges Thema, sondern sehr viele und im schlimmsten Fall ist alles wichtig.

Doch egal wie viele Prioritätskonflikte es gibt, Kontextwechsel sind immer teuer. Je mehr Themen ein Team parallel bearbeiten muss, desto mehr sinkt die Effizienz. Das war schon eine Ursprungsmotivation von Scrum. Teams sollten in die Lage versetzt werden, innerhalb der Sprints in Ruhe an einem Thema zu arbeiten. Danach (zum Sprintwechsel) darf der Product Owner gerne ein neues Thema einbringen, aber nicht dreimal am Tag. Fokus ist sogar als einer der zentralen Scrum-Werte definiert.

Fokus ist also eine weitere wichtige Metrik für Scrum-Teams. Neben dem Arbeiten an den wichtigen Themen (z.B. anhand ausgewählter hierarchischer Teilziele) ist die Reduzierung auf möglichst wenige parallele Themen essenziell. Das Festlegen eines Sprint-Ziels geht genau in diese Richtung und verhindert, dass Nebenbaustellen aufgemacht werden.

Um diesen Fokus zu garantieren, ist es wichtig, auch die regelmäßigen Meetings, die die Scrum-Methodik mit sich bringt, auf den Prüfstand zu stellen: Nutzen wir unser Daily, um wichtige Informationen auszutauschen und das Aufgaben-Alignment zu überprüfen oder ist es der Ort, an dem heimlich neue Seitentickets eingeschoben und kommuniziert werden? Starten wir das Sprint-Planning damit, uns die Team-Ziele in Erinnerung zu rufen und Tickets entsprechend auszuwählen? Oder ist das Sprint-Planning ein verzweifelter Versuch, einfach irgendwie das Backlog zu leeren? Werden in der Sprint-Retrospektive wichtige Erkenntnisse gewonnen und aktiv als Learnings in den nächsten Sprint mitgenommen? Oder ist die Retro das Meeting, was alle außer dem Scrum-Master absitzen, während sie noch ein Seitenticket fertig machen?

Scrum gilt als agile Methodik, die durch strukturierte Rahmen den Fokus von und die Zusammenarbeit in Teams optimieren und Kommunikationsaufwand reduzieren soll. Umso größer ist die Gefahr, sich auf diesem System auszuruhen. Jede noch so effektive Methodik kann und sollte durch eine ständige Reflektion optimiert werden.

Fehlt Fokus führt das oft zu Frust in Teams. Jeder kennt das Gefühl am Ende des Sprints, wenn wichtige Dinge nicht fertig geworden sind, weil zu viele Seitenthemen unerwartet bearbeitet wurden. Hier noch ein Meeting mit einem anderen Team oder dort noch ein Solution Proposal für Sales schreiben. Oft ist dieser Fokusverlust nicht explizit sichtbar. Viele Teams haben überhaupt keinen Überblick darüber, wie viel Zeit sie auf die wichtigen Themen verwenden und wohin die restliche Zeit verschwindet. Selbst wenn Metriken wie beispielsweise „Scope Change“ erfasst werden, so sind diese oft ungenau. Tickets, die während des Sprints hinzukommen, müssen nicht unbedingt mit einem neuen Thema zu tun haben. Gleichzeitig kann ein Team sehr viel Zeit an Nebenschauplätzen verbringen, ohne dass sich die Tickets im Sprint ändern.

2 Tipps, um Eure Scrum-Performance mit den richtigen Metriken zu messen

Tipp Nr. 1: Effektiv arbeitende Scrum-Teams verlassen sich nicht nur auf teambezogene Metriken, sondern stellen auch einen klaren Bezug zur Unternehmensstrategie her

Nutzen gute Scrum-Teams also keine Scrum-Metriken? Wir haben gesehen, dass die effektive Performance eines Scrum-Teams in Softwareproduktunternehmen davon abhängt, wie gut die Aufgaben des Teams an den Unternehmenszielen ausgerichtet sind. Ein Team welches „langsam“ vorwärts kommt, aber am wichtigsten Thema arbeitet ist performanter als ein Team, welches sehr schnell arbeitet, aber auf kein relevantes Ziel einzahlt. Darum sind Metriken, die sich nur auf das Team selbst beziehen (z.B. Team Velocity) nicht wirklich aussagekräftig. Es muss immer ein klarer Bezug zur Unternehmensstrategie und Mission sichtbar sein.

Ullis Team kann Städte nur dann grüner machen, wenn Menschen wirklich ihr privates Auto abschaffen und es durch Have-a-Seat ersetzen. Und das wird eben nur dann Realität, wenn die wichtigsten Teilziele zur Erreichung dieser Mission zuerst bearbeitet und die Anzahl der parallelen Baustellen minimiert wird. Die Geschwindigkeit von Ullis Team hat erst dann einen Einfluss darauf, ob Have-a-Seat erfolgreicher ist als die Konkurrenz, wenn es fokussiert in die richtige Richtung arbeitet. Mehr Velocity in die falsche Richtung nützt niemanden.

Bleibt noch die Frage: Warum machen Teams das nicht schon genau so?

Ein Teil der Antwort ist sicher darin begründet, dass Softwareprodukte von technisch orientierten Menschen entwickelt werden. Softwareentwickler interessieren sich „per default“ mehr für Frameworks und Tools als für Business-Metriken. Sie werden dazu ausgebildet, Lösungen für Probleme zu entwickeln. Probleme zu priorisieren und zu hinterfragen, gehört nicht zu ihren „natürlichen“ Kernkompetenzen.

Doch auch wenn Softwareproduktentwicklung sehr viele technische Aspekte umfasst, so kommt niemand darum herum, sich mit Business-Metriken auseinanderzusetzen – auch nicht die Entwickler. Jedes neue Feature, jede Änderung, jeder Bug Fix, jede Performance-Optimierung und jedes Refactoring müssen letztendlich darauf abzielen, eine Business-Metrik positiv zu beeinflussen. Das müssen gerade technisch orientierte Teammitglieder erst lernen.

Gute Produktteams konzentrieren sich auf Business-Metriken und orientieren ihre Arbeit daran. Je näher Teams an diesen sogenannten Outcomes arbeiten, desto größer die Wahrscheinlichkeit, dass ihre Arbeit auf die richtigen Dinge einzahlt und damit das Unternehmen erfolgreich macht.

Zu dieser Orientierung auf Business-Metriken gehört auch die permanente Reflektion über den Einsatz der eigenen Zeit. Teams, die sich fragen, wie sie ihre Zeit nutzen, verstärken automatisch das Alignment mit Unternehmenszielen und stellen so ihre Wirksamkeit sicher.

Tipp Nr. 2: Effektiv arbeitende Scrum-Teams evaluieren ihren Scrum-Prozess kontinuierlich

Auch die methodische Arbeit mit Scrum muss kontinuierlich und datenbasiert überprüft werden. Es ist verlockend, Scrum als Mittel zum Zweck zu betrachten und die Effektivität der Methode anhand ihres Outputs zu bewerten. Aber auch eine hohe Anzahl fertiger Tickets und erreichter Story-Points kann täuschen, selbst wenn sie mit den Unternehmenszielen aligned sind. Wisst ihr, ob ihr das volle Potential der Scrum-Methodik schon ausschöpft?

In der Regel hat jedes Scrum-Team einen Scrum-Master oder Scrum-Verantwortlichen, der sich dafür einsetzt, dass Scrum als Rahmenmethodik für das Team funktioniert. Er unterstützt das Team auch dabei, den Fokus zu behalten und Störungen zu beseitigen. Im Idealfall schreitet der Scrum-Verantwortliche jedoch nicht erst dann ein, wenn es nicht funktioniert. Nachhaltiger ist es, einen Rahmen zu schaffen, in dem der Prozess kontinuierlich und auf einfache Art reflektiert und optimiert werden kann. Wir bei DevBoost verwenden hierfür ein Analyse-Tool, mit dem wir z.B. auch unsere Scrum-Events auswerten lassen. So kann das ganze Team aktiv dazu beitragen, die Fokuszeit für das Team und die wirklich wichtigen Aufgaben zu optimieren.

Und jetzt?

Als kleinen ersten Schritt hin zu einem Team mit mehr Wirksamkeit und Fokus, kannst Du unseren kostenlosen Focus Time Check nutzen. Er hilft Dir für Dein Team zu analysieren, ob ihr Euren Fokus klar gesetzt habt und wie gut ihr Eure Zeit für die Entwicklung Eures Softwareprodukts nutzt. Das ist „nur“ der erste Schritt, aber damit beginnt ja bekanntlich jede große Reise.

P.S.: Ulli hat den Focus Time Check auch schon gemacht!