»Woher wissen wir, dass wir in unserer agilen Transformation vorankommen?« Das Spektrum möglicher Antworten auf dem Beratungsmarkt reicht von Velocity-Tracking bis Kultur-Untersuchung.
Inhalt:
- Lieber nicht den Output messen
- Output & Outcome
- Sinnvolle Outcome-Kennzahlen
- Velocity und Burndowns
- Und wenn man vom Weg abkommt?
Um das Ergebnis einer Veränderung zu messen, braucht man ein Instrument, dass möglichst viele Aspekte der Veränderung beinhaltet. Andererseits sollte das Instrument sich nicht direkt auf den Output der Teams beziehen – denn das läßt sich zu leicht fälschen.
Ein schönes Beispiel dafür ist die Idee eines Bonus für gefundene und behobene Bugs.
Lieber nicht den Output messen
Der CTO eines mittelgroßen Lager- und Transportunternehmens in Nordkalifornien kündigte ein innovatives Programm an, um die Mitarbeiter zu motivieren und die Qualität ihrer Logistiksoftware zu steigern. Für jeden Fehler, der von einem Tester gefunden und von einem Programmierer behoben wird, würden beide 10 Dollar erhalten:
Der CTO hoffte, die Codequalität bei der weitreichenden Überholung der Beschaffungs-, Einkaufs-, Bestands-, Lager-, Vertriebs-, Transport-, Kundensupport- und Finanzsysteme des Unternehmens zu verbessern. Das Entwicklungsteam war anfangs skeptisch, aber am Ende des ersten Tages des Anreizprogramms waren sowohl die Programmierer als auch die Tester überzeugt. Nach einem durchschnittlichen Tag, an dem sie Fehler gefunden und behoben hatten, hatte jeder von ihnen zwischen 30 und 40 Dollar zusätzlich verdient.
Am vierten Tag war der Brunnen ausgetrocknet. Die Tester ließen die Testfälle laufen, wiederholten sie und wiederholten sie, aber sie konnten nur eine handvoll Probleme finden. Die Entwickler strapazierten das Fehlerverfolgungssystem, luden ständig die Seite mit den "nicht zugewiesenen Fehlern" neu und beeilten sich, alles, was auftauchte, sich selbst zuzuweisen.
Und dann passierte beim Mittagessen etwas Seltsames. Anstatt mit seinen üblichen Teamkollegen essen zu gehen, ging einer der Entwickler mit einem Tester aus. Bald darauf ging ein anderer Entwickler mit einem anderen Tester aus. Innerhalb weniger Minuten hatten sich fast alle Entwickler mit Testern zusammengetan.
Als die Entwickler vom Mittagessen zurückkamen, machten sie sich sofort an die Arbeit. Anstatt nach neu gefundenen Fehlern zu suchen, arbeiteten sie an "Code-Refactoring" und neuen Funktionen. Und sobald sie ihre Änderungen einsetzten, fanden die Tester Fehler - kleinere, obskure Fehler, die ein Entwickler leicht übersehen konnte. Und genau so schnell, wie die Tester Fehler gefunden hatten, konnten die Entwickler diese beheben und neu implementieren. Am Ende des Tages hatten die Entwickler und Tester durchschnittlich 120 Dollar verdient.
Zitiert nach The Defect Black Market, The Daily WTF, 2008.
Wie also messen wir unsere agile Transfomation? In dem wir auf Outcome achten.
Output & Outcome
Output ist, trocken formuliert, die Leistung der Organisation als direktes Ergebnis der Prozesse. Es gibt einen Prozess, dessen Ergebnis Softwarecode ist, also ist Softwarecode ein Output der Organisation.
Hingegen ist Outcome die Folge der Leistung.
Hier wird gerne Umsatz als Beispiel genannt. Prüfen wir mal, ob das stimmt: Umsatz ist das Geld das Dritte uns für unsere Leistung bezahlt haben.« Aus der Leistung, deren Ergebnis ein Stück Software ist, wird Umsatz. Passt.
Leider ist Umsatz ein »lagging indicator«. Die Information zum Umsatz kommt mit Verzögerung an. Es ist als Messinstrument für Kurskorrekturen einer agile Transformation zu langsam.
Die meisten Outcome-Kennzahlen beinhalten mehr als einen Faktor. Das macht die Zurechnung einzelner Maßnahmen zu Erfolg und Misserfolg schwierig. Diese intellektuelle Arbeit, die Analyse und Schlussfolgerung aus Ihrer Beobachtung einer Kennzahl, kann Ihnen kein Dashboard und kein Management-System abnehmen.
Gute Zusammenarbeit entsteht durch stetige Investition Ihrer Zeit in Vertrauen, Respekt und Sicherheit. Auch das nimmt Ihnen niemanden ab.
Sinnvolle Outcome-Kennzahlen
Grundsätzlich sollten Agilitäts-Kennzahlen über mehrere Teams hinweg Vergleichbarkeit herstellen. Ist eine Kennzahl für ein Team nicht relevant, oder erlaubt eine Kennzahl keinen Vergleich, ist sie nicht geeignet, die Ausgangsfrage nach der Verbesserung der Arbeitsweise durch agile Methoden zu beantworten. Siehe den Abschnitt über Velocity und Burndowns.
Scrum-Metriken
Diese Metriken hängen von Artefakten und Praktiken in Scrum ab.
- »Haben wir unser Sprintziel erreicht?« Schlicht und simpel. Haben wir, gemäß unserer »definition of done«, unser Sprint-Ziel erreicht. Wenn die Antwort darauf konsistent »nein« lautet, läuft etwas schief.
- Länge des vollständigen Plannings. In Scrum hat ein Planning-Event eine Timebox. Es darf für einen Zwei-Wochen-Sprint nicht länger dauern als vier Stunden. Mehr dazu im Sprint-Kalender. Warum diese Festlegung? Dahinter steckt die Überlegung, dass ein Planning umso länger dauert, je mehr Unklarheiten über den Scope bestehen. Da Scrum vorsieht, Unklarheiten zeitnah nach ihrem Auftreten zu klären, sind konsistent zu lange laufende Plannings ein guter Indikator für Schwierigkeiten.
- Ticket-Überlauf. Tickets wandern von einem Sprint in den nächsten. Häufig ist eine unvollständige »definition of done« sichtbares Artefakt des Problems. Im Detail habe ich das hier beschrieben.
Beide kann man natürlich auch negativ betrachten. Wir erreichen immer unsere Sprint-Ziele, aber gefühlt tut das Team quasi nichts. Das Planning dauert nur eine Stunde. Weiter oben sagten wir: »Diese intellektuelle Arbeit, die Analyse und Schlussfolgerung aus Ihrer Beobachtung einer Kennzahl kann Ihnen kein Dashboard und kein Management-System abnehmen.«
Produkt-bezogene Metriken
- Fehlermeldungen nach Release. Je mehr Fehler durch Kund*innen gemeldet werden, desto schlechter. Durch agiles Arbeiten, also z. B. Einbeziehung der Kund*innen, Zusammenarbeit zum Verständnis des Scopes und der Lösungsansätze, Test Driven Development, Pair Programming (oder sogar Mob Programming), oder regelmäßige Integrationstest möchten wir möglichst viel gleich im ersten Anlauf richtig machen, und handwerklich Schlamperei rechtzeitig zu erkennen und zu korrigieren.
- Ähnlich dazu: Die Anzahl der Bugs, die erst im nächsten Zeitabschnitt gefixt werden. Diese Zahl sollte ebenfalls gegen Null gehen. Einerseits sollte ein Bug grundsätzlich immer sofort gefixt werden. Andererseits fallen Bugs manchmal erst nach dem Deployment auf. Hier sind sie ein Indikator für mangelnde Automatisierung bzw. zu unregelmäßige Integration. Finden Integrationstest zu selten und gegen Ende einer Entwicklungsphase statt, bleibt keine Zeit mehr für Bugfixes.
Velocity und Burndowns
Warum Velocity eine denkbar schlechte Metrik ist, darüber haben schon andere geschrieben. Jedes Wort in diesem Satz (der nächste ist ein Klassiker) verlinkt auf einen Artikel dazu.
Burndowns sind über Teams hinweg nicht vergleichbar. Warum Team A heute früh vier Storypoints weiter ist als Team B ist keine relevante Frage, weil es in der Situation gute Gründe dafür gibt, die nicht veränderbar sind. Burndowns mögen Rückschlüsse auf den Fortschritt der aktuellen Timebox liefern, weiteren Nutzen haben sie nicht.
Das lässt sich analog für Velocity formulieren: Die Velocity ist über Teams hinweg nicht vergleichbar. Warum Team A vier Storypoints mehr geschafft hat als Team B ist keine relevante Frage, weil es in der Situation gute Gründe dafür gibt, die nicht veränderbar sind. Gleiches gilt für die Veränderung der Velocity eines Teams über die Zeit. Davon unbenommen ist die Frage, ob Storypoints an sich eine gute Idee sind. Tipp: sind sie nicht.
Und wenn man vom Weg abkommt?
Wir konnten die vier vorgestellten Metriken auf Werte und Prinzipien des Scrum-Guides und des Agilen Manifests zurückführen. Wenn wir den Fortschritt unserer Agilen Transformation messen wollen, ist das nur folgerichtig: Wonach sonst, als nach den Ideen in diesen Dokumenten wollen wir uns richten?
Was war Ihr Ziel?
Welcher Handlungsdruck Sie Ihre Agile Transformation auch starten ließ, natürlich sollten Sie sich auch darin messen, ob Mitarbeiter*innenflukuation oder Kundenzufriedenheit. Wichtig ist nur, dass Sie sich ein relevantes Ziel gesetzt haben, es nachhalten und nachjustieren und auf dem Weg keine Scheuklappen aufsetzen.
Agile Realign
Mit dem Agile Realign-Workshop kann ich Ihnen helfen, sowohl Ziele zu formulieren als auch Werkzeuge und Maßnahmen zu entwickeln, mit denen Sie auf Kurs bleiben und, am wichtigsten, den Kurs jederzeit sinnvoll korrigieren können. Sprechen Sie mich an.