Die Produktwerker

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.

Oliver & Tim im Gespräch Das Aufteilen (sog. Splitting) von User Stories erscheint oft als eine der schwierigsten agilen Praktiken für Product Owner. Letztlich ist es aber eine Frage der Übung. In dieser Episode besprechen Tim und Oliver "Übungen", um diesen "Muskel" zu trainieren. Es geht also zum Strategien, wie man gute Schnitte zum Aufteilen von User Stories finden kann. User Stories fühlen sich oft zu groß an, um sie in einem Sprint fertig zu stellen. Es ist aber unser Ziel, in regelmäßigen Abständen sinnvolles Feedback zu erhalten, um im komplexen Umfeld in möglichst kurzen Zyklen zu lernen, was unser Produkt wertvoll macht. Vielen Product Ownern und Teams fällt es jedoch schwer, (zu) große User Stories bzw. Features in gute, kleine Stories aufzuteilen. Wir suchen daher immer nach vertikalen Schnitten, so dass wir nach ihrer Umsetzung ein hilfreiches Feedback auf das neue Produktinkrement erhalten können. Wir besprechen u.a. die folgenden Fragen: Wann sind User Stories "zu groß"? Prinzipien und Kriterien beim Aufteilen von User Stories Strategien und Muster, um gute Schnitte zu finden Stolperfallen beim Schneiden von User Stories Grenzen beim Story Splitting: manchmal geht's halt nicht - was dann? Quellen zum Story Splitting Im Gespräch beziehen wir uns auf die folgenden Quellen: INVEST in Good Stories von Bill Wake 10 powerful strategies for breaking down Product Backlog Items in Scrum (with cheatsheet) von Christiaan Verwijs Twenty Ways to Split Stories von Bill Wake User Story Splitting Flowchart von Richard Lawrence (Deutsche Fassung übersetzt von Kai Simons) S.P.I.D.R. Approach von Mike Cohn Im Zusammenhang mit User Story Splitting sind auch weitere Folgen rund um das Product Backlog Management und vor allem in Bezug auf User Stories und andere Product Backlog Elemente empfehlenswert: Erfolgreich mit User Stories arbeiten Akzeptanzkriterien richtig einsetzen Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? Feature Breakdown: schnell User Stories finden und grob schätzen Wie können wir den Erfolg von User Stories messen? Wie läuft das Aufteilen von Anforderungen bzw. das Schneiden von zu großen User Stories bei Euch ab? 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.

Dominique & Oliver im Gespräch Jeder macht Fehler und jeder sammelt Erfahrungen. Wie oft denken wir uns dabei, hätten wir das doch früher gewusst. Als das einem von uns vor kurzem wieder mal passiert ist haben wir uns entschieden unsere bisherigen Erfahrungen zu reflektieren und zu sammeln, was wir gerne zu Beginn gewusst hätten. Daher sprechen Oliver und Dominique in dieser Folge über all die Erkenntnisse und Erfahrungen, die sie gerne vorher gewusst hätten. Sie sprechen über Themen wie dem Schnitt der eigenen Verantwortung, die Gesamtheit aller Aufgaben, den eigenen Wirkungskontext, Nutzen verschiedener Backlogs, den Umgang mit anderen Disziplinen und vielem mehr. Im Gespräch verweisen die beiden auf das Buch "Escaping the Build Trap: How Effective Product Management Creates Real Value" von Melissa Perri. In diesem geht es vor allem darum nicht immer nur neue Features zu bauen, sondern das Produkt als Ganzes weiterzuentwickeln und ggf. auch mal Features zu entfernen, wenn sie keinen Mehrwert liefern. Was die Rolle als Product Owner angeht referenziert Oliver auf das "POEM", ein Instrument zum besseren Verständnis der Product Ownership. Mehr dazu findet ihr hier: https://productownership.de/poem/ Und nun ist es auch an euch eure Erfahrungen zu teilen. Was hättet ihr gerne vorher schon gewusst?

Mick Hohmann im Gespräch mit Oliver Was sollte ich in meiner Verantwortung als Product Owner wirklich niemals tun? Was sind absolute NoGos? Oliver spricht in dieser Folge mit Mick Hohmann über seine persönlichen Erkenntnisse zu diesem Thema. Mick hat 5 NoGos mitgebracht, die er in der Diskussion ausführlich erläutert: Product Owner ist nicht Teil des Teams oder wird nicht so wahrgenommen Product Owner übernimmt Scrum Master Aufgaben Das Fehlen einer Produktvision Fehlendes Wissen über Wert & Kosten Nutzer als Stakeholder wird vergessen Und Mick hat dann als Bonus noch ein weiteres NoGo dabei, welches an dieser Stelle aber noch nicht erraten wird. ;) Solltest du den einen oder andere Punkt auch bei dir erkennen, dann kann sicher der Scrum Master weiterhelfen. Wir empfehlen daher gerne die Episode "Dein Freund der Scrum Master" mit Steffi Götten, weil wir dort einige Lösungsansätze zur Überwindung der NoGos besprochen haben.

Dominique und Oliver im Gespräch Keiner mag Bugs, aber es ist vollkommen normal, dass welche entstehen. Oliver und Dominique sprechen in der Folge darüber, wie wir als Product Owner mit Bugs umgehen können. Dazu müssen wir natürlich erst einmal kurz darüber sprechen, was Bugs eigentlich sind. Danach stürzen die beiden sich auf verschiedene Ansätze. Bugs können im Product Backlog eingeplant werden. Alternativ kann auch ein eigenes Bug-Backlog eingerichtet werden, an dem pro Sprint eine feste Zeit (Timebox) gearbeitet wird. Man könnte auch so arbeiten, dass ein Mitglied des Dev-Teams in einem Sprint nur Bugs abreitet. Diese verschiedenen Ansätze haben aber alle Vor- und Nachteile, weshalb unsere Diskussion in eine klare Richtung geht. Wir sind gespannt zu hören, was eure erprobten Praktiken sind, um Bugs angemessen zu behandeln. Schreibt es uns gerne in die Kommentare unter https://produktwerker.de/wie-product-owner-mit-bugs-umgehen-sollten/