NBA44: Der Product Owner – Schlüsselrolle oder überforderte Schnittstelle?

Hallo und herzlich willkommen bei Noobullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Man fokussiert immer auf der Praxis, daher auch der Name Noobullshit Agile. In der letzten Folge habe ich mit Johanna über Motivation gesprochen. Schöne Grüße nochmal, vielen Dank Johanna. Wenn euch das interessiert, hört da gerne rein. Den Link dazu findest du in den Schonots. Das hier ist die Folge 44 und heute geht es um die Rolle des Product Owners. Bevor wir in das Thema einsteigen, wie immer ein bisschen Housekeeping, es gibt ja die virtuelle Agile User Group und wir treffen uns einmal im Monat und das nächste Treffen ist am 10.12. um 19 Uhr 30. Den Link zu dem virtuellen Treffen und weiteren Informationen den findest du in den Schonots. Und dann würde ich sagen, wir steigen mal ein. Der Titel der Folge ist ja der Product Owner Schlüsselrolle oder über vorderte Schnittstelle und das hing eigentlich alles auf Mastodon beziehungsweise auf LinkedIn an. Ich bin ab und zu ja auch mal auf LinkedIn unterwegs. Bin jetzt kein Riesen Fan von LinkedIn, muss ich auch sagen und da hatte eine Person in ihrem Titel Freelance Product Owner stehen. Und da bin ich ein bisschen ins Grübeln gekommen. Ich selber war ja mal Product Owner von unserem Scrum Team. Kleine Erinnerung, wir sind Agentur und wir machen Softwareentwicklung und Customizing für Kunden und da war ich fünf Jahre lang Product Owner und ich habe mir halt überlegt, ich habe mich schon schwer getan in meiner Rolle und da komme ich in der Folge gleich auch nochmal drauf. Wie funktioniert denn ein externer also ein Freelancer zumindest habe ich den Titel so interpretiert als Product Owner. Die Diskussion habe ich mal auf Mastodon mitgenommen. Ich kann halt sagen, ich habe ja gerade gesagt, LinkedIn ist nicht so mein favorite. Auf Mastodon funktioniert so eine Diskussion für mich zumindest viel viel besser und da entstand dann auch eine ganz tolle Diskussion. An der Stelle schöne Grüße an Marco von Scrum Show, Ralf und Hauke, ganz tolle Sache so macht es einfach echt Spaß und darum soll es heute gehen um meine Gedanken dazu. Warum ist der Product Owner so zentral in Scrum? Was sind eigentlich die Herausforderungen von dem Product Owner und wie gesagt, ich würde ein bisschen auch erzählen über meine Erfahrung als Product Owner. Gut, steigen wir mal ein und ich würde sagen, wir steigen einfach ein, wo es am meisten Sinn macht, wir schauen einfach mal in den Scrum Guide und der beschreibt folgendes zum Product Owner unter anderem. Er hat die Verantwortlichkeit für Entwicklung und explizite Kommunikation des Produktziels. Er ist weiterhin verantwortlich oder sie für die Erstellung und klare Kommunikation von Product Backlocker Items. Weitere Aufgabe oder Verantwortung ist anordnen von Product Backlock Items und nächster Punkt sicherstellen, dass das Product Backlock transparent, sichtbar und verständlich ist. Das macht Sinn, das klingt erstmal gar nicht so falsch. Ich hatte mich tatsächlich schon gewundert, dass da nicht mehr Rolle Product Owner steht, sondern Verantwortung, Accountability. Das hat sich im Scrum Guide geändert, wie gesagt, seit über fünf Jahren machen wir keinen Scrum, sondern kann man. Aber zu meiner Zeit stand da halt noch Rolle, also die Dev Rolle, die Scrum Master Rolle und die Product Owner Rolle. Das fand ich schon mal interessant, dass der Scrum Guide da eine Veränderung vorgenommen hat und eben diesen Begriff der Verantwortung eingeführt hat. Nach ein bisschen Austausch lesen und auch einen Linktipp, den ich bekommen habe. Gibt es nämlich auch der Link ist übrigens in den Show notes ein bisschen Erklärung, was Accountability denn hier meint. Hab ich verstanden. Es geht darum, ein bisschen flexibler zu sein und weg von Hierarchien zu kommen. Eine Rolle kann immer irgendeine Hierarchie implizieren, das verstehe ich auch. Und es geht hier vor allen Dingen um die Verantwortung zählt und nicht die Position im Unternehmen. Also ich kann mehrere Verantwortlichkeiten in einer bestimmten Position oder Rolle haben. Hab ich verstanden, genau. Der nächste Punkt im Scrum Guide ist tatsächlich beim Product Owner steht, dass er diese Verantwortlichkeiten bzw. nicht die Verantwortlichkeiten ganz wichtig, aber die Aufgaben da drin auch delegieren kann. Er kann delegieren, aber er bleibt weiterhin verantwortlich, also Accountable für das Ergebnis. Zum Beispiel die Backlog-Flege oder die Entwicklung des Produktziels. Das könnten andere für den Product Owner machen. Der Product Owner bleibt aber verantwortlich. Das ist ganz interessant und das sollten wir uns mal merken, für das was so als nächstes kommt. Ja, wie sieht die Praxis denn aus für so ein Product Owner? Also ich habe mal ein bisschen diese Diskussion auf Mastodon hier auch aufgegriffen und ein Zitat fand ich von Marco Cool. Marco schrieb dann irgendwann, weil ich gesagt habe, es ist aber anstrengend und war auch meine Erfahrung als Product Owner zwischen den Stühlen. Alles was dazugehört, und dann schrieb Marco, niemand sagt, dass Deck Holder Management einfach sei und er hat so recht. Das kommt am Ende auch nochmal. Ich glaube, der Scrum Guide will das Richtige. Ich glaube, in der Praxis ist es super schwer. Ich glaube, das ist eher der Punkt, dass es hier kein Scrum Bashing oder Product Owner Definitions Bashing, sondern ich glaube, die Praxis macht es einfach unheimlich schwer. Was wir feststellen können, was ich auch in der Praxis festgestellt habe, der Product Owner steht zwischen den Stühlen. Also er hat die Stake Holder, er hat den Kunden mit seiner Anforderung, er hat das Dev Team, er hat weitere Personen oder Rollen im Unternehmen und in anderen Unternehmen, zum Beispiel auch das Management. Die Stake Holder wollen schnelle Ergebnisse und viele Features in wenig Zeit und für wenig Geld im Zweifel auch. Kennen wir, glaube ich, alle. Das Team möchte verständlicherweise klare Prioritäten und eben eine technische Machbarkeit dessen, was man sich da so wünscht. Der PO, der steht jetzt dazwischen und der muss immer entscheiden oder intelligiert das und muss die Entscheidung mittragen. Das ist eben sehr schwer. Es ist selten einfach. Zu diesem Punkt Delegation habe ich mir notiert, Delegation als theoretische Freiheit. Weil das wäre es ja, wenn der Product Owner überlastet ist und er Delegieren kann, dann schafft das natürlich eine gewisse Freiheit. Aber es ist in der Praxis natürlich total problematisch. Wie gesagt, laut ScrumGite kann der PO Aufgaben Delegieren, aber oft genug akzeptieren andere, die es delegiert bekommen haben das nicht. Mein bestes Beispiel an der Stelle ist, der Product Owner kann oder muss manchmal Dinge an den Kunden delegieren, gerade in der Situation, in der wir waren und wenn ich da an Sprintziel zum Beispiel denken kann oder Prioritäten in den Stories, das kann ich gar nicht entscheiden. Also ich habe ja das Domänenwissen nicht. Ich bin nicht bei dem Kunden, ich gehöre nicht zu dem Kunden. Die Produktvision, die habe ich nicht. Je länger ich den Kunden kenne, desto besser werde ich da drin. Aber der Beste wäre eigentlich der Kunde, der das entscheiden kann. Schließlich entwickeln wir ja auch für den Kunden. Und der sollte am besten wissen, was ist mein strategisches Ziel und welche Sprintziele leiten sich davon ab? Welche Story-Beschreibungen sind hier richtig aus der anfordernden Sicht, sage ich mal. Und ich habe das oft genug erlebt, dass ein Kunde das verweigert. Ein Kunde sagt dann gerne auch mal, ja, das muss alles fertig werden und ich brauche es ganz dringend. Und das Sprintziel ist dann ja alles, was ihr hier definiert muss, fertig werden. Alles, zu dem ihr euch kummittet. Das ist aber kein Sprintziel. Und auch die Produktvision, wenn ich da nachfrage, das Team fragte mich dann, ja, also was ist denn hier die Produktvision, wohin soll es denn gehen, damit wir auch selber mitreden können über Prioritäten. Und dann hat der Kunde keine. Und was mache ich denn dann als PO? Da komme ich nur in die Prädulier. Ich erb jetzt so eine Schattenverantwortung aufgrund des Frameworks und ich nutze die Chance der Delegation und mache das gerne auch im Dialog. Ich will ja auch beraten tätig sein, das ist ja überhaupt kein Problem. Und der Kunde sagt, nie damit beschäftige ich mich nicht und dann stehe ich da. Natürlich ist das doof, also auch aus Kundensicht. Das ist ja offensichtlich, der Kunde sollte sich mit seinem Produkt beschäftigen. Aber was, wenn er es nicht tut, dann habe ich da eine Verantwortung, eine Accountability für etwas, was ich nicht verantworten kann. Und das wird ein Riesenproblem in der Praxis. Das Team wird dann irgendwann nölig und ich verstehe es auch, weil das Team sagt, das ist ja gar kein Sprintziel und wir haben auch keine Produktvision jemals richtig erklärt bekommen und sollen trotzdem jetzt Entscheidungen treffen. Ich versuche mein Bestes und das Team merkt natürlich auch, ja aber das ist nicht voll durchdacht, das passt nicht zusammen und es ist nicht voll durchdacht, weil ich es nicht voll durchdenken kann, weil ich einfach das Domänenwissen nicht vollständig habe. Und das passiert, weil ich vermute, es passiert euch auch. Also zumindest ist es mir passiert immer und immer wieder. So und wie gesagt, das ist meine Erfahrung. Kunden treffen manchmal Entscheidungen nicht, das Team steht dann blöd da, ich stehe blöd da und ich habe halt die Verantwortung. Ja, ist blöd, ne? Ja und wie gesagt, es gibt noch so einen Punkt, alle haben viel zu tun, das verstehe ich auch, aber in diesem ganzen Konstrukt, wie wir das jetzt gerade gesprochen haben, ist der PO wirklich, also erst mal Single Point of Fail ja, ganz klar, wenn der PO ausfällt, nicht besonders gut und man hat diese Doppelbelastung, auf der einen Seite geht es so um langfristige Ziele und Wertemaximierung für das Produkt, das ist eher was Strategisches und operativ, bin ich für die Backlog-Fege zuständig die Priorisierung, ich habe meine Meetings, ich erhebe die Anforderungen, ich schreibe die Stories und da kommt eben genau der Titel jetzt her, ne? Die große Frage, die lasse ich auch mal offen erstmal, ist der PO wirklich die Schlüsselrolle oder ist das eher eine überforderte Schnittstelle? Wie geht man jetzt damit um, wenn man ein Product Owner ist? Also ich hatte ja schon gesagt, das ist hier kein Framework-Bashing, es geht mir nicht darum, dass Scrum hier was falsch macht oder so in dieser Art, sondern es geht darum zu überlegen, wie kann ich denn als Product Owner mein Umfeld so gestalten und ich habe hier ja ganz oft schon darüber gesprochen, dass es eine Aufgabe ist, von uns die Agilität weiterbringen wollen, den Kunden permanent zu Schulen, zu Educaten sage ich ja manchmal und ich glaube, dass ist echt ganz wichtig, Stakeholder Management verbessern, Transparenz schaffen, eine regelmäßige Reviews, um auch mit Erwartungen umzugehen, Prioritäten rechtfertigen oder Prioritäten erarbeiten, Tools nutzen wie Impact Mapping, also eine visuelle Methode, um die Verbindung zwischen Geschäfts- und Projektzielen zu verdeutlichen oder WSJF, weighted, shorted, job first, eine Methode um Arbeit nach Wert, Kosten und Dringlichkeit zu priorisieren, also versuchen, im Toolbaukasten was aufzubauen, um die Transparenz herzustellen und mit den Stakeholders im Dialog zu kommen oder zu bleiben, also Daten basiert, Entscheidungen treffen können. Eine wichtige Eigenschaft ist glaube ich wirklich auch Nein sagen, also clown konstruktiv zu kommunizieren, warum zum Beispiel das nicht alles sofort umgesetzt werden kann, immer wieder auch zu erklären, was da auf der Straße verloren geht, wenn der Kunde sagt, nee das ist ja dein Job und der Kunde da nicht mitarbeiten will. Ich hatte das letztens erst, wie gesagt, aus einer ganz anderen Situation, aber da habe ich dem Kunden einen vorgerechnet, was ihnen das Schluss endlich an Geld und Zeit kostet, dass er sagt, ich kann mich jetzt gerade mit dem Projekt nicht beschäftigen, aber das Projekt muss jetzt fertig werden. Ich kenne die Situation, ich kann den Kunden schon nachvollziehen, mir ist es dann aber wichtig, dass der Kunde das versteht. Ich habe dann halt gesagt, pass auf, ja verstehe die Situation und wir können jetzt auch weiter machen, aber es wird nicht das rauskommen, was du möchtest, du wirst hinten raus, super viel dich damit beschäftigen müssen, also die Zeit, die du vorne nicht investiert hast, musst du dann hinten investieren und das Risiko, dass das nicht rauskommt, was du eigentlich willst, ist halt super hoch und das bedeutet, wir fassen es wieder, wieder, wieder und wieder an und das kostet Zeit und Geld. Da kann man zumindest versuchen an dieser Stelle ja mit dem Kunden auch dran zu arbeiten oder mit den Stakeholders sagen, ich sage immer Kunde, weil ich in dieser Situation bin, nehmt man Stakeholder da immer so als Platzhalter für euch. Ja, also die Unterstützung eben einfordern, das erklären das Ganze, ich glaube darum geht es mir hier einfach in den Punkt, ja und wir brauchen halt die Unterstützung des Management, je nachdem, welchen Konstrukt ihr so lebt, es muss eben klar sein, dass der PO eben nicht eine Schattenverantwortung da irgendwie nur übernimmt, sondern eher die Verantwortung auch tragen will und deswegen diese Zuarbeit auch braucht oder die verlässliche Delegation, klare Regeln schaffen, wer trifft, wann welche Entscheidung und warum. Die Autorität dieses POs, warum gibt es diese Rolle, das macht ja Sinn, die muss man halt auch klar kommunizieren und das ist so ein bisschen das Konstrukt des Problemen, die Situation und Lösungsansätze, damit der Product Owner seinen Job wirklich gut machen kann und das auch in dem Sinn machen kann, wie das Scrum Framework sich das vorstellt. Kleine Zusammenfassung vielleicht an der Stelle, also der PO ist sicherlich zentral ins Scrum und die Praxis zeigt Stakeholder Management und klare Priorisierungen sind große Herausforderungen. Die Delegation ist möglich, aber sie scheitert dran oder scheitert immer dann, wenn Delegation nicht angenommen wird, wenn von Kunden oder anderen Stakeholders der Sinn der Delegation nicht verstanden wird, wenn diese Menschen keine Zeit haben, wenn sie noch im Modus sind von, ah jetzt habe ich das Projekt initialisiert und abgegeben und in drei Monaten kümmere ich mich wieder drum und in der Zeit kann ich was anderes machen. Das ist einfach super schwer, wenn so ein Denken da ist. Als Ergebnis der PO trägt die Verantwortung, hat aber manchmal nicht die Befugnisse, um sinnvoll Entscheidungen zu treffen und braucht dann Unterstützung und diese Unterstützung muss ihm irgendwie gewährt werden. Was ich mich so frage, kann der PO in jeder Organisation erfolgreich sein oder braucht es nicht wirklich diese Unterstützung und Klarheit und kann man Scrum machen, wenn diese Unterstützung und Klarheit nicht da ist, weil was ich glaube ist, wenn solche Rollen verwässert werden oder nicht klar sind, wird jedes Framework nicht nur Scrum einfach ganz große Schwierigkeiten haben. Es muss in der Organisation einfach das Fundament dazu da sein und Organisationen, finde ich, bezieht sich eben auf eine internen Organisation, aber auch auf die erweiterte Organisation, also dieses Zusammenspiel zwischen Kunden und Agenturen in unserem Fall. Ich glaube, da kann man lange lange lange und viel darüber diskutieren und wie gesagt, genau darum geht es mir ja immer hier in diesem Podcast. Ich möchte ja so zur Diskussion und zum Nachdenken anstiften. Deswegen, es ist mir super wichtig, welche Erfahrung habt ihr mit der PO Rolle gemacht? Also, vielleicht seid ihr PO, vielleicht seid ihr Teil eines Scrum Teams, dann habt ihr ein PO. Wie funktioniert das mit Delegation bei euch? Machen eure Kunden mit, wenn ihr in so einer Situation seid. Und wie geht ihr damit um, wenn ihr PO seid, wenn eure Stakeholder ihre Verantwortung nicht übernehmen? Wie vermeidet ihr so was wie in eine Schattenverantwortung gedrängt zu werden? Das wäre für mich super, super wichtig und es wäre ganz klasse, wenn ihr dazu ein Feedback darlast. Dazu gibt es verschiedene Stellen, kannst mir zum Beispiel eine Mail schreiben an nobias@gmail.com. Ich würde dich bitten, wenn du nicht auf Mastodon bist, komm bitte zu Mastodon. LinkedIn ist wirklich, also diese Woche waren so viele Posts, wo ich gedacht habe, das gibt es doch nicht und so viele Leute haben sich auch über LinkedIn beschwert. LinkedIn ist kein guter Platz und viele wechseln jetzt zu Blue Sky. Ich kann euch aber garantieren, Blue Sky wird auch irgendwann Geld verdienen müssen und die werden in Algorithmus einführend und Werbung und eure ganze Followerschaft, Protaktion auf Blue Sky, die wird auch den Bach runter gehen. In einem Jahr steht ihr wieder da und sagt, "Hm, eben meine Posts werden gar nicht mehr angezeigt, deswegen, Leute geht auf Mastodon, das ist frei, da gibt es kein Algorithmus, da wird es nie Werbung geben." Ich kann aus eigener Erfahrung sagen, die besten Diskussion, die ich habe, das beste Engagement zu meinem Post, das ist auf Mastodon und deswegen lasst uns auf Mastodon über so was reden. Den Link zu meinem Mastodon Profil findest du in den Show Notes. Zusätzlich gibt es ja parallel zu diesem Podcast noch ein Forum. Auch da ist die Idee, freien Austausch zu haben, der nicht mit Werbung oder Algorithmus konkurrieren muss, sondern ein ganz klassisches Forum, so wie wir es früher hatten und du findest in diesem Forum zu jeder Folge auch ein einzelnes Thread, deswegen auch da können wir gerne diskutieren und deswegen lasst uns darüber reden, welche Ideen habt ihr, welche Ansätze habt ihr. Ich habe dann noch eine weitere Bitte, wenn dir diese Folge gefallen hat, wenn sie dir vielleicht sogar geholfen hat, wenn du die Diskussion spannen findest, dann teil die Folge mit Kolleginnen und Kollegen im Team, mit dem Management, vielleicht sogar mit deinen Kunden hier gucke mal, da wurde das Thema gerade besprochen, über das wir auch geredet haben und teile es natürlich gerne auf deinen Social Media Kanälen. Mir ist es so unheimlich wichtig, dass sich der Podcast verbreitet, nicht damit ich berühmt werde oder irgendwas in der Art. Ich habe hier keine monetären Interessen, sondern je mehr Leute an der Diskussion teilnehmen, desto besser ist es für alle, für alle Devs in den Teams, für alle Kunden, die sich damit beschäftigen, für alle Stakeholder, für alle Leute, die, sag ich mal, wir wollen was Cooles bauen, weiter kommen wollen und Agilität ist der einzige Weg und ich glaube ganz, ganz oft scheitert es nur an Informationen und Diskussion, deswegen teil das gerne. Ansonsten würde ich sagen, habt noch eine ganz tolle Woche und bis zum nächsten Mal. Bye. [Musik] [Aufregende Musik]