Der schlechteste Programmierer, den ich kenne (2023)

• Dieser Text erklärt, wie der Versuch scheiterte, die Produktivität eines Teams zu messen
• Es wurde beschlossen, individuelle Leistungskennzahlen für Bewertung und Weiterentwicklung einzuführen
  • Kennzahlen wie Codezeilen oder Bug-Anzahl wurden wegen ihrer hohen Manipulierbarkeit ausgeschlossen; stattdessen sollte die Leistung über Story Points oder die Anzahl ausgelieferter Stories gemessen werden

Tim Mackinnons Leistung ist „0“

• Mit Tools zur Messung der Teamproduktivität (Jira usw.) wurde die Leistung aller Teammitglieder erfasst
• Tims Leistungswert war 0 → weil er keinen einzigen Story Point erfasst hatte
• Der Manager forderte, Tim zu ersetzen, da seine Leistung bei 0 liege

Warum Tim Mackinnon keine messbare Leistung brachte

• Tim übernahm Stories nicht direkt
• Stattdessen konzentrierte er sich auf Pair Programming mit anderen Teammitgliedern
  • Er arbeitete mit weniger erfahrenen Entwicklern zusammen und half ihnen, Probleme selbst zu lösen
  • Er löste Probleme nicht direkt, sondern half durch Fragen dabei, selbst zu einer Lösung zu kommen
  • Mit Senior-Entwicklern dachte er gemeinsam über Probleme nach und verbesserte Lösungen
• Tim schrieb nicht selbst direkt Code, verbesserte aber die Gesamtleistung des Teams

Tim Mackinnons tatsächlicher Beitrag

• Tims Beitrag lässt sich nicht mit individuellen Leistungswerten messen
• Dank Tim verbesserten sich die Produktivität des gesamten Teams und die Codequalität
• Wenn Tim mitarbeitete, wurden schnellere und bessere Ergebnisse erzielt

Umstellung der Bewertung auf Teamproduktivität

• Dem Manager wurde Tims Beitrag erklärt und die Möglichkeit gegeben, ihn zu beobachten
• Nachdem bestätigt wurde, dass sich die Leistung des gesamten Teams verbessert hatte, wurde die individuelle Leistungsmessung aufgegeben
• Die Bewertung wurde von individueller Leistung auf Teamleistung und Business Impact umgestellt

Zusammenfassung (tl;dr)

• Produktivität sollte an Business-Ergebnissen gemessen werden (z. B. Kostensenkung, Umsatzgenerierung usw.)
• In komplexen Systemen ist die Messung individueller Leistung nicht sinnvoll
• DORA Metrics sind Werkzeuge zur Messung der Systemleistung, nicht zur Messung individueller Beiträge
• Wenn sich die Gelegenheit ergibt, mit Tim Mackinnon zu arbeiten, sollte man sie nicht verpassen

[bus710]

Tatsächlich entfernt man sich, wenn man über Senior hinaus in Richtung Staff Engineer geht, zunehmend von dem Code, der tatsächlich ins Feld ausgerollt wird ... Stattdessen coacht man eher Senior- und Junior-Leute. Man muss sich auch das Gejammer der Manager anhören ... und wenn ein Problem auftritt, wird man von überallher dazugeholt, um Lösungen vorzuschlagen.

So sieht die Arbeit dann aus, und Jira-Tickets und Story Points lassen sich dabei unmöglich quantitativ erfassen.

[castedice]

Als Tech Lead mache ich solche Aufgaben ziemlich häufig. Ähnlich ist es auch mit dem Versuch, auf Story Points basierende Quantifizierung einzuführen, aber zum Glück ist das Unternehmen nicht so groß, sodass die Mitarbeitenden einschließlich der Führungsebene verstehen, welche Rolle ich habe, und deshalb scheint es aktuell keine Probleme zu geben.
Wenn die Organisation wächst, werde ich wohl auch über Methoden zur Quantifizierung nachdenken müssen.

[kallare]

Kam mir vor wie eine Geschichte, die ich schon irgendwo gesehen hatte … ist also ein Text aus dem Jahr 2023.
Der gleiche Beitrag wurde schon vor 2 Jahren einmal gepostet: https://de.news.hada.io/topic?id=10680

[crawler]

Sie sind wohl so jemand wie GitHub Copilot....

[GN⁺]

Hacker-News-Kommentare

• Die Produktivität einzelner Entwickler zu messen, ist unsinnig. Codezeilen oder Story Points zu messen, ist das Gegenteil von Produktivität. Wichtig ist, dass Entwickler mit weniger Code mehr Wert schaffen.

  • Es ist wichtig, Geschäftsergebnisse zu messen, aber es ist schwer, sie einem bestimmten Entwickler zuzuordnen.
  • Am Ende ist es besser anzuerkennen, dass man sich zwangsläufig auf subjektive Urteile stützen muss.

• Sie haben eine Methode gefunden, Probleme zu lösen, indem sie Tims Namen an ein Ticket hängen. Die Teammitglieder werden bereitwillig helfen.

  • Produktivitätsmetriken sind nicht völlig wertlos. Wenn man im Team das Verhältnis von PRs zu Jira-Tickets betrachtet, kann man erraten, wer der Teamleiter ist.

• Es freut mich, dass Tim im Team geblieben ist und die Prozesse in die richtige Richtung gelenkt hat. Es braucht Manager, die zuhören.

  • Durch OKRs werden Entwickler isoliert. Persönliche statt teambezogene OKRs verursachen Probleme.
  • Das Lösen von Problemen dauert lange. Wegen der OKRs konnte keine Hilfe in Anspruch genommen werden.

• Ein Modell, in dem ein Programmierer ohne eigene Aufgaben nur allen anderen hilft, ist seltsam.

  • Es wäre gesünder, wenn Tim wie die anderen Stories übernimmt und bei Bedarf die Gruppe um Hilfe bittet.
  • Wenn das Team sehr unausgewogen ist, sollte Tim eine Mentorrolle übernehmen.

• Es ist seltsam, dass Tim keine eigenen Aufgaben übernimmt. Um die Teamproduktivität zu maximieren, braucht es ein Gleichgewicht zwischen individueller Leistung und Teamzusammenarbeit.

  • Tim war vielleicht zu geduldig und hat dadurch Zeit verschwendet.

• Wenn Tim nichts Eigenes zum Team beiträgt, würde ich ihn auffordern, die Arbeit zu beginnen und Stories auszuliefern. Es ist gut, dass Tim anderen hilft, aber er muss auch seine eigenen Aufgaben erledigen.

• Nicht alles muss eine Gruppenaktivität sein. Wenn ein durchschnittlicher Entwickler ohne Tims ständige Hilfe keine Features liefern kann, gibt es ein Problem im Team.

  • Die Softwareentwicklung braucht Zeit sowohl für Einzelarbeit als auch für Gruppenarbeit.

• Die besten Teams haben immer jemanden wie Tim. Tims Hilfe überträgt sich auf andere, und so wächst das gesamte Team.

  • Wenn Entwickler nicht weiterkommen, versuchen sie zuerst, es selbst zu lösen, und bitten bei Bedarf um Hilfe.

• Die Produktivität von Entwicklern mit Story Points zu messen, ist keine gute Idee. Ein Entwickler namens Zero bekam keine Stories zugewiesen und half stattdessen dem Team.

  • Der Manager verstand die Bedeutung von Zero. Wenn Zero nicht da war, wurden wichtige Releases sogar verschoben.

• Den Wert von Support zu quantifizieren, ist schwierig. Aber Support ist unverzichtbar. Man muss darauf vertrauen, dass Führungskräfte das richtig beurteilen.