Team-Produktivität versus Team-Illusion - 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

“There is no such thing as ‘a team’.” 

Jan Bosch

Die Kontroverse nach dem Widerspruch

Der Artikel von McKinsey mit dem Titel "Yes, you can measure developer productivity" [1] hat in der Software-Engineering-Gemeinschaft viel Widerspruch hervorgerufen. Die Autoren schlugen vor, die Produktivität von Entwicklern zu messen, indem sie die DORA- (DevOps Research and Assessment) und SPACE- (Satisfaction, Performance, Activity, Comm. & Coll. and Efficiency) Metriken durch "opportunity-focussed metrics" wie Developer Velocity Index, Contribution Analysis Metriken und einen Talent Capability Score ergänzen.

Der Vorschlag endete mit einer Antwort [2, 3] von Kent Beck (einer lebenden Legende in der Softwareentwicklung) und Gergely Orosz (ebenfalls mit viel Erfahrung in der Softwareentwicklung), die bei vielen Entwicklern auf Linkedin und auf pragmmaticengineer.com großen Anklang gefunden hat

Ich habe beides gelesen, den McKinsey-Artikel (vor meinem Sommerurlaub), und bin später (nach dem Urlaub) auf die Antwort gestoßen. Viele Leute und Entwickler schienen mit der Antwort zufrieden zu sein. Das erste Zitat ganz oben fasst die Antwort in einem Satz recht gut zusammen.

Dann stieß ich auf den Blog von Jan Bosch über Team Illusion [4]. Er widerspricht der Antwort zwar nicht offen, aber sie gibt Anlass zu einer neuen Kontroverse.

Deshalb habe ich beschlossen, meine eigene Sicht niederzuschreiben. Ich werde einen Ansatz zur Bewältigung dieser Herausforderungen in einer Blogserie beschreiben. Lassen Sie mich die eigentliche Kontroverse, die ich sehe, als ersten aus einer Reihe von drei Blogs niederschreiben. 

Kent Beck und Gergely Orosz haben ein mentales Modell der Softwareentwicklung vorgestellt und zeigen, dass Produktivitätskennzahlen in eine von vier Kategorien eingeordnet werden können:

• Effort: Aktivitäten wie Planung, Codierung usw.
• Output: greifbare Dinge, die aus dem Aufwand resultieren, z. B. Funktionen, Code, Design-Dokumente usw.
• Outcome: das Kundenverhalten als Ergebnis des Outputs, z. B. könnte ein Kunde dank gewisser Features während des Onboarding-Prozesses keine Schwierigkeiten erfahren und das ganze flüssiger werden.
• Impact: Als Ergebnis dieser Verhaltensänderung fließt ein Wert an das Engineering (Unternehmen) zurück, z. B. in Form von Feedback, Einnahmen oder Empfehlungen.

Kent Beck und Gergely ordnen nicht nur die von McKinsey vorgeschlagene Produktivität diesem Modell zu, sondern auch die DORA-Kennzahlen, einige SPACE-Produktivitätskennzahlen und Kennziffern aus anderen Bereichen wie Sales und Recruiting.

Ich habe die Zuordnungen in einer Tabelle zusammengefasst, die einen Überblick über alle gibt:

DORA (DevOps Research and Assessment)
McKinsey (Opportunity-focussed metrics)
SPACE (Satisfaction, Performance, Activity, Comm. & Coll. and Efficiency)
SALES/RECRUITMENT

Sie argumentieren, dass die von McKinsey vorgeschlagenen Produktivitätskennzahlen für Entwickler alle im Bereich Effort/Output angesiedelt sind und dass es im Vergleich zu Sales oder Recruiting es fast unmöglich ist, gültige individuelle Produktivitätsmetriken für Entwickler im Bereich Outcome/Impact im Gegensatz zu Team-Produkitivätsmetriken zu finden sind:

“The earlier in the cycle you measure, the easier it is to measure. And also the more likely that you introduce unintended consequences. Let’s take the extreme of measuring only profits. The good news is that everyone is aligned, across the company! The bad news: attributing who contributed how much to the profit is nearly impossible! You can ‘fix’ the attribution question by measuring outputs, or effort. But the cost is that you change people’s behavior, as it incentivizes them to game the system to ‘score’ better on those metrics.”

Sie schlagen vor, sich stattdessen auf die Team-Produktivität zu konzentrieren, und begründen dies wie folgt:

1. “Please the customer at least once per team, per week. This output might not sound so impressive, but in practice is very hard to achieve.”
   
   
2. “Delivering business impact committed to by the team. There is a good reason why “impact” is so prevalent at the likes of Meta, Uber, and other fast-moving tech companies. By rewarding impact, the business incentivizes software engineers to understand the business, and to prioritize helping it reach its goals.”
    
3. “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.”
   
   
4. “Team performance is easier to measure than individual performance. Engineering teams track performance by projects shipped, business impact (e.g. revenue, profit generated, churn reduced etc), and other indicators, similarly to how sports teams track performance via numbers of wins, losses, and other stats.” 

Wir könnten uns nun mit folgender Ansicht zurücklehnen: Ok, wir können die Entwicklerproduktivität nicht wirklich gut messen, ohne dass die Entwickler die Ergebnisse beeinflussen. Aber es kommt auf das Team und seine Produktivität an. Und diese muss indirekt durch teambildende Maßnahmen, ein gutes Arbeitsklima und eine gute Führungskultur gefördert werden.

Aber Teamproduktivität ist leichter gesagt als getan. Jan Bosch hat es in seinem Blog mit der folgenden Aussage sehr gut auf den Punkt gebracht.

There is no such thing as “a team”

Interessanterweise bin ich kurz nach der Lektüre des McKinsey-Artikels auf den Artikel von Jan Bosch mit obigem Titel gestoßen.  Er stellt fest, dass "der Begriff des Teams eine Illusion oder bestenfalls ein unerreichbares platonisches Ideal" ist, selbst für agile Teams im Kontext der Softwareentwicklung, denn:

• “different disciplines approach challenges in very different ways, which easily leads to conflicts. A typical example is between user experience (UX) folks and engineers.”
  
  
• “there often is a conflict between those who are more inclined toward architecture and have a long-term focus and those who are more concerned with simply getting functionality implemented, even if it means incurring some technical debt.”
  
  
• “as humans, we have different temperaments, but one of the common behaviors is to seek to climb higher up in the hierarchy” und “the reputational, informal hierarchy is just as relevant for most of us"

Daher stellt sich die Frage, ob Teambuilding und die anderen Maßnahmen wirklich ausreichen, um ein gutes Team aufzubauen und indirekt seine Produktivität zu steigern. Brauchen wir nicht konkrete Vorschläge, Maßnahmen und Anreize, um die Produktivität von Teams zu fördern? Und können wir deren Erfüllung und Wirkung nicht auch ohne "Gaming"-Einflüsse messen? 

Auf diese Fragen werde ich im folgenden Blog Entwickler-Beiträge und Team-Produktivität eingehen. In der Tat können die Beiträge von Entwicklern die Teamproduktivität beeinflussen. Und es gibt Möglichkeiten, sie zu messen.

Links

[0] Photo by Pixabay

[1] Yes, you can measure software developer productivity 

[2] Measuring Developer Productivity, Part 1

[3] Measuring Developer Productivity, Part 2

[4] There’s no such thing as “the team”