Messen von Entwicklerproduktivität

Ja, Entwicklerproduktivität kann gemessen werden, …

Das schreiben die Autoren von McKinsey in einem am 17. August 2023 veröffentlichten Artikel. Kann der gewählte Zugang in der Entwicklung von Softwareprodukten funktionieren? Wurde hier die Softwareentwicklung revolutioniert? TLDR: Nein. Der Rest im Artikel.

Systemische Metriken vs Individuelle Metriken

Die Autoren des McKinsey Artikels gehen davon aus, dass systemische Metriken wie Deployment-Frequenz keine nützliche Metrik sind, weil sie nicht die Performance eines Individuums, sondern die des Teams misst. Ich halte diese Metriken für die wertvollsten Metriken in einem Team, weil diese alle Faktoren der Softwareentwicklung mit einbeziehen, und nicht lokale Optimierungen in den Vordergrund stellen.

Stellt man lokale Optimierungen in den Vordergrund, werden oft einzelne, gemessene Bereiche schneller. Es leiden dann aber andere Faktoren, die das gemeinsame Ziel (zB. eine abgeschlossene Softwareversion) verlangsamen.

Der Vorschlag der Autoren ist eine Contribution Analysis. Die Methode wird hier nur als proprietäre Analyse auf Basis von JIRA beschrieben. Diese Methode ist nicht neu oder innovativ. Jede stark Issue-Tracking basierte Organisation, die ich kenne, hatte eigene Entwicklermetriken in ihren Excelsheets. Sie hatten alle eines gemeinsam: sie führten zu falschen Schlüssen. Auf den zweiten Blick nehmen sich Entwickler:innen, die schlecht in solchen Metriken abschneiden:

  • Komplizierte Tasks
  • Zeit um Teamkolleg:innen zu unterstützen
  • Zeit um andere Teams im Unternehmen zu unterstützen
  • Zeit um dem Support Fragen zu klären
  • usw.

Sie können einen großen Anteil am Backlog-Erfolg anderer haben.

Auf Unternehmensebene ist der Einsatz systemischer Metriken, die den Erfolg des Teams messen, die bessere Wahl. Individuelle Metriken können teamintern eingesetzt werden, um Verbesserungsmöglichkeiten zu finden. Diese Metriken haben aber außerhalb des Teams nichts verloren.

Inner Loop vs. Outer Loop Tasks

Die Autoren beschreiben, dass “Top Tech Companies” 70% mit “Inner Loop” Tasks und 30% mit “Outer Loop” Tasks verbringen. “Inner Loop” beschreiben sie als Build, Code, Test. “Outer Loop” beschreiben sie nicht vollständig zB als Meetings, Deploy at Scale, Security and Compliance, und Integrate.

Diese Aufteilung ist nicht zielführend. Dass undefinierbare Top Tech Companies eine 70-30 Aufteilung zwischen diesen Tasks haben, hilft im Management nicht weiter. Ein Produkt wird nicht besser oder schneller wenn es diese Aufteilung hat. Es heißt auch nicht, dass dein Produkt schlecht gemanaged ist, wenn es eine andere Aufteilung hat.

Weiters sprechen die Autoren davon, dass Outer Loop Tasks jene sind, die Entwickler:innen weniger gern machen. Auf der anderen Seite reihen sie Testing als “Inner Loop” Task ein. Diese Trennung bestätigt Vorurteile, die Manager:innen Entwickler:innen oft gegenüberbringen. Menschen und ihre Interessen sind aber vielseitiger als das.

Ich kenne gute Entwickler:innen, die:

  • Am liebsten keine Unit Tests schreiben (aber den Mehrwert erkennen)
  • Sich gerne um Deployments kümmern
  • Gerne Sicherheit im Produkt verbessern
  • Integrationstests verbessern
  • Sich in Meetings für ein besseres Produkt einsetzen
  • Unglücklich sind, wenn ihr Produkt nicht eingesetzt wird

Gute Leads arbeiten nicht mit Vorurteilen, sondern lernen ihr Team kennen, helfen dabei, dass Teammitglieder ihre Stärken einsetzen können und fördern den Austausch zwischen Teammitgliedern mit unterschiedlichen Stärken, wenn es notwendig ist.

Low Value Added Tasks

