Für einen Projektmanager ist die Leistung seiner Mitarbeiter sicherlich nicht uninteressant. Das Wissen über die Leistung von Mitarbeitern kann hilfreich sein den Projekterfolg sicherzustellen. Wenn niemand wirklich arbeitet, dann kann das Projekt keinen Fortschritt machen. Wenn jeder Mitarbeiter effektiv und effizient arbeitet, dann ist der Projekterfolg wahrscheinlicher, als wenn niemand wirklich arbeitet. Auch für die Mitarbeiter kann das Messen der eigenen Leistung interessant sein, wenn diese eine leistungsgerechte Vergütung erhalten möchten. Außerdem bietet erst das Messen der Leistung einen Anhaltspunkt dafür, ob sich ein Mitarbeiter persönlich weiterentwickelt. Wenn du persönliche Weiterentwicklung, leistungsgerechte Bezahlung und erfolgreiche Projekte im Kontext der Software-Entwicklung interessant findest, dann könnten auch die DORA Metriken für dich interessant sein.

Es hat es schon viele Versuche gegeben die Leistung von Software-Entwicklern zu messen. Ein einfacher und verbreiteter Ansatz ist das Untersuchen von erfolgreich abgeschlossenen Tickets von Software-Entwicklern. Je mehr Tickets ein Software-Entwickler oder auch ein Team in einem festgelegten Zeitraum schließt, desto bessere Arbeit leistet er bzw. das Team. Diese Metrik wird beispielsweise mit einem Burndown-Chart visualisiert. Es wird ein Zeitraum festgelegt, in welchem ein Team eine festgelegte Anzahl von Tickets erledigen soll. Zu einem gegebenen Zeitpunkt zeigt der Burndown-Chart an, wie viele der geplanten Tickets bereits umgesetzt wurde. Je mehr der geplanten Tickets bereits umgesetzt wurden, desto besser. Um die Produktivität von Software-Entwicklern anhand der geschlossenen Tickets zu messen, muss zuvor der Aufwand der Tickets geschätzt werden. Die Leistung des Software-Entwicklers ist dann das Verhältnis zwischen geplantem Aufwand und tatsächlichem Aufwand.

Das Problem dieses Ansatzes ist, dass der Aufwand für Tickets im Voraus nicht genau geschätzt werden kann. Manchmal wird angenommen, dass die Bearbeitung eines Tickets mehrere Tage dauert, und in der Realität dauert es nicht einmal einen Tag. Manchmal wird angenommen, dass die Bearbeitung in nur wenigen Stunden zu erledigen ist, aber in der Realität dauert es eine ganze Woche. Das Problem: Der Großteil des Aufwands lässt sich auf Probleme zurückführen, welche im Voraus nicht absehbar waren.

Nassim Taleb greift in seinem Buch The Black Swan (Taleb, 2017) das Phänomen von unvorhersehbaren Ereignissen auf. Er spricht davon, dass unvorhersehbare Ereignisse einen disproportional großen Effekt auf den Verlauf der Geschichte haben. Niemand konnte beispielsweise vorhersagen, dass es 2008 zu einer Weltfinanzkrise kommen würde. Wer sein Kapitel in einem Zeitraum von 2000 bis 2023 angelegt hat wird aber feststellen, dass dieses Ereignis einen disproportional großen Einfluss auf seine Rendite nahm. Das Konzept lässt sich auf die Aufwandsschätzung übertragen.

Es sind die unvorhersehbaren Probleme, welche den größten Einfluss auf die Entwicklungszeit nehmen. Und gerade die Probleme, welche im Voraus nicht vorhersehbar sind, sind der Grund, warum Software-Entwickler gebraucht werden, um Software zu schreiben. Wäre die Entwicklung von Software berechenbar und planbar, dann wäre die gesamte Entwicklung der Software bereits automatisierbar. Der Großteil der Arbeit von Software-Entwicklung ist also die Lösung von unvorhersehbaren Problemen. Dementsprechend kann auch der Arbeitsaufwand nicht geschätzt werden.

Wenn der Arbeitsaufwand nicht geschätzt werden kann, dann kann auch nicht die Leistung von Software-Entwicklern gemessen werden. Denn die Aufwandsschätzung muss in diesem Fall als Maßstab dienen, mit welcher der Arbeitsaufwand des Software-Entwicklers verglichen wird. Wenn es also nicht möglich ist die Leistung eines Software-Entwicklers anhand der Anzahl und Größe der abgeschlossenen Tickets zu messen, wie ist es dann stattdessen möglich die Leistung von Software-Entwicklern zu bestimmen?

Hier kommen die DORA-Metriken ins Spiel. Die DORA Metriken orientieren sich nicht an der Leistung einzelner Software-Entwickler, sondern an messbaren, objektiven Qualitätskriterien des Entwicklungsprozesses eines Teams. Die Annahme ist, dass Teams besser sind, je häufiger sie in der Lage sind die Software zu veröffentlichen, je seltener dabei Fehler auftreten und je schneller aufgetretene Fehler korrigiert werden. Aus dieser Annahme ergeben sich die DORA-Metriken Deployment Frequency, Lead Time, Mean Time To Recover und Change Failure Rate. Sie werden im Folgenden näher erläutert:

Deployment Frequency: Die Deployment Frequency gibt an, wie häufig neue Änderungen auf der Produktionsumgebung veröffentlicht werden.

Lead Time: Die Lead Time ist die Zeit zwischen dem Pushen eines Commits und der Veröffentlichung auf der Produktionsumgebung. Wenn bereits Continuous Delivery praktiziert wird, dann durchläuft der gepushte Code eine Code-Pipeline, welche damit endet, dass der neue Code direkt auf der Produktionsumgebung veröffentlicht wird. In diesem Fall ist die Lead Time die Laufzeit der Pipeline. Wenn allerdings kein Continuous Delivery praktiziert wird, dann kann die Lead Time wesentlich höher sein.

Mean Time To Recover: Die Mean Time To Recover gibt an, wie lange es im Schnitt dauert einen kaputten Produktionsstand zu reparieren.

Change Failure Rate: Die Change Failure Rate gibt an, wie viele der Veröffentlichungen in Produktion einen Fehler verursachen. Wenn der Produktionsstand in den letzten drei Monaten drei Mal aktualisiert wurde, und zweimal ist nach der Aktualisierung ein Fehler in Produktion aufgetreten, dann liegt die Change Failure Rate bei 66%.

Die DORA-Metriken sind aus dem Grunde besonders interessant, weil sie eine statistische signifikante Korrelation mit Mitarbeiterzufriedenheit, Kundenzufriedenheit und Unternehmenskennzahlen aufweisen. Um diese Korrelationen zu erörtern, wurden Teams zunächst geclustert, also in Gruppen aufgeteilt. So lassen sich Teams anhand der vier DORA-Metriken in Low Performer, Medium Performer und High Performer aufteilen. Die nachfolgende Tabelle zeigt, dass High Performer in der Lage sind, Änderungen in unter einer Stunde On-Demand zu veröffentlichen. Dabei treten nur selten Fehler auf. Im Gegensatz dazu brauchen Low Performer bis zu sechs Monate, um Änderungen zu veröffentlichen, wobei wesentlich häufiger Fehler auftreten.

High Performer Medium Performer Low Performer
Deployment Frequency On-Demand 1 Woche – 1 Monat 1 – 6 Monate
Lead Time < 1 Stunde 1 Woche – 1 Monat 1 – 6 Monate
Mean Time to Recover < 1 Stunde < 1 Tag < 1 Tag
Change Failure Rate 0-15% 1-45% 6-30%
Tabelle 1: Werte von DORA Metriken in verschiedenen Teams (PhD. Nicole Forsgren, 2018)

Es konnte gezeigt werden, dass der Einsatz von Continuous Delivery mit den DORA Metriken korreliert. Das bedeutet, dass Teams, welche Continuous Delivery verwenden, laut den DORA Metriken besser performen. Weiterhin konnte gezeigt werden, dass Unternehmen mit High Performance Entwicklungsteams eine höhere Kundenzufriedenheit, sowie Mitarbeiterzufriedenheit erreichen. Gemessen werden diese anhand des Net Promoter Scores1. Entsprechend der höheren Mitarbeiterzufriedenheit konnte festgestellt werden, dass es durch den Einsatz von Continuous Delivery zu weniger Burnout und „Deployment Pain“ kommt. Als Deployment Pain wird der psychologische Druck bezeichnet, welcher mit der Veröffentlichung des aktuellen Softwarestands einhergeht. Dazu gehören auch Überstunden am Wochenende, weil es bei der Veröffentlichung zu Problemen kam.

Entsprechend der höheren Kundenzufriedenheit konnte gezeigt werden, dass die Performance der Organisation positiv mit dem Einsatz von Continuous Delivery korreliert. Das bedeutet, dass Unternehmen, welche Continuous Delivery forcieren, bessere Unternehmenskennzahlen besitzen, wie zum Beispiel Umsatz.

Literaturverzeichnis

PhD. Nicole Forsgren, J. H. (2018). Accelerate: Building And Scaling High Performing Technology Organizations. Portland: IT Revolution.

Taleb, N. (2017). The Black Swan: The impact of the highly improbable. London: Taylor and Francis.