Die Produktwerker

Jan an de Meulen im Gespräch mit Tim In dieser Folge unseres Podcasts berichtet Jan an de Meulen von seinen Erfahrung von der Führungskraft zurück in die Product Owner Rolle zu wechseln. Im Gespräch mit Tim teilt er sehr offen seine Gedanken und seine Motivation für diesen sicherlich noch ungewöhnlichen Schritt. Jan war im Führungskreis von Congstar für das Produkt- und Prozessmanagement verantwortlich. Im ersten Teil des Gesprächs sprechen die beiden über Jans Entwicklung hin in diese Führungsposition. Doch merkte nach mehreren Jahren, dass es ihm fehlte, selber aktiv und nah an der Produktentwicklung sein. So reifte in ihm die Entscheidung, wieder Product Owner werden zu wollen. Doch solch eine Entscheidung trifft man natürlich nicht von jetzt auf gleich. Jan reflektierte die Idee mit einigen Vertrauenspersonen und identifizierte die Dinge, die ihm Spass machen, wo seine größte Motivation und Leidenschaft liegt. Der Schritt von der Führungskraft zurück zum Product Owner wurde von seiner Organisation begleitet. Und so war relevant, wie das Umfeld, die die anderen Product Owner oder die Developer auf diese Veränderung reagierten. Im letzten Teil des Podcast erklärt Jan, was er neu lernen musste und was ihn in seiner alten/neuen Rolle überraschte. Dabei hat er sich einige Ziele für die Zukunft als Product Owner gesetzt. Und er versucht selber die Dinge vorzuleben, die er zuvor von seinen Product Owner erwartet hat. Ingesamt ein sehr spannender Einblick in eine sicherlich außergewöhnliche Entscheidung.

Oliver präsentiert seine persönlichen Highlights des Jahres 2021 In dieser Episode stellt Oliver die besten Product Talks 2021 vor. Natürlich handelt es sich um eine ganz subjektive Auswahl von Speakern & Themen. Wir glauben jedoch, dass die hier vorgestellten Videos eine perfekte Ergänzung zu der einen oder anderen Podcastfolge sind. Die Reihenfolge der hier gelisteten Talks soll jedoch nicht als Wertung oder Rangliste verstanden werden. John Cutler - "Linking Strategy to everyday work" (Juli 2021) - Video Teresa Torres & Hope Gurion - "Why there's no single right way to do discovery" (Februar 2021) - Video 1 / Video 2 Marty Cagan & Sohrab Salimi - "Product Leadership" (November 2021) - Video: Jeff Patton - "The mindset that kills product thinking" (Oktober 2021) - Video Wusstest Du schon, dass wir einen Mitschnitt unserer Live-Events kostenfrei auf YouTube zur Verfügung stellen? Auf dem Produktwerker-Kanal kannst Du Videos u.a. zu den Themen Produktstrategie, User Stories, Story Splitting, Stakeholdermanagement oder Story Mapping finden. Am besten direkt den Kanal abonnieren..

Daniel Hommel im Gespräch mit Oliver In dieser Episode unseres Product Owner Podcast ist erneut Daniel Hommel zu Gast. Daniel spricht mit Oliver über das Thema "Coaching Skills als Product Owner entwickeln". Nachdem die erste Folge der beiden schwerpunktmäßig das Coachen von Product Ownern diskutierte, reflektieren sie dieses mal, ob Coaching Skills und eine Coaching Haltung hilft, den Job besser erledigen zu können. Wir möchten vorausschicken, dass es sich bei Coaching nicht um die Basis Skills als Product Owner handelt. Es gibt definitiv andere Fähigkeiten, die ich zuerst lernen und verbessern sollte. Aber Coaching kann etwas sein, was meine Skill sinnvoll ergänzt. Denn Coaching dient dazu, mehr Klarheit zu erhalten und neue Perspektiven zu entdecken - eine Herausforderung vor der jede Product Owner häufig genug steht. Daniel und Oliver fokussieren sich auf drei Bereiche: Zuhören, auch über das gesprochene Wort hinaus - Spiegeln - offene Fragen stellen. Dabei behandeln sie auch diverse Fragentechniken, wie z.B. die Wunderfrage, Skalenfragen oder zirkuläre Fragen aus dem systemischen Coaching. Ein weiteres Thema ist Clean Language und NLP. Alles in allem bietet das Gespräch viele Impulse, um sich als Product Owner dem Thema Coaching zu nähren und sich dennoch von dem Verantwortungsbereich eines Scrum Master klar abzugrenzen. Alle in der Folge erwähnten Literaturempfehlungen findest du auf unser Webseite

