Ankündigung:
Ich habe einen kostenlosen E-Mail-Crash-Kurs für angehende Trainer erstellt. Willst du 5 häufige Fehler in Schulungen vermeiden und stattdessen Austausch und Beteiligung fördern, sodass die Teilnehmer noch lange von deiner Schulung schwärmen?
Dann melde dich hier an – garantiert kostenlos.
Wenn es ums Schätzen geht, scheint die agile Community gespalten:
Die eine Hälfte der Community schätzt das Schätzen
Im Jahr 2016 habe ich zum ersten Mal als Product-Owner gearbeitet.
Das Produkt war neu und sollte viele Probleme des Unternehmens lösen. Somit wuchs das Backlog fast täglich. Natürlich fiel mir auf, dass das Team weniger Einträge fertigstellte, als ich hinzufügte. Aber ich dachte mir: Wenn sich das Team noch mehr findet und zusammenwächst, dann verbessert sich seine Geschwindigkeit und dem Release zum Ende des Quartals steht nichts im Weg. Irgendwann setzte sich unser Scrum Master dann mit den Entwicklern für einen Nachmittag im Büro zusammen. Danach sagte er zu mir:
„Simon, wir haben das Backlog jetzt einmal geschätzt. Um alles abzuschließen, brauchen wir mindestens 6 Monate.“
Das Schätzen der verbleibenden Arbeit war mein Weckruf. Es beraubte mich zwar einer Illusion, ermöglichte mir aber auch zu handeln und die Katastrophe noch abzuwenden.
Nach dieser Erfahrung kannst du die gängigen Argumente für das Schätzen gut nachvollziehen:
Schätzen hilft …
- … bei der Planung von Kapazitäten. Den Aufwand der Product-Backlog-Einträge zu schätzen, ist nötig, um den Sprint zu planen.
- … bei der Kommunikation mit Stakeholdern. Stakeholder wollen eine Frage beantwortet haben: „Wann ist mein Eintrag fertig?“
- … für ein besseres Verständnis für die Arbeit. Im Refinement des Product-Backlogs ist es nötig, um den Umfang der Arbeit zu berechnen.
- … bei der Priorisierung des Product-Backlogs. Der Umfang bestimmt die Reihenfolge der Arbeit mit.
- … dem Team beim Lernen über den Prozess. In der Retrospektive kann ein Vergleich zwischen geschätztem und tatsächlichem Aufwand zu Verbesserungen im Entwicklungsprozess führen.
Die andere Hälfte sieht das Schätzen kritisch
Ihre Argumente gegen das Schätzen lauten:
- Da die Bearbeitungszeit niemals die eigentliche Lieferzeit widerspiegelt, ist das Schätzen der Bearbeitungszeit nicht hilfreich.
- Wenn diese Abweichung durch einen zusätzlichen Zeitpuffer verhindert werden soll, verdoppelt sich das Problem nur. Teams können weder die Bearbeitungszeit noch den Puffer gut abschätzen, sodass sie ihre schlechte Schätzung zu einer noch schlechteren addieren.
- Schätzen ist Zeitverschwendung. Die Zeit, die fürs Schätzen genutzt wird, fehlt dann beim Entwickeln.
- Beim Schätzen wird immer nur der Aufwand geschätzt. Wieviel Aufwand ein Eintrag aus dem Product-Backlog hat, ist allerdings unerheblich, wenn er keinen Wert verspricht – dann sollte er eh niemals umgesetzt werden.
- Schätzungen erzeugen eine falsche Sicherheit im Team, bei den Stakeholdern und im PMO. Darauf Pläne zu bauen, ist zu riskant.
Ich kann diese Seite auch gut nachvollziehen:
Im Jahr 2019 habe ich in einem Team als Scrum Master gearbeitet, und dort haben wir die Einträge des Product-Backlogs so gut wie nie geschätzt. Manchmal habe ich im Refinement gefragt:
„Wer glaubt, dass dieser Eintrag in einem Sprint umgesetzt werden kann, wenn alle im Team daran arbeiten würden? Der hebt die Hand.“
Gingen nicht alle Hände hoch, haben wir diesen Eintrag noch weiter diskutiert oder aufgeteilt. Im Sprint-Planning haben die Entwickler dann so lange Einträge aus dem Product-Backlog gezogen, bis sie ein gutes Gefühl für den Sprint hatten. Das Gute daran war: Da wir die Arbeit nicht geschätzt haben, wurden die Entwickler auch nicht für schlechte Schätzungen zur Rechenschaft gezogen.
Es gibt wohl gute Argumente für das Schätzen und genauso gute Argumente dagegen.
Aber einer Wahrheit können sich weder die Verfechter des Schätzens noch ihre Gegner entziehen:
Eigentlich sollte es diese Debatte gar nicht geben.
Denn es geht überhaupt nicht ums Schätzen. Worum es eigentlich gehen sollte, beschreiben Bill Carr und Colin Bryar in ihrem Buch „Das Amazon-Geheimnis“:
„Tempo, oder genauer: eine Geschwindigkeit, die sowohl Tempo als auch Richtung misst, ist im Geschäftsleben ein wichtiger Faktor. Wenn alle anderen Faktoren gleich sind, bringt die Organisation, die schneller ist, mehr Innovationen hervor – schlicht und einfach, weil sie mehr Experimente pro Zeiteinheit durchführen kann.“
Nach den Worten von Bill und Colin hängt der Erfolg bei der Entwicklung von Produkten von zwei Faktoren ab: einmal vom Tempo und einmal von der Richtung. Allerdings glaube ich, dass die Richtung fast zu vernachlässigen ist. Denn die Richtung ergibt sich zwangsläufig, wenn wir nur schnell genug Experimente machen und dadurch herausfinden, welche Richtungen wir nicht einschlagen sollten.
„Wir wollen schneller als jeder andere Fehler machen.“
So beschreibt Daniel Ek, wie die Aufrechterhaltung einer Kultur des ständigen Experimentierens für den Erfolg von Spotify entscheidend ist. Oder wie es Mark Zuckerberg kürzlich zusammenfasste:
„Wenn wir schneller lernen können als jedes andere Unternehmen, werden wir gewinnen.“
Und genau das ermöglicht Geschwindigkeit.
Und darum sollten Scrum Master von Geschwindigkeit besessen sein – und sich nicht in endlosen Debatten über das Schätzen verlieren. Auch wenn die meisten in der agilen Community den Buchtitel „Twice the Work in Half the Time“ nur als Verkaufsslogan abtun: Ich denke, Jeff Sutherland wollte uns schon immer darauf hinweisen, dass es am Ende bei Scrum um Geschwindigkeit geht. Ungeachtet dessen, dass es einigen in der Community sauer aufstößt: die Verbesserung der Liefergeschwindigkeit stellt das erste Versprechen der Agilität dar.
Und daran müssen sich Scrum Master nun mal messen lassen.
Wie lässt sich Geschwindigkeit eigentlich verbessern?
Als Erstes müssen wir sie messen.
Erst dann können wir sie verbessern – und ich spreche hier explizit von Geschwindigkeit. Mir ist bewusst, dass „Velocity“ die deutsche Übersetzung dieses Wortes ist. Allerdings verstehen viele Scrum Master unter Velocity nur die Anzahl von Story-Points pro Sprint.
Alles auf eine Metrik zu reduzieren, wäre jedoch der erste Fehler:
„Produktivität in der Softwareentwicklung lässt sich nicht auf eine einzige Dimension (oder Metrik) reduzieren.“
Wie Nicole Forsgren von GitHub, Margaret-Anne Storey von der University of Victoria und eine Forschergruppe von Microsoft Research in ihrer Forschung zum SPACE-Modell zeigten. Das SPACE-Modell bietet eine Definition, um die Produktivität in Entwicklungsprojekten fundiert zu verstehen und zu verbessern. Hierzu werden fünf Dimensionen erfasst:
- Zufriedenheit und Wohlbefinden
- Leistung
- Aktivität
- Kommunikation und Zusammenarbeit
- Effizienz und „Flow“
Neben dem SPACE-Modell gibt es auch noch die DORA-Kennzahlen.
Die DORA-Kennzahlen stammen aus der Forschung hinter dem „State of DevOps Report“ und stellen die bislang wissenschaftlich umfassendste Studie zur Produktivität von Softwareteams dar. Diese Forschung hat gezeigt, dass sich Geschwindigkeit und Stabilität keineswegs als Kompromisse darstellen, und hat vier Schlüsselmetriken identifiziert, um die Leistung von Softwareteams zu messen:
- Deployment Frequency (Bereitstellungshäufigkeit): wie oft ein Team neue Software-Versionen bereitstellt.
- Lead Time for Changes (Durchlaufzeit von Änderungen): Wie viel Zeit vom Code-Commit bis zum erfolgreichen Deployment vergehen kann.
- Mean Time to Restore (Durchschnittliche Wiederherstellungszeit): Wie rasch ein Team auf Störungen reagiert und wieder den Normalbetrieb erreicht.
- Change Failure Rate (Änderungsfehlerrate): Wie häufig Deployments zurückgerollt werden müssen oder zu schwerwiegenden Problemen führen.
Neben SPACE und DORA gibt es noch einen dritten Ansatz, um die Geschwindigkeit zu messen.
Hier stützen wir uns maßgeblich auf die Erfahrung, die Entwickler in Projekten machen, – daher auch der Name „DevEx“, was für „Developer Experience“ steht. Im Kern geht es um die Art und Weise, wie Entwickler ihre Arbeit empfinden, darüber denken und sie wertschätzen. So wirken sich beispielsweise Unterbrechungen, unrealistische Fristen und Reibungsverluste in Entwicklungswerkzeugen negativ auf die DevEx aus, während klare Aufgaben, gut organisierter Code und schmerzfreie Releases die DevEx verbessern. An der DevEx arbeiten Forscher der Unternehmen DX, der University of Victoria und von Microsoft Research.
Ich möchte ehrlich zu dir sein:
DORA, SPACE und DevEx klingen zunächst nach viel Theorie. Wenn du allerdings aufhören willst, nur noch auf den Velocity-Graphen in Jira zu schauen, und endlich wirkliche Geschwindigkeit messen möchtest, musst du irgendwo anfangen.
Und so habe ich es gemacht:
Eine Anleitung, wie du Geschwindigkeit messen kannst
Ich bin bisher immer in drei Schritten vorgegangen:
Schritt 1: Sammle die Zahlen, um die Time-to-Market zu bestimmen. Aus Jira lassen sich einfach die Cycle-Time und die Lead-Time ermitteln. Darüber hinaus misst du auch die Release-Häufigkeit. Damit erhältst du Kennzahlen zur Time-to-Market:
- Cycle-Time
- Lead-Time
- Release-Häufigkeit
Das ist bereits ein guter Startpunkt. Später kannst du diese Zahlen noch mit den Kennzahlen aus dem DORA-Modell verfeinern.
Neben den „harten“ Fakten wissen wir aus der Arbeit an der Developer-Experience, dass auch die Erfahrung der Entwickler maßgeblich zur Geschwindigkeit beiträgt.
Schritt 2: Miss die Entwicklererfahrung. Ich habe mich hierfür bisher immer am Spotify Health Check orientiert und folgende Kennzahlen erhoben:
- Einfache Freigabe
- Technische Qualität
- Schnelligkeit
- Unterstützung
- Moral
Die Erhebung der Zahlen erfolgt mittels Umfragen. So kann die technische Qualität zum Beispiel von: „Wir sind stolz auf die Qualität unseres Codes! Er ist sauber, leicht zu lesen und hat eine gute Testabdeckung“, bis hin zu: „Unser Code ist ein Haufen Mist und die technische Schuld gerät außer Kontrolle“, bewertet werden.
Die Umfragen führe ich jeden Sprint vor der Sprint-Retrospektive durch – und sie sollten unbedingt anonym erfolgen.
Schritt 3: Passe die Umfragen später weiter an, um der tatsächlichen Entwicklererfahrung immer näher zu kommen.
Hier noch einige weitere Kriterien aus der DevEx-Forschung:
- Dokumentation
- Tiefe Arbeits-/Fokus-Zeit
- Build- und Testprozesse (CI, Automatisierung)
- Vertrauen in Änderungen (Change Confidence)
- Reaktion auf Zwischenfälle (Incident Response)
- Lokale Entwicklungsumgebung (Local Development Experience)
- Planungsprozesse
- Teamübergreifende Abhängigkeiten (Cross-Team Dependencies)
- Leichtigkeit der Veröffentlichung (Ease of Release)
- Wartbarkeit des Codes (Code Maintainability)
Wenn du noch tiefer eintauchen willst, hier noch drei weitere Punkte:
- Verwende die Vorlage von Laura Tacho. Sie ist CTO von DX und arbeitet an einem weiteren Modell zur Messung und Verbesserung der Entwicklererfahrung, das „Core 4“ heißt.
- Oder du nutzt direkt den Scrum Team Survey. Die Umfrage wurde von Barry Overeem und Christiaan Verwijs entwickelt und konzentriert sich nicht mehr ausschließlich auf die Time-to-Market.
- Wenn du auch Aspekte über Psychologische Sicherheit einbeziehen willst, dann wende dich gerne an Karen Eilers. Sie ist die Expertin auf diesem Gebiet und kann dir sicherlich weitere Tipps geben.
Klingt zunächst nach viel Aufwand. Deshalb bin ich bisher immer in drei Schritten vorgegangen und habe die Umfragen und Metriken nur langsam erweitert. Warum solltest du den Aufwand betreiben, die Geschwindigkeit deines Teams zu messen?
Oder anders gefragt:
Warum sollten Scrum Master von Geschwindigkeit besessen sein?
Es ist kein Geheimnis mehr:
Im Moment stellen viele Unternehmen den Wert von Scrum Mastern infrage. Schaffst du es aber, mit deiner Arbeit die Geschwindigkeit deines Teams zu verbessern, sorgst du für Prozessverbesserungen und Innovationen.
Lass uns die beiden Punkte im Detail ansehen:
Wie führt Geschwindigkeit zu mehr Prozessverbesserungen?
Wie wirken sich Prozessverbesserungen aus?
Immer finanziell. Und hierfür gibt es eine schöne Fallstudie von DX.
In dieser Studie wurden die Daten von 40 000 Entwicklern in 800 Unternehmen anhand des „Developer-Experience-Index“ ausgewertet. Es konnte ein Zusammenhang zwischen der Erfahrung von Entwicklern und der Effizienz der Entwicklung aufgezeigt werden. Eine Verbesserung der Effektivitätsbewertung um einen Punkt bedeutet eine Einsparung von 13 Minuten pro Woche und Entwickler – das entspricht 10 Stunden pro Jahr. Bei 150 Entwicklern in einem Unternehmen bedeutet dies eine Einsparung von etwa 33 Stunden pro Woche. Und jetzt lass uns weiterdenken: Eine Verbesserung um drei Punkte würde bedeuten, dass rund 100 Stunden pro Woche eingespart würden – das entspricht mehr als zwei Vollzeitentwicklern. Die Verbesserung der Entwicklererfahrung führt zu höherer Geschwindigkeit, was wiederum Einsparungen beim Personal gleichkommt.
Prozessverbesserungen haben immer das Ziel, Geld einzusparen.
Wie führt mehr Geschwindigkeit zu mehr Innovation?
Ich glaube, es war der Ökonom Gary Hamel, der sagte:
„Der einzige Weg, einen Wettbewerbsvorteil zu erhalten, ist kontinuierliche Weiterentwicklung … und der einzige Weg zur Weiterentwicklung ist Innovation.“
Somit garantiert nur Innovation das Überleben eines Unternehmens, und die Verbesserung der Innovationsfähigkeit sollte einen zentralen Stellenwert im Unternehmen haben. Aus meiner Erfahrung lässt sich Innovationsfähigkeit nur indirekt messen.
Bisher habe ich dazu immer die beiden folgenden Fragen genutzt:
- Wie hoch ist der Prozentsatz der Änderungen in der Produktion, der zu einer Beeinträchtigung des Dienstes führt (z. B. zu einem Ausfall des Dienstes) und in der Folge Fixes erfordert?
- Wie viel Prozent deiner Zeit hast du in den letzten drei Monaten für folgende Tätigkeiten aufgewendet?
- Entwicklung neuer Funktionen
- Fehlerkorrekturen, Support, Wartung, Sonstiges
Wie du siehst, hängt die Antwort auf diese Fragen stark von der „Erfahrung der Entwickler“ ab. Schlechte technische Qualität kann der Grund dafür sein, dass ein Entwickler mehr Zeit für Wartung und Fehlerkorrekturen aufwenden muss. Oder andersherum betrachtet: Gute technische Qualität – also eine gute Entwicklererfahrung – führt dazu, dass der Entwickler mehr Zeit für die Entwicklung neuer Funktionen hat, was wiederum zu höherer Geschwindigkeit führt. Höhere Geschwindigkeit bedeutet mehr Zeit für die Entwicklung neuer Funktionen und damit mehr Potenzial für Innovation. Und diesen Zusammenhang kannst du mit den obigen Fragen messen und sichtbar machen.
Somit resultiert die Verbesserung der Entwicklererfahrung in höherer Geschwindigkeit – was äquivalent zu einer Verbesserung der Innovationsfähigkeit ist.
Und wer im Scrum Team ist für Verbesserungen zuständig?
Ein Hinweis aus dem Scrum Guide:
„Der Scrum Master dient dem Scrum Team durch die Beseitigung von Hindernissen (impediments) für den Fortschritt des Scrum Teams.“
Fortschritt bedeutet natürlich auch die Verbesserung der Geschwindigkeit und der Entwicklererfahrung. Somit ist aus meiner Sicht der Scrum Master für die Verbesserungen verantwortlich.
Zurück zum Problem, dass viele Unternehmen Schwierigkeiten haben, den Wert eines Scrum Masters zu beziffern. Das eigentliche Problem liegt doch eher darin, dass Unternehmen den Wert von Scrum Mastern oft nicht erkennen, weil niemand die Auswirkungen ihrer Arbeit misst. Nicht mal die Scrum Master selbst. Deshalb mein Appell an jeden Scrum Master:
Miss die Geschwindigkeit und verbessere sie – so sieht dein Unternehmen auch den Nutzen deiner Arbeit.
Und zwar in Euro!
Wenn du hierfür weitere Unterstützung brauchst, dann empfehle ich das Buch des „Professional Agile Leadership – Evidence Based Management“-Trainings. Dort lernst du noch viele weitere Metriken kennen, mit denen du den Erfolg deines Scrum Teams sichtbar machen kannst.