Technische Schulden
Fallstrick Qualität beim Stack Ranking im Software Engineering
Fallstrick Nummer zwei beim Stack Ranking von Entwicklern: die Software-Qualität vernachlässigen!
Fallstrick Nummer eins beim Stack Ranking von Entwicklern: rein kompetitiv bewerten und die Kollaboration unter den Tisch fallen lassen. Und zweitens ...
“SAP-Chef will schlechte Mitarbeiter identifizieren lassen”
Süddeutsche Zeitung (Dezember 7, 2023)
“Stack Ranking Makes a Comeback”
Virginia Backaitis
Stack Ranking für Software Entwickler?
Eine der Meldungen im IT-Bereich Ende des Jahres 2023 hat für Schlagzeilen gesorgt. SAP-Chef Christian Klein “vermisst offensichtlich den Leistungsgedanken” und möchte die Mitarbeiter in Performer/Achiever bzw. Improver einordnen und bewerten lassen [1].
Auch international scheint dieses sogenannte Stack Ranking ein Comeback zu erleben [2]. Es gibt genügend Berichte, wonach einige Digitalkonzerne dieses Verfahren schon immer angewendet haben. Amazon wird auch in dem Artikel zum Comeback auch ausdrücklich erwähnt.
Die Frage stellt sich nun, ob Stack Ranking für die Softwareentwicklung und deren Softwareentwickler das richtige ist. Sicherlich kann man z.B. Projektleiter, Product Owner, selbst Software-Architekten bzw. Technische Koordinatoren, wie bei Amazon praktiziert wird, durch ein Komitee bewerten lassen, da deren Arbeit sich mittels Meßgrößen in Bezug zu Produktfeatures und Kundenzufriedenheit bewerten lässt.
Aber wie sollte das Komitee für die Bewertung von Softwareentwicklern/innen aufgestellt sein? Wir möchten in diesem und einem folgenden Blog auf zwei Fallstricke aufmerksam machen und konkret zeigen, auf welche Kriterien beim Stack Ranking der Software Entwickler zu achten wäre.
Kompetitive UND kollaborative Aspekte
Zurück zur Frage. wie eventuell das Komitee für die Bewertung von Softwareentwicklern/innen aufgestellt sein soll? Ihre Arbeit, die erstellte Software, ist zwar sichtbar als Quellcode, aber schwer verständlich für Außenstehende bis auf Software-Architekten oder Peers.
Zudem stellen sich weitere Fragen: Was ist in dem Zusammenhang ein "Top Performer"?
- Die-/derjenige, die/der die meisten Features entwickelt?
- Wer die meisten Bugs fixt?
- Oder die Person, die den meisten Code schreibt?
Selbst wenn man auf vernünftige Meßgrößen zur Developer-Produktivität käme, besteht damit die Gefahr einer rein kompetitiven Bewertung. Aber wir wissen doch alle, dass Softwareentwicklung vor allem eine Art Teamsport ist.
Unser Blog “Entwickler-Beiträge und Team-Produktivität” [3] weist dafür einen Ausweg,
- indem die Einzelarbeiten eines Entwicklers als “Knowledge Islands” (KIs) gemessen und als solche sichtbar werden, so dass ein Entwickler dafür die alleinige “Urheberschaft” erheben und stolz sein kann (womit wir die einzelne Developer-Produktivität erhöhen würden)
- die Beiträge des einzelnen Entwicklers zur Team-Resilienz und zum Knowledge-Sharing mittels bidirektionaler Zusammenarbeit als “Knowledge Balances” (KBs) erfasst werden und
- und auf eine gute Mixtur der beiden Gesichtspunkte basierend auf einer Kombination dieser beiden Kriterien für jeden Entwickler geachtet wird
Somit wird ein/e Entwickler/in zum Top Performer, wenn die Person nicht nur den größten Aufwand zur Weiterentwicklung leistet, sondern auch in vergleichbarem Maße zum Knowledge Sharing und damit der Team-Motivation und dem Team-Building beiträgt.
Dabei kann eine bidirektionale Zusammenarbeit auch weitere Formen annehmen, z.B. über Review-Aktivitäten oder Pair-Programming, wie im obigen Blog und dem dazu weiterführenden Blog Positiver Impact von Entwicklerbeiträgen (Abschnitt “Weiterführung des Ansatzes”) aufgezeigt.
Beispiel einer “Co-Bewertung”
Die folgende Tabelle nimmt Bezug auf die Entwickler des Django Open Source Web Frameworks im Jahr 2023, die den meisten Aufwand (Spalte Feat. Effort) zur Weiterentwicklung von Features geleistet haben.
Tabelle: "Top Performer" Kandidaten
Folgendes Whitepaper [4] gibt Aufschluss darüber, wie wir mit der DETANGLE Analyse Suite von Cape of Good Code den Entwicklungsaufwand für Features (oder den Bug-fix Aufwand) messen.
Ist nun Mariusz Felisiak mit dem größten Aufwand ein “Performer”? Sicherlich hat er 76% seines Aufwands (Effort Knowledge Islands %) parallel zu den anderen und völlig eigenständig geleistet. Aber der Aufwand an bidirektionaler Zusammenarbeit (Effort Knowledge Balances %) liegt mit 18% knapp unter dem akzeptablen Grenzwert von 20%. Der Wert von 76% Knowledge Island Effort ist zudem definitiv schon im kritischen Bereich (über 60%), da somit der Ausfall von Mariusz Felisiak bereits ein Projektrisiko darstellt. Insgesamt ist er ein Top-Performer, für den aber die Empfehlung gilt, seine Zusammenarbeit auszubauen und seine alleinige Arbeit zu reduzieren.
Eine zweite Kategorie von Entwicklern besteht aus Nick Pope, Ben Lomax und Francesco Panico (vierter, fünfter und achter Eintrag). Sie sind bei den Top-10 der beitragenden Feature-Entwickler, aber ihre “Effort Knowledge Balances %” Werte liegen im einprozentigen Bereich. Da die Bewertung zur Kollaboration das gleiche Gewicht hat wie die zur eigenständigen Arbeit, sind diese Entwickler nicht als “Performer” und eher als “Achiever” einzuschätzen.
Als "Performer" ist sicherlich Jon Janzen (dritter Eintrag der Tabelle) einzuschätzen, da er mit 48% Effort in Knowledge Islands (KIs) und 30% Effort in Knowledge Balances (KBs) hinsichtlich beider Aspekte gut bis sehr gut abschneidet.
Ausblick
Der Gesichtspunkt, den wir bisher betrachtet haben, ist eine Seite der Medaille. Es gibt einen weiteren Fallstrick bei Top Performern, dem wir in einem weiteren Blog nachgehen werden. Denn die Qualität der Arbeit eines Top-Performers spielt dabei eine genauso große Rolle.
Links
[0] Photo by Pixels (ROMAN ODINTSOV)
[1] SAP-Chef will schlechte Mitarbeiter identifizieren lassen
[2] Stack ranking Makes a Comeback
[3] Entwickler-Beiträge und Team-Produktivität
[4] Technical debt - why the term causes more confusion than clarity and how to do it better