Was Product Owner FALSCH machen!

Innerhalb der Softwareentwicklung kommt dem Product Owner eine große Verantwortung zu: Er koordiniert und steuert das Entwicklungsprojekt. Dabei passiert es jedoch oft, das die Product Owner einen entscheidenden Fehler machen der auf lange Sicht gesehen dazu führt, dass ein Softwareprojekt in große Schwierigkeiten kommen kann. In dieser Episode schauen wir uns an, welche Fehler das sind und wie genau das ganze umgangen werden kann - Viel Spaß!

▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬

Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)

▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

[superlive-sh]

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!

[sebastiangrafe]

Beliebter Satz von unserem PO: "Aber der Kunde will das genau so haben." Gegenrede der Entwickler ist nicht erwünscht.

[sicilianotube]

Sehr gut und anschaulich erklärt! 👍👍👍
Hat mein Interesse für PO geweckt, wusste vorher nicht genau wohin es mich zieht.

[projektingenieur]

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 🙂

[Jan_Hille]

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.

[rohrbold]

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.

[michaeldornberger]

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.

[eseldu]

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.

[michaelschmitz]

Danke für das Video, wie immer lehrreich mit praktischen Einblicken!

[andreweinert]

Wie immer ein sehr interessantes Video. Es zeigt auch wieviel in einer Firma schief laufen kann.

[tomdanielsofficial]

Super Video - hab ein Abo dagelassen ;)

[fwgmpvc]

Wenn alle jammern, dass ihre Bedürfnisse nicht ausreichend Berücksichtigung finden ist man wahrscheinlich grade in der goldenen Mitte 😂

[heikokunze]

Prinzipiell alles richtig, aber da war jetzt wenig neues dabei :-( Leider sind POs meist von sich viel zu sehr überzeugt, um solche Videos anzusehen.

[aggifun]

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…

[hansvetter]

Die Ursache aller Schwierigkeiten ist die Illusion das Neuentwicklungen planbar seien!

[robertneville]

Ich könnte einiges auf Product Owner schieben. Aber unfähige Projektleiter sind das eigentliche Problem.