Der Scroduct Ownster

Bild: Wikimedia Commons / Wilhelm von Kaulbach - Public Domain

Zu den einschneidendsten Änderungen die Scrum in das Projektmanagement gebracht hat gehört die Teilung des bisherigen Projektleiters oder Teamleiters in zwei Positionen, den Scrum Master und den Product Owner. Der Grund für diese Aufteilung war die Erkenntnis, dass die Konzentration aller Verantwortlichkeit auf eine Person sich zu häufig als dysfunktional erwiesen hat, da diese dann zwei sich widersprechende Rollen erfüllen sollte: Zum einen sollte der Projektleiter dafür sorgen, dass die Teammitglieder sich an die Projektmethodik hielten, also an Prince2, PMP, ITIL oder andere. Zum anderen wurde von ihm aber auch erwartet, dass er neue Produkte oder Features möglichst schnell an den Markt brachte, damit mit ihnen Geld verdient werden konnte.

Wenn nun gegen Ende des Projekts oder eines Projektabschnitts ein (scheinbar) fertiges Produkt vorlag, die Methodik aber noch Quality Gates oder Dokumentationen vorsah, entstand ein Intra-Rollen-Konflikt - sollte die Vermarktung des Produktes jetzt warten bis die Prozesse sauber abgeschlossen waren, oder waren die Prozesse verzichtbar wenn der Markt mit schnellem Geld lockte? In der Theorie wurde zwar verlangt eine Lösung zu finden die beide Aspekte berücksichtigte, in der Realität war es aber anders - fast immer entschieden sich die Projektmanager für eine der beiden Seiten, vernachlässigten die andere und fügten dem Projekt und Produkt so Schaden zu. Mal wurden von den Teams möglichst viele neue Produkte und Funktionen in möglichst kurzer Zeit verlangt (Featuritis, bzw. Feature Creep), mal wurde das einmal beschlossene Vorgehen in Beton gegossen und jede Anpassung abgelehnt (Methodismus). Der eine Fall führt zu Bugs in der Produktion, der andere zu verspäteter Auslieferung.

Die Teilung in Scrum Master und Product Owner beseitigt diesen Intra-Rollen-Konflikt: Der Product Owner ist nur dafür verantwortlich die Anforderungen so in das Team zu steuern, dass möglichst viele Features möglichst schnell entstehen können, der Scrum Master sorgt nur für die Einhaltung der vorgegebenen Regeln und damit für Prozessqualität (und höchstens indirekt für Produktqualität). Sollte beides im Widerspruch stehen kann nicht die eine Seite die andere unterdrücken (alleine deshalb nicht weil keiner der beiden dem Team Befehle geben darf), sondern sie müssen sich auf einen gangbaren Mittelweg einigen.¹ Leider wird dieser Hintergrund von vielen Managern nicht verstanden, weshalb eine häufige "Effizienzsteigerungsmassnahme" die ist, die Positionen des Scrum Masters und des Product Owners wieder zusammenzulegen. Der damit einhergehende, bzw. zurückkehrende Intra-Rollen-Konflikt ist in einem der großartigen "The wrong way to do agile"-Videos von Atlassian sowohl visuell als auch semantisch passend dargestellt worden: das Ergebnis ist der "Scroduct Ownster", ein kaum noch arbeitsfähiges Mischwesen.


Abschreckend genug ist dieses Bild aber wohl nicht, denn noch immer liest man wieder und wieder Stellenausschreibungen wie diese hier aus der letzten Woche, in der sich der folgende Satz findet:

Es handelt sich bei dieser Position um eine interne Produktmanager-Position (mit einer Zusammenlegung der Rollen Scrum Product Owner und Scrum Master).

Ich wage die Voraussage, dass dieses Projekt relativ schnell im Murks enden wird. Aber das müssen die dort zuständigen Leute dann vor sich selbst verantworten.


¹Natürlich könnte man an dieser Stelle aufschreien und klar machen, dass die Scrum-Regeln nie geändert werden dürfen. Das wäre dann aber auch nur wieder Methodismus. Klar ist aber, dass es einen Kernbereich gibt, der vor "Anpassungen" geschützt sein sollte.