Wie sich Entwickler-Beiträge auf die Team-Produktivität auswirken - Cape Of Good Code

"Individual performance does not directly predict team performance. And if it’s not possible to deduct team performance from individual performance in a domain that’s as easy to measure as sports, then we can expect even less success in software engineering.”
        
Kent Beck and Gergely Orosz

“Developer contribution patterns DO influence team productivity and these can be identified and measured.” 

Egon Wuchner

Developer-Produktivität UND Team-Alignment anstreben

Ich habe im ersten Blog den Widerspruch zwischen Team-Produktivität versus Team-Illusion angesprochen. Als Reaktion auf die Antwort von Kent Beck und Gergely Orosz auf den McKinsey Artikel zur Messung der Developer-Produktivität. Sie argumentieren, dass Developer-Produktivität schlecht gemessen werden kann und dass man stattdessen auf die Team-Produktivität achten und Kennzahlen dazu ableiten sollte. 

Andererseits habe ich auf den Post von Jan Bosch zur Team-Illusion aufmerksam gemacht, dass es sowas wie ein “Team” nicht gibt, da Teammitglieder durchaus miteinander um Positionen in der offiziellen Organisationshierarchie oder der inoffiziellen “Reputations-Hierarchie” miteinander konkurrieren. 

Als Schlussfolgerung ziehe ich daraus, dass es auf folgendes ankommt:

1. zum einen, dass Team-Alignment zu stärken, um die Effekte der Team-Illusion abzumildern und damit implizit die Team-Produktivität zu fördern
   
   
2. zum anderen jedem Entwickler die Möglichkeit zu geben, Zeit für sich allein zu erhalten, um produktiv allein an Dingen zu arbeiten und diese zu vollenden, und sich dabei auch ein klein wenig selbst zu verwirklichen und auch Anerkennung für gute Einzelleistungen zu erhalten, auf die er verweisen kann.

Daraus ergeben sich mehrere Fragen:

1. Wie können wir die Beiträge des einzelnen Entwicklers zum Team-Alignment nachweisen, sichtbar machen und incentivieren (womit wir die Team-Produktivität erhöhen würden)?
   
   
2. Wie können wir die Einzelarbeiten eines Entwicklers ausweisen, für die er alleinige “Urheberschaft” erheben und stolz sein kann (womit wir die einzelne Developer-Produktivität erhöhen würden)?
   
   
3. Wie können wir dabei eine gute Mixtur beider Gesichtspunkte erreichen und diese in der Balance halten?

Nun, die beste Art des Knowledge-Sharings und des Team-Buildings ist die bidirektionale Zusammenarbeit. Also nicht drei, oder vier oder ev. mehr Leute, die an einer Sache “zusammenarbeiten”, sondern GENAU zwei. Lasst uns diese Paare “Knowledge Balances” (KB) oder “Contributor Balances” nennen.  

Dazu gibt es folgende Ausgestaltungen zwischen zwei Entwicklern:

• Pair Programming ist die 100%tige und ideale Inkarnation solch einer Kollaboration. Dies wird aber meiner Erfahrung nach leider selten praktiziert.
  
  
• Eine gemeinsame Schnittmenge an Code, an dem genau ZWEI Entwickler gleichzeitig über eine gewisse Zeit arbeiten. Dadurch lernen sie den Code des anderen kennen, die Denkweise, Practices/Prinzipien des anderen zu verstehen und sie tauschen sich dazu automatisch aus. 
  
  
• Code Review der Arbeit eines Entwicklers durch einen zweiten Entwickler.

Komplementär dazu lasst uns die Einzelarbeit eines Entwicklers an separaten Code-Bereichen “Knowledge Islands” (KI) oder “Contributor Islands”nennen. Das wäre eine Kennzahl der alleinigen, produktiven Arbeit des Einzelnen mit Anerkennungspotential.

Was es nun als Ziel zu erreichen gilt, ist eine gute Mixtur der beiden Knowledge Islands und Balances im Code. Die Inseln dürfen natürlich auch nicht zu groß werden, da sonst ein Knowledge Loss Risiko besteht. Und die Balances  sollten nicht zu klein sein, da sonst kein ausreichender Austausch zwischen den Entwicklern stattfindet. 

Das Idealbild könnte so aussehen:

• 50% Aufwand eines Entwicklers in Knowledge Islands und 50% in Balances
• Die Code-Bereiche und Entwickler hinter den KIs und KBs sollten über die Zeit variieren

Nun ist ein Idealbild eben ein Idealbild und schwer zu erreichen. Daher stellen wir etwas weichere Anforderungen auf:

• ein gleitender KI-Bereich zw. 40-60% wären schon mal gute Richtwerte
• ein realistischer KB-Wertebereich zwischen 20-40% als Mindestmaß
• eine erkennbare Menge an KI/KB-Cluster über die Zeit hinweg

Die folgenden Diagramme aus unserer Analyse mittels des DETANGLE® Tools von Cape of Good Code zeigt die prozentualen KI- und KB-Anteile am LOC-Wert (Lines of Code) der einzelnen Source Folder des Django Web Frameworks über die Jahre von 2019-2022 hinweg:

Die x-Achse zeigt den KB-Prozentanteil und die y-Achse den KI-Prozentanteil an LOC pro Source Folder an. Dabei werden die LOC der Files gezählt, die im jeweiligen Zeitraum für die Entwicklung neuer Features bzw. der Bearbeitung der Cleanup/Optimization Tickets verändert wurden. Maintenance-Arbeit zum Fixen von Bugs werden explizit bei dieser Bewertung ausgeschlossen (wir kommen darauf im nächsten Blog noch zurück).

Der untere linke Quadrant zeigt die kritische Menge an Folder, die einen sehr geringen Knowledge Balance- UND einen geringen Knowledge Island-Anteil aufzeigen, also Folder, die weder dem KI- noch dem KB-Ideal entsprechen. Im oberen linken Quadranten befinden sich die Folder mit einem hohen Knowledge-Island Anteil, aber einem sehr kleinen KB-Anteil. Der untere rechte Quadrant stellt generell den guten Fall dar, dass der Knowledge Balance Anteil höher als 30% liegt und der Knowledge Island nicht Überhand genommen hat.

Allgemein gilt, je näher das Verzeichnis am Schnittpunkt der beiden Werte von 50% für KI und 30% von KB liegt, desto besser ist die Mixtur an KI- und KB-Anteilen. 

Beobachtungen

Die Zahl der kritischen Folder im unteren linken Quadranten nimmt ab über die Jahre. Die Menge der Folder im “guten” rechten Quadraten überwiegt immer mehr bei der Entwicklung des Django Web Frameworks. 

Auffällig ist auch, dass sich immer mehr Folder in Richtung der Diagonale von den Werten (KB=0%, KI=100%) links oben nach (KB= 100%, KI= 0%) rechts unten bewegen. D.h. dass an immer mehr Foldern nur noch die Arbeit von Einzel- UND Zweier-Teams an Entwickler verrichtet wird, wenn auch in unterschiedlichem Mischungsverhältnis. Diese Entwicklung ist sehr positiv zu bewerten, da es viel damit schon viel leichter fällt, dieses Verhältnis noch weiter Richtung KI=50%, KB = 30% zu verändern.

Die allgemeinen Ziele und abgeleitete Maßnahmen sollten folgende sein:

1. Nur sehr wenige Folder im unteren linken Quadranten zuzulassen, weil sie weder dem Team-Alignment noch der Developer-Produktivität zuträglich sind. Hier muss das Team besprechen, wie Verantwortlichkeiten geklärt werden können und welche Zweier-Teams in nächster Zeit an welchen dieser Folder vorwiegend zusammen die weiteren Arbeiten verrichten.
   
   
2. Nur ein kleiner Teil der Folder sollte im oberen linken Quadranten akzeptiert werden. Hier sollten sich einige der dahinterstehenden Einzelentwickler zu mehr bidirektionaler Arbeit mit anderen Teammitgliedern bereit erklären.
   
   
3. Das übergeordnete Ziel besteht darin, die überwältigende Mehrheit der Folder im unteren rechten Quadranten über die Zeit hinweg wiederzufinden. Die oben vorgeschlagenen Maßnahmen zum Erreichen dieser Ziele könnten geprüft und incentiviert werden.

Soweit so gut. Es sieht danach aus, dass bei der Entwicklung des Django Web Frameworks der Spagat von Team-Alignment und Developer-Produktivität im großen und ganzen recht gut erreicht wird.

Bisher haben wir aber die Bubble-Größe der Folder noch nicht angesprochen. Sie stellt den jeweiligen Wartungsaufwand (Maintenance Effort/ME) dar. Und damit kommt vielleicht sogar der wichtigste Aspekt mit ins Spiel, auf den ich im letzten Blog Positiver Impact von Entwicklerbeiträgen dazu noch eingehen werde. Ich behaupte, dass man damit auch den Impact einer guten bzw, mangelhaften Mixtur an KI/KB Anteilen messen kann. Ein Impact, der sich auch beim Kunden bemerkbar macht.

Links

[0] Photo by Andres Ayrton