Direkt zum Hauptbereich

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.
Im klassischen Management gibt es das Gefühl, dass man Kennzahlen braucht, um einen Prozess richtig zu steuern. Dann überlegt sich ein Manager, wie er die Produktivität oder Qualität misst. Danach legt er den Teams in regelmäßigen Abständen Berichte vor und erwartet Korrekturmaßnahmen ("corrective actions"), wenn die Zahlen sich nicht wie erwartet verhalten. Am Ende verhält sich das Team so, dass die Zahlen unter allen Umständen stimmen, aber der Prozess schon lange zerbrochen ist. Genau das wollen wir bei Scrum nicht.

Teamkennzahlen

Wenn sich Teams selbst organisieren, bedeutet das auch, dass sie selbst die Kennzahlen bestimmen, mit denen sie sich messen. Die Kennzahlen gehören dem Team und nicht dem Management.

Kennzahlen dürfen kein Selbstzweck sein, sondern müssen dem Prozess dienen. Sie müssen nicht mal ganz genau sein. Beim Autofahren sind die wichtigsten Kennzahlen die aktuelle Geschwindigkeit und die restliche Treibstoffmenge. Damit lässt sich der Prozess des Fahrens von A nach B gut steuern.

In einem Video /1/ erklärt der Co-Erfinder von Scrum, Jeff Sutherland, warum er in seinem ersten Scrum-Projekt Gantt-Charts abgeschafft hat und was die Alternative ist.

In Scrum benutzt das Team sog. Burndown-Charts, um sich zu vergewissern, ob es noch das Sprintziel erreicht.

Dazu braucht das Team echte Transparenz in die Produktqualität. Wie es das misst, muss das Team entscheiden. Ein Team kann Fehlerraten oder fehl geschlagene Tests messen. Für ein anderes sind Antwortzeiten und Stabilität wichtiger. Das nächste Team misst Softwarekomplexität und technische Schulden.

Sehr weit gehen die Ideen von Christoper Davis. In "Agile Metrics in Action" /2/ beschreibt er, wie er alle beteiligten elektronischen Systeme nutzt, um einen besseren Einblick in die Qualität und den Fortschritt des Produkts bekommt. Eine Kurzversion zum Thema gab es im letzten Jahr in der Session "Democratizing Development Metrics [CON1999]" auf der Oracle Open World.

M. E. sollte jedes Team seine Velocity kennen und regelmäßig die Happiness messen.

Persönliche Kennzahlen

Es bleibt natürlich jedem Teammitglied unbenommen, für sich eigene Kennzahlen zu erheben. Das hat mich beim Vortrag von Patrick Koglin auf dem freiräume.camp im Mai in Hannover beeindruckt. Er hat mal gezählt, wie viele Module das Team bearbeitet hat und wie viele noch zu bearbeiten sind. Diese Information hat er dann völlig unrealistischen Managementerwartungen gegenübergestellt. Gut, wenn jedes Team jemanden wie Patrick hat, der einfach mal Dinge zählt.

Für die eigene Qualitätsbewertung finde ich die Kennzahlen aus dem "Personal Software Process" (PSP) /3/ nach wie vor aktuell.

Produktkennzahlen

Die Product Owner (PO) in Scrum-Projekten stehen oft vor dem Problem, die eingesammelten User Storys zu bewerten und danach zu priorisieren.Sie wollen nach der Umsetzung vielleicht auch wissen, hat sich der Aufwand für die Umsetzung gelohnt. Welche Kennzahlen könnte ein PO nutzen? Der Scrum-Guide sagt auch hier nichts dazu. Warum? Für mich geht das in die gleiche Richtung wie die Antwort von Deming, warum er denn keine "Kochrezepte" für seine Ideen anböte /4/. Denken sollte man schon selbst. Jedes Produkt, jedes Projekt und jede Umgebung ist anders.

Der PO hat die Aufgabe den Wert des Produkts zu erhöhen. Er muss sich also einen Überblick darüber verschaffen, was Wert für den Enduser bedeutet. Entweder kann man es direkt messen (neue Funktion X = 1.000 neue zahlende Anwender) oder man nutzt indirekte Größen wie Verzugskosten (cost of delay; wie viel Geld verliere ich, wenn ich dieses Feature nicht sofort veröffentliche?) oder Net Present Value (= ich verdiene lieber heute 1.000 EUR als in einem Jahr).

Die Scrum Inc. berichtet in ihrem Scrum @ Scale Kurs von einer Entscheidung, bei der "Schreiben eines weiteren Buchs" und "Anschaffung einer Videokonferenzanlage" zur Auswahl standen. Durch die Betrachtung des Net Present Value war klar, dass die Videokonferenzanlage einen höheren Wert als das Buch hatte und deshalb der Kauf vorgezogen wurde.

Die mathematischen Grundlagen für das Produktmanagement hat Don Reinertsen in "Flow" ziemlich dicht zusammengefasst /5/. Eine Liste mit User Storys und angefangene Software sind letztendlich Warteschlangen. In dem Buch kann man nachlesen, warum es sich lohnt, Warteschlangen aktiv zu steuern, statt den lautesten Stakeholder zu bedienen.

