Vor etwa zehn Jahren habe ich einen Blogbeitrag mit dem Titel "Can we measure Developer Productivity?" verfasst. In diesem Rahmen habe ich die zahlreichen objektiven Versuche, die Entwicklerproduktivität zu messen (Codezeilen, Funktionspunkte, etc.) diskutiert und dabei vorgeschlagen, einige subjektive Kennzahlen einzubeziehen. Mein damaliges Fazit: Entgegen der Wunschvorstellungen KPI-verliebter Manager sah ich damals keine praktikable Möglichkeit, die Produktivität einzelner Developer zu messen.

Das erwähne ich deshalb, weil sich die Dinge in den letzten Jahren deutlich verändert haben. Zum Zeitpunkt der Artikelerstellung kämpften mit Git und Mercurial zwei Quellcodekontrollsysteme um die Vorherrschaft in den Entwicklungsabteilungen. Als Softwaremanager verantwortete ich zu dieser Zeit die Migration von Microsofts Visual Source Safe zu Mercurial, für das wir uns wegen seiner Windows-Freundlichkeit entschieden.

Dabei haben wir bekanntermaßen auf das falsche Pferd gesetzt: Inzwischen gilt Git als De-Facto-Standard für die Versionskontrolle. Infolgedessen hat sich um Git-Repositories eine eigene Branche gebildet. Wie wertvoll die ist, zeigt beispielsweise der Kauf von GitHub durch Microsoft für 7,5 Milliarden Dollar. Die Entwicklung hat auch dazu geführt, dass viele Unternehmen inzwischen Metriken für ihren Git-Code anbieten - und dabei auch nahelegen, sie könnten die Produktivität von Softwareentwicklern messen.

Her mit den Kennzahlen

Wenn wir davon ausgehen, dass es tatsächlich möglich ist, die Developer-Produktivität zu messen (wovon ich nicht ganz überzeugt bin), müssen wir uns fragen, ob das eine gute Idee ist. Das Management dürfte es begrüßen: Führungskräfte wollen wissen, welche Entwickler am besten performen und wünschen sich Metriken, die Sie bei der Leistungsbeurteilung unterstützen. Auch die Personalabteilung dürfte Interesse daran haben, Performance-Probleme zu dokumentieren - und CEOs wollen vor allem wissen, ob das Budget, das Sie zur Verfügung stellen, effektiv genutzt wird.

Selbst wenn Sie neuartige Tools einsetzen, um die individuelle Entwicklerproduktivität zu messen - die Messgrößen, die dabei angelegt werden, sind oft nicht mehr als ein schlechter Witz und vor allem leicht manipulierbar - etwa die Anzahl der geschriebenen Codezeilen. Wenn Sie Developer an solchen Metriken messen, können Sie davon ausgehen, dass sich alle Teammitglieder auf dem Papier verbessern werden. Dafür bezahlen Sie allerdings einen hohen Preis in Form der Team-Produktivität: Wenn Entwickler "gegeneinander" gemessen werden, entsteht eine Konkurrenzsituation - die noch verschärft wird, wenn es um Gehalt oder Beförderungen geht. Teamgeist und -work rückt so in weite Ferne.

So messen Sie richtig

Erfolg in Sachen Softwareentwicklung ist letztendlich Teamarbeit und beruht nicht auf einzelnen Devs: Ein Entwicklungsteam bespricht den Entwurf und die Umsetzung eines bestimmten Projekts, bevor der Code geschrieben wird. Wenn die einzelnen Entwickler den Code schreiben, geschieht das oft mit Hilfe von Teamkollegen, die Fragen beantworten und Einblicke geben. Alle Teammitglieder überprüfen und genehmigen die Arbeiten im Rahmen von Code-Reviews - sie arbeiten zusammen, um die Dinge voranzutreiben.

Deshalb sollten Sie davon absehen, die Produktivität einzelner Entwickler zu messen und stattdessen auf das gesamte Team abstellen. Schließlich dürfte es auch im Interesse des Managements liegen, dass die Entwickler im Team zusammenwirken und auf ein gemeinsames Ziel hinarbeiten. (Anmerkung der Redaktion: Zumal das ganze Thema - anders als vielleicht im Rest der Welt - bereits rein rechtlich in Deutschland anders gelagert ist, sofern es im Unternehmen einen Betriebsrat gibt - hierzulande gibt es zum Thema Leistungskontrolle und -überwachung von Mitarbeitern klar definierte Mitbestimmungsrechte und -pflichten nach dem Betriebsverfassungsgesetz).

Dabei ist den Entwicklungs-Teams sehr bewusst, dass sie ihren Erfolg steigern, wenn sie ihre Team-Metriken verbessern. Wenn die Benefits sichtbar werden, steigt die Motivation zusätzlich, sich weiter auf die richtigen Tasks und Kennzahlen zu fokussieren. Denn Teams wollen ihre Produktivität verbessern und gute Ergebnisse erzielen - teambezogene Kennzahlen zu messen, unterstützt sie dabei.

Als ich vor zehn Jahren gefragt habe, ob wir die Produktivität von Entwicklern messen sollten, beziehungsweise können, habe ich die falsche Frage gestellt. Ein einzelner Entwickler ist nur so stark wie sein Team. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.