Raus aus dem Hamsterrad

Bild: Wikimedia Commons / Mylius - CC BY-SA 3.0

Wenn Scrum irgendwo neu eingeführt wird kann man davon ausgehen, dass es eine der ersten aufkommenden Diskussionen sein wird: müssen denn diese Rollen Product Owner und Scrum Master wirklich sein? Können diese Aufgaben nicht von jemand anderem nebenher gemacht werden? Die Antwort: wenn das Ergebnis wirklich Scrum sein soll, dann nicht. Allerdings nicht als Selbstzweck, sondern weil es Sinn macht.

Welcher das ist, zeigt sich vor allem dort, wo das "nebenher machen" stattfindet, etwa wenn die PO-Aufgaben von einem Business Analysten oder Fachabteilungs-Mitarbeiter übernommen werden und die Scrum Master-Aufgaben von einem Teammitglied. Wie gesagt, nebenher, also zusätzlich zu dem, was ohnehin schon zu dem bisherigen Job gehört. Das Ergebnis wird fast immer das gleiche sein - die neuen Aufgaben werden stark vernachlässigt werden. Und das mit gutem Grund.

Der entscheidende Punkt ist hier, dass die Arbeit der Product Owner und Scrum Master im Gegensatz zu der der meisten anderen Mitarbeiter zu einem Grossteil nicht anlassgetrieben ist. Sowohl die Konzeption und Validierung neuer Produktumfänge als auch die Evolution eines Teams in Richtung Crossfunktionalität und Selbstorganisation brauchen in der Regel Monate um umgesetzt zu werden, Sprints oder operative Tätigkeiten erfordern dagegen die Konzentration auf die Gegenwart.

Die Folgen sind immer die gleichen. "Um die langfristigen Themen kümmern wir uns wenn es mal im täglichen Betrieb nicht so viel zu tun gibt" heisst es dann. Dieser Zeitpunkt kommt aber praktisch nie, denn irgendetwas Dringendes zu tun gibt es immer. Die Verschiebung der PO- und Scrum Master-Themen führt sogar zu mehr Arbeit im Alltag, da die stockende Weiterentwicklung des Teams und die unklare Produktstrategie den Beteiligten immer wieder auf die Füsse fallen und neue kurzfristige Reaktionen erforderlich machen. Ein Teufelskreis.

Um eben das zu verhindern ist es nötig, in kurzen, regelmässigen Abständen aus dem operativen Hamsterrad herauszusteigen, einige Schritte zurückzutreten, das große Ganze auf sich wirken zu lassen und sich Sinn- und Perspektivfragen zu stellen. "Wird das neue Feature wirklich so angenommen wie wir dachten?" "Wird der aktuelle Arbeitsmodus auch in einem Vierteljahr noch so funktionieren?" Etc. Wenn die Antwort darauf unklar ist, sollten auch die anderen Teammitglieder aus dem Rad herausgeholt werden, um sie auf das aufmerksam zu machen was von dort aus nicht sichtbar ist.

Den Product Ownern und Scrum Mastern diese Möglichkeit (und die damit verbundene Befreiung von Hamsterrad-Aufgaben) zu geben, ist eine der Grundvoraussetzungen dafür, dass Scrum wirklich zum Greifen kommt. Und da das aufgrund der Gegenläufigkeit zur anlassgetriebenen Alltagsarbeit nicht im Rahmen einer Zusatzaufgabe funktioniert, sollten diese Rollen so eingeführt werden wie sie gedacht sind: als Vollzeit-Stellen.