Aber zurück zur Frage, wie man den Wert eines Produkt messen kann. Manchmal, gerade bei interner Softwareentwicklung für interne Kunden, ist das nicht so klar sichtbar. Hier muss man sich wieder an Doug Hubbards Buch "How to Measure Anything" erinnern. Wenn eine Entscheidung wichtig ist, muss es ein Ergebnis geben. Wenn das Ergebnis für das Business relevant ist, muss es beobachtbar sein. Wenn es beobachtbar ist, könnte es messbar sein. Wenn es messbar ist, könnte man es mit diskreten Werten ausdrücken.

Bei Software müssen wir uns daran erinnern, dass sie per se nutzlos ist. Software hat nur einen Wert, wenn sie Arbeitsabläufe im Unternehmen verbessert. Sie hat einen Wert, wenn ich neue Dinge tun kann, die ich vorher nicht konnte. Sie hat einen Wert, wenn bestimmte Aufgabe deutlich schneller werden. Und sie hat einen Wert, wenn bestimmte Fehler oder Probleme nicht mehr auftreten. Alle diese Dinge kann ich mit Wahrscheinlichkeiten versehen und quantifizieren. Okay, das ist manchmal ziemlich mühsam. Oft reicht es aber schon, im Rahmen einer Retro ein paar Fälle durch zu spielen.

Sie können sich es auch leicht machen. Der Zweck des internen Dienstleisters ist es, interne Kunden zu finden, die für die Leistungen bereit sind zu bezahlen. Ein Kantinenbetreiber weiß schon, dass Schnitzel und Pommes nicht unbedingt gesundheitsförderlich für die Mitarbeiter sind. Aber wenn sie dafür bezahlen, reicht das schon für die Kantine. Sie hat Kunden gefunden. Ähnlich kann auch eine interne Abteilung, die Software für andere interne Abteilungen baut, sich darauf zurückziehen, dass alles OK ist, solange die Kunden für die Software bezahlen. Ob das gesund bzw. förderlich für das Unternehmen ist, müssen die Auftraggeber entscheiden.

Falls sich mehrere interne Kunden an der Finanzierung beteiligen, lohnt es sich gemeinsam die nächsten Releases zu planen. Für die Workshops mit den internen Kunden kann man sich dann bei den Innovation Games /7/ bedienen und zum Beispiel "Buy a feature" oder Speedboat spielen.

Wie komme ich an Kennzahlen?

Sie sehen schon, dass es keine allgemeingültigen Rezepte gibt. Bei Scrum ist uns Selbstorganisation wichtig. Wenn wir vor so einem kniffeligen Kennzahlenproblem stehen, ist es gute Praxis, alle Beteiligten mit einzubeziehen. Entweder in Form einer Retrospektive oder außerhalb des Scrum-Rhythmus Open Spaces anzusetzen.

Anmerkungen

  • /1/ OpenViewVenture: Scrum: Jeff Sutherland Breaks Down the Structure of Scrum, Youtube.de, Hochgeladen am 21.01.2011, abrufbar unter https://www.youtube.com/watch?v=O7cA1q0XwhE 
  • /2/ Christopher W. H. Davis: Agile Metrics in Action, Measuring and enhancing the performance of Agile teams, erscheint im Juli 2015. Manning. Mehr Informationen auf der Webseite des Verlags unter http://www.manning.com/davis2/
  • /3/ Humphrey, Watts S.: Introduction to the Personal Software Process. New.. Boston: Addison-Wesley Professional, 1997.
  • /4/ John Hunter: Thinking Required – Not Just a Recipe to Follow, The W. Edwards Deming Institute Blog, erschienen am 28. Juli 2014, abrufbar unter http://blog.deming.org/2014/07/thinking-required-not-just-a-recipe-to-follow/
  • /5/ Reinertsen, Donald G.: The Principles of Product Development Flow : Second Generation Lean Product Development. 1. Aufl.. Redondo Beach, California: Celeritas, 2009.
  • /6/ Hubbard, Douglas W.: How to Measure Anything : Finding the Value of Intangibles in Business. 3. Aufl.. New York: John Wiley & Sons, 2014. 
  • /7/ Hohmann, Luke: Innovation Games : Creating Breakthrough Products Through Collaborative Play. 1. Aufl.. Amsterdam: Pearson Education, 2006. Alle Übungen sind auch auf der Webseite des Autors beschrieben: http://www.innovationgames.com/resources/the-games/ 

Kommentare

  1. Lieber Jan,
    vielen Dank für den Artikel.
    Zwei Erkenntnisse sind mir besonders wichtig.
    Zum einen: Ein gemessener Prozess ist ein anderer als ein nicht gemessener Prozess. Kennzahlen tendieren dazu, sich zu verselbständigen. Zuerst überlegt man sich: "Ich müsste etwas mehr Bewegung haben." Dann denkt man sich die Kennzahl aus "gelaufene km pro Woche". Dann will man immer besser werden, und irgendwann wird das Laufen zum Fetisch und vom ursprünglichen Zweck abgekoppelt. Deshalb ist dein Hinweis so wichtig, dass die Kennzahlen dem Prozess dienen sollen und nicht umgekehrt.
    Zweitens: Die Gefahr ist noch größer, wenn Kennzahlen von außen vorgegeben werden. Messen dient dem Zweck, Prozesse beherrschbar zu machen. Wenn das Management die Kennzahlen besitzt, dann wird mit dem Prozess auch das Team fremdbeherrscht. Deshalb finde ich deine Maxime, dass das Team selbst die Kennzahlen bestimmt, so wichtig.
    Am besten sind Kennzahlen, wenn sie vom Kunden stammen (z. B. in Form von Zahlungswilligkeit) oder zumindest mit ihm abgestimmt sind. Dann bin ich am meisten gegen Fetischisierung gefeit, wie sie oben beim Lauftraining auftrat, weil ich dabei selbst mein eigener Kunde bin.

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Zu viel zu tun? Planen Sie Ihre ideale Woche

Wir hören immer wieder, dass Teams zu viel zu tun haben. Aber woher wissen wir eigentlich, was zu viel genau bedeutet? Hier ist ein ungewöhnlicher Tipp: Treffen Sie Annahmen über eine gute Menge. Planen Sie eine ideale Woche.

Transparenz als Schlüssel zum Erfolg: 20 Reflexionsfragen für moderne Organisationen

Transparenz ist das Herzstück erfolgreicher Teams. Sie schafft Vertrauen und fördert Zusammenarbeit. Wenn alle Zugang zu den notwendigen Informationen haben, können sie fundierte Entscheidungen treffen und gemeinsam Lösungen erarbeiten. Dies führt zu höherer Effizienz, schnelleren Entscheidungsprozessen und besseren Arbeitsergebnissen. Transparenz ist mehr als ein Schlagwort – es gilt, sie greifbar zu machen, ein gemeinsames Verständnis davon zu entwickeln und es in die Praxis umzusetzen. Wie das gelingt und welche Vorteile es für Euer Team und Eure Organisation bringt, erkunden wir im Folgenden.

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.

Wenn dein Team die Anforderungen blockt: 12 Tipps für Product Owner*innen

Liebe Product Owners, wir müssen reden. Schon wieder eine Anforderung, die im Nirgendwo landet? Zeit, das Ganze anders anzugehen. Ihr kennt das Spiel: Anforderungen sind ausgearbeitet, und doch läuft es im Team holprig. Was fehlt? Oft sind es Klarheit, realistische Erwartungen und ein bisschen Fingerspitzengefühl. Doch keine Sorge! Mit ein paar praktischen Tipps könnt ihr Missverständnisse vermeiden, Blockaden umgehen und den Entwicklungsprozess so richtig in Fahrt bringen – natürlich in Zusammenarbeit mit eurem Scrum Master. Hier sind zwölf Regeln, die euch helfen, das Team auf Kurs zu bringen und das Chaos in produktive Zusammenarbeit zu verwandeln. Wir zeigen dabei auch, wo der Scrum Master unterstützen kann, damit ihr eure Rolle als Product Owner noch besser erfüllen könnt. Häufige Stolperfallen: Warum Anforderungen oft scheitern Bevor wir ins Eingemachte gehen, kurz zu den typischen Stolperfallen. „Klare Anforderungen“? Klingt gut, scheitert aber sehr häufig an der realen Praxis.

Pragmatisch oder nur “Quick and Dirty”?

“Wir müssen aber pragmatisch vorgehen”, drängt der Kollege. Hm… Im Wörterbuch finde ich für “pragmatisch” in etwa: sachbezogenes, praktisches Handeln. Klingt gut. Leider zeigt sich in meinen Erfahrungen, dass pragmatisch für viele doch eher “quick and dirty” bedeutet. Es soll schnell fertig werden. Aber auf welche oder wessen Kosten? Wo ist die Grenze? Warum steht “praktisch” im Konflikt mit einem langfristigen “Nützlich”? Muss das sein?

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Meetings in Scrum Teams: Mehr Fokus, weniger Kontextwechsel

  Meetings in Scrum Teams: Mehr Fokus, weniger Kontextwechsel  „Wir arbeiten agil“ – das bedeutet für viele von uns: Daily Stand-up am Morgen, dann Refinement, dazwischen eine Demovorbereitung, später noch ein kurzes Scrum of Scrums (SoS) und am Nachmittag ein Community-Meeting. Gleichzeitig soll ich an meinen Sprint-Aufgaben arbeiten. Wenn dir diese Situation bekannt vorkommt, les dir gerne meinen Beitrag an. Hier sprechen wir über den Einfluss von häufigen Kontextwechseln auf die Arbeit in agilen Teams und zeigen Best Practices, um diese Wechsel zu minimieren. Viel Spaß & Let’s grow, Michi.  Foto von Matt Bero auf Unsplash

Wie schreibt man ein Fachbuch mit vielen Autor:innen?

Was gibt es zu beachten, wenn viele Menschen gemeinsam ein Buch schreiben? Was ist wichtiger: das Team oder die Technik? Wir geben einen Einblick in unsere Arbeit für das Buch „Agile Verwaltung 2024“.