Woran liegt es, dass Tester oft so wenig Unterstützung von Entwicklern bekommen? Viele Verbesserungen wären doch mit wenig Entwicklungs-Aufwand verbunden und würden das Gesamtergebnis voranbringen, oder?

Genau da liegt eine der Ursachen: Entwickler werden oft an ihrem Entwicklungs-“Output” gemessen, nicht am Gesamtergebnis. Da geht es um KPIs wie Story-Points pro Woche, oder etwa “durchschnittliche Zeit für die Bearbeitung eines Tickets”.

Wir müssen jetzt nicht diskutieren, warum diese KPIs fehlgeleitet sind; ich will auf etwas anderes hinaus: Wenn man Ergebnisse von Einzelpersonen misst, bekommt man eine Gruppe von Einzelkämpfern, aber kein Team.

Der Entwickler als Einzelkämpfer sieht keinen Vorteil darin, einem Tester die Arbeit zu erleichtern. Je stärker diese “Incentivierung” (sprechen wir lieber vom Anreizsystem) ausgeprägt ist, um so weiter verschiebt es sich in Richtung Einzelkämpfertum. Es genügt schon, wenn die “individuelle Performance” vom Management sichtbar gemacht wird, man braucht gar nicht über den Jahresbonus o.ä. zu reden. Die Leute können sich ihren Teil denken: “Wenn ich in der Metrik schlecht aussehe, werde ich als Minderleister eingestuft, wozu sollte es sonst da sein?”

Warum soll jemand seinen KollegInnen einen Gefallen tun, wenn er in derselben Zeit “Bonuspunkte” für gute Produktivität sammeln kann?

Die Betonung der individuellen Produktivität geht nicht nur zu Lasten der gestern besprochenen Hilfestellungen für Tester, sie hat noch etliche andere negative Auswirkungen auf das Gesamtergebnis:

• Aufräumen im Code beeinträchtigt kurzfristig meine Story-Points. Mag sein, dass ich es beim nächsten Mal leichter habe, wenn ich an derselben Stelle eine Änderung machen muss. Kann aber auch sein, dass einer von meinen Kollegen davon profitiert (seine KPIs steigert), ohne dass ich etwas davon habe.
• Wissenstransfer lohnt sich nicht, denn ich selbst bekomme ja in dieser Zeit nichts fertig.
• Schwierigere Aufgaben übernehmen, die manchmal viel länger dauern als geschätzt? Das kann jemand anderes machen, ich nehme lieber eine lange Liste von Kleinigkeiten, die sich gut abarbeiten lassen.
• Auf Qualität achten? Lohnt sich nur, wenn die von mir eingebauten Bugs auch mir persönlich angekreidet werden.

Zum Glück braucht es viel “Einsatz” des Managements, bis die Leute so egoistisch werden. Normalerweise überwiegt der Wille zur Kooperation innerhalb der Gruppe, den Homo sapiens im Laufe seiner Evolution erworben hat.

Wie kann man also sinnvoll messen, ohne den Egoismus zu fördern? Da hilft ein Prinzip, das ich von Mary Poppendieck unter dem Titel “Measure Up!” gelernt habe: immer eine Ebene höher messen. Wenn man die Performance des Einzelnen misst, fördert man egoistische Individuen. Daher sollte man auf Ebene des gesamten Teams messen, das stimuliert die Zusammenarbeit und nützt dem Gesamtergebnis.

Das Spiel lässt sich natürlich noch fortsetzen. Wer auf Teamebene misst, bekommt egoistische Teams. Sie kennen das: Development-Team vs. Test-Team, oder Entwicklung vs. Betrieb. Um das zu kompensieren, geht man eine Ebene höher (“Measure up!”) und misst die Team-Leads an den Ergebnissen auf Abteilungsebene.

Matthias Berth