In vielen „Agilen Projekten“ in denen ich in verschiedensten Rollen tätig war, kam am immer wieder die Frage auf: Wie messen wir jetzt, ob das Team gut ist oder schlecht? Wie messen wir die Performance des Teams und haben die Transparenz und das Wissen, ob wir regulierend oder unterstützend eingreifen müssen?
Zunächst einmal sind das die falschen Fragen, aber wer aus der klassischen projektorientierten Entwicklung kommt, stellt diese sich nun mal. Sehr oft wurden die Metriken hier eingesetzt, die Scrum mit sich bringt, Burn Down Chart und Velocity Chart.
Während das Burn Down Chart nur unwesentlichen Informationsgewinn auf die oberen Fragen liefert - schließlich messen wir nur den Fortschritt des Sprints, sollte das Velocity Chart in 99% der Fälle vollkommen missverstanden und damit falsch interpretiert werden.
In tatsächlich so gut wie allen Projekten wurde hiermit die Umsetzungsperformance des Teams „gemessen“ und mit anderen Teams verglichen. Man brauchte eine Größe, um den Output des Teams zu messen und das sah doch ganz gut aus. Ich sehe jeden Sprint, wie viele Story Points das Team erledigt hat, wie viel Durchfluss ich habe. Erhöht sich dieser nicht kontinuierlich, kann ich Maßnahmen treffen, damit das Team besser arbeitet und noch mehr Aufgaben schafft.
Clevere Teams machen sich das natürlich zunutze. Sie schneiden die Aufgaben kleiner, so dass mehr Tickets in den Sprint genommen werden können. Sie schätzen die Tickets höher, so dass auch noch mehr Story Points abgearbeitet werden.
Sie kommt aus der Industriewelt. Bei der industriellen Herstellung von Waren ist es gang und gäbe den Gewinn zu steigern, in dem ich die Produktion bei Beibehaltung der Qualität und der Produktionszeit erhöhe. Ich produziere also mehr Stück der gleichen Ware in gleicher Zeit und bei möglichst gleicher Qualität. Diese Denkweise prägt auch die führenden Köpfe in einem Projekt: Ich muss nur den Durchfluss erhöhen und schon schaffe ich gleich mehr Arbeit, erbringe mehr für das Projekt.
So sieht auch in „Agilen Projekten“ dann meist die Sprint-Planung aus. Jeder Sprint soll die Velocity steigern. Es sollen mehr Tickets, mehr Story Points umgesetzt werden.
Und hierin liegt der große Irrtum. Geistige Arbeit lässt sich nicht beliebig skalieren. Probleme bei der Entwicklung von Software sind immer individuell und es zahlen verschiedenste Dinge auf die Lösung des Problems ein.
Angefangen vom Menschen selbst, der das Problem lösen soll, bis hin zu seiner Arbeitsumgebung, der verwendeten Programmiersprache, den eingesetzten Frameworks und vielen weiteren Dingen, die die Umsetzung bzw. Lösung eines Problems beeinflussen.
Am Ende zahlt der Output, den unsere Entwickler:innen liefern, aber nicht auf die Qualität und Güte unseres Produkts ein. Der Kunde oder Nutzer unserer Applikationen hat nichts davon, wenn wir möglichst viel machen. Wir müssen vom industriellen Fokus weg, hin zur Orientierung, was dem Kunden am meisten bringt.
Hier kommt der Outcome ins Spiel. Outcome ist der tatsächliche (Mehr-)Wert den der Kunde / Nutzer mittelbar oder unmittelbar von unserer Entwicklung hat. Diesen zu messen ist selbstverständlich etwas aufwändiger und bedarf zunächst eines sehr breiten Wissens des Produkt-Owners / Business-Owners über den Markt und den Kunden. Ich muss jetzt neben einer Aufwandsschätzung jede Story und jeden Epic mit einem entsprechenden Business Value beziffern.
Dies ist natürlich nur möglich, wenn ich entsprechend den Wert der Story für den Kunden einschätzen kann. Vermutlich für eine Vielzahl der Product- und Business-Owner eine große Herausforderung.
Anschließend messen wir nicht mehr den Durchsatz an Tickets, sondern den erbrachten Business Value pro Sprint. Die Maßeinheiten für unsere Teams haben sich also dahingehend geändert welchen Mehrwert sie für den Kunden erzeugen. Dies kann sicherlich pro Sprint variieren, aber gerade auch technische Schulden oder Improvements lassen sich durch das Beziffern eines Wertes für den Kunden wesentlich besser in einer Produktplanung zeitnah realisieren als normalerweise üblich.
Wichtig ist aber auch hierbei, sich den kritischen Blick auf die Zahlen zu bewahren, denn für alle Kennzahlen gilt, es finden sich immer auch Wege, die den ursprünglichen Zweck in eine andere Richtung verschieben.