@@krccmsitp2884 Wenn der Kunde nicht bekommt was er will, sondern nur das, was die Developer denken was er braucht, dann kauft er nicht und das Produkt wird eingestampft. IT hat oft das Gefühl besser zu wissen, was die Fachabteilung will als die Anwender selber. Millionen von Data Warehouse Projekte sind so grandios gescheitert.
Ihr Spezialisten. Dafür macht man mit dem Kunden iterative Requirements-Analyse. Um zwischen dem was der Kunde will und dem was er braucht eine Überschneidung herzustellen. Da wird die Freude aber groß, wenn das gekaufte Produkt sich tatsächlich bewährt.
Diese Erfahrung mache ich mit meinen Projektleitern auch jeden Tag. Ungenügende Kommunikationsfähigkeit um dem Kunden die Augen zu öffnen was er wirklich braucht aber oft nicht mal das Hirn sich einen Kollegen vom Vertrieb zu holen um im Kunden die Bedürfnisse in machbare Bahnen zu lenken. 😅 Klar geht das nicht immer aber es klappt zumindest wenn man auf Standards hinwirken möchte um die fehlerträchtige Extravaganz zu bendigen und Supportkosten im Zaun zu halten.
Ist immer ein Problem, wenn ein Product Owner Projektmanagement und Projektlebenszyklen wenig kennt oder sogar bewusst nicht beachtet. Meine Hypothese: Viele PO's mit denen ich zusammenarbeite denken häufig, dass es jetzt nicht mehr um Projekte geht sondern um Produkte. Anstatt zu verstehen, dass es darum geht innerhalb eines Projektes ein Produkt zu entwickeln 🙂 Und dann versteht man einfach nicht mehr, dass es eigentlich nicht darum geht Stakeholder zu verteufeln, sondern genau darum Stakeholder auch wirklich abzuholen bzw. zu integrieren in den Entwicklungsprozess. Danke für deinen Impuls das hier zu teilen!
Das sehe ich jetzt durchaus differenzierter. POs tragen die maßgebliche Verantwortung gegenüber dem Auftraggeber, was auch die Qualitätsattribute betrifft, die im überwiegenden Teil von den Entwicklern verantwortet werden. Er befindet sich häufig in einer undankbaren Rolle zwischen vielen verschiedenen Stakeholdern und kann es selten allen Recht machen. Von der einen Seite kommen unrealistische Forderungen bezüglich Featureumfang, Kostenersparnis und Zeitplanung; von der anderen Seite kriegt er zu hören, was alles Probleme bereitet, welche technischen Schulden abzubauen wären, dass die Zeitpläne unrealistisch sind etc. Wichtig ist doch, dass der PO immer noch Teil des Entwicklungsteams ist. Und so muss man von einem PO auch erwarten, dass er in kontinuierlichem Austausch mit seinen Entwicklern (und Architekten und QA etc.) ist. Natürlich funktioniert das Konstrukt nicht, wenn es hier keinen engen Austausch gibt, denn ein PO muss auch für das Team einstehen. Das sehe ich als das zentrale Versäumnis in den genannten Beispielen dieses Videos. Und auf der anderen Seite hat der PO auch nur einen Job, der ihm von jemand anderem anvertraut wurde, der wiederum hinter Features und schneller Markteinführung her ist. Es ist ja nur menschlich und verständlich, wenn der PO dann auch um seiner selbst willen dem Druck nicht immer standhalten kann. Aus meiner Sicht macht man es sich zu einfach, wenn man es auf "den PO" schiebt, wenn die Entwicklung nicht wie gewünscht verläuft. Die Welt ist da doch etwas komplexer.
Sehe ich genauso. Schlussendlich wird in der Softwareentwicklung von einem einzigen Menschen (PO) teilweise Unmenschliches verlangt von allen Seiten, teilweise wird dieser Rolle dabei gleichzeitig oft aber nicht die nötige Kapazität gegeben (Interessen jonglieren und überein bringen kostet Zeit, denn nicht immer ist sich jeder Stakeholder auch wirklich bewusst was er/sie möchte und kann direkt klar formulieren!), ein der Rolle PO inhärenter Konflikt per se. Hinzu kommt: Je mehr Interessenten, desto unwahrscheinlicher ist es, als PO alleine und ohne Unterstützung diese Mammutaufgabe zu stemmen. Die Folge: Fehlende Kommunikation oder gar "Vogel, friss oder stirb" - Kommunikation in Richtung der vermeintlichen leichtesten Richtung (Entwicklerteam 😞) Um so etwas zu vermeiden, werfe ich als Lösung hier mal die Rolle eines Scrum-Masters in den Ring, die bisher noch gar keine Erwähnung gefunden hat. Allein dass diese Rolle existiert mit ihrer Definition, die Zusammenarbeit im Team (PO + Entwickler) effizienter und transparenter zu gestalten, ist doch der Beweis dafür, dass am Ende immer das gesamte Team Verantwortung trägt, wenn etwas nicht läuft. Umgekehrt möchten doch auch alle etwas vom Kuchen haben, wenn etwas großartig geworden ist, oder nicht? 🙂 In den Fällen wo etwas nicht läuft, stecken meistens mehrere Kleinigkeiten auf beiden Seiten dahinter und es gibt nicht die eine Ursache. Nichtdestotrotz ist es mit Product Ownern wie mit Entwicklern, es gibt gute und es gibt schlechte. Mit dem Unterschied, dass der PO seine Rolle allein bekleidet und in einem nicht funktionierenden Team somit auch niemanden hat, der ihn/sie covern oder mit konstruktivem Feedback einfangen kann.
David du bist nicht nur Technik verliebt sondern hast auch immer ein Blick für Farben und Beleuchtung. Deine Videos geben uns neben dem super Content auch noch was fürs Auge ❤ Ich sage immer bunte Bilder macht die Leute glücklich 🙂
Hey, sehr schön erklärt. Ich beschäftige mich aktuell auch mit dem Thema bezüglich einer Produktionsmaschine. Deine Videos sind sehr hilfreich und haben mir noch einige neue Aspekte eröffnet.
Ich würd sagen dass PO, Architekt UND andere Schlüsselpersonen (Abteilungsleiter , Systemingenieure, Programleiter, …) als Team arbeiten müssen um solche komplexen Sachverhalte langfristig zu bewerkstelligen. Für mich ist es nicht in Ordnung, die Schuld bei 1 oder 2 Rollen zu suchen - zumindest in den Umgebungen in denen ich bisher tätig war.
Gebe dir völlig recht. Ist aber nicht auch der Architekt dafür verantwortlich dem PO z.B. fehlende oder unzureichende Qualitätsaspekte zu melden und mit ihm zu "verhandeln"? PO und SA sollten da aus meiner Sicht an der Stelle enger zusammenarbeiten. Das fehlt aber häufig.
Die Rolle des Product Owners - so wie Du sie beschreibst - hatte anscheinend konkrete Personen vor Augen - nicht nur eine Rolle. Meine Erfahrungen deuten darauf hin, dass es zu massiven Problemen kommt, wenn diese Rolle durch eine einzelne Person wahrgenommen werden soll. Das ging bislang immer schief. Ich versuche gerade diese Rolle auf ein Team aus Marketing, Designer, IT und Support aufzuteilen - ganz bewusst hat der Vertrieb dort nichts zu suchen, da er immer ausschliesslich projektbezogen denken würde, er kommuniziert aber regelmässig mit dem Marketing. Ich bin gespannt, wie weit wir mit diesem Ansatz kommen…
Spannender Ansatz einen Stakeholder auszuschließen. Das Vertriebler meistens die lauteren sind und ihre Anforderungen hierdurch überbewertet werden, sollte man meiner Meinung nach bei der Priorisierung in den Vordergrund rücken. Ich kritisiere gerade, dass bei uns die Rollen durch mehrere Personen besetzt werden, da jede Partei ihre eigenen Ziele verfolgt und für das Ganze übernimmt keiner die Verantwortung. Ist ein totales Chaos. Natürlich steht und fällt die Qualität des Produktes mit der Qualität der Product Owners, aber Verantwortung teilen, sehe ich als das größere Übel an. Drück dir die Daumen, dass es bei euch funktioniert! Jedes Team ist individuell 😉
Wie sind den bis jetzt deine Erfahrungen mit dem PO Komitee? Deine beschriebene Vorgehensweise ist entgegen des Scrum Guides. In meinen Augen ist das Marketing und der Support Stakeholder, der Designer Teammitglied und die IT wenn sie DevOps macht ebenfalls Team, sonst auch Stakeholder. Ich frage deswegen, weil ich schon häufig gelesen habe, das es ein Fehler ist und zu Schwierigkeiten kommen kann, wenn der PO durch mehrere Personen vertreten wird.
![Scrum - Von A bis Z [Mit Profi-Tipps]](http://i.ytimg.com/vi/QtTH3m8GfN0/mqdefault.jpg)
Beliebter Satz von unserem PO: "Aber der Kunde will das genau so haben." Gegenrede der Entwickler ist nicht erwünscht.
Ja der Kunde zahlt auch dafür
@@BinGanzLieb Der Kunde mag vielleicht wissen und sagen was er *will*, aber nicht unbedingt das was er *braucht*.
@@krccmsitp2884 Wenn der Kunde nicht bekommt was er will, sondern nur das, was die Developer denken was er braucht, dann kauft er nicht und das Produkt wird eingestampft.
IT hat oft das Gefühl besser zu wissen, was die Fachabteilung will als die Anwender selber. Millionen von Data Warehouse Projekte sind so grandios gescheitert.
Ihr Spezialisten. Dafür macht man mit dem Kunden iterative Requirements-Analyse. Um zwischen dem was der Kunde will und dem was er braucht eine Überschneidung herzustellen. Da wird die Freude aber groß, wenn das gekaufte Produkt sich tatsächlich bewährt.
Diese Erfahrung mache ich mit meinen Projektleitern auch jeden Tag. Ungenügende Kommunikationsfähigkeit um dem Kunden die Augen zu öffnen was er wirklich braucht aber oft nicht mal das Hirn sich einen Kollegen vom Vertrieb zu holen um im Kunden die Bedürfnisse in machbare Bahnen zu lenken. 😅
Klar geht das nicht immer aber es klappt zumindest wenn man auf Standards hinwirken möchte um die fehlerträchtige Extravaganz zu bendigen und Supportkosten im Zaun zu halten.
Ist immer ein Problem, wenn ein Product Owner Projektmanagement und Projektlebenszyklen wenig kennt oder sogar bewusst nicht beachtet. Meine Hypothese: Viele PO's mit denen ich zusammenarbeite denken häufig, dass es jetzt nicht mehr um Projekte geht sondern um Produkte. Anstatt zu verstehen, dass es darum geht innerhalb eines Projektes ein Produkt zu entwickeln 🙂
Und dann versteht man einfach nicht mehr, dass es eigentlich nicht darum geht Stakeholder zu verteufeln, sondern genau darum Stakeholder auch wirklich abzuholen bzw. zu integrieren in den Entwicklungsprozess.
Danke für deinen Impuls das hier zu teilen!
Das sehe ich jetzt durchaus differenzierter. POs tragen die maßgebliche Verantwortung gegenüber dem Auftraggeber, was auch die Qualitätsattribute betrifft, die im überwiegenden Teil von den Entwicklern verantwortet werden. Er befindet sich häufig in einer undankbaren Rolle zwischen vielen verschiedenen Stakeholdern und kann es selten allen Recht machen. Von der einen Seite kommen unrealistische Forderungen bezüglich Featureumfang, Kostenersparnis und Zeitplanung; von der anderen Seite kriegt er zu hören, was alles Probleme bereitet, welche technischen Schulden abzubauen wären, dass die Zeitpläne unrealistisch sind etc.
Wichtig ist doch, dass der PO immer noch Teil des Entwicklungsteams ist. Und so muss man von einem PO auch erwarten, dass er in kontinuierlichem Austausch mit seinen Entwicklern (und Architekten und QA etc.) ist. Natürlich funktioniert das Konstrukt nicht, wenn es hier keinen engen Austausch gibt, denn ein PO muss auch für das Team einstehen. Das sehe ich als das zentrale Versäumnis in den genannten Beispielen dieses Videos.
Und auf der anderen Seite hat der PO auch nur einen Job, der ihm von jemand anderem anvertraut wurde, der wiederum hinter Features und schneller Markteinführung her ist. Es ist ja nur menschlich und verständlich, wenn der PO dann auch um seiner selbst willen dem Druck nicht immer standhalten kann.
Aus meiner Sicht macht man es sich zu einfach, wenn man es auf "den PO" schiebt, wenn die Entwicklung nicht wie gewünscht verläuft. Die Welt ist da doch etwas komplexer.
@@opodendorf Perfekt beschrieben!
Sehe ich genauso. Schlussendlich wird in der Softwareentwicklung von einem einzigen Menschen (PO) teilweise Unmenschliches verlangt von allen Seiten, teilweise wird dieser Rolle dabei gleichzeitig oft aber nicht die nötige Kapazität gegeben (Interessen jonglieren und überein bringen kostet Zeit, denn nicht immer ist sich jeder Stakeholder auch wirklich bewusst was er/sie möchte und kann direkt klar formulieren!), ein der Rolle PO inhärenter Konflikt per se. Hinzu kommt: Je mehr Interessenten, desto unwahrscheinlicher ist es, als PO alleine und ohne Unterstützung diese Mammutaufgabe zu stemmen. Die Folge: Fehlende Kommunikation oder gar "Vogel, friss oder stirb" - Kommunikation in Richtung der vermeintlichen leichtesten Richtung (Entwicklerteam 😞) Um so etwas zu vermeiden, werfe ich als Lösung hier mal die Rolle eines Scrum-Masters in den Ring, die bisher noch gar keine Erwähnung gefunden hat. Allein dass diese Rolle existiert mit ihrer Definition, die Zusammenarbeit im Team (PO + Entwickler) effizienter und transparenter zu gestalten, ist doch der Beweis dafür, dass am Ende immer das gesamte Team Verantwortung trägt, wenn etwas nicht läuft. Umgekehrt möchten doch auch alle etwas vom Kuchen haben, wenn etwas großartig geworden ist, oder nicht? 🙂 In den Fällen wo etwas nicht läuft, stecken meistens mehrere Kleinigkeiten auf beiden Seiten dahinter und es gibt nicht die eine Ursache. Nichtdestotrotz ist es mit Product Ownern wie mit Entwicklern, es gibt gute und es gibt schlechte. Mit dem Unterschied, dass der PO seine Rolle allein bekleidet und in einem nicht funktionierenden Team somit auch niemanden hat, der ihn/sie covern oder mit konstruktivem Feedback einfangen kann.
Sehr gut und anschaulich erklärt! 👍👍👍
Hat mein Interesse für PO geweckt, wusste vorher nicht genau wohin es mich zieht.
David du bist nicht nur Technik verliebt sondern hast auch immer ein Blick für Farben und Beleuchtung. Deine Videos geben uns neben dem super Content auch noch was fürs Auge ❤
Ich sage immer bunte Bilder macht die Leute glücklich 🙂
Hey, sehr schön erklärt. Ich beschäftige mich aktuell auch mit dem Thema bezüglich einer Produktionsmaschine. Deine Videos sind sehr hilfreich und haben mir noch einige neue Aspekte eröffnet.
Ich würd sagen dass PO, Architekt UND andere Schlüsselpersonen (Abteilungsleiter , Systemingenieure, Programleiter, …) als Team arbeiten müssen um solche komplexen Sachverhalte langfristig zu bewerkstelligen. Für mich ist es nicht in Ordnung, die Schuld bei 1 oder 2 Rollen zu suchen - zumindest in den Umgebungen in denen ich bisher tätig war.
Wie immer ein sehr interessantes Video. Es zeigt auch wieviel in einer Firma schief laufen kann.
Gebe dir völlig recht. Ist aber nicht auch der Architekt dafür verantwortlich dem PO z.B. fehlende oder unzureichende Qualitätsaspekte zu melden und mit ihm zu "verhandeln"? PO und SA sollten da aus meiner Sicht an der Stelle enger zusammenarbeiten. Das fehlt aber häufig.
Danke für das Video, wie immer lehrreich mit praktischen Einblicken!
Wenn alle jammern, dass ihre Bedürfnisse nicht ausreichend Berücksichtigung finden ist man wahrscheinlich grade in der goldenen Mitte 😂
Die Rolle des Product Owners - so wie Du sie beschreibst - hatte anscheinend konkrete Personen vor Augen - nicht nur eine Rolle.
Meine Erfahrungen deuten darauf hin, dass es zu massiven Problemen kommt, wenn diese Rolle durch eine einzelne Person wahrgenommen werden soll. Das ging bislang immer schief. Ich versuche gerade diese Rolle auf ein Team aus Marketing, Designer, IT und Support aufzuteilen - ganz bewusst hat der Vertrieb dort nichts zu suchen, da er immer ausschliesslich projektbezogen denken würde, er kommuniziert aber regelmässig mit dem Marketing.
Ich bin gespannt, wie weit wir mit diesem Ansatz kommen…
Spannender Ansatz einen Stakeholder auszuschließen. Das Vertriebler meistens die lauteren sind und ihre Anforderungen hierdurch überbewertet werden, sollte man meiner Meinung nach bei der Priorisierung in den Vordergrund rücken.
Ich kritisiere gerade, dass bei uns die Rollen durch mehrere Personen besetzt werden, da jede Partei ihre eigenen Ziele verfolgt und für das Ganze übernimmt keiner die Verantwortung. Ist ein totales Chaos.
Natürlich steht und fällt die Qualität des Produktes mit der Qualität der Product Owners, aber Verantwortung teilen, sehe ich als das größere Übel an.
Drück dir die Daumen, dass es bei euch funktioniert! Jedes Team ist individuell 😉
Wie sind den bis jetzt deine Erfahrungen mit dem PO Komitee? Deine beschriebene Vorgehensweise ist entgegen des Scrum Guides. In meinen Augen ist das Marketing und der Support Stakeholder, der Designer Teammitglied und die IT wenn sie DevOps macht ebenfalls Team, sonst auch Stakeholder. Ich frage deswegen, weil ich schon häufig gelesen habe, das es ein Fehler ist und zu Schwierigkeiten kommen kann, wenn der PO durch mehrere Personen vertreten wird.
Prinzipiell alles richtig, aber da war jetzt wenig neues dabei :-( Leider sind POs meist von sich viel zu sehr überzeugt, um solche Videos anzusehen.
Super Video - hab ein Abo dagelassen ;)
Stimme dir vollkommen zu!
Ich könnte einiges auf Product Owner schieben. Aber unfähige Projektleiter sind das eigentliche Problem.
Die Ursache aller Schwierigkeiten ist die Illusion das Neuentwicklungen planbar seien!
Noch Happy mit dem Surface Book?