Positiver Impact von Entwicklerbeiträgen

Im zweiten Blog bin ich darauf eingegangen, wie man das Dilemma Team-Produktivität versus Team-Illusion auflösen könnte. Und habe dabei die Konzepte der Knowledge/Contribution Islands (KI) und Knowledge/Contribution Balances (KB) eingeführt, um zu zeigen, wie eine gute Mixtur aussehen könnte, so dass beides, Developer-Leistungen und Team-Alignment incentiviert werden können. 

Developer Contribution/Knowledge Balances machen den Unterschied

Hier gehe ich einen Schritt weiter und behaupte, dass man den Impact einer guten bzw, mangelhaften Mixtur an Knowledge Island/Knowledge Balance (KI/KB) Anteilen messen kann. Denn die Bug-Dichte bzw. der Wartungsaufwand in der Entwicklung in den einzelnen Verzeichnissen lässt sich genauso messen.

Die Diagramme aus dem vorherigen Blog zeigen die Source Folder des Django Web Frameworks über die Jahre von 2019-2022 hinweg. Hier zeigen wir nochmals das Diagramm aus dem Jahr 2022:

Mittels der Bubble-Größe wird der Wartungsaufwand in den einzelnen Source Foldern wiedegegeben. Dabei lässt sich feststellen, dass die Folder im unteren linken Quadranten mit einer schlechten Mixtur an KI/KB-Werten oftmals sehr hohe Wartungsaufwände pro Jahr aufweisen. 

Das lässt nur einen Schluss zu: Knowledge Balances zahlen sich aus! Der Wartungsaufwand ist in den Code-Bereichen mit einem geringen KB-Anteil sehr oft wesentlich höher im Vergleich zu jenen mit einem KB-Anteil über 30%. 

Unsere Daten und Erfahrung aus einer Vielzahl an DETANGLE Analysen bestätigen diese Einsicht immer wieder. Übrigens, um zu wissen, wie wir mit DETANGLE Aufwände messen, sei auf dieses Whitepaper (Seiten 11-12) verwiesen.

• der Austausch per Chats in den Kollaborationstools zw. Product Owner und Entwickler
• die bidirektionale Zusammenarbeit an Issue Tracker Tickets zw. Product Owner und verantwortlichem Entwickler für das jeweilige Issue
• die bidirektionale Zusammenarbeit zw. Tester und Entwickler am Testcode 
• Lernprojekte in 2er oder 3er Gruppen zum Erwerb von neuem Wissen

Das sind alles mögliche Erweiterungen einer umfassenden KI/KB-Analyse, indem andere Datenquellen über Code-Repos hinaus mit analysiert werden. 

“Gaming” der Messungen

Als letztes gehe ich noch auf den Gaming-Einwand von Gergely Orosz ein, dass jede Metrik einem “Gaming” unterliegen kann: 

“When you measure in the open, aim for team outcomes and impact, not effort and output. People will figure out how to “game” what you measure, and optimize for this. Here’s what happens when you measure each of the areas:

Measure effort: create high-effort busywork of dubious value

Measure output: increase the quantity of the output by what’s easiest to do. This might not help with outcomes or impact.

Measure outcomes: aim to beat targets, even if this means taking shortcuts

Measure impact: get creative in reaching this with less effort and output”

Wie kann man das Gaming für die neu vorgeschlagenen Metriken verhindern? Antwort: gar nicht. Aber für diese Art des Gamings ist Zusammenarbeit wiederum nötig, über alle Entwickler und über Zeiträume hinweg. Denn Knowledge Balances sollten über die Zeit auch wechseln. “Konstante” Knowledge Balances, die über Paare von zwei Entwicklern abgesprochen sind, fallen über die Zeit auf, wenn diese sichtbar gemacht werden. 

Selbst der Fall, dass alle KB/KI-Anteile abgestimmt zwischen den Entwicklern über einen längeren Zeitraum mit Absicht “künstlich” hergestellt werden würden, bedarf eines hohen Maßes an “Gaming”-Zusammenarbeit zwischen Entwicklern. Was zum einen wiederum definitiv zum Team-Alignment beiträgt, und zum anderen die Tendenz in sich trägt, dass Entwickler dieses Vorgehens irgendwann doch überdrüssig werden und stattdessen der Einfachheit halber im beabsichtigten Sinne kooperieren.

Links

[0] Image by storyset on Freepik