Wie Sie die Produktivität Ihrer Entwickler messen – und wie nicht

Wenn Sie Produktivitätskennzahlen für die Softwareentwicklung verwenden, um die Leistung Ihrer Entwickler zu beurteilen, dann machen Sie etwas falsch. Die besten Ergebnisse erzielen Sie, wenn Sie sie mit Geschäftsergebnissen verknüpfen. [...]

Die Ermittlung der Anzahl der abgeschlossenen Releases ist ein Schritt in eine bessere Richtung, aber auch diese Metrik bedarf einer Klärung (c) pixabay.com

Ich erschaudere, wenn Entwicklerteams mir erzählen, dass ihr Unternehmen sie dazu zwingt, Stunden in Jira Software, Azure DevOps oder einem anderen agilen Management-Tool zu erfassen, das sie verwenden. Die Erfassung von Stunden ist verständlich und für professionelle Dienstleistungsunternehmen, die ihren Kunden oft Zeit und Material in Rechnung stellen, oft erforderlich. Aber für die meisten Unternehmen ist die Auswahl von Buchhaltungsmetriken zur Quantifizierung der Entwicklungsproduktivität ein Antipattern, das aus den Managementpraktiken von Command and Control übernommen wurde.

Es gibt eine lange Liste von anderen Produktionsmetriken, die ebenfalls problematisch sind. Die Produktivität nach fertiggestellten Codezeilen zu berechnen? Das ist ein guter Weg, um Entwicklungsteams zu ermutigen, die Organisation mit technischen Schulden aus aufgeblähten Codebases zu belasten. Messen Sie die Anzahl der gelieferten User Stories oder Story Points? Das ist nur eine Aufforderung an die Entwickler, Features in mehr Storys aufzuteilen oder ihre Story-Point-Schätzungen aufzublähen.

Die Ermittlung der Anzahl der abgeschlossenen Releases ist ein Schritt in eine bessere Richtung, aber auch diese Metrik bedarf einer Klärung. Produktions-Releases, die Defekte einführen, größere Zwischenfälle verursachen oder schlechte Endbenutzererfahrungen liefern, müssen anders gekennzeichnet werden als erfolgreiche Implementierungen.

Es ist klar, dass die Messung der Softwareentwicklungsproduktivität mit vielen Herausforderungen verbunden ist. Einer der Experten, mit denen ich darüber sprach, Sagar Bhujbal, der VP of Technology bei Macmillan Learning ist, warnte, dass die Wahl der falschen Metriken die Moral des Teams beeinträchtigen kann:

Die Produktivität von Entwicklern sollte nicht an der Anzahl von Fehlern, Lieferverzögerungen oder Zwischenfällen gemessen werden. Das verursacht unnötige Ängste bei den Entwicklungsteams, die immer unter dem Druck stehen, mehr Funktionen schneller und besser liefern zu müssen. Sorgen Sie stattdessen für psychologische Sicherheit und passen Sie den Betriebsrahmen kontinuierlich an und verbessern Sie die Entwicklungspraktiken.

In diesem Artikel werden wir untersuchen, wie Produktivitätskennzahlen bei Softwareentwicklern und Entwicklungsteams eingesetzt werden können, um nicht nur deren Produktivität und Moral zu verbessern (und ihnen nicht zu schaden), sondern auch um die Geschäftsergebnisse zu verbessern.

Verwenden Sie keine Produktivitätsmetriken für die Entwicklung, um die Leistung zu bewerten

Ich bin ein starker Befürworter der Erfassung von Entwicklungs- und Devops-KPIs und -Metriken, um Verbesserungen in den Prozessen, der Qualität und ja, der Produktivität voranzutreiben. Das Hauptproblem besteht darin, dass Unternehmen Produktivitätsmessungen mit Team- oder individuellen Leistungszielen gleichsetzen. Das Problem ist, dass die Gleichsetzung von Produktivität und Leistung ohne den richtigen Kontext oft zu unerwünschten Verhaltensweisen führt, wie z. B.:

  • Die Entwicklung von mehr Funktionen, die nur geringe Auswirkungen auf das Geschäft haben.
  • Die Freigabe von mehr Software ohne Berücksichtigung von Risiken, Sicherheit, Qualität und betrieblichen Auswirkungen.
  • Innovation ohne einen realisierten Pfad zur Produktion für erfolgreiche Experimente.

Wenn ich mit Personalverantwortlichen spreche oder die Gesamtleistung einer Softwareentwicklungsgruppe bespreche, versuche ich daher, über die Produktivität hinaus ein breiteres Spektrum von Maßnahmen abzudecken.

Produktivitätsmessungen in der Entwicklung für das Unternehmen nutzen

Wo können also Produktivitätsmessungen bei Softwareentwicklungsteams angewendet werden, um die Geschäftsergebnisse zu verbessern? Konkret sollten Produktivitätsverbesserungen dem Unternehmen helfen, den Umsatz zu steigern, die Erfahrung der Endbenutzer zu verbessern, die Qualität zu erhöhen, die Kosten zu senken, Innovationen zu ermöglichen, strategische Fähigkeiten bereitzustellen, die Zusammenarbeit zu verbessern, die Effizienz zu steigern, den Zugang zu Informationen zu vereinfachen oder Risiken zu reduzieren.

