Team-Produktivität schlägt Developer-Produktivität. Andererseits geben wir uns der Team-Illusion hin. Die wahre Kontroverse ist doch die: wie kann man Team-Alignment erreichen?
"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:
Individual productivity
Team productivity
Effort
inner/outer loop time spending talent capability score
developer velocity index
Output
contribution analysis metrics
Outcome
total $ of closed deals close percentage number of heads filled
deployment frequency lead time for changes mean time to recover story points completed handsoff
Impact
developer satisfaction retention interruptions percentage of target hits percentage of target hits
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:
“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.”
“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.”
“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.”
“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 BlogEntwickler-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.
Entwickler-Produktivität und Team-Alignment schließen sich nicht aus. Es kommt auf die richtige Mischung an Einzel- und Team-Beiträgen der Entwickler...
Fallstrick Nummer eins beim Stack Ranking von Entwicklern: rein kompetitiv bewerten und die Kollaboration unter den Tisch fallen lassen. Und zweitens...