Tim und Dominique im Gespräch "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product." - Scrum Guide 2020 Die Definition of Done (kurz DoD) ist ein wichtiges Commitment in der agilen Produktentwicklung nach Scrum. Letztlich ist es das, meist dokumentierte, gemeinsame Verständnis des Scrum-Teams darüber, wann etwas fertig ist. Für uns als Product Owner hat es eine wichtige Bedeutung, weil wir neben der Zusammenarbeit mit den Developers auch in der Kommunikation mit Stakeholdern immer wieder auf das Verständnis der Qualität zu sprechen kommen. Noch bedeutender wird die DoD, wenn wir nicht nur mit einem Team an einem Produkt arbeiten sondern mit anderen Teams zusammen wirken. Dann braucht es umso mehr eine Klärung des Mindeststandards. Tim und Dominique sprechen in dieser Folge über verschiedene Aspekte der Definition of Done. Sie klären zum Beispiel, wer die DoD alles entwickelt, wer sie kennen muss und wer dafür verantwortlich ist, sie einzuhalten. Auch sprechen die beiden darüber, was in eine DoD nach ihrer Erfahrung alles rein gehört und welche Fehler man mit der DoD alles machen kann. Insgesamt bleibt aber das offensichtliche Fazit, dass die DoD ein wirksames Instrument für eine erfolgreiche und fokussierte Produktentwicklung ist. Wir müssen es aber in der richtigen Art und Weis einsetzen, wobei gerade Scrum Master die richtigen Unterstützer sind. In der Folge verweist Tim übrigens kurz auf die Akzeptanzkriterien und einer dazugehörigen Folge (https://produktwerker.de/akzeptanzkriterien-richtig-einsetzen/). Während die Definition of Done für die Umsetzung aller Product Backlog Items einen Rahmen bietet, sind Akzeptanzkritieren auf einzelne Product Backlog Items anwendbar. Wir empfehlen euch daher bei Bedarf die andere Folge auch anzuhören. Welche Tipps habt ihr für den Einsatz der Definition of Done und welche Erfahrungen möchtet ihr mit anderen teilen? Oder sind euch schonmal total abgedrehte DoD untergekommen. Schreibt euer Feedback, Erfahrungen und Tipps gerne in die Kommentare auf unserer Website. Darüber freuen wir uns immer!

Im Gespräch mit Denny Meier Wie bereite ich mich als Product Owner eigentlich auf eine Bewerbung vor? Gemeinsam mit Denny Meier spricht Dominique in dieser Folge über verschiedene Themen rund um die Vorbereitung auf eine Bewerbung. Denny arbeitet als Headhunter und ist auf Product Owner spezialisiert. Also genau der richtige Gesprächspartner für diese Folge. Die beiden streifen dabei nicht nur das Thema Außendarstellung (z. B. das eigene LinkedIn-Profil), sondern sprechen auch darüber wie ein Lebenslauf gestaltet sein muss und wie wir uns auf ein Bewerbungsgespräch vorbereiten. Ein wenig sprechen die beiden auch über die allgemeine Karriereplanung und zum Beispiel darüber warum ein Branchenwechsel gar nicht so einfach ist. Wenn ihr Kontakt zu Denny sucht, findet ihr seine Kontaktdaten hier: https://www.linkedin.com/in/denny-meier-2a16b2181/ Die von Denny genannte Studie findet ihr hier: https://www.hrdive.com/news/eye-tracking-study-shows-recruiters-look-at-resumes-for-7-seconds/541582/ Aber natürlich interessieren uns auch ganz besonders eure eigenen Erfahrungen rund um das Thema Bewerbungen und wir würden uns daher sehr freuen, wenn ihr einen Kommentar hinterlasst. Gerne auf Twitter (https://twitter.com/produktwerker), LinkedIn (https://www.linkedin.com/company/produktwerker) oder unsere Website (https://www.produktwerker.de).

Oliver & Tim im Gespräch Eine Produktstrategie ist das Bindeglied zwischen Product Vision und dem Product Backlog. Eine validierte Produktstrategie ist notwendig, damit ich als Product Owner Fokus behalten kann. Ich sollte also eine Produktstrategie entwickeln und mit den relevanten Playern vereinbaren. Dies sind nur einige Gründe, warum sich Tim und Oliver in dieser Folge dem Thema Produktstrategie angenommen haben. Das Gespräch der beiden Produktwerker startet mit einer Annäherung an den Strategie-Begriff. Sie grenzen Unternehmensstrategie von Produktstrategie ab und reflektieren, welche Elemente Teil einer guten Produktstrategie sein sollten. Denn eine Roadmap oder ein übergeordneter Plan alleine ist noch lange keine Produktstrategie. Weitere Inhalte dieser Folge: Was macht ein "gute" Produktstrategie aus? Wie entwickle ich eine Strategie und welche Tools und Template können mich als Produkt Owner dabei unterstützen? Allerdings macht Oliver im Gespräch klar, dass es sich bei den besprochenen Inhalten in dieser Episode um einen aktuellen Wissenstand handelt. Es gibt auf dem Gebiet Produktstrategie noch viele weitere interessante und relevante Dinge zu entdecken. Alle erwähnten Quellen findest du auf unserer Webseite in der "Produktwerker Box" https://produktwerker.de/box/. Dort geben wir unsere Empfehlungen für Bücher, Artikel, Videos, Tools, Podcasts, etc. - jeweils zu ganz speziellen Herausforderungen für Product Owner. Gerade frisch in der Box haben wir auch alles zu dieser Episode zusammengestellt - sogar noch mehr als wir erwähnt haben. Neugierig? Dann guckt doch einfach mal in der "Produktwerker Box" in die Herausforderung "Wie entwickle ich eine effektive Produktstrategie?" rein. Du findest die "Box" auch im Menü auf unserer Website. Wir hoffen jedoch, dass wir dein Interesse für das Thema Produktstrategie wecken können!

Bernd Joussen im Gespräch mit Oliver In dieser Folge ist Bernd Joussen zu Gast. Bernd ist Agile Coach, Mediator und Trainer und hat seinen Schwerpunkt auf der Entwicklung von Teams. Ein zentraler Bestandteil seiner Arbeit legt er auf dem Thema Retrospektiven. Mit Oliver spricht er daher über die Herausforderungen zwischen Product Owner und Developer - aus Sicht eines Scrum Master. Oliver und Bernd ergründen, wo und warum Herausforderungen zwischen Product Owner und Developer entstehen. Liegt es an der oft fehlenden Produktvision oder an der schlechten Kommunikation - oder eventuell sogar an beiden Faktoren. Damit sich aus dem Scrum Team ein echtes Team entwickeln kann, sollte man die gegenseitigen Erwartungshaltungen klären und im Blick behalten. Bernd vertritt dabei den Standpunkt, dass man den Gegenüber einladen sollte, über die eigene Sicht nachzudenken. Diese und andere Tipps, wie ich mit den in dieser Episode diskutierten Herausforderungen umgehen kann, werden dir als Product Owner helfen, erfolgreicher in deiner Rolle agieren zu können. Freue dich auf ein spannendes und sehr erkenntnisreiches Gespräch! Wenn ihr mehr über Bernd Joussen erfahren möchtet, dann findet ihr mehr Informationen auf seiner Webpage unter https://der-teamdynamo.de. Oder ihr verbindet euch direkt mit Bernd via LinkedIn. Bernd bietet auf der Plattform jeden zweiten Dienstag um 08:00 Uhr ein LeanCoffee zum Thema Retrospektiven an.

Dominique und Tim im Gespräch Durch das Refinement wird das Product Backlog zu einem gut gepflegten Product Backlog und ist dadurch ein wichtiges Werkzeug für Product Owner. Tim und Dominique unterhalten sich in dieser Folge über das Refinement des Product Backlogs und welche Bedeutung es für uns als Product Owner hat. Zu Beginn klären wir erst einmal, was Refinement eigentlich ist und wie es in Scrum passt. Das Refinement wird zwar oft als Termin gesehen, ist aber eigentlich ein Prozess. Deshalb sprechen wir über den allgemeinen Ablauf des Refinements, wer alles mitwirkt und was wir als Product Owner vorbereiten sollten. Wir sind nämlich davon überzeugt, dass wir neben Vision und Product Goal auch eine aktuelle Roadmap dabei haben sollten. Dank dem Refinement haben wir dann nicht nur ein gepflegtes Product Backlog; wir erhalten auch neuen Input für die Priorisierung von Product Backlog Items und erlangen ein Verständnis über Umfang, Kosten, Risiken und anderer Aspekte der ganzen Backlog Items. Wir können daher dank des Refinements bessere Entscheidungen treffen. Und wie in jeder Folge wollen wir mit ein paar Tipps abschließen. Habt ihr beispielsweise mal daran gedacht das Refinement eines bestimmten Themas als Product Backlog Item einzuplanen, damit im nächsten Sprint an diesem Thema gearbeitet wird? In der Folge erwähnen wir übrigens kurz das Product Backlog Refinement Canvas, eine gut geeignete Vorlage, um sich eine strukturierte Übersicht zu machen. Ihr findet es unter https://www.kaizenko.com/the-product-backlog-refinement-canvas/ Wenn ihr noch mehr über das Product Backlog hören wollt, dann empfehlen wir euch die folgenden Folgen: Das Product Backlog (https://produktwerker.de/product-backlog/) Ist dein Product Backlog voll bzw. zu groß? (https://produktwerker.de/product-backlog-voll/) Product Backlog Einträge sind nicht nur User Stories! (https://produktwerker.de/product-backlog-eintraege/) Wenn euch dieser Podcast gefällt, freuen wir uns auch über eine positive Bewertung in eurer Podcast App oder als Feedback per Mail an podcast@produktwerker.de oder via Instagram oder Twitter (@produktwerker).

Dominik Kress im Gespräch mit Tim Tim spricht mit Dominik Kress über dessen Erfahrung auf seiner Lernreise vom Entwickler zum Product Owner. Dominik hat ist von Hause aus lange Jahre Software Engineer und liebt es auch heute noch zu Programmieren. Aber er konnte sich auch schon immer für die (Software)-Produkte begeistern, an denen er als Entwickler arbeitete. So war es irgendwann ein logischer Schritt, auch schon aus dem Team heraus (eher) technische User Stories zu erstellen und so das Produkt an einigen Ecken mit zu gestalten. Vor einer Weile ergab sich dann durch einen Teamwechsel die Möglichkeit, die Product Owner Rolle für ein technisches Produkt (eine Cloud Runtime) komplett zu übernehmen. Im Gespräch interessiert Tim daher die Frage, was Dominik bei dem Wechsel in die andere Rolle überrascht hat. Vermisst er das entwickeln? Und wie schafft es Dominik, nicht in das (technische) "WIE" des Teams einzugreifen? Letztlich geht es um die Frage, ob Product Owner mit einem Entwickler-Background mit dem ein oder anderen Thema anders umgehen. Gibt es einen größeren Fokus auf technische Exzellenz und werden technische Folgen eher vermieden? Und wie wird er von den Teammitgliedern oder auch Stakeholdern gesehen? Interessant ist auch die Frage, ob sich Dominik nach dem aktuellen sehr technischen Produkt auch als Product Owner für ein eher fach-nahes Produkt sehen würde. Am Ende gibt Dominik natürlich noch Tipps für andere Entwickler, die sich vielleicht mal in der Product Owner Rolle ausprobieren möchten. Freut euch auf einen spannenden und kurzweiligen Erfahrungsbericht! Wenn ihr mit Dominik Kress in Kontakt treten wollt, freut er sich über eure Nachricht per Mail: dominik.kress@mail.schwarz Im Zusammenhang mit einem Bereich der Diskussion in dieser Episode ist auch die Folge 73 rund um Technische Schulden empfehlenswert: Technische Schulden und wie wir als Product Owner damit umgehen Welche Erfahrungen hast du vielleicht selbst als Entwickler:in auf dem Weg zur Product Owner:in erlebt? Welche Tipps hast Du für andere? Oder überlegst du diesen Weg noch zu gehen und stellst dir noch Fragen, die nicht beantwortet wurden? Wir freuen uns, wenn du deine eigenen Erfahrungen, Tipps oder Fragen mit uns in einem Kommentar auf unserer Webseite oder auf unserer Produktwerker LinkedIn-Seite teilst. Wenn euch dieser Podcast gefällt, freuen wir uns auch über eine positive Bewertung in eurer Podcast App oder als Feedback per Mail an podcast@produktwerker.de oder via Instagram oder Twitter (@produktwerker).

Eike Gehler im Gespräch mit Tim LeSS zwingt den Product Owner, seinen Fokus auf die Priorisierung zu legen und die Klärung von Details zu delegieren! Noch klarer bringt es unser Gast Eike Gehler auf den Punkt: "Prioritization over clarification". Eike ist erfahrener Agile Coach und langjähriger Scrum Master - v.a. bringt er aber sehr viel Erfahrung in sehr großen und skalierten Kontexten mit ins Gespräch ein. Er mag keine Blaupausen und mag am Liebsten zusammen mit den Organisationen die er begleitet herausfinden, welcher Skalierungsansatz im jeweiligen Kontext der geeignete ist. Dabei bedient er sich aufgrund seiner Erfahrung gerne im "Baukasten" verschiedener Skalierungs-Frameworks und -Modelle. Dennoch hat er einen Favoriten: das Framework LeSS - kurz für "Large-Scale Scrum". Dennoch betont Eike Gehler, dass die entscheidende Frage der Produkt-Kontext sei, in dem das Skalierungsvorhaben stattfindet. Tim beleuchtet zusammen mit Eike zunächst dessen eigene Weg in die Agilität sowie seine aktuellen Wirkungskreise in oft großen Organisationen. Zusammen rätseln die beiden, warum das sogenannte "Spotify"-Modell (oder zumindest die dort genannten organisatorischen Formate) derzeit so viele Nachahmer hat. Warum muss jetzt plötzlich alles Squad, Tribe, Gilde usw. heißen? Warum legen Organisationen soviel Hoffnung in diese Organisationsmuster, obwohl dies von Henrik Kniberg und Anders Ivarsson, die damals bei Spotify die Transformation begleiteten, nie als Skalierungs-Framework gemeint war. Tim stellt die These auf, dass "Spotify" derzeit sogar SAFe den Rang abläuft. Tiefer geht es dann um das LeSS-Framework. Hier wird vieles reduziert: für bis zu sieben Feature-Teams ist dort nur EIN Product Owner und nur EIN Product Backlog (innerhalb einer Area) vorgesehen. Eike erklärt zunächst den Begriff des Feature-Teams und wie schwer es oft ist, für diese Idee in großen, bislang silo-artig organisierten Unternehmen Befürworter zu finden. Aber wenn es nur einen Product Owner in LeSS gibt - wie verhält es sich dann mit den Scrum Mastern? Wie viele Scrum Master sind z.B. in einer Area mit fünf Feature Teams sinnvoll? Im letzten Teil geht es nach dieser Herleitung dann ganz konkret um diese Product Owner Rolle in LeSS und welche Herausforderungen sie mit sich bringt. Eike Gehler gibt in diesem Zuge auch noch wertvolle Tipps für Menschen, die als Product Owner in LeSS arbeiten. Quellen zum sog. "Spotify-Model" und LeSS: Die damalige Beschreibung von Henrik Kniberg und Anders Ivarsson der Skalierung bei Spotify… die dann als das Spotify-Model (miss)verstanden wurde. Spotify Engineering Culture, dieses Video wird üblicherweise als Video über das "Spotify-Model" referenziert Henrik Kniberg: No, I didn’t invent the Spotify model Heutige Sicht von Henrik Kniberg auf Scrum@Scale im Vergleich zum "Spotify-Model" Die offizielle Beschreibung von LeSS mit allen Details, die ihr über das (De)Skalierungs-Framework LeSS wissen müsst Wenn ihr mit Eike Gehler in Kontakt treten wollt, freut er sich über eure Nachricht auf folgenden Kanälen: Mail: eike@aykey.de LinkedIn Web Telefon: 089 208044440 Im Zusammenhang mit dieser Episode ist auch die Folge 41 rund um Skalierung empfehlenswert: Product Owner im skalierten Umfeld mit Björn Schotte Welche Herausforderungen erlebt ihr selbst als Product Owner in LeSS oder Ansätzen die sich an das Spotify-Model anlehnen? Wir freuen uns, wenn du deine eigenen Erfahrungen mit uns in einem Kommentar auf unserer Webseite oder auf unserer Produktwerker LinkedIn-Seite teilst. Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.