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.
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.
Für die eigene Qualitätsbewertung finde ich die Kennzahlen aus dem "Personal Software Process" (PSP) /3/ nach wie vor aktuell.
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.
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/
Lieber Jan,
AntwortenLöschenvielen 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.