Klasse statt Masse und wenig Know-how bei Product Ownern

4. Funktionen statt robuster Code

Ich habe mir von einem sehr erfahrenen Entwickler sagen lassen, dass großartige Entwickler sich über ihre Fähigkeit, robusten Code zu entwickeln, definieren. Schlechte Entwickler zählten dagegen die Aufgaben, die sie erledigen, und arbeiteten eher nach dem Prinzip Masse statt Klasse.

Der Product Owner eines Scrum-Teams muss meiner Meinung nach in der Lage sein, diesen Unterschied in seinem Team zu erkennen. Zusammen mit dem Scrum Master muss er es schaffen, dass das Team nur noch aus großartigen Entwicklern besteht.

Wenn ein Product Owner jedoch kein solider Techniker ist und sich fachlich keine Meinung bilden kann, ist es allerdings oft so, dass eher nur abgehakt wird. Eine Story dann als "done" zu bezeichnen, kommt so eher einer Entscheidung über ein Feature gleich und nicht einer robusten Überprüfung des geschriebenen Codes.

Fachliche Expertise und technisches Know-how sind enorm wichtig, auch für Product Owner im agilen Scrum-Framework. Müssen Product Owner also Programmierer sein? Nein. Aber es ist wichtig, dass sie die groben Zusammenhänge verstehen und warum eine Aufgabe eben länger dauert. Dass es hochkomplex ist, eine Rakete zu bauen, wissen wir ja auch, obwohl wir keine Raketentechnik studiert haben.

Dabei sollte es dem Product Owner nicht um Kontrolle gehen, sondern um fachliche Einschätzung. Texte werden ja auch redigiert und korrekturgelesen. Nicht, weil der Schreiber schlecht ist, sondern weil eine zweite, qualifizierte Meinung den Text mit weiteren Ideen und Anpassungen bereichern kann.

Der Product Owner sollte zumindest in der Lage sein, zu verstehen, was die Entwickler da umsetzen. Oftmals werden sie bei agilen Transformationen irgendwie aus den eigenen Reihen in ihre neue Position gesetzt, ohne auch nur ansatzweise Erfahrungen in diesem Bereich zu haben.

5. Keine Zeit für Austausch mit Gleichgesinnten

Wenn die Geschwindigkeit die einzige Messgröße im Scrum-Framework wird, hat das Team keine Zeit mehr, sich zu beraten, eine zweite Meinung einzuholen, ein Konzept mit jemandem durchzusprechen - all die Dinge, die ein Team zu einem Team machen.

Der Rat dieser Top-Entwickler ist sehr gefragt. Aber die Zeit, die sie dafür aufwenden, ihre Meinungen und Sichtweisen zu teilen, ist weniger Zeit, die sie mit der Bearbeitung von Tickets verbringen, so dass ihre Arbeitsgeschwindigkeit sinkt. Auch hier ist, wie bereits erwähnt, die Messgröße entscheidend, nach der die Performance für diesen Mitarbeiter beurteilt wird.

Werden Entwickler also daran gemessen, wie viele Tickets sie wegschaffen und wird ihre Arbeit nicht in einen qualitativen Kontext gesetzt, dann entsteht Frust, der dazu führt, dass nur noch stumpf die Aufgaben erledigt werden. Die Teilnahme am aktiven Austausch muss genauso gesehen und belohnt werden, wie das Wegschaffen von Tickets aus dem Sprint und dem Backlog. Wir müssen anerkennen, dass großartige Leistung manchmal auch innerhalb kürzester Zeit möglich ist, während schlechte Leistung manchmal Wochen braucht.