Product Owner Days 2024: Was POs nicht aus dem Scrum Guide erfahren – aber asap wissen sollten!
Summary
TLDRDer Sprecher diskutiert die Rolle des Product Owners im Kontext von Scrum und敏捷性, betonend, dass die Bedeutung von 'Product Owner' je nach Organisation und Produkt stark variieren kann. Er betont die Notwendigkeit, kontinuierlich zu lernen und sich im Produktmanagement weiterzubilden, da jeder Kontext einzigartig ist. Der Fokus liegt auf der Bedeutung der Vision, der Kommunikation mit Stakeholdern, der Bedeutung der Entscheidungsfindung und der Notwendigkeit, die Grenzen der Verantwortung des Product Owners zu verstehen. Zudem wird die Bedeutung des Zuhörens und des Fokus auf eine Sache zur Maximierung des Wertes hervorgehoben.
Takeaways
- 😀 Der Sprecher betont die Bedeutung des Kontextes im Product Owner-Role und wie unterschiedliche Kontexte unterschiedliche Aufgaben erfordern.
- 🤔 Es wird darauf hingewiesen, dass der Begriff 'Product Owner' in verschiedenen Organisationen unterschiedlich interpretiert werden kann, was zu Missverständnissen führen kann.
- 📚 Der Sprecher teilt seine Erfahrung, dass es wichtig ist, sich im Bereich Produktmanagement weiterzubilden und nicht nur auf Scrum zu fokusieren.
- 🎯 Er betont die Notwendigkeit, die Lücke zwischen der Produktvision und dem Product Backlog mit geeigneten Tools und Methoden zu schließen.
- 🤝 Der Sprecher plädiert für eine stärkere Zusammenarbeit mit Stakeholdern, um ein besseres Verständnis und Engagement für die gemeinsame Produktentwicklung zu erreichen.
- 💬 Die Bedeutung des Zuhörens bei der Kommunikation mit Stakeholdern wird hervorgehoben, da es zu einer Verbesserung der Beziehungen und Empathie führen kann.
- 🃏 Der Vergleich von Product Owner Arbeit mit einem Pokerspiel unterstreicht, dass Entscheidungen oft unter Unsicherheit getroffen werden müssen.
- 🔍 Der Sprecher erläutert, dass Product Ownern die Vision und den Backlog miteinander verbinden und eine konsistente Geschichte für die Produktentwicklung erzählen müssen.
- 📉 Er diskutiert die Herausforderungen, die mit der Priorisierung des Product Backlogs einhergehen und wie dies oft das Hauptthema in Trainings ist.
- 🤖 Der Sprecher reflektiert über die Rolle des Scrum Masters und wie diese bei der Unterstützung von Product Ownern und der Organisation wichtig sein kann.
- 🔗 Er weist darauf hin, dass es notwendig ist, sowohl in der agilen als auch in der Produktmanagement-Community tätig zu sein, um ein ganzes Bild zu erhalten.
- 🚀 Schließlich betont der Sprecher die kontinuierliche Lernreise des Product Owners und die Bedeutung, sich mit neuen Themen und Ideen aus verschiedenen Quellen fortzuwenden.
Q & A
Was ist der Hauptthema des Vortrags?
-Der Vortrag konzentriert sich auf das Verständnis und die Rolle des Product Owners in unterschiedlichen Kontexten, die Herausforderungen und die Bedeutung des kontinuierlichen Lernens im Produktmanagement.
Was bedeutet der Sprecher mit 'Product Owner ist nicht gleich Product Owner'?
-Der Sprecher betont, dass die Rolle des Product Owners je nach Unternehmen und Kontext sehr unterschiedlich sein kann, was die Bedeutung und die Verantwortlichkeiten betrifft.
Was sind die Hauptbestandteile des Vortrags?
-Der Vortrag beinhaltet persönliche Erfahrungen, die Bedeutung des Produktlebenszyklus, die Unterschiede zwischen Scrum Product Owner und anderen Produktmanagement-Rollen, sowie die Notwendigkeit, sich im Produktmanagement weiterzubilden.
Was versteht der Sprecher unter 'Produktmanagement Bubble'?
-Die 'Produktmanagement Bubble' bezieht sich auf die Isolation innerhalb der Produktmanagement-Gemeinschaft, die sich möglicherweise nicht ausreichend mit der agilen Community verbindet und umgekehrt.
Was ist die Rolle des Scrum Masters im Vortrag?
-Der Scrum Master wird als Helfer und Unterstützer der Product Owner in der Organisation und bei der Zusammenarbeit mit Stakeholdern dargestellt.
Was bedeutet 'Spielen wir Poker und nicht Schach'?
-Dieser Ausdruck soll verdeutlichen, dass die Arbeit des Product Owners mit Unsicherheiten und Wetten einhergeht, im Gegensatz zu Schach, wo alle Informationen klar sind und der nächste Zug logisch folgt.
Wie sieht der Sprecher die Bedeutung der Vision für den Product Owner?
-Die Vision ist für den Sprecher wichtig, aber es muss eine Brücke zwischen der Vision und der Product Backlog geschlossen werden, um eine konsistente Produktentwicklungsgeschichte zu erzählen.
Was sind die Schwierigkeiten, die der Sprecher bei der Zusammenarbeit mit Stakeholdern sieht?
-Der Sprecher identifiziert die Schwierigkeit, alle Beteiligten auf ein Thema zu fokussieren und die Notwendigkeit, Stakeholder als Teil eines zweiten Teams zu betrachten, das zusammen mit dem Entwicklungsteam arbeitet.
Was ist der Vorschlag des Sprechers für die Arbeit mit Stakeholdern?
-Der Sprecher schlägt vor, Stakeholder als ein zweites Scrumteam zu betrachten und regelmäßig Reviews von Entscheidungen durchzuführen, um eine bessere Aligned-Ziele zu erreichen.
Was unterscheidet den Sprecher zwischen der agilen Community und der Produktmanagement-Community?
-Der Sprecher sieht zwei getrennte Communitys, die zwar ähnliche Herausforderungen haben, aber unterschiedliche Ansätze und Begriffe verwenden und nicht genügend miteinander kommunizieren.
Was ist der letzte Punkt, den der Sprecher anspricht?
-Der letzte Punkt, den der Sprecher anspricht, ist die Notwendigkeit des kontinuierlichen Lernens und die Anerkennung, dass sich der Kontext des Product Owners im Laufe der Zeit verändern wird.
Outlines
😀 Willkommen und Einführung
Der Sprecher begrüßt die Teilnehmer und betont die Bedeutung der Perspektive im Plenum. Er möchte nicht viel über sich selbst erzählen, sondern den Teilnehmern nach dem Vortrag Gelegenheit geben, Fragen zu stellen. Er erwähnt, dass er während der gesamten Veranstaltung verfügbar ist. Der Sprecher betont die Bedeutung des Product Owner-Konzepts und teilt mit, dass er in den letzten Jahren viel gelernt hat und seine Erfahrungen teilen möchte. Er reflektiert über die unterschiedlichen Rollen und Verantwortlichkeiten von Product Owners in verschiedenen Kontexten.
🤔 Die Rolle des Product Owners im Kontext
Der Sprecher erklärt, dass der Begriff 'Product Owner' je nach Kontext unterschiedliche Bedeutungen haben kann. Er kritisiert, dass viele Product Owner möglicherweise nicht genug über das tatsächliche Produktmanagement wissen und dass die Rolle des Product Owners in Abhängigkeit zur Scrum-Richtlinie variiert. Der Sprecher betont die Notwendigkeit, die Aufgaben und Verantwortlichkeiten im richtigen Kontext zu betrachten und kritisiert, dass viele/Product Ownerinnen möglicherweise nicht die nötigen Kenntnisse haben, um ihre Aufgaben effektiv auszuführen.
📈 Produktmanagement und Scrum
Der Sprecher diskutiert die Verbindung zwischen Produktmanagement und Scrum. Er betont, dass Scrum seine Stärken im Produktlebenszyklus am Ende zeigt, wenn das Produkt betrieben und iteriert wird. Der Sprecher kritisiert, dass viele Product Owner nicht genug über moderne Produktmanagement-Techniken wissen und dass sie sich mehr mit diesem Thema auseinandersetzen sollten. Er erwähnt auch die Herausforderungen, die mit der Verantwortung als Product Owner verbunden sind und wie man unter Unsicherheit Entscheidungen treffen muss, vergleicht es mit dem Spielen von Poker anstatt Schach, wo man auf incomplete Informationen agiert.
🛠️ Produktvision und Backlog-Management
Der Sprecher konzentriert sich auf die Bedeutung der Produktvision und wie diese in die Backlog-Management-Praxis integriert werden kann. Er kritisiert, dass Scrum-Richtlinien zu wenig darüber sagen, wie man von einer Vision zu einem Backlog kommt, und dass viele Product Owner sich zu sehr auf das Priorisieren des Backlogs konzentrieren, anstatt die Lücke zwischen Vision und Backlog zu schließen. Der Sprecher betont die Notwendigkeit, eine konsistente Geschichte für die Produktentwicklung zu erzählen und die Lücke zwischen Vision und Backlog mit sinnvollen Dingen zu füllen.
🔍 Fokussierung und Stakeholder-Management
Der Sprecher diskutiert die Bedeutung der Fokussierung im Produktmanagement und wie Product Owner ihre Arbeit auf eine Sache reduzieren sollten, um den größten Wert zu maximieren. Er betont, dass die meisten Product Owner zu viele Dinge gleichzeitig erledigen und dadurch den Fokus verlieren. Der Sprecher reflektiert auch über die Rolle des Product Owners in der Beziehungs- und Kommunikationsarbeit mit Stakeholdern und betont die Notwendigkeit, aufzuhören zu überzeugen und zuzuhören, um eine echte Verbindung aufzubauen.
🤝 Die Rolle des Product Owners in der Zusammenarbeit mit Stakeholdern
Der Sprecher vertieft das Thema der Zusammenarbeit mit Stakeholdern und wie diese als ein zweites Scrum-Team behandelt werden kann. Er betont die Notwendigkeit, Stakeholder zusammenzubringen, um die bestmöglichen Produkt- und Geschäftsentscheidungen zu treffen. Der Sprecher reflektiert über die Herausforderungen, die mit der Arbeit in verschiedenen Communities verbunden sind, und betont die Bedeutung, sowohl in der agilen als auch in der Produktmanagement-Community tätig zu sein, um ein ganzes Bild zu bekommen.
🌟 Kontinuierliches Lernen und Zusammenarbeit
Der Sprecher schließt mit der Betonung des kontinuierlichen Lernens und der Notwendigkeit, sich mit neuen Themen und Ideen auseinanderzusetzen. Er betont, dass die Rolle des Product Owners ständig wechselt und sich verändert und dass es wichtig ist, offen für neue Ideen zu bleiben. Der Sprecher empfiehlt, sich in beiden Welten, der agilen und der Produktmanagement-Community, zu bewegen und nicht in einer einzigen Hinsicht zu verankern. Er betont die Herausforderung und das Potenzial, das in der Rolle des Product Owners liegt und fordert die Teilnehmer auf, aktiv an Fortbildungen teilzunehmen, um ihre Fähigkeiten zu erweitern.
Mindmap
Keywords
💡Product Owner
💡Product Ownership
💡Scrum
💡Produktlebenszyklus
💡Produktvision
💡Produktstrategie
💡Produktbacklog
💡Wettbewerbsanalyse
💡Stakeholder
💡Agiles Framework
💡Produktmanagement
💡Kontinuierliche Lernreise
Highlights
Begrüßung und Einführung: Der Sprecher begrüßt das Publikum und betont die Bedeutung der Perspektive im Plenum.
Persönliche Einführung: Sprecher möchte weniger über seine Person sprechen und stattdessen über sein und das Publikums' Engagement für das Thema.
Produktbesitzer-Rollenverständnis: Es wird ein allgemeines Verständnis von Product Owner und product ownership diskutiert.
Erfahrungsbericht: Der Sprecher teilt seine Erfahrung im Bereich Scrum und Product Owner und betont die kontinuierliche Lernreise.
Kontextabhängigkeit: Der Fokus liegt auf der Bedeutung des jeweiligen Kontextes im Product Owner-Umfeld.
Produktlebenszyklus: Es wird über die unterschiedlichen Phasen im Produktlebenszyklus und die Rolle des Product Owners in diesen Phasen gesprochen.
Produktmanagement-Kenntnisse: Der Sprecher betont die Bedeutung von Produktmanagement-Kenntnissen für Product Owner.
Scrum-Framework-Kritik: Es wird kritisiert, dass das Scrum-Framework nicht ausreichend zwischen Produktvision und Backlog-Management vermittelt.
Produktvision und Backlog: Der Sprecher diskutiert die Lücke zwischen der Festlegung einer Produktvision und der tatsächlichen Backlog-Management-Praxis.
Priorisierung des Backlogs: Es wird auf die Herausforderungen und die Bedeutung der Backlog-Priorisierung eingegangen.
Produktowner-Entscheidungen: Der Sprecher betont, dass die Entscheidungen des Product Owners von der gesamten Organisation akzeptiert werden müssen.
Kommunikation und Beziehungsarbeit: Es wird auf die Wichtigkeit von Kommunikation und Beziehungsaufbau mit Stakeholdern hingewiesen.
Produktowner-Rollenverständnis: Der Sprecher teilt seine Sichtweise auf die Rolle des Product Owners und ihre Verantwortung.
Produktowner-Entwicklung: Es wird über die kontinuierliche Entwicklung und das Lernen im Bereich Product Ownership gesprochen.
Produktmanagement-Community: Der Sprecher fordert eine stärkere Vernetzung zwischen der agilen Community und der Produktmanagement-Community.
Produktowner-Kontinuität: Es wird betont, dass das Wissen und Lernen als Product Owner eine nicht endende Reise ist.
Schwerpunkte für Product Owner: Der Sprecher listet verschiedene Aspekte auf, auf die Product Owner achten sollten, wie z.B. Stakeholder-Management und Vision-Umsetzung.
Einladung zu Trainings: Der Sprecher teilt Informationen über anstehende Trainings und wie man ihn kontaktieren kann.
Transcripts
schön dass Ihr alle da seid ähm ich
hoffe bei Martin sind auch noch ein paar
weil ja weil der Raum so voll wirkt ich
habe eben hinten gesessen die
Perspektive ist ganz anders
freut mich sehr
m ich möchte gar nicht so viel über
meine Person sagen ich halte das so ein
bisschen wie der Holger eben wenn er
euch dafür interessiert was ich so mache
was wir so machen wenn ihr fragen habt
kommt gerne irgendwie nach dem Talk zu
mir ich bin auch die ganzen zwei Tage da
sprecht mich an ähm dann können wir uns
so dieses ganze ich muss euch erzählen
ne wer ich bin und was ich alles so
gemacht habe sparen weil die halbe
Stunde auch durchaus sehr knapp bemessen
ist ich würde euch aber gerne
zumindestens zwei drei Sätze mitgeben
dazu ähm warum es sich vielleicht lohnen
könnte zuzuhören ähm und dass ich was zu
erzählen habe ähm stefan hat das ja
schon angedeutet ne also es gibt ähm
ein gewisses Verständnis von Product
Owner oder von product ownership was ich
auch immer wieder ja draußen beobachten
darf wenn ich Trainings gebe wenn ich
Leute unterstütze wenn ich
ein Mentoring annehme und ich habe halt
vor es lass es jetzt auch 12 13 Jahre
das erste Mal Berührung mit Scrum und
auch mit der Verantwortlichkeit des
Product owners gehabt und glaube dass
ich in diesen letzten Jahren noch
relativ viel gelernt habe was ich damals
nicht wusste also ich bin gewissen Weg
gegangen hab eine gewisse lernreise für
mich selber gemacht jetzt stehen wir da
wo wir halt sind aber wenn ich so ein
bisschen zurückblicke denke ich immer da
war mal eine Abzweigung da habe ich
damals nicht besonders gut
hingeguckt da hätte ich mal besser
hingucken sollen und wenn ihr nur aus
dem Talk zwei drei Punkte mitnimmt wo
ihr denkt da habe ich noch gar nicht so
sehr drüber nachgedacht da lohnt es sich
vielleicht mal hinzugucken und drüber
nachzudenken ob das für mich in meinem
Kontext in meinem meiner Entwicklung die
ich mache für mich relevant sein könnte
dann hätte ich mein Ziel dieses talks
eigentlich schon
erreicht gut viel mehr gar nicht dazu
dann lasst uns direkt in den Inhalt
Starten der holger hat das eben auch
schon so ein bisschen angedeutet aber
ich würde verschiedene Aspekte noch mal
anders
Frame Product Owner ist nicht gleich
Product Owner wenn wir ein Unternehmen
gehen wenn wir in der Organisation
sind und jemand sagt ich bin Product
Owner oder ich mache hier product
ownership in dem scum Team
ist der Aussagegehalt von dieser Antwort
für mich quasi gleich null ich weiß
überhaupt nicht was der macht ne obwohl
ich 12 Jahre product ownership mache und
ihr werdet das auch feststellen wenn
euch draußen mit dem einen oder der
anderen unterhaltet ihr heißt vielleicht
alle Product Owner oder ihr seid Product
Owner in so Teams aber er macht
höchstwahrscheinlich in nur nicht nur in
Nuancen sondern vielleicht auch im
Detail ganz viele andere Dinge das eine
hat mit dem anderen gar nichts zu tun
und es liegt aus meiner Sicht halt daran
dass natürlich der Kontext in dem ihr
unterwegs seid zum Teil komplett anders
ist das kann ein Produkt liegen ne also
ihr habt ein ganz unterschiedliches
Produkt vielleicht habt ihr ein B2B
Produkt die anderen haben B2C Produkt
vielleicht liegt es daran wo ihr mit
eurem Produkt im Produkt Lebenszyklus
euch aufhaltet vielleicht seid ihr
gerade in der Phase wo ihr überhaupt
drüber nachdenkt was ist denn eigentlich
das Kundenproblem ähm was sind denn
Ideen wie wir das Kundenproblem lösen
vielleicht ist seid Ihr aber auch in der
Phase wo euer Produkt eigentlich nur
noch abgewickelt werden muss und ihr ähm
hinterher nur noch guckt dass er eine
gewisse Art von maintenance oder Betrieb
irgendwie dieses Produktes noch macht
die Branche kann komplett anders sein ne
also bin ich in einem regulierten Umfeld
unterwegs oder wie auch immer und hinzu
kommt glaube ich auch noch zumindestens
komme ich auch aus dieser agilen Bubble
und nicht aus der Produktmanagement
Bubble ursprünglich ein Problem kann
auch noch sein dass ähm sag mal so die
agile Community wenn man sie
weitergreift sich auch glaube ich kein
Gefallen damit getan hat zu sagen in
Scrum gibt ist den Scrum Product Owner
und das ist auch ein bisschen das was
Stefan gerade gesagt hat aber in safe in
einem skalierungsf gibt's auch die Rolle
des Product owners der hat aber mit dem
Scrum Product Owner gar nichts zu tun
das heißt ihr werdet auch wenn ihr auf
stellenusschreibung guckt für Product
Owner lesen und wenn ihr eure eene
Aufgaben die ihr gerade habt so ein
bisschen reflektiert dass das eine mit
dem anderen gar nichts zu tun hat und
das ist was was mir am Anfang z.B gar
nicht klar war ne ich habe gedacht ich
kan aus dem Training raus oder habe in
samgide geguckt und habe gedacht völlig
klar was so Po macht ich brauche nur das
machen was man mir beigebracht hat aber
ihr müsst alles was ihr tut zumindestens
aus meiner Sichtweise immer in den
richtigen Kontext setzen und überlegen
was braucht ihr für eure Aufgabe und wie
gestaltet ihr eure Aufgabe tatsächlich
dann irgendwie aus ja und keine Ahnung
es muss auch nicht so sein dass ihr
alles mögt also ich kann aus eigener
Erfahrung heraus sagen ich bin nicht
besonders gut bei Produkten die noch
so weiß ich nicht ein am Anfang sind wo
Markus der wahrscheinlich sehr stark ist
der sitzt hier vorne oder wo wo es viel
und Innovation und wie auch immer geht
wenn wir aber in so eine Phase kommen
von jetzt ist eigentlich klar was das
Kundenproblem ist und wir fangen an zu
bauen und zu iterieren also da wo in
meiner Welt zumindestens Scrum auch
seine Stärken ausspielen kann da bin ich
wieder besonders gut wenn wir am Ende
des produktlebenszyklusses sind und
eigentlich das Produkt nur noch
betrieben werden muss und keine da bin
ich wieder total schlecht also mir
geht's auch darum dass ihr mitnehmt es
ist überall unterschiedlich der Kontext
ist Unterschied und reflektiert
vielleicht auch wo habt ihr eure Stärken
oder wo wollt ihr auch
sein und am auffälligsten finde ich wird
das auch immer bei Stellenausschreibung
auf die ihr guckt und ich würde genau
diese Fragen tatsächlich wenn ihr
irgendwann eine neue Aufgabe übernehmt
auch beim neuen Arbeitgeber in der neuen
Organisation tatsächlich auch
stellen was könnte ich euch noch
erzählen das ist glaube ich ein Punkt
der eben auch schon mal klarer
artikuliert wurde für mich ist Product
Owner eine Verantwortlichkeit eine Rolle
innerhalb des Scrum Frameworks was ich
übernehme aber das was ihr tun solltet
ist Produktmanagement machen vielleicht
agil Produktmanagement machen und was
ich beobachte ist dass ganz viele
Product Owner die ich kennenlerne und
das ist jetzt gar nicht ne ich kenne
euch alle nicht ne aber ich ziehe mich
mal mit damit ein überhaupt keine Ahnung
von Produktmanagement haben oder was
state of the art Produkt ement
eigentlich ist wie man ein Produkt
entwickelt und Gott sei Dank haben wir
hier viele andere Speaker auch die
gerade in diesem Thema vielleicht sogar
noch viel mehr Ahnung haben als ich und
euch ein paar Sachen erzählen können
eine Roadmap nicht wie ein releasepan
behandelt wird sondern eher etwas was
irgendwie auf outcomes aus ist oder wie
ich innovativ unterwegs bin auch der
holger hat ja bestimmte Dingen erzählt
ne und ihr müsst euch zumindestens aus
meiner ganz subjektiven Sicht mit dem
Thema Produktmanagement auseinanders
setzen ja und es reicht nicht zu sagen
ja ich habe jetzt verstanden wie denn
dieses Scrum Framework und die
Verantwortlichkeiten funktionieren weil
das hat Stefan auch gesagt da gibt's
ganz viel dazwischen was überhaupt nicht
erklärt ist da wird auch nicht erklärt
den Entwicklern ähm ob wie sie denn zu
entwickeln haben ne das ist der Sinn und
Zweck eines Frameworks aber Product
Owner product ownerin zumindest in
meiner Beobachtung beschäftigen sich zu
wenig mit Produktmanagement und auch das
ist etwas was ich am Anfang gar nicht
klar hatte sondern gedacht habe ich bin
eigentlich gut unterwegs und es ist eine
Motivation
euch eher auch mit dem Thema
Produktmanagement noch mal
auseinanderzusetzen und da genauer
hinzugucken sage ich aber gleich im
Anschluss auch noch mal ein bisschen was
dazu ein dritten Punkt der mir wichtig
ist und ich habe gerade eben auch mit
mit Markus der vorne sitzt der die
schlusskinot hält ein bisschen schon
gesprochen ähm dass er vielleicht auch
darauf Bezug nehmen wird ähm das Spiel
was wir hier spielen die Aufgabe die wir
haben als Product Owner ja das ist nicht
Schach und was meine ich mit Schach
schach ist wenn ich vor dem Schachbrett
sitze und guck mir an wo die Figuren
stehen dann zu überlegen dass ich alle
Informationen habe weil es ist ja
vollkommen klar wo welche Figur steht
und dann kann ich auf Basis der
vollständigen Information den nächsten
Zug machen sonder das Spiel was wir
spielen ähnelt viel eher als Product
Owner Poker weil wir gehen Wetten ein
unter Unsicherheit also wir haben eine
gewisse Hand oder wir haben gewisse
Informationslage und wissen ja so und so
stehen wir gerade da so stehen wir mit
unserer Entwicklung so ist der Mark
gerade mit unseren Wettbewerbern wie
auch immer und wir wissen aber nicht wie
die anderen auch ihre Züge machen wir
können uns vielleicht
Wahrscheinlichkeiten ausrechnen wie gut
wir da stehen und welche Wette wir
gewinnen können aber es ist eher etwas
wo wir ich glaube es Annie Duke
irgendwie dieses thinking in bets Buch
dass wir in Wetten denken und nicht in
klaren Abfolgen unter vollständiger
Information und ich habe ganz viel
geplant am Anfang ne selbst als
producter ich habe mir überlegt jetzt
machen wir das und dann machen wir
Roadmap und dann kommt die Roadmap
verfällt dann häufig auch eher in
Richtung eines releasepes oder eines
klaren Planes und ich glaube dass das
nicht hilfreich ist sondern wir müssen
uns klar sein dass das alles unter
Unsicherheit passiert und dass es eher
wie ein Pokerspiel anzusehen ist was wir
da tun und mit der Haltung herangehen
als dass wir Schachspieler
sind ein Punkt den ich euch auch noch
mitgeben würde oder versuche
mitzugeben mein oder eins meiner größten
Probleme mit dem Scrum Framework ist
dass dort über produktvision geredet
wird als etwas was da sein muss und
worum sich eine product ownerin ein
Product Owner kümmert und dann gibt es
in der weiß ich nicht zwei Drittel Seite
Beschreibung der Verantwortlichkeit
Product Owner wird sehr viel über
product backlock management geredet ne
was da drunter zu verstehen ist welche
Aufgaben habe nimmt ungefähr auch die
Hälfte glaube ich ein von dieser zwei
Drittel
Seite
und alles was dazwischen passiert was
vielleicht Produktmanagement ist in
unserem Verständnis wie komme ich denn
von der Vision zu einem gescheiten
backlock was steht da drin in welcher
Priorität steht da irgendwas drin wird
nichts gesagt und wenn ihr in einer
Situation seid dass ihr vielleicht sogar
in eurer Organisation es geschafft habt
andere davon zu überzeugen wir brauchen
eine
produktvision und ich ich dann in
manchen Trainings gehört habe ja wenn du
eine Vision hast dann kannst du auch
dein backlock daran orientieren und
priorisieren dann glaube ich stimmt das
nicht das ist viel zu abstrakt was da
als Vision ist ihr müsst die Lücke
zwischen der produktvision und dem
backlock mit geeigneten Tools Methoden
wie auch immer füllen und was eigentlich
ist passiert ist dass ihr immer weiter
ein Funnel kleiner machen werdet ja also
wenn ihr jetzt sagt das ist meine Vision
und dann fangt der euch mit
Produktstrategien zu beschäftigen dann
werden die Option was wir gerade machen
könnten vielleicht immer kleiner und
wenn wir dann vielleicht noch outcome
basierte Roadmaps haben die noch eher in
konkretere Pläne gehen und dann meinfing
für den nächsten Sprint für die nächste
Iteration das ist das Ziel was wir
erreichen wollen und kommt dann die
Geschichte so erzählt auf die
backlockebene wäre meine These ist
priorisieren des backlocks keine Aufgabe
mehr da bleiben nur sechs Sachen
übrig in fast allen Trainings die ich
gebe ist das Hauptthema priorisieren des
Product backlocks in fast allen weil
nämlich der Rest fehlt so und die
Motivation ist dass ihr versucht durch
die Methoden die euch helfen und da
werden der ein oder die andere auch von
den anderen Speakern euch wesentlich
konkretere Tipps geben guckt wie ihr
diese Lücke tatsächlich schließen könnt
um diese Geschichte zu erzählen um nicht
zu sagen ja gut jetzt habe ich immer
noch
7000 Alternativen was ich alles machen
kann und wann ich was machen kann und
ich bin immer noch keinen Schritt weiter
und versteht mich nicht falsch das ist
auch gut dass das Scrum Framework dazu
nichts Konkretes erzählt ja es ist ein
Framework aber es gibt so die Haltung
und manchmal auch bei den
Coaches und Sam mastern ja wir brauchen
ja nur eine Vision oder ein backlock das
ist das was ich eigentlich so ein
bisschen stressen möchte oder wo ich
euch noch mal darauf hinweisen
möchte was habe ich noch jetzt haben wir
in scam so Werte ne also glaub fünf
Stück wenn ich das noch richtig im Kopf
habe ne immer noch Stefan Nick g sei
Dank ne weil die werden ja auch manchmal
gerne vergessen oder nicht so behandelt
in meiner Welt ne ist alles subjektiv
was ich hier erzähle oder meine eigenen
Erfahrung ich glaube das Fokus für die
Product Owner der wichtigste Wert ist
der da drin steht ne da kann man sich
lange drüber streiten können wir auch
beim Kaffee oder beim Bier oder was auch
immer aber ich sehe ganz viele product
ownerinen und Product Owner die sehr
viel Arbeit da reinstecken
meintwegen die backlock Items die Sie
ins backlock packen zu bessern
schöner zu gestalten mehr zu diskutieren
wie auch immer aber dann wenn sie in
eine Iteration starten oder wenn sie in
sprintplan und wie auch immer auf einmal
wieder ein wildes samelsorium von ganz
vielen unterschiedlichen Themen haben
und ich glaube wenn wir es irgendwie
schaffen und ich glaube auch der Felix
Ring Krieg redet heute oder morgen oder
sowas eher aus der kann manw ich glaube
wenn wir es schaffen die Zahl der Dinge
die wir gleichzeitig tun zu minimieren
und maximal vielleicht im oder
optimalerweise nur eine Sache zu machen
nur ein Ziel zu erreichen dass es der
größte Hebel ist den wir als Product
Owner haben um den Wert zu maximieren
ihr könnt bei ganz vielen Dingen überall
viel besser werden aber der Effekt den
ihr erreicht wenn ihr nicht auf einmal
an dem Button arbeitet und dann noch an
dem Menü und dann noch irgendwas im
Backend was irgendwie in dre Monaten
kommt s ihr schafft euer Team euch
selber und alle Beteiligte auf ein Thema
zu fokussieren dass ihr damit den
größten Hebel habt in Hinblick auf
wertmaximierung relativ einfach
ausprobieren ne also in Trainings sehe
ich manchmal ne da werden so Sachen wie
was ist das Name Game glaube ich von
Henrik Nieberg manchmal gemacht und
solche Sachen dann wird das auch relativ
offensichtlich dass er darüber
eigentlich den größte die größte
Möglichkeit habt Mehrwert zu schaffen
und euch auf irgendwas zu fokussieren
und damit auch euer
Team
gut und wenn ich schon so 8 9 10 Punkte
mitgebracht habe muss ich natürlich auch
den Punkt mitbringen wo Tim und ich vor
Jahren irgendwie sehr intensiver
unterwegs
waren ich glaube im scramgide heißt es
immer noch damit der Product Owner
erfolgreich sein kann müssen die
Entscheidung des Product owners von der
gesamten Organisation akzeptiert werden
ja ich glaube ich die die Aussage die da
ist ne also Stefan Nick das ist immer
gut wenn da vorne einer ist der den
scrumgide besser kennt als ich und dann
nickt sehr gut ähm aber das als gefühlt
in meiner Realität sehr wahrscheinlich
in eurer auch völlig utopisch ne die
gesamte Organisation muss alle
Entscheidungen des productonas
akzeptieren das wäre schön wenn es so
ist vielleicht auch gar nicht ne also es
kann ja sein dass jemand auch vielleicht
nicht die Fähigkeiten und Skills hat
diese Verantwortung wahrzunehmen das
Produkt richtig zu entwickeln aber das
ist eigentlich das wie Scrum auf die
Produktentwicklung und auf die
Verantwortlichkeit des producters guckt
und ich glaube da gibt's natürlich nicht
nur schwarz und weiß sondern gibt's
immer auch irgendwas dazwischen und das
wird in den Unterneh in die ich
reingucken kann nie explizit gemacht
also wie weit geht denn mein
Verantwortungsbereich denn eigentlich so
als product ownerin oder als Product
Owner und ich glaube ihr nimmt euch so
viel Zeit
Stress unnötige Diskussion wie auch
immer weg und schiebt die vom Tisch wenn
ihr darüber redet und wenn ihr das ganze
explizit macht und das muss ja auch
nicht ein Stein gemeißelt sein es kann
ja sein dass es sie über Zeit auch
verändert weil ihr mehr
Verantwortlichkeit bekommen hat und ich
habe gesagt Tim und ich haben da lange
drüber diskutiert und manchmal sieht man
das in auch so einer product
unerschulung kann ich euch hinterher
auch mitgeben wir haben damals so ein
Tool entwickelt wo man das selber mit
sich mit seinem Team irgendwie machen
kann nennt sich product ownership
Evolution
Model gibt's aber auch ein Youtube Video
zu ne da brauche ich jetzt heute nicht
so lange drüber zu sprechen und euch zu
erklären wie das ganze funktioniert mir
geht's eher darum macht es explizit weil
jeder der kommt wird eine andere
Vorstellung davon haben ja der wird
sagen ja das darfst noch entscheiden das
darfst aber nicht entscheiden oder hier
möchte ich mitreden oder nicht mitreden
ähm ihr müsst das versuchen allen
Beteiligten ein gemeinsames Bild zu
entwickeln und dann gibt's was
ähm was mich eigentlich die letzten 12
Jahre begleitet und was mir am
allerschwersten ganz persönlich fällt
ähm ich habe so ein bisschen beigebracht
bekommen oder immer da vielleicht auch
eher das Gefühl gehabt ich muss andere
Leute überzeugen und sie ihnen erzählen
was wir denn jetzt zu tun weil ich ohne
ja das Produkt ja ich gehe voran und sag
hier guck mal das die Entscheidung hier
machen wir das ja oder im Zweifel ich
glaub der Roman Pichler erzählt das
häufig in den Trainings zumindestens da
wo ich vorbei dabei war ja die können
auch gerne selber diskutieren als
developmentteam was zu tun ist aber wenn
du als Product Owner das Gefühl hast das
ist jetzt nicht gut investierte Zeit
wenn wir noch eine halbe Stunde darüber
reden dann nimmt der Product Owner die
product ownerin die Entscheidung Stopp
jetzt der Button ist rot und nicht grün
in der Hoffnung dass im nächsten Sprint
den einfach auf Grün verändern können
oder so aber wenn es nicht wertstiftende
Diskussionen gibt ne ist immer besser
wenn das Team natürlich sich selber mit
einbringt vielleicht selber das Problem
löst ne ihr als product own es nicht
vorgibt aber in den Fällen wo das nicht
passiert oder nicht effizient und
effektiv ist habe ich die gesonderte
Mütze auf und sag jetzt treff ich die
Entscheidung jetzt machen wir erstmal
links rum ja so
und dafür müsst ihr den anderen aber
zuhören ihr dürft nicht die jenigen sein
die nur vorne wegen und sagen ja wir
gehen machen jetzt das dann machen wir
das ich habe ja schon eine Roadmap mit
dem habe ich das vereinbart und die
ganze Zeit erzählen denn ihr müsst
zuhören was die anderen sagen wir sind
komplexen Welt ihr könnt das gar nicht
alleine alles entscheiden das wäre für
mich Argument Nummer 1 und Argument
Nummer Z was ich habe ist dass das
natürlich auch auf der Beziehungsebene
was ganz anderes macht also das
Hauptproblem was ich häufig zwischen
product und ein Stakeholdern sehe ist
dass der Stakeholder irgendwas möchte
erzählen will und der Product Owner
kommt und sagt wir haben aber das und
das schon entschieden und erzählt nur
seine Geschichte ich glaube wenn ihr in
einen Modus kommen könntet oder ab und
zu mal dran denkt einfach mal nicht zu
sagen und einfach nur zuzuhören was er
erzählt werdet
ihr eine Reaktion bekommen dass das
Zuhören Schritt für Schritt für Schritt
auch zu einer Veränderung auf der
Beziehungsebene führt und vielleicht
auch zu einer gewissen Form von Empathie
irgendwann weil wenn ihr nur erzählt ich
will was anderes und der will das dann
werdet ihr nie auf einer Beziehungsebene
zusammen arbeiten und ich glaube dass so
Kommunikation und äh Beziehungsarbeit
mit eine der Hauptaufgaben ist da geht's
gar nicht um Prozesse und Tools in der
Product Owner Rolle ihr müsst alle
mitnehmen zusammenbringen auch lateral
zu in vielen Fällen dass er noch nicht
mal bestimmen könnt dass das nach links
und rechts geht und ich glaube dort eher
fragend unterwegs zu sein als Aussagen
treffend ja also ja warum willst das
denn gibt's noch irgendwas was du willst
dann fängt er an weiter zu erzählen oder
sie weiter zu erzählen und noch
irgendwas ihr müsst damit ja nicht
einverstanden sein ne also was er sagt
aber es zu verstehen glaube ich hilft
total weil ihr dann auf der
Beziehungsebene weiterkommt und erst
wenn eine gewisse Form von empathiee
sich entwickelt hat also man das Gefühl
hat dass man irgendwie miteinander
verbunden ist dann glaube ich kann man
auch anfangen seine eigenen Bedürfnisse
zu adressieren und dann werden sie auch
gehört und wir hören viel zu wenig zu
als POS aus meiner Sicht wir reden viel
zu viel ne also auch ich habe viel zu
viel geredet und versucht andere zu
überzeugen und das ist
auch nicht so einfach ist einfach mal
auszuhalten und
zuzuhören was ich vielen product
ownerinnen und Product Owner noch
mitgebe und wo ich gerne auch im
Nachgang kontrovers mit wenn es
interessiert drüber diskutiere ist ich
habe versucht meine Stakeholder oder die
Gruppe der Stakeholder als ein zweites
scrumteam zu betrachten ich glaube dass
eine Eins zu Eins Arbeit Diskussion mit
einzelnen Stakeholdern schwierig ist
weil im Zweifel haben die noch
verschiedene Ziele der eine will das
Unternehmensziel Erreichen der nächste
das der nächste das und ich bin dann
immer nur wie so eine Art Proxy mit dem
einen wird das abgeklärt ich nehme das
zurück dann versuche ich den zweiten das
zu verkaufen weil die drei sich nicht
einigen können oder es keine Align oder
abgestimmte Ziele auf der anderen Ebene
ist bin ich derjenige der versucht da in
irgendeiner Art und Weise zu
vermitteln und ihr müsst versuchen die
Stakeholder
zumindestens in meiner Sicht
zusammenzubringen ja also mit denen
gemeinsam zu reden und ich glaube dass
es helfen kann wenn ihr das macht wenn
ihr eher mit dem Gedanken rangeht weil
das ist auch ein scrumteam ich habe die
Entwickler die Developer als scrumteam
und die liefern das und auf der anderen
Seite habe ich aber meine Stakeholder
und mit den gucke ich wie wir
bestmögliche Produktentscheidung treffen
schrästrich Business Entscheidung
treffen und ich habe tatsächlich auch
schon mit product Ownern und mit Teams
das so gelebt
ähm dass sie tatsächlich mit denam
gemacht
haben jetzt kann man sagen was gucken
die sich in so einem Review an
vielleicht die Qualität der Entscheidung
die wir hier gemeinsam treffen oder die
Art wie wir gemeinsam Entscheidung
treffen warum soll ich nicht eine Art
von entscheidungsreview irgendwie führen
ist dann nur ein anderer Punkt den ich
da betrachte aber vielleicht treffen wir
uns auch regelmäßig und diskutieren
irgendwie in der Art von
refinement wie wollen wir denn mit
welchen Entscheidungen wieder auch immer
vorangehen es hat nämlich noch einen
interessanten Nebeneffekt dass die
Stakeholder viel mehr verstehen wie denn
dieses agile Framework was ihr anwendet
wie das ganze funktioniert weil sie es
nämlich selber mitspielen müssen und ich
glaube dass auch da ein großer
Hindernisgrund ist dass es wenig
Akzeptanz auf Stakeholder Seite gibt wo
ihr wie unterwegs seid und wie ihr das
mit dem Team macht weil die selber gar
nicht in dem Spiel irgendwie mit drin
sind ihr müsst nur aufpassen und
deswegen auch dieses Bild eigentlich
habt ihr das Trikot von beiden an ne
also das ist die Schwierigkeit darin und
ihr müsst euch klar sein wann spiele ich
mit dem Einen oder mit dem anderen Team
oder spiele ich die ganze Zeit mit
beiden Teams und ich würde als weiteren
Tipp auch mein Scrum Master wenn ihr
denn einen habt ne habe ich hier schon
gehört dass hier viele ohne Scrum Master
oder AG Coaches leider unterwegs sind
den zu motivieren euch auch da zu helfen
und euch da auch zu unterstützen weil
das ist dann Arbeit mit der Organisation
oder mit anderen Beteiligten was in
meiner Welt auch squam Master Aufgabe
wäre und dann kommen wir zu einem
vorletzten
Punkt und der ist schon so ein bisschen
auch in der Moderation von dem
Programmbeirat angesprochen worden was
ich ganz spät verstanden habe ist dass
es da draußen eine Produktmanagement
Produkt Bubble Community gibt und es
gibt eine Agi Bubble und Agi Community
und eigentlich beschäftigen sich mit den
gleichen Herausforderungen und die haben
teilweise auch ähnliche Lösung die
benutzen vielleicht andere wordings und
ne also manche Sachen passieren
schneller in der einen Community und
langsamer in der anderen Community aber
die haben viel zu wenig Schnittpunkte
und ihr seid Product Owner und
eigentlich habe ich am Anfang gesagt
seid ihr viel eher in der
Produktmanagement welelt unterwegs oder
solltet es zumindestens aus meiner Sicht
sein und ich finde ihr müsst gucken dass
ihr euch nicht auf eine Seite stellt
also ich habe hier ein hartes Ploier
dafür nicht zu sagen ja ich bin ja in
der ED Community total gut unterwegs und
da gehe ich auf irgendwie
Veranstaltungen ihr werdet
auf internationalen Scrum gatherings
greif mal so groch relativ wenig Produkt
Themen Product Owner Themen oder Speaker
mit Erfahrung über Produktmanagement
treffen ja wenn ihr Glück habt taucht
Stefan auf oder Jeff Patton oder wer
auch immer ne weil die in dem Umfeld
noch unterwegs sind und noch Expertise
haben aber dann wird's irgendwann auch
schon relativ dünn ne und ich würde auch
nicht vorschlagen zu sagen ja gut dann
bewege ich mich nur noch in der
Produktmanagement oder product Bubble
weil ich glaube dann fehlen euch auch
bestimmte Dinge weil natürlich schlaue
Ideen auch in der agilen oder scam Welt
oder Community gibt und ihr müsst gucken
wie ihr da nicht so ein schwarz-weiß
habt und die beiden Communities sich zum
Teil auch gar nicht wirklich sehen und
aneinander vorbeigucken und manchmal
auch dieses unerträgliche Bashing der
anderen Community irgendwie stattfindet
und zu sagen ja die haben alle keine
Ahnung ne also hatten wir gestern in der
Diskussion beim speakers Dinner keine
Ahnung Marti Kagen halt in seinem
inspire Buch über Reviews und plannings
und Iteration und was auch immer alles
spricht aber sagt das sind alles Idioten
aber die Begriffe aus dem Scram
Framework halt einfach benutzt weil das
halt erwartet ne und das führt uns
glaube ich nicht weiter sondern mein
playdoier ist eher zu sagen wir müssen
da mehr zusammenkommen weil ich glaube
dass aus eins und eins dann eher drei
wird anstatt irgendwie sich voneinander
abzugrenzen und der letzte Punkt den ich
habe und der kam ja eben auch schon mal
durch ähm das eins sicher ist und wenn
eins sicher ist was ich so gelernt habe
ist das hört nicht auf sich mit diesen
Themen zu beschäftigen und zu lernen und
ihr müsst euch klar sein wenn ihr diese
verantwortlich als Product Owner
übernehmt dann wird so viel im Laufe der
Zeit passieren also auch einfach
methodisch von Ideen die da draußen sind
dass ihr bereit sein müsst immer weiter
auch zu lernen und euch mit diesen
Themen zu beschäftigen ihr müsst gucken
dass ihr da so versucht irgendwie zu
gucken ja aber jetzt habe ich das
gelernt und dann schlage ich die Brücke
vielleicht auch wieder zu dem Kontext
Thema am Anfang dann wird sich euer
Kontext verändern euer Produkt
vielleicht die Firma das was ihr macht
in der Branche und dann werden
vielleicht ganz andere Dinge total
relevant und ich glaube dass product
Ownern klar sein muss dass es nicht so
ist dass wenn sie in den äh in so ein
Training gehen oder mein Scrum Guide
gucken dass sie verstanden haben wie das
Spiel funktioniert sondern das eine
kontinuierliche sehr wahrscheinlich
nicht endende lernreise irgendwie sein
wird weil immer wieder neue Themen
aufkommen werden und ihr feststellen
werdet da gibt's noch so viel zu
entdecken und aus meiner Sicht macht das
gerade auch diese Herausforderung total
spannend und äh
erstrebenswert ich weiß aber das
Menschen gibt die das nicht mögen oder
auch nicht so gerne haben deswegen
wollte ich das noch mal
anbringen nachdem wir Stefan schon die
Kärtchen hochhält will ich das zumindest
noch einmal kurz zusammenfassen weil ich
gelernt habe wenn man alles mal auf
einer Folie hat dass das manchmal auch
hilfreich sein kann das ist g meine ganz
persönliche Sicht ne also Product Owner
sollten aus meiner Sicht bewusst sein in
welchem Kontext Sie unterwegs sind und
sich bewusst machen dass jeder Kontext
anders ist und sehr wahrscheinlich auch
jeder Product Owner und sollten sich mit
Produktmanagement beschäftigen Fähigkeit
und Fertigkeiten im Produktmanagement
aufbauen und diese Veranstaltung ist ja
wahrscheinlich auch ein guter erster
Schritt viele Dinge kennenzulernen und
nutzt die in den in den nächsten zwei
Tagen ihr spielt Poker und kein
Schach ja also ihr geht mit Wetten und
mit Unsicherheiten um ihr müsst
versuchen das was nicht beschrieben ist
im Scrum Guide zwischen Vision und
backlock mit sinnvollen Dingen zu füllen
damit ihr eine konsistente Geschichte
eurer weiteren Produktentwicklung
erzählen könnt
m versucht den maximalen Fokus auf so
wenig Themen wie möglich herzustellen
für alle Beteiligten euch immer daran zu
orientieren je weniger wir machen Zeit
gleich desto besser ist es im Zuge von
ich bin derjenige der wertmaximierung
für mein Produkt betreiben sollte
m vielleicht ist es schlau drüber
nachzudenken mehr zu fragen und weniger
zu antworten und selber weniger zu reden
ähm guckt mal auf die Stakeholder aber
mit denen nicht eher als Team vielleicht
sogar als samteam in ein gewissen Logik
unterwegs sein könnt in ein gewissen
Regelmäßigkeit mit Rhythmus ähm und auch
nicht im eins zu eins
ähm versucht euch in beiden Welten zu
bewegen und
äh wisst dass sehr wahrscheinlich das
nur
ein ganz kleiner Auszug ist von den
Dingen die ich noch alles hätte erzählen
können ähm und ihr in allen Bereichen
auch noch hättet Weiterlernen können und
dass das Lernen sehr wahrscheinlich auch
nie
ausbleibt
gut wer ein bisschen mehr erfahren will
wir machen paar Trainings das muss ich
nur hinten dran werfen ne also könnt ihr
mich aber auch ansprechen ich versuche
gerade auch so durch ein Training von
der Vision bis zum backlock dazwischen
auch in einem zweitage Training das ein
oder andere product ownerin und Product
Owner
mitzugeben ich gebe die Slides ab ne
braucht er jetzt nicht fotografieren ne
also kriegt auch hier genauso wie beim
Nils 20%
Rabatt und wenn es dann Fragen gibt ich
gucke mal gerade so in Richtung vom
Stefan und
wenn ihr noch Anmerkungen habt zu dem
einen oder anderen Punkt
dann können wir das gerne jetzt noch
machen ist fast Punktlandung ne und auf
die produktwecker muss ich trotzdem noch
kurz hinweisen der Dominik der eben hier
im Programmbeirat war der Macht am 23.4
kostenfreies Live Event über Skalierung
von product ownership wenn er da Lust
habt guckt gerne mal bei uns rein ähm
wir versuchen da so ein bisschen was
anzubieten Impulse zu geben und wenn die
ein oder der andere mal vorbeikommt dann
freuen wir uns danke
euch
تصفح المزيد من مقاطع الفيديو ذات الصلة
Heil über Bürgergeld: Nur ein Bruchteil sind Arbeitsverweigerer | Markus Lanz vom 16. Juli 2024
Die Würde des Menschen in drei Minuten
Die richtige Verkaufsstrategie: So verkaufst du mehr Produkte // Mike Dierssen
Hans Thiersch im Interview 5.5.2014 (Frage 3/10)
Krypto: Glaub mir, die TOP Altcoins werden MILLIONÄRE erschaffen!
Kant: Aufklärung einfach erklärt! (Abiturwissen)
5.0 / 5 (0 votes)