Entwickler-Produktivität

Für den Fall, dass es im eigenen Unternehmen gerade nicht aufregend genug ist - eine der sichersten Möglichkeiten das zu ändern ist, sich jemanden aus der IT-Abteilung (oder aus einer Abteilung, die die IT beauftragt) zu suchen und mit ihm oder ihr ein Gespräch zum Thema Entwickler-Produktivität zu beginnen. Was das ist, ob sie in ausreichendem Ausmass vorhanden ist und wie man sie messen kann. So lässt sich schnell Stimmung in die Firma bringen.

Aber Scherz beiseite, das Thema ist tatsächlich ein Klassiker. Und dass es seit Jahrzehnten in zahllosen Unternehmen immer wieder diskutiert wird, zeigt, dass bei ihm noch grundlegende Fragen ungeklärt sind - zum Beispiel, was das überhaupt ist, Entwickler-Produktivität. Eine allgemein anerkannte Definition gibt es bis heute nicht, und die existierenden Definitionsversuche haben alle ihre Schwächen. Daher zunächst ein Überblick: welche Versuche gibt es, Entwickler-Produktivität zu definieren?

I. Code-Output

Aus klassischer Management-Sicht der naheliegendste Ansatz. Wie viele Zeilen Code wurden in welcher Zeit geschrieben? Das ist einfach verständlich, gut messbar - und völlig unsinnig. Warum, habe ich hier aufgeschrieben. Eigentlich war das auch bereits allgemein anerkannt, seit dem Aufkommen von KI in der Softwareentwicklung hat die Zählung von Code-Zeilen (die auf einmal so schnell erzeugt werden können wie nie) aber ein unerwartetes und unschönes Revival erlebt.

II. Increment-Output

Schon besser als der erste Ansatz. Die Zählung von Incrementen (entwickelten, getesteten, integrierten und deployeten Features) geht mehr in Richtung der Zählung nutzbarer Funktionalitäten, und wird u.a, von McKinsey empfohlen. Schwierig dabei ist, dass es selbst in dem selben System massive Unterschiede beim Erstellungsaufwand verschiedener Incremente geben kann. Und das ist etwas, was auch über die Zeit nicht besser wird (bei Systemen mit geringer Degradability sogar eher schlechter).

III. Story Points (oder vergleichbare Werte)

Die vermutlich am weitesten verbreitete Metrik in agilen Entwicklungsteams, vor allem in Extreme Programming, Scrum und SAFe. Das Problem: wenn sie so benutzt werden wie ursprünglich gedacht, entsprechen sie keinen Zeiteinheiten und lassen sich nur rückwirkend und im langfristigen Durchschnitt auf solche umrechnen. Das Vorgeben einer festen Umrechnung in Zeit ist zwar möglich, beseitigt aber die Vorteile, wegen denen Story Points überhaupt erfunden wurden (siehe hier).

IV. Output-Flussmetriken

Die klassischen Lean-Metriken. Gemessen wird nicht mehr wie viele Arbeitspakete fertig werden, sondern wie lange die Fertigstellung im Schnitt braucht, ob von der Idee bis zum Endabnehmer (Lead Time) oder auf Teilstrecken dazwischen (Cycle Time). Je kürzer, desto besser. Wird auf Systemebene optimiert, etwa durch Abbau von Flaschenhälsen zwischen Anforderungsmanagement und Entwicklung, bessere Übergaben, etc. Daher auch eine System-Metrik, nicht nur eine auf Entwickler-Ebene. 

V. Outcome-Flussmetriken

Ähnlich wie der letzte Metriken-Typ, aber mit einem klareren Focus auf der Durchschnittszeit bis zur Erzielung eines angestrebten Geschäftswertes. Klassiker sind die Time to Market und die Feedback Loop Time, möglich sind aber auch andere, etwa die Durchführungsdauer eines A/B-Tests oder die Zeit bis zur Skalierung auf 10.000 Nutzer. Da daran neben den Entwicklern auch Produktmanagement, Marketing und andere Einheiten beteiligt sind, ebenfalls eher eine Metrik für das Gesamtsystem.

VI. Qualitäts-Metriken

Wieder eine reine Entwickler-Metrik. Kann sowohl unmittelbare Qualitätsmessungen enthalten (z.B. die Bug Rate oder Incident Rate) als auch Messungen der Qualitätssicherung (z.B. der Testabdeckung oder des Live-Monitorings). Anders als man zunächst denken könnte ein durchaus zweischneidiges Schwert, da hohe Qualitätsstandards zu unverhältnismässigen Aufwänden für die Durchführung von Experimenten oder die Erstellung von Prototypen und MVPs führen können.

VII. Betriebswirtschaftliche Metriken

Damit kann man die Augen vieler Controller zum Glänzen bringen. Return on Investment, Cost of Delay, Ressourcenaufwand pro Feature (z.B. in Form von Token-Verbrauch) oder Höhe von Betriebs- und Wartungskosten versprechen eine Steuerbarkeit anhand von Business Value, allerdings sind auch diese Zahlen sowohl stark vom jeweiligen System abhängig (siehen oben, Degradability) als auch von der Arbeit von verschiedenen Nicht-Entwicklungseinheiten wie Marketing oder Vertrieb.

VIII. Auslastungs-Metriken

Wieder ein Klassiker, aber diesesmal einer, der verheerende Auswirkungen haben kann. Jede Arbeitsstunde mit Tätigkeiten zu verplanen mag wie ein guter Weg zu hoher Produktivität erscheinen, da dadurch Leerlauf vermieden wird, allerdings reicht dann eine einzige Verzögerung aus um einen Domino-Effekt zu erzeugen, der alles nach hinten verschiebt (siehe hier). Und dazu kommen noch die Zusatzaufwände durch Umplanung, Informationsverteilung, Triage, Eskalation, etc.

IX. Kombinierte / gewichtete Metriken

Naheliegenderweise gibt es Versuche, mehrere Metriken zu verbinden oder miteinander zu verrechnen. Bekannt sind vor allem WSJF (Cost of Delay geteilt durch Durchlaufzeit) und das von McKinsey popularisierte inner Loop / outer Loop, das Entwicklungs- und Abstimmungs-Ergebnisse ins Verhältnis zueinander setzt. Das Problem daran ist, das sie leicht zu mechanistischen oder über-vereinfachten Betrachtungen komplexer Systeme führen können, die der Realität nicht mehr gerecht werden.

***

Was man an all diesen Versuchen, Entwickler-Produktivität zu messen, merken kann, ist, dass man bei ihrer Anwendung relativ schnell auf Probleme stösst. Zum Teil (v.A. bei Output- und Qualitätsmetriken) können versehentlich falsche Anreize gesetzt werden, zum Teil (bei Outcome- und Betriebswirtschafts-Metriken) lässt sich nur die Produktivität einer Gesamt-Organisation messen, nicht hingegen die von einzelnen Teilbereichen wie der Software-Entwicklung.

Bedingt dadurch führt der Wunsch, Entwickler-Produktivität zu messen meistens in einen nicht auflösbaren Konflikt. Auf der einen Seite stehen dabei Management und Controlling, die ein berechtigtes Interesse daran haben, die eigene Produktivität empirisch nachvollziehbar und auf Datenbasis optimierbar zu machen, auf der anderen Seite die Entwickler, die ebenfalls zu Recht anmerken, dass das durch die Erhebung und Auswertung von Metriken nur sehr eingeschränkt möglich ist.

Am Ende kann in genau diesem Konflikt aber auch die Lösung liegen. Wenn es gelingt, ihn sachlich, fallbezogen und lösungsorientiert auszutragen, kann das zu Produktivitätsmessungen führen, die dem jeweils einzelnen Fall eher gerecht werden als eine Einheitslösung, die in jedem Fall zwar zum Teil passend, zum Teil aber auch unpassend ist. Man hat dann nicht mehr ein zentrales Dashboard für alle IT-Teams, dafür aber das Potential für echte Verbesserungen. Und darum geht es doch eigentlich.