NBA20: Product Owner kann nur der Kunde sein
Shownotes
Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile.
Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/36-nba20-product-owner-kann-nur-der-kunde-sein
—
Letzte Folge NBA19: Entscheidungen im Team treffen
Artikel „Die Rolle des Product Owners in agilen Projekten: Eine kritische Analyse für kundenorientierte Teams“
Zusammenfassung
In Folge 20 von „No Bullshit Agile“ diskutiert Thomas die Rolle des Product Owners im Kontext von Kundenprojekten und Agenturen. Hier sind die zentralen Punkte zusammengefasst:
Product Owner als Kunde: Thomas argumentiert, dass der wahre Product Owner in Kundenprojekten der Kunde selbst ist. Der PO in der Agentur fungiert eher als Vermittler und Sortierer von Anforderungen, aber die tiefere Verantwortung und Vision für das Produkt liegt beim Kunden.
Herausforderungen im Scrum-Ansatz: Der Scrum Guide beschreibt den Product Owner als verantwortlich für die Maximierung des Produktwerts und die Priorisierung der Backlog-Elemente. Thomas kritisiert, dass diese Aufgaben in einer Agenturumgebung schwierig zu erfüllen sind, da der PO in der Agentur nicht die gleiche Tiefe an Marktkenntnis und Verantwortung wie der Kunde hat.
Unzureichende Autorität des Agentur-POs: Der Agentur-PO hat oft nicht die notwendige Autorität oder die umfassende Sicht auf das Produkt, die erforderlich ist, um klare Ziele zu setzen und Prioritäten zu bestimmen. Diese Rolle ist stark auf Kommunikation und Abstimmung mit dem Kunden angewiesen, was die Effektivität beeinträchtigen kann.
Probleme mit der „Hero-Rolle“: Der Scrum Guide verlangt, dass der PO als Einzelperson Entscheidungen trifft und nicht als Komitee handelt. Thomas kritisiert diesen Ansatz als unvereinbar mit agilem Arbeiten, da er den PO in eine isolierte „Hero-Rolle“ drängt, anstatt kollaborative Entscheidungsfindung zu fördern.
Dualität im Agenturmodell: Thomas sieht das Modell problematisch, wenn der PO beim Kunden sitzt und das Entwicklungsteam von einer Agentur kommt. Diese Dualität kann zu Konflikten und Missverständnissen führen, da die Agentur und der Kunde unterschiedliche Interessen und Perspektiven haben können.
Zusammengefasst stellt Thomas in Frage, ob das traditionelle Verständnis der Product Owner-Rolle in Agenturumgebungen wirklich praktikabel ist, und schlägt vor, dass der Kunde selbst die zentrale Rolle des Product Owners übernehmen sollte.
Transkript
Hallo und herzlich willkommen bei NoBullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt dabei auf der Praxis, daher eben auch der Name NoBullshit Agile.
In der letzten Folge habe ich darüber gesprochen, welche Methoden es gibt, um im Team Entscheidungen gut treffen zu können. Wenn dich das interessiert, hör da gerne rein. Den Link dazu findest du in den Show Notes. Das hier ist die Folge 20 und heute spreche ich darüber, warum meiner Meinung nach der Product Owner nur der Kunde sein kann.
Vielleicht ein kleiner Disclaimer vorab: Wenn ihr in-House für euch selber Produkte entwickelt, dann gilt einiges von dem, was ich erzähle, sicherlich nicht. Mir geht es vor allen Dingen um die Situation, wenn ihr in einer Agentur arbeitet und für Kunden Projekte macht und/oder Software entwickelt.
Bei meiner Zertifizierung zum Kanban Management Professional, das ist tatsächlich auch schon ein bisschen länger her, kam ich so am Rande mit dem Referenten ins Gespräch. Ich habe davor fünf Jahre Scrum im Team gemacht und war da Product Owner. Wir haben von Scrum auf Kanban gewechselt und in dem Zuge habe ich eben die Zertifizierung zum Kanban Management Professional gemacht. Wir entwickeln tatsächlich für Kunden Software und während meiner Scrum-Zeit bin ich immer und immer wieder mit mir selber, mit dem Team und mit dem Kunden so an der Definition des PO aus dem Scrum Guide gescheitert. Ich hatte halt immer das Gefühl, dass ich nur ein Vertreter bin, dass ich gar nicht wirklich der Product Owner bin. In dem Gespräch mit dem Referenten nach ein bisschen hin und her sagte der schlussendlich zu mir: "Naja, wenn man jetzt ganz genau ist, du bist wirklich kein PO, das ist der Kunde." Und das ist irgendwie hängen geblieben.
Wie gesagt, ich habe fünf Jahre lang Scrum gemacht und wir machen jetzt schon bestimmt fünf Jahre, ich glaube sogar schon ein bisschen länger, Kanban. Und trotzdem ist das irgendwie kleben geblieben. Ich habe mir mal den aktuellen Scrum Guide angeguckt und habe auch einen Artikel dazu geschrieben. Den Link zu dem Artikel verlinke ich auch in den Show Notes. Aber ich bin den Scrum Guide mal so schrittweise durchgegangen.
Das erste Zitat aus dem Scrum Guide, da geht es um die Maximierung des Produktwerts. Das Zitat lautet: "The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organisations, Scrum Teams and individuals." Der Scrum Guide betont, dass der Product Owner für die Maximierung des Produktwerts verantwortlich ist. Ich glaube, das kann ein PO und sein Team schon durchaus leisten. Durch Beratung und Führung vom Kunden ist es sicherlich machbar. Und ich glaube, dass es tatsächlich auch ein bisschen unabhängig davon ist, ob In-House-Produkte entwickelt werden oder ob es für den Kunden entwickelt wird. Allerdings, das ist schon so der erste Pferdefuß meiner Meinung nach, kann das der PO nur im Rahmen dessen tun, was der Kunde ihm auch mitteilt. Der Kunde steckt ja schlussendlich viel tiefer in den Prozessen drin. Er versteht ja viel besser, warum er was entwickeln lässt. Das kann man durch Gespräche herausfinden als PO und das sollte man auch tun. Das ganze Team soll sich ja Stück für Stück intensivst mit dem Produkt beschäftigen, das es da entwickelt. Aber es braucht eben dann super, super viel Austausch. Aber dann glaube ich, ist dieses Maximieren des Produktwerts auf jeden Fall eine Sache, die der klassische Product Owner im Scrum leisten kann.
Der nächste Abschnitt, den ich rausgepickt habe, da geht es um effektives Product Backlog Management. Das Zitat lautet: "Developing and explicitly communicating the product goal." Das ist das erste, mit dem ich ganz große Schwierigkeiten hatte, als ich PO war und auch heute noch habe. Die Entwicklung des Produktziels und auch die Kommunikation dazu. Ich bin der Meinung, das kann wirklich nur der Kunde, der Verantwortliche auf Kundenseite für das Produkt. Der wird sich auch nicht so leicht damit tun, weil so ist es zumindest in meiner Praxis: Viele Leute haben ein Interesse an dem Produkt. Ganz klassisch der Vertrieb, der seine Vertriebszahlen erfüllen will, das Marketing, das drum herum in die Marketing-Maßnahmen hat, die Geschäftsführung oder ich sage mal der Produktleiter, je nach Konstrukt. Und da wird der einzelne Product Owner wieder viel mit anderen reden müssen, um überhaupt so ein Ziel des Produkts wirklich formulieren zu können. Nur jemand beim Kunden hat die Produktvision. Nur die Leute kennen wirklich intensiv die Marktanalyse. Nur die Leute steuern die Marketing-Maßnahmen. Ich weiß ganz genau, dass mein Team mich oft gefragt hat, welches Ziel der Produktverantwortliche jetzt der Kunde mit diesen Anforderungen verfolgt. Und natürlich habe ich dann immer den Kunden gefragt. Die Frage ist ja richtig vom Team. Und das ist sicherlich eine Frage, die sich alle stellen sollten. Aber der PO in der Agentur, der PO in dem Scrum-Team, der kann das nicht beantworten, egal wie intensiv er wirklich in dem Produkt steckt. Die beste Antwort kann ja nur derjenige geben, der das Produkt owned, der Product Owner und das Ownership, der Besitz, wenn man das wirklich mal auf dieses Wort runterbricht. Das ist ja der Kunde. Das ist doch nicht die Agentur.
Der nächste Punkt aus dem Scrum Guide, da geht es um klare Kommunikation und Reihenfolge von Backlog-Elementen. Zitat: "Creating and clearly communicating product backlog items." Natürlich ist der Product Owner für die Kommunikation der Reihenfolge der Entwicklung verantwortlich. Das sehe ich so. Aber auch das kann ich aus meiner Praxis sagen, das mache ich ja nicht alleine. Das mache ich ja nicht auf einer Insel, sondern das geschieht ja nur in Abstimmung mit dem Kunden. Und warum geschieht das in Abstimmung mit dem Kunden? Naja, weil er das Product owned, offensichtlicherweise. Ein PO kann alleine, also der PO in einem Scrum-Team kann alleine nicht die Reihenfolge definieren. Das kann er tun, aber ich glaube nicht, dass das erfolgreich ist.
Der nächste Punkt aus dem Scrum Guide ist Transparenz und Verständnis des Product Backlogs. Das Zitat ist: "Ordering product backlog items and ensuring that the product backlog is transparent, visible and understood." Der PO soll die Items gemeinsam mit dem Team, würde ich jetzt einfach ergänzen, sortieren. Ja, klar. Schlussendlich ist er derjenige, der wahrscheinlich in Jira vor allen Dingen arbeitet oder in Trello oder wo auch immer ihr eure Backlog-Items habt. Es ist dann aber ehrlich gesagt mehr so, dass der PO die Sortiermaschine des Kunden ist. Klar, er bringt seine Erfahrung mit ein. Das sollte er immer tun oder sie. Aber ich zumindest mache zwar einen Vorschlag oder habe zwar einen Vorschlag zur Sortierung gemacht, aber auch das nur in Abstimmung mit dem Kunden. Mit dem Kunden bin ich durchgegangen und habe gesagt: Pass auf. Ich sehe aus meiner Erfahrung folgende Vorteile, es so und so zu machen. Aber in welcher Reihenfolge welche Elemente entwickelt werden sollen, damit schnell ein Wert auch erzeugt wird, das kann doch nur der Kunde. Nur er nutzt das Produkt doch auch. Und insofern bleibe ich dabei: Für diesen Teil ist der Product Owner in einem Scrum Team schlussendlich eine Sortiermaschine. Zum Teil ist er vielleicht auch eine Art Kommunikationsmaschine, weil er immer wieder die Verbindung zwischen Kunde, Kundenwunsch und Team und Teamwunsch herstellt. Aber schlussendlich, die Verantwortung, die liegt hier auch wieder beim Kunden.
Der nächste Punkt aus dem Scrum Guide, da geht es um Delegation von Verantwortlichkeiten. Und das Zitat ist: "The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable." Der Product Owner kann zwar delegieren, aber er bleibt weiterhin verantwortlich. Das gilt ja grundsätzlich bei Delegationen. Wenn ich was delegiere, bin ich es nicht los, sondern ich bleibe verantwortlich. Die große, große Frage ist aber: Accountable, wofür? Wofür bin ich denn verantwortlich? Bin ich verantwortlich für die Sortierung, für die Erledigung von den Stories? Ja, okay, da kann ich mitgehen. Aber die Verantwortlichkeit für den Erfolg des Produkts liegt doch nicht beim PO. Die kann doch nur beim Kunden liegen. Die Gesamtverantwortung für ein Produkt, die muss doch beim Kunden liegen. So etwas kann ein Kunde ja nicht delegieren. Der PO hat ja überhaupt keinen Einfluss darauf. Er hat keinen Einfluss auf das Budget. Er hat keinen Einfluss auf Marketingmaßnahmen. Da kann man doch nicht sagen: Lieber PO, du bist verantwortlich für den Produkterfolg. Wenn das so wäre, dann müsste der PO auch viel mehr Möglichkeiten haben, dem Kunden gegenüber zu sagen: Nein, nach meiner Erfahrung sollten wir das nicht so tun. Und ich glaube, dann wird es echt super, super schwer, in so einem Szenario gemeinschaftlich daran zu arbeiten. Wenn ein Externer auf einmal bestimmt, wie das Produkt aussieht und was die nächsten Produktentwicklungsschritte sind.
Der nächste Punkt im Scrum Guide, da geht es darum, dass der PO eine einzelne Person ist und kein Gremium sein soll. Also das Heilene-Prinzip, habe ich immer gesagt. Das Zitat ist: "The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the product backlog. Those wanting to change the product backlog can do so by trying to convince the Product Owner." Ja, da tue ich mich halt auch echt schwer mit. Also allein der letzte Satz. Wenn jemand etwas anders haben möchte, muss er halt versuchen, den Product Owner zu überzeugen. All das führt irgendwie dazu, dass der Product Owner auf einmal so eine Hero-Rolle hat und das widerspricht meiner Meinung nach kompletter Agilität und auch dem agilen Manifest. Wir wollen keine Heroes, wir wollen Kollaboration. Wir wollen doch nicht einen Einzelnen, der schlussendlich die Entscheidungsinstanz ist und der im Zweifel sogar relativ willkürlich dann entscheidet. Das ist nicht Agilität. Wieso gibt es auf einmal hier einen Hero und warum ist so eine Formulierung gewählt wie "by trying to convince the Product Owner"? Also spätestens da ist meiner Meinung nach irgendwie diese Rolle des POs, wie gesagt, nicht für In-House, das kann ich mir schon vorstellen, aber für das Verhältnis zur Agentur, also wirklich, wirklich schwer. Der Kunde soll jetzt den Product Owner überzeugen, dass doch bitte die Reihenfolge so rum sein soll? Das macht wirklich keinen Sinn. Also zumindest in meiner Welt macht das einfach keinen Sinn.
Ja, ihr merkt schon, ich tue mich halt mit Scrum super schwer. Scrum in Agenturen ganz besonders und ich tue mich mit dieser Rolle des Product Owners schwer. Ich habe mich die fünf Jahre damit sehr schwer getan. Es gab viele, viele, viele Situationen, wo ich auch keine Antworten hatte. Also wenn zum Beispiel Fragen vom Team kamen oder in Diskussionen mit einem Scrum Master, wie machen wir das denn? Da sind wir halt immer wieder an den Punkt gekommen, dass diese Rolle wirklich sehr merkwürdig ist. Und korrekterweise, meiner Meinung nach, wenn man jetzt wirklich Scrum machen will, dann müsste der Product Owner beim Kunden sein. Dann wäre aber auch die Situation relativ merkwürdig, weil der Kunde auf einmal dann ein Dev Team hat. Das ist eine verlängerte Werkbank in dem Moment. Da gibt es das Dev Team, das kommt jetzt von der Agentur, das entwickelt im Auftrag des Kunden etwas und der Product Owner sitzt beim Kunden. Das heißt, man hat da eine komplette Dualität drin. Das hat zumindest alles ein Geschmäckle. Das ist meine Meinung dazu.
Ich bin ganz gespannt, was deine Meinung ist. Ich denke, wir sind für heute so weit erstmal durch. Wenn du Feedback hast, dann erreichst du mich auf verschiedenen Kanälen, unter anderem per Mail an nobsagile@gmail.com. Ich bin auch auf Mastodon, das Profil verlinke ich hier in den Show Notes. Und wir haben auch ein Forum. Da gibt es unter anderem für jede Podcast-Folge auch einen Thread. Das heißt, du findest genug Wege, mich zu erreichen. Ich würde mich wirklich über Feedback freuen. Ich würde mich wirklich auch über kritische Anmerkungen von dir freuen. Ich kann mir vorstellen, dass es relativ einseitig heute war. Und ich bin ein Mensch, der sich tatsächlich auch über kritische Anmerkungen freut. Deswegen, wenn du da was hast, gib mir gerne ein Feedback. Ansonsten wünsche ich dir noch eine ganz tolle Woche und wir hören uns beim nächsten Mal. Bye.