Die Softwareentwicklung (und die IT im Allgemeinen) trägt häufig zu diesen Geschäftsergebnissen bei, und die ergebnisbasierten KPIs sollten den Kontext für alle Softwareentwicklungs- (und IT-)Kennzahlen bilden. Die operative Seite dieser KPIs sollte Metriken darüber sein, wie effektiv das Team die festgelegten Werte und Standards erfüllt hat.

Es gibt eine wachsende Anzahl von Erkenntnissen über diese Metriken. Hier sind einige Beispiele:

  • Zu den Metriken für die Softwareentwicklung, die heute von Bedeutung sind, gehören agile Metriken wie Zykluszeit und Teamgeschwindigkeit und Produktionsmetriken wie die mittlere Zeit bis zur Behebung.
  • Einige clevere Produktivitätsmetriken konzentrieren sich auf Verhaltensweisen wie abgeschlossene Code-Reviews, geschriebene Dokumentation und Gespräche mit anderen, die Produktivität, Qualität und Zusammenarbeit erfassen.
  • Der Vergleich von wertschöpfenden Aktivitäten wie Softwaredesign, Testen und Integrationen mit nicht wertschöpfenden Aktivitäten wie dem Konfigurieren von Umgebungen, dem Streiten über Implementierungsprobleme oder dem Schreiben von neuem Code, um herauszufinden, wie der vorhandene Code funktioniert.

Bei der Betrachtung einiger dieser Produktivitätsmaße lohnt es sich, die Deltas im Vergleich zu den aktuellen Metriken zu bewerten. Wenn Teams die Geschwindigkeit und die Zykluszeiten verbessern oder die Fehlerausbruchsrate und die mittlere Reparaturzeit reduzieren, dann verbessert sich wahrscheinlich die Produktivität des Teams.  

Verwenden Sie Entwicklungsproduktivitätsmessungen zur Verbesserung der Produktivität

Eines der Ziele der Produktivitätsmessung sollte die Optimierung von Investitionen sein, die Produktivitätsverbesserungen liefern. Investitionen, die Softwareentwicklungsteams dabei helfen, mehr Zeit und Energie auf die Lösung priorisierter Geschäftsprobleme zu konzentrieren, fallen in diese Kategorie. Einige Beispiele:

  • Automatisieren von Deployments mit CI/CD, anstatt sie manuell auszuführen.
  • Standardisierung von Umgebungen mit Infrastructure-as-Code (IaC) und Containern, um manuelle Konfigurationen zu minimieren und durch Systemunterschiede bedingte Fehler zu reduzieren.
  • Automatisierung von Regressionstests, so dass Entwickler Bugs während des Entwicklungsprozesses beheben und weniger Zeit für die Untersuchung und Behebung von Fehlern aufwenden müssen, die in der Produktion gefunden werden.

Bhujbal von Macmillan Learning weist auf die Bedeutung von Teamverhalten und Tools hin, die die Produktivität beeinflussen. „Immaterielle Maßnahmen wie weniger Reibungsverluste und eine nahtlose Zusammenarbeit mit den Fachabteilungen sowie die Optimierung von Werkzeugen werden letztlich dazu beitragen, die gewünschten und zeitnahen Ergebnisse zu erzielen.“

Produktivitätsmetriken sollten sich auf die Geschäftsergebnisse konzentrieren

Martin Davis, ein erfahrener CIO bei Southern Company Services, betont ebenfalls, dass man sich auf den Geschäftswert und die Ergebnisse konzentrieren sollte:

Je mehr die IT ihre Produktivität anhand von Geschäftsmetriken messen kann, desto leichter kann das Senior Management den Wert verstehen. Ich würde immer versuchen, unsere Entwicklungsproduktivität in Form von zusätzlichen Funktionen oder gelösten Geschäftsproblemen zu messen und idealerweise versuchen, den Mehrwert in Euro zu beziffern. Auf diese Weise kann man das Gespräch von der IT als Kostenfaktor auf die IT als Wertanbieter lenken.“

Ramki Ramaswamy, VP of IT, Technology, and Integrations bei JetBlue, stimmt Davis zu, dass die Entwicklungsproduktivität ein Faktor für den gelieferten Wert sein sollte, und er fügt die Risikobeseitigung als zweiten Faktor hinzu. „Die Entwicklungsproduktivität wird normalerweise in Stunden oder Defekten oder Dollar angegeben“, sagt er, „aber sie sollte idealerweise in Wert (Rendite, Chancen, betriebliche Einsparungen) pro ausgegebenem Euro gegenüber dem Risiko (Sicherheit, Chancen) des Nichtstuns gemessen werden.“

Die Ratschläge von Ramaswamy und Davis stimmen mit dem überein, was meiner Meinung nach der wichtigste agile KPI ist. Letztlich sollten Teams zuerst die Geschäftsergebnisse messen und diese dann mit Metriken qualifizieren, die das angestrebte Verhalten veranschaulichen. Die Darstellung von KPIs, die Ergebnisse und Lieferqualifikationen kombinieren, helfen bei der Beantwortung der Frage, wer, was, warum und wie man Software von hoher Qualität liefert. Diese KPIs sind weitaus aussagekräftiger als die Konzentration auf einen Haufen von Metriken auf niedriger Ebene.

Sobald diese KPIs definiert sind, erhalten Technologie- und Prozessverbesserungen viel mehr Kontext und Bedeutung sowohl für Softwareentwickler als auch für das Unternehmen. Ein Beispiel:

  • Ein Entwicklungsteam, das aufgefordert wird, die Kundenzufriedenheitsmetriken als Geschäftsergebnis zu verbessern, kann sich dafür entscheiden, sich auf die Verbesserung der mittleren Zeit bis zur Behebung von Problemen und der Fehlerausbruchsraten zu konzentrieren.
  • Wenn Entwicklungsteams Verbesserungen bei diesen Metriken nachweisen, sollten sie zum Ausdruck bringen, wo sie in Produktivitätsverbesserungen investieren, z. B. in die Automatisierung, die Entwicklung von Dokumentation oder die Reduzierung technischer Schulden.
  • Wenn Entwicklungsteams Verbesserungen erzielen, sollten sie die Kundenzufriedenheit messen und über die ausgewählten Metriken berichten.

KPIs, die Geschäftsergebnisse und Metriken zur Entwicklerproduktivität kombinieren, helfen bei der Beantwortung der Frage: „Erreicht das Team die priorisierten Geschäftsergebnisse und verbessert gleichzeitig seine Produktivität?“ Da Teams nicht alles auf einmal verbessern können, sollten Unternehmen darauf achten, Teams zu fördern, die umsichtige Entscheidungen treffen, die Ergebnisse liefern und gleichzeitig die Produktivität verbessern.

*Isaac Sacolick ist der Autor des Amazon-Bestsellers „Driving Digital: The Leader’s Guide to Business Transformation through Technology“, der viele Praktiken wie agile Planung, Devops und Data Science behandelt, die für erfolgreiche digitale Transformationsprogramme entscheidend sind. Sacolick ist ein anerkannter Top-Social-CIO, Influencer für digitale Transformation und mitwirkender Redakteur bei CIO.com und Social, Agile, and Transformation.


Mehr Artikel

Die Teilnehmer des Roundtables (v.l.n.r.): Roswitha Bachbauer (CANCOM Austria), Thomas Boll (Boll Engineering AG), Manfred Weiss (ITWelt.at) und Udo Schneider (Trend Micro). (c) timeline/Rudi Handl
News

Security in der NIS2-Ära

NIS2 ist mehr ein organisatorisches Thema als ein technisches. Und: Von der Richtlinie sind via Lieferketten wesentlich mehr Unternehmen betroffen als ursprünglich geplant, womit das Sicherheitsniveau auf breiter Basis gehoben wird. Beim ITWelt.at Roundtable diskutierten drei IT-Experten und -Expertinnen über die Herausforderungen und Chancen von NIS2. […]

Christoph Mutz, Senior Product Marketing Manager, AME, Western Digital (c) AME Western Digital
Interview

Speicherlösungen für Autos von morgen

Autos sind fahrende Computer. Sie werden immer intelligenter und generieren dabei jede Menge Daten. Damit gewinnen auch hochwertige Speicherlösungen im Fahrzeug an Bedeutung. Christoph Mutz von Western Digital verrät im Interview, welche Speicherherausforderungen auf Autohersteller und -zulieferer zukommen. […]

Andreas Schoder ist Leiter Cloud & Managend Services bei next layer, Alexandros Osyos ist Senior Produkt Manager bei next layer. (c) next layer
Interview

Fokus auf österreichische Kunden

Der österreichische Backup-Experte next layer bietet umfassendes Cloud-Backup in seinen Wiener Rechenzentren. Im Interview mit ITWelt.at erläutern Andreas Schoder, Leiter Cloud & Managed Services, und Alexandros Osyos, Senior Produkt Manager, worauf Unternehmen beim Backup achten müssen und welche Produkte und Dienstleistungen next layer bietet. […]

Miro Mitrovic ist Area Vice President für die DACH-Region bei Proofpoint.(c) Proofpoint
Kommentar

Die Achillesferse der Cybersicherheit

Eine immer größere Abhängigkeit von Cloud-Technologien, eine massenhaft mobil arbeitende Belegschaft und große Mengen von Cyberangreifern mit KI-Technologien haben im abgelaufenen Jahr einen wahrhaften Sturm aufziehen lassen, dem sich CISOS ausgesetzt sehen. Eine große Schwachstelle ist dabei der Mensch, meint Miro Mitrovic, Area Vice President DACH bei Proofpoint. […]

Be the first to comment

Leave a Reply

Your email address will not be published.


*