Danke für das Thema. Es hat mich angeregt endlich mal hier im Forum anzumelden. Hier ist doch etwas mehr Platz als bei Mastodon, um tiefere Diskussionen führen zu können.
Ich arbeite ebenfalls im von dir umrissenen Umfeld der kundenindividuellen Softwareentwicklung (Ein Unternehmen (AG Auftraggeber) beauftragt mein Unternehmen (AN Auftragnehmer) für sie eine Software nach dessen Wünsche zu entwickeln. Wir arbeiten grundsätzlich nach agilen Prinzipien, oft Scrum und dessen Abwandlungen).
Ich mag ein paar Definitionen in die Diskussion einbringen, die helfen könnten:
Im Scrum Guide wird von "accountable" (englisch, auf deutsch: ergebnisverantwortlich) gesprochen. Das unterscheidet sich von "responsible" (zuständig/ausführend). Der Scrum Guide verweist übrigends an der Stelle nochmal darauf hin:
"The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable." (Der:die Product Owner:in kann die oben genannten Arbeiten selbst durchführen oder die
Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der:die Product Owner:in
ergebnisverantwortlich.)
Wieso kann das wichtig sein bei der Argumentation: Wenn der AG eine Produktentwicklung an AN vergibt, dann entsteht bereits automatisch (!) eine Ergebnisverantwortung für den AN (Wenn Qualität usw. nicht stimmen, dann wir der AN zuerst zur Verantwortung gezogen). Die Ergebnisverantwortung entsteht somit automatisch beim AN. Wenn der PO nicht beim AN ist, dann entsteht sogar implizit ein unsichtbarer PO im Scrum-Dev-SM-Team (teilweise wird dann das Konzepts des Proxy-POs aus dem Hut gezaubert).
Die von dir zitierten 4 Punkte aus dem Scrum Guide stehen hier unter der Bezeichnung "accountable". Der PO ist verantwortlich, dass u.a. das Produktziel kommuniziert wurde, Product Backlog sortiert ist, Product Backlog Items angelegt wurden usw. Aber der/die PO muss das nicht selbst tun. Wer das tun kann, lässt der PO offen. Es können sowohl die Devs tun (Softwareentwickler im Team, als auch Business Analysts, Projektassistent und andere).
All diese Aufgaben können auch beim PO des AN stattfinden.
Was jedoch wirklich schwer ist, und das hast du Thomas einige Male angesprochen: Der Wissenstransfer und das Netzwerk ist oft nicht beim AN vorhanden, sondern liegt oft beim AG. Das sind zwei wichtige Dinge, die ein guter PO braucht. Häufig ist beim AG der PO bereits viele Jahre mit dem fachlichen Thema bereits involviert und kennst sich somit wirklich gut aus. Gedankenexperiment: Was ist, wenn der AG PO plötzlich wechselt und ein neuer/junger/frischer PO kommt zum Team hinzu und ersetzt den alten/erfahrenen PO? Dieser neue AG PO muss sich genauso in die Themen einarbeiten wie ein PO beim AN (fachliche Einarbeitung, Netzwerk aufbauen usw.).
Meine Erfahrung ist, dass es auch eine Frage des Geldes ist: Ist der AG bereit Zeit und Geld in den AN PO zu investieren, oder greift er die "Investitionen" des vorhandenen AG POs ab? In meiner Welt ist oft kein Budget vorhanden den AN PO entsprechend einzuarbeiten.
Meine weitere Erfahrung ist: AG POs sind fachlich so sehr in ihren Arbeitsalltag eingebunden, dass sie plötzlich die PO-Rolle on-top hinzubekommen. Für eine gute Ausführung der PO-Rolle ist aber selten Kapazität vorhanden. Es wird entweder die fachliche Arbeit leiden oder die PO-Arbeit. (Nach meiner Erfahrung) sind die AG POs oft gar nicht geschult/vorbereitet auf die PO Tätigkeiten. Das führte in meinen Teams bereits zu viel Frust auf der Scrum-Dev-SM-Team-Seite. Der AG könnte ja einen extra PO auf seiner Seite dafür extra benennen, aber dann sind wir wieder beim Thema Einarbeitung, Wissenstransfer und Netzwerk (siehe oben).
Zum Punkt "wie sehr ownt ein Product Owner sein Produkt": Der AG PO ownt sein Produkt auch selten wirklich zu 100%. Es gibt zu viele Abhängigkeiten innerhalb des Unternehmens, die seine Entscheidungen beeinflussen. Wenn der AG Geschäftsführer sagt "Dieses Feature muss übermorgen rein, und das Feature kommt dafür sofort raus", dann wird es schwer für den PO, denn der AG PO hat auf seiner Seite auch "Auftraggeber", die er glücklich machen soll.
Damit kommen wir zu einer weiteren Definition: "Kunde". Was ist der "Kunde"? Ist damit der "Sponsor" gemeint? Sind damit die Nutzer gemeint?
Selbst der AG PO unterliegt oft der Macht der "Sponsoren". Der AG PO kennt die Nutzer oft auch nicht gut.
Es ist aus meiner Erfahrung ein Trugschluss zu glauben, dass der AG PO es einfacher hat als der AN PO. Der AG PO hat oft nur den Wissens- + Netzwerkvorsprung aus der langjährigen Arbeit. Aber auch das ist nicht immer ein Vorteil.
Puh, das war jetzt schon sehr viel Text. Das hätte auch ein Blogartikel werden können. Und reißt trotzdem nur viele Themen am Rand an. Ein guter Start für weitere Diskussionen 🙂
Euer SCRUMschau
https://scrumschau.wordpress.com/
https://mastodon.social/@scrumschau