Die Autoren beschreiben den Erfolg eines Transformationsprojektes, in dem eine Firma erfolgreicher wurde, indem Low-Value-Added-Tasks wie die Provisionierung von Infrastruktur, das Ausführen von Tests und die Bearbeitung von Testdaten automatisiert wurden. Diese Tasks fügen aber nicht wenig Value im Produkt hinzu. Diese Tätigkeiten unterstützen den Erfolg des Produktes indem sie sicherstellen, dass die Applikation so wie vorgesehen in der Zielumgebung läuft und eine klare Beschreibung der notwendigen Infrastruktur existiert, dass erwartetes Verhalten beschrieben und über die Lebensdauer der Applikation überprüft werden kann, und dass sichergestellt wird, dass die Entwickler mit realitätsnahen Modellen der realen Welt testen können.

Sollten diese Tätigkeiten keinen Wert im Produkt haben, sollten sie weggelassen werden.

Auch hier ist es gefährlich, wenn Manager:innen solche Tasks für Low-Value-Added halten. Wird die Arbeit an solchen Tätigkeiten nicht mehr finanziert, obwohl sie wichtig sind, führt das zu Qualitätsproblemen, unzufriedenen Kunden und Fehlschlägen.

Die Entscheidung, welche Tasks wichtig und nicht wichtig sind, sollte in einem Dialog innerhalb des zuständigen Teams getroffen werden. Entscheidungen, die so tief in Operatives eingreifen, sollten nicht von teamfernem Management getroffen werden.

C-Level should learn the basics

Als Handlungsempfehlung geben die Autoren unter anderem, dass das C-Level Management die Basics des Softwareentwicklungsprozesses lernen soll. Die Vorstellung, dass das C-Level Management Supermenschen sind, die einfach alles im Unternehmen lernen und verstehen sollen, ist hoch gegriffen. Management sollte das Ziel haben, dass ihre Softwareentwicklungsteams sich gut aufstellen können. Es sollte sicherstellen, dass

  • die Entwicklungsteams eigenständige Entscheidungen treffen können, die den Erfolg des Produktes vorantreiben
  • dass die notwendigen Kommunikationsschnittstellen und damit der Informationsfluss zu den Entwicklungsteams funktioniert
  • dass Projekte und Softwareprodukte im wirtschaftlichen Kontext des Unternehmens sinnvoll sind
  • dass Metriken existieren, die Fortschritt und wirtschaftlichen Erfolg der Teams transparent machen (aber nicht feingranularer)
  • dass Teams aus denjenigen Mitarbeiter:innen bestehen, die notwendige Entscheidungen auf Teamebene treffen können, um gute Metriken zu erreichen

C-Level Management, welches sich mit Schlagwörtern und Basics in den Softwareentwicklungsprozess einmischt, ist kontraproduktiv. Stattdessen sollte es lernen, welche Informationen im Entwicklungsprozess eines Projektes wertvoll sind, und bereit sein, Zeit zu investieren, um diese Information in hoher Qualität zur Verfügung zu stellen.

Bad metric in the end

Dass C-Level Management sich nicht in die Entscheidungen individueller Teams einmischen sollte, zeigt auch ein Beispiel im letzten Abschnitt des Artikels. Die Autoren empfehlen hier, dass Unternehmen investieren sollten, um den Entwicklungsprozess ihrer Systeme zu instrumentieren. Ein guter Vorschlag und eine wichtige Tätigkeit, um innerhalb eines Teams den Erfolg steuern zu können.

Die Metrik, die beispielhaft angeführt wird (Code coverage of automated tests) ist aber eine schlechte teamübergreifende Metrik. Projekte mit 100% Testabdeckung beweisen nur, dass der Code genau das macht, was im Code und Test angeführt ist. Es zeigt nicht, dass das Projektteam die Anforderungen richtig versteht, Performance mit vielen Daten funktioniert, Anwender:innen die Applikation verwenden können usw.

Teams müssen anhand ihrer Anforderungen entscheiden können, wo Automatisiertes effizient und effektiv ist. Es können aber auch andere Methoden eingesetzt werden, um gut und schnell zu einem korrekten System zu kommen (zB geeignetes Errormonitoring im Produktivsystem, …)

Weiterführende Links