Funktioniert Scrum in deinem Unternehmen? So kannst du den Nutzen von Scrum messen
Agile Projekte sind fast viermal so erfolgreich und scheitern dreimal seltener als Wasserfallprojekte.
So lautet das Ergebnis des Chaos-Reports. Die Umfrage untersuchte von 2011 bis 2015 etwa 10 000 Softwareprojekte hinsichtlich der Frage: Sind agile Projekte oder Wasserfallprojekte erfolgreicher? Da Scrum das am häufigsten genutzte agile Rahmenwerk ist, sollten wir die Frage, ob Scrum grundsätzlich funktioniert, also bejahen können.
Wenn ich allerdings Scrum Master in meinen fortgeschrittenen Scrum-Trainings frage, ob Scrum funktioniert, dann zeigt sich ein anderes Bild: Die meisten Antworten lauten: „So lala“ oder: „‚Scrum by the book‘ machen wir nicht!“
Die Frage lautet also nicht, ob Scrum grundsätzlich funktioniert oder nicht, sondern genauer: Wie können wir den Nutzen von Scrum speziell für unser Unternehmen messen?
Das können wir herausfinden, wenn wir einen Weg finden, um die folgenden Fragen zu beantworten:
1. Wie lange dauert es bis wir eine neue Version liefern können?
2. Welchen Wert bietet das Produkt?
Wie lange dauert es, bis wir eine neue Produkt-Version liefern können?
Über Sprints die Time-to-Market verbessern
Im Jahr 2018 leitete ich eine Agile Transformation. Mein Auftrag war, bei 3 bis 5 Teams, die gemeinsam ein Produkt zur Steuerung von Stromnetzen entwickelten, Scrum einzuführen.
Auf die Frage, warum Scrum eingeführt werden sollte, erhielt ich damals die Antwort, dass das Unternehmen schneller werden müsse. Herkömmlich ziehen sich Projekte oft über Jahre und erst ganz am Ende steht das Produkt den Kunden zur Verfügung. In Scrum ist das anders. Die Zeit vom Beginn der Arbeit bis zu einer neuen Version des Produkts darf einen Monat nicht überschreiten. Somit kann jeder Sprint als ein kurzes Projekt betrachtet werden.
Sprints helfen dabei, die Time-to-Market zu verbessern.
Undone work undoes Scrum
„Zu sprinten“ bedeutet in der Produkt-Entwicklung, auch wirklich die Ziellinie zu überschreiten und mit der Arbeit fertig zu werden.
Warum das so wichtig ist, habe ich einige Jahre früher erfahren:
Als frisch gebackener Product Owner eines Produktes zur Verwaltung von Inhalten auf Haushaltsgeräten hatte ich zum Sprint Review eingeladen. Zwei Wochen zuvor hatten wir den Sprint geplant. Ich hatte mich mit den Entwicklern darauf verständigt, dass wir eine erste Oberfläche benötigen. Diese Oberfläche sollte es uns ermöglichen, die Inhalte zu bearbeiten. Was mir im Review des Sprints vorgestellt wurde, schien auf den ersten Blick hilfreich. Erst als ich einen Entwickler fragte, wann ich darauf zugreifen kann, um es selbst auszuprobieren, lautete seine optimistische Prognose: „Ich denke, etwa in 4 bis 7 Wochen.“ Und da er selbst nur als Externer angestellt war, traute er sich nicht, eine verlässlichere Aussage zu treffen, da diese auch in den Bereich der internen IT-Abteilung fiel.
Wenn ich seither das Zitat von Ken Schwaber lese: „Undone work undoes Scrum“, erinnert es mich an dieses Sprint Review und an meine Einsicht von damals:
Durch die Arbeit in Sprints entsteht kein Vorteil, wenn am Ende des Sprints nicht auch wirklich eine nutzbare Version des Produkts an den Kunden geliefert werden kann.
Diese Einsicht ist grundlegend für jedes Scrum-Team und wird deshalb in der Definition of Done festgehalten.
Einen ausführliche Erklärung rund um die Definition of Done findet ihr im folgenden Blogbeitrag: Scrum im Selbststudium – Teil 9: Die Vergangenheit – Das Produkt-Inkrement.
Release-Häufigkeit, Lead- und Cycle-Time
Kommen wir zurück zu der Frage: Wie lange dauert es, bis eine neue Version des Produktes geliefert werden kann? Die Antwort auf diese Frage finden wir, wenn wir diese beiden Werte betrachten:
- Release-Häufigkeit
- Lead- und Cycle-Time
Release-Häufigkeit
Die Release-Häufigkeit besagt, wie häufig eine neue Produktversion, z.B. ein Software-Update, veröffentlicht wird. Von wenigen Tagen bis zu mehreren Monaten kann die Release-Häufigkeit variieren.
Lead- und Cycle-Time
Lead- und Cycle-Time sind Metriken zur Bestimmung von Effizienz und Fortschritt im Entwicklungsprozess.
Die Lead Time ist die Gesamtzeit, die von der Erfassung einer Anforderung bis zur Bereitstellung der fertigen Produktversion benötigt wird. Dies umfasst alle Phasen des Entwicklungszyklus, einschließlich Planung, Entwicklung, Testen und Bereitstellung. Eine kürzere Lead Time deutet darauf hin, dass das Entwicklungsteam effizient arbeitet und Anforderungen schnell in funktionsfähige Software umsetzen kann.
Die Cycle Time bezieht sich auf die Zeit, die benötigt wird, um eine spezifische Aufgabe oder einen bestimmten Arbeitsschritt abzuschließen. Sie konzentriert sich auf einen bestimmten Aspekt des Entwicklungsprozesses und hilft dabei, Engpässe oder ineffiziente Arbeitsabläufe in diesem spezifischen Bereich zu identifizieren. Eine kürzere Cycle Time zeigt an, dass einzelne Aufgaben oder Arbeitsschritte effizient durchgeführt werden können.
Neben diesen beiden Metriken findest du im „Evidence Based Management“-Rahmenwerk noch 28 weitere Metriken. Willst du Produktentwicklung nicht auf der Basis von Meinungen, sondern auf der Grundlage von Fakten steuern, dann empfehle ich dir ein Training in „Evidence Based Management“.
Mit den drei Metriken Release-Häufigkeit, Lead und Cycle Time bekommen wir einen recht guten Überblick über die Liefergeschwindigkeit in unserer Organisation.
Die Liefergeschwindigkeit allein als den Nutzen von Scrum zu sehen, hat allerdings einen Haken.
Um das besser zu verstehen, hier eine persönliche Frage: Was liebst du an den Produkten von Google, Apple, Netflix, Spotify oder Amazon?
- Dass die Apps nutzbar sind?
- Dass sie jeden Monat eine neue Version der App herausbringen?
- Dass mindestens 12 neue Versionen der App im Jahr bereitgestellt werden?
Wenn es dir wie mir geht, dann lautet die Antwort auf jede dieser Fragen: „Nein.“ Was ich an diesen Produkten liebe, zeigt sich in Situationen wie dieser:
Letzte Woche stand ich am Bahnhof in Berlin – einer für mich fremden Stadt –, bepackt mit einem schweren Koffer, einem Flipchart-Köcher und einem Rucksack. Ein Blick auf die Uhr meines iPhones sagte mir, ich sollte mich beeilen: Der Workshop beginnt in einer Stunde! Ein weiterer Blick auf Google Maps auf meinem iPhone verriet mir, dass die schnellste Möglichkeit, mein Ziel zu erreichen, heute ein Taxi ist, da der Nahverkehr gerade bestreikt wird.
Ich liebe nicht, dass die App nutzbar ist, sondern dass sie nützlich ist!
Für Unternehmen, die langfristig am Markt erfolgreich sein wollen, sollte es nicht genug sein, zu messen, wie häufig sie liefern, sondern sie sollten auch messen, welchen Wert ihr Produkt stiftet.
Deshalb stelle dir nicht nur die Frage, wie lange es dauert, eine neue Version des Produkts zu liefern, sondern auch:
Welchen Wert bietet das Produkt?
Denn ein Unternehmen schafft nur dann Wert, wenn es die Erfahrungen seiner Kunden verbessert.
Dieser Wert kann sich in Form von
- höherer Nutzungsdauer und Nutzungshäufigkeit,
- gesteigerter Kundenzufriedenheit oder
- einem höheren Umsatz
bemerkbar machen. Die Grundlage für alle drei Punkte bildet immer die Kundenerfahrung!
Oder noch mal in anderen Worten:
Unternehmen werden keinen Wert für die Kunden schaffen, indem sie die Kosten senken, häufiger oder schneller liefern. Natürlich sind diese Dinge wichtig. Aber ich fürchte, ein Unternehmen, das sich nicht darauf konzentriert, die Erfahrung seiner Kunden zu verbessern, wird nicht lange genug überleben, um die Vorteile von Kostenreduzierung oder Verringerung der Lieferzeit auszukosten.
Deshalb kommen Scrum-Teams mit den Stakeholdern des Produkts mindestens einmal pro Sprint – im Sprint Review – zusammen und beantworten gemeinsam die Frage:
„Welchen Wert bietet das Produkt?“
Dafür sehen sie sich unter anderem diese Metriken an:
- Den Feature-Nutzungs-Index und
- die Kundenzufriedenheit.
Erst mit der Beantwortung der Frage nach dem Wert schließt sich auch die Feedback-Schleife, die Scrum zugrunde liegt.
Scrum fußt auf einer empirischer Prozesskontrolle: auf der Theorie, dass alles Wissen aus der Erfahrung abgeleitet wird. Ohne regelmäßiges Überprüfen, welchen Wert das Produkt den Kunden liefert, bleibt diese Theorie eben nur Theorie. Scrum wird dann nicht funktionieren und dem Unternehmen nur wenig nutzen.
Welchen Nutzen hat Scrum für dein Unternehmen?
Wenn du wissen willst, welchen Nutzen Scrum aktuell für dein Unternehmen hat, dann stelle diese Fragen:
- Wie lange dauert es, eine neue Version des Produkts zu liefern?
- Welchen Wert bietet das Produkt?
Hilf deinem Team dabei, für die Beantwortung Daten über diese Metriken zu sammeln:
- Release-Häufigkeit
- Lead- und Cycle-Time
- Feature-Nutzungs-Index
- Kundenzufriedenheit
Damit kannst du beide Fragen beantworten und erhältst eine Antwort darauf, wie nützlich Scrum für dein Unternehmen im Moment ist!
Fragen zum Thema, Hilfe oder einfach Austausch gewünscht?
Wendet euch gerne per Mail oder über die Kommentare direkt an Simon.
Scrum-Trainings mit Simon Flossmann
Für Scrum Master, Product Owner, Coaches und Führungskräfte: Hier findet ihr eine Übersicht der Scrum-Trainings mit Simon Flossmann.
Weitere Blogbeiträge zu Metriken in der Produktentwicklung:
Warum Story Points nicht geeignet sind, um Releasedaten vorherzusagen (Simon Flossmann)
Was ist ein MVP wirklich? 5 entscheidende Unterschiede zwischen MVP und Release (Pascal Gugenberger)
3 Fehler, die Scrum-Teams bei der Verwendung von Velocity vermeiden sollten und wie sie stattdessen Performance, Prognosesicherheit und Wert messen können (Simon Flossmann)