Die Produktwerker

Jennifer Rolle im Gespräch mit Tim Der individuelle organisatorische Kontext, in dem wir als Product Owner agieren können, ist mit entscheidend für unsere eigene Wirksamkeit. Grund genug einmal explizit auf die Rolle von HR in agilen Transformationen zu schauen. Dafür ist Jennifer Rolle von den hr pioneers bei Tim zu Gast in unserem Podcast. Jennifer begleitet Unternehmen bei ihren agilen Transformationsprozessen. Zu Beginn ihres Gesprächs berichtet Jennifer, wann und warum HR in der Regel in den Veränderungsprozess mit involviert wird. Ausgehend von dem Wissenstand über neu entstehende Rollen und Verantwortlichkeiten reflektieren die beiden, welche Probleme es beispielsweise bei der Ausgestaltung dieser neuen Rollen und der Etablierung in Fachbereichen gibt - vor allem bei einem nicht klar kommunizierten Verständnis der Unterschiede zwischen Job & Rolle oder Product Owner & Product Manager. In der spannenden Diskussion kommen Tim und Jennifer auch an den Themen Führungsrolle als Product Owner, Gehaltsdiskussion und interne Bewerbungsprozesse auf eine PO Rolle vorbei. Spannend sind die Einblicke, wie der HR Bereich unterstützen kann, in die neue Verantwortlichkeit hineinzuwachsen. Die Episode schließt wie üblich mit ganz praktischen Tipps für Dich als Product Owner ab. Referenzen aus dieser Folge: Agile HR Manager Training (Certified) -> https://hr-pioneers.com/leistungen/trainings/certified-agile-hr-manager/ Interessante, zum Thema passende Folgen: Welche Aufgaben gehören zur Product Owner Rolle? Ownership verpflichtet Product Owner als Agile Leader Kontakt zu Jennifer Jennifer freut sich, wenn Du bei Fragen mit ihr Kontakt aufnimmst. Am einfachsten schreibst Du sie über ihr LinkedIn-Profil an. Sie freut sich auch über ein Email, alle Kontaktdaten findest Du auf ihrer Profilseite bei den hr pioneers. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

Dominique & Oliver im Gespräch Für Organisationen entsteht durch die agile Produktentwicklung eine besondere Herausforderung. Wissen muss innerhalb eines Teams aber auch darüber hinaus ausgetauscht und weitergegeben werden. Eine mittlerweile bewährte Möglichkeit des teamübergreifenden Austauschs bieten beispielsweise Communities of Practice. In diesen tauschen sich Menschen zu einem bestimmten Themengebiet aus und lernen voneinander. Dominique und Oliver sprechen daher in dieser Folge über Product Owner Communities, den Communities of Practice für Product Owner. In der Praxis begegnen uns Product Owner Communities in ganz unterschiedlicher Form. Von Buchclubs hin zu Lerngruppen und Orten für kollegiale Fallberatung besprechen die beiden verschiedene Erscheinungsformen der PO Communities, klären aber auch, wie man als EInzelkämper oder Einzelkämpferin von einer externen Community profitieren kann. Folgende Referenzen haben Oliver und Dominique in dieser Folge erwähnt: Cultivating Communities of Practice von Wenger, McDermott und Snyder (https://www.amazon.de/Cultivating-Communities-Practice-Managing-Knowledge/dp/1578513308) Der interne UX-Stammtisch - Entwicklung einer Community of Practice für UX-Professionals im Unternehmen (https://dl.gi.de/handle/20.500.12116/5472) Agiles Produktmanagement mit Scrum - Roman Pichler (https://www.romanpichler.com/romans-books/agile-product-management-with-scrum/) Rund um die Vernetzung und die Weiterentwicklung von Product Ownern empfehlen wir euch noch folgende Folgen: Als Product Owner erfolgreich zusammenarbeiten (https://produktwerker.de/als-product-owner-erfolgreich-zusammenarbeiten/) Das Product Owner Team (/https://produktwerker.de/product-owner-team/) Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern (https://produktwerker.de/sei-dein-eigenes-produkt/) Welche Erfahrungen hast du beim Aufbau von Product Owner Communities gemacht? Was hat gut und was vielleicht auch gar nicht funktioniert? Wenn du Tipps, Tricks und Erfahrungen für uns alle hast, freuen wir uns über dein Feedback. Auch der Austausch hier ist eine Art der Community und des gemeinsamen Lernens. Daher freuen wir uns besodners über einen Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker). Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

Tim Herbig im Gespräch mit Oliver Wir haben in diesem Podcast schon öfter über die Bedeutung der Produktstrategie für Product Owner und agile Produktmanager gesprochen. Will ich eine Produktstrategie entwickeln, dann greifen viele Product Owner auf die bekannten Templates und Cavases zurück. Tim Herbig, Product Coach und Author aus Erfurt, teilt im Gespräch mit Oliver seine Gedanken, wie das Erarbeiten der Produktstrategie auch ohne diese Tools gelingen kann. Die beiden starten die Diskussion mit einer Definition von Produktstrategie. Hier referenziert Tim auf das Buch von Roger Martin. Spannend ist die kritische Haltung von Tim, dass die komplette Strategie meist nicht in Workshops durch das Ausfüllen eines der gängigen Canvases entsteht. Für Bestandteile der Strategie, wie beispielsweise die Produktvision oder eine Wettbewerbsanalyse macht ein Workshopformat hingegen wieder viel Sinn. Tim erläutert darüber hinaus, wie ich OKRs und Produktstrategie sinnvoll miteinander verbinden kann. Seine These: Ohne eine nützliche Produktstrategie kann ich keine sinnvolle OKRs definieren. Abschließend reflektieren die beiden, wen ich an dem Strategie-Erstellungsprozess beteiligen und welche Bestandteile erarbeitet werde sollten, damit die Produktstrategie mich auch in meiner Arbeit unterstützt. Wie immer schließt die Folge mit konkreten Tipps und Tricks ab. Folgende Bücher und Blogbeiträge haben Tim und Oliver in dieser Folge erwähnt: Newsletter von Tim -> https://herbig.co/newsletter/ Roger Martin - Playing to Win -> https://www.amazon.de/Playing-Win-Strategy-Really-Works/dp/142218739X/ Ravi Metha - Product Strategy Stack -> https://www.reforge.com/blog/the-product-strategy-stack Tim Herbig - Product Strategy Ressources Hub https://herbig.co/product-strategy-hub/ Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

Dominique und Tim im Gespräch In Trainings, Workshops und Coachings bekommen wir immer wieder Fragen zur Abnahme von User Stories gestellt. Grund genug, zu diesem Thema mal eine Episode aufzunehmen. Dominique und Tim nähern sich dem Thema über die Frage, was denn überhaupt eine Abnahme ist und wo sie sonst stattfindet. Schnell wird klar, dass es sich dabei um Vertragssituationen handelt. Hierbei nimmt der Auftraggeber die Leistung des Auftragnehmer ab. Das Allein zeigt schon, dass die Frage im agilen Kontext eines Scrum Teams vielleicht falsch gestellt ist. Es besteht kein Vertragsverhältnis zwischen Product Owner und Developern, daher ist im engeren Sinne auch nichts abzunehmen. User Stories und andere Product Backlog Elemente enthalten dagegen sogenannte Akzeptanzkriterien, die wir auch in einer anderen Folge schon mal ausführlich betrachtet haben. Es geht also eher um die Frage, wann eine erstellte Lösung im Hinblick auf das zu lösende Problem als akzeptabel gelten kann. Die beiden diskutieren also, wie man die Akzeptanz einer User Story organisieren kann und welche Rolle dabei die Definition of Done spielt. Dabei geht es natürlich auch um die Frage, wann hierfür der beste Zeitpunkt innerhalb des Sprints ist. Und was passiert, wenn eine User Story nicht "abnahmefähig" ist? Wie üblich gibt es gegen Ende der Folge noch besondere Tipps, wie man mit der Frage zur Abnahme von User Stories umgehen kann. Die folgenden anderen Episoden unseres Podcasts passen zu diesem Thema: Akzeptanzkriterien richtig einsetzen Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? Die Definition of Done aus Sicht von Product Ownern Habt ihr die Diskussionen auch, von wem und wann die User Stories abgenommen werden sollen? Wie regelt ihr das? Wenn du Tipps für uns alle hast, würden wir uns über deinen Input freuen? Wir sind wirklich sehr neugierig zu erfahren, welches Vorgehen in deinem Kontext erfolgreich ist. Und wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

Roman Pichler im Gespräch mit Dominique In dieser Folge unterhält sich Dominique mit Roman Pichler über das Thema Produktstrategie. Roman hat gerade erst eine neue Auflage seines Buchs Strategize veröffentlicht und die beiden nehmen dies zum Anlass, um über dieses wichtige Thema zu sprechen. Roman sieht dabei die Produktstrategie als einen Plan bzw. den Weg wie man eine Produktvision erreichen möchte. Die beiden sprechen auch über die Probleme beim Entwickeln von Strategien. Oft beobachtet Roman beispielsweise, dass in einer Organisation gar nicht richtig klar ist, was das Produkt ist. Daneben sieht er auch eine fehlende Bevollmächtigung der Produktmanager bzw. Scrum Product Ownern. Aus der Produktstrategie werden dann Teilziele abgeleitet und eine zielorientierte Roadmap entwickelt. Mit Hilfe der zielorientierten Roadmap können Entwicklungsteams angeleitet und Stakeholder miteinander abgestimmt werden. Von Feature Roadmaps rät Roman dabei aber explizit ab, da es ihm weniger um die Auslieferung von Features geht, sondern mehr um das Erreichen von Zielen. Ein besondere Idee hat Roman noch für die Überführung der Strategie ins Product Backlog. Das aktuelle Product Goal wird als alleiniges Kriterium für die Elemente im Product Backlog genommen und nur Elemente, die auf dieses Ziel einzahlen sollten im Backlog aufgenommen werden. Damit wird das Product Backlog recht schlank aber sehr auf das Produktziel fokussiert. Roman war bereits einmal bei uns zu Gast und hat darüber gesprochen, welche Herausforderungen und Praktiken bestehen, um als Product Owner zu führen (https://produktwerker.de/how-to-lead-in-product-management/). Wenn euch das Thema Produktstrategie interessiert, empfehlen wir euch noch folgende Folgen: The Product Field (https://produktwerker.de/product-field/) Eine Produktstrategie entwickeln (https://produktwerker.de/produktstrategie-entwickeln/) Wardley Mapping - Produktstrategie ist wie Schach (https://produktwerker.de/wardley-mapping/)

Oliver und Tim im Gespräch Als PO verantworten wir in der Regel nicht ein einziges Produkt während unseres langjährigen Product Owner Lebens. Produkte kommen und gehen, wir entwickeln neue Ideen oder begleiten ehemalige Cash-Cows bis ans Ende ihres Produktlebenszykluses. Und es kann vorkommen, dass wir das „Problem Produkt“ erben, an dem niemand in unserer Organisation gerne arbeiten möchte. In dieser Folge sprechen Oliver und Tim über genau diese Situation. Wir können dann als Product Owner nicht auf der grünen Wiese agieren, sondern spielen nun eher im "Brown Field". Häufig bringt die Übernahme solch eines Produktes eine Reihe von Problemen mit sich: Es ist nur noch schwer erweiterbar oder wartbar, es existieren sehr viele Abhängigkeiten zu anderen Produkten oder Mitarbeitenden. Darüber hinaus lässt auch die Verfügbarkeit/Stabilität zu wünschen übrig. Oliver und Tim reflektieren in dieser Folge, an welchen Symptomen wir erkennen können, dass wir an solch einem Problem Produkt arbeiten. Und sie gehen in ihrer Diskussion einen Schritt weiter, indem sie möglichen Ursachen auf den Grund gehen. Die Folge schließt mit unterschiedlichen Lösungsansätzen ab. Was kann ich al sProduct Owner ganz konkret tun, wenn ich mich in der oben beschriebenen Situation befinde? Hierzu geben Oliver und Tim wie gewohnt eine Reihe von praktischen Tipps und Beispiele aus der eigenen Product Owner Praxis.

Michael Mahlberg im Gespräch mit Tim Wir sprechen in unserem Podcast über Product Owner und meinen damit implizit Scrum Product Owner. Doch was ist eigentlich mit Kanban und Product Ownern? Kennt Kanban POs? Über diese und viele weitere Fragen spricht Tim in dieser Folge mit Michael Mahlberg, Geschäftsführer von The Consulting Guild GmbH. Als Berater und Begleiter in großen Veränderungsvorhaben und ausgewiesener Kanban-Experte teilt Michael zu Beginn dieser Episode seine Sicht auf die Unterschiede zwischen Scrum und Kanban. Kanban ist Change und startet bei dem, was schon da ist. Die beiden stellen fest, dass die Definition von Product Owner sehr schwammig ist. Diese Unschärfe bezieht sich nicht nur auf die dreiviertel Seite an Beschreibung im Scrum Guide sondern auch in der Interpretation vieler Organisationen. Es gilt, die Frage zu beantworten: Welche Art von Product Owner wollen wir in dem jeweiligen Kontext einsetzen. Michael führt anschließend aus, was Kanban generell zu Rollen sagt. Und ergänzt seine persönlichen Beobachtungen aus der eigenen Beraterpraxis. Wie immer schließen wir mit Tipps und Tricks für dich als PO ab. Weitere Quellen Aufzählungs-Text- Michael Mahlberg: Why are there no Product Owners in Kanban Kanban University: The Official Guide to the Kanban Method Buchempfehlung: Essential Kanban Condensed David Anderson: Kanban - Successful evolutionary change for your technology business Falls du Kontakt mit Michael aufnehmen möchtest, kannst du ihn gerne über Webseite seiner Firma (http://consulting-guild.de/) oder gerne auch direkt via Mail unter mm@consulting-guild.de kontaktieren. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

Oliver und Tim im Gespräch Manchmal erfordert das Umfeld einer Produktentwicklung mit einem externen Entwicklungspartner eine Umsetzung als "Agiler Festpreis", also einer bestimmten Vertragsform. Was das heißt, wie man es erfolgreich angehen kann und welche Erfahrungen wir damit schon gemacht haben, besprechen Oliver und Tim in dieser Folge. Kaum eine agile Produktorganisation wird sich vermutlich darum reißen, in einem Festpreis-Konstrukt ein Produkt zu entwickeln, aber die Rahmenbedingungen können wir uns in der Realität nicht immer "backen". So gibt es natürlich immer noch viele Produktvorhaben, die in Form eines Projektes gestartet werden und bei dem ein externer Dienstleister zum Einsatz kommt. Bei der Beauftragung von extern Dienstleistungsunternehmen fordern zunehmend mehr Einkaufsabteilungen großes Organisationen oder Konzerne dabei die Beauftragung als "Festpreis", d.h. nicht mehr in Form eines Dienstleistungsvertrags ("Time & Material"). Wie passt das aber zu einer agilen Vorgehensweise? Auch wenn ein agiler Festpreis nach unserer Beobachtung in letzter Zeit zwar zunehmend seltener als Vertragsform vorkommt, als noch vor einigen Jahren, ist es spannend sich dieses Konstrukt noch mal zusammen anzusehen. Vermutlich ist die Forderung nach einem agilen Festpreis auch eher einem nicht agilen Umfeld geschuldet. D.h. die Budgetierungs- und Einkaufsprozesse des Unternehmens sind noch nicht auf die Vorgehensweise einer agilen Produktentwicklung eingestellt. Somit ist ein "Agiler Festpreis" u.E. letztlich nur ein Hilfskonstrukt, um eine agile Produktentwicklung im Kontext eines nicht agilen Organisationsumfeldes starten zu können. Tim berichtet von seinen Erfahrungen eines großen agilen Festpreis-Projektes, das er in einem Konzernumfeld zusammen mit einem externen Entwicklungsdienstleister eingeführt und umgesetzt hat. Tipps was, was er heute anders machen würde und was damals geholfen hat, die Entwicklung letztlich positiv umzusetzen. Tim verweist im Gespräch rund um das Thema Team "Estimation Game" auf die Folge Agiles Schätzen: Magic Estimation. Eine weitere gute Episode unseres Podcast zu dem Themenkomplex ist sicherlich auch "Zusammenarbeit mit einem externen Team vom Dienstleister". Aber auch andere Folgen haben sich schon mit den Dienstleister-Kontext beschäftigt. Mögliche Quellen, um tiefer in das Thema einzusteigen: Stefan Roock, Fritz-Ulli Pieper: Agile Verträge - Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche Boris Gloger, Andreas Opelt et al: Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge Hast du selber schon Erfahrungen mit der Vertragsform "Agiler Festpreis" gemacht? Wenn ja, welche Tipps hast du für uns alle? Wir sind wirklich sehr neugierig zu erfahren, welches Vorgehen in deinem Kontext erfolgreich ist/war. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Christian Klein im Gespräch mit Tim "Seine Inneren Antreiber zu kennen, ist der erste Schritt, um negativen Wirkungen in Stresssituationen entgegenwirken zu können." sagt unsere heutiger Gast Christian Klein, Systemischer Coach und Scrum Master sowie Geschäftsführer von paragraph eins. Tim beleuchtet mit Christian in dieser Episode das Phänomen der sogenannten "Inneren Antreiber", die sich aus dem Kontext der Transaktionsanalyse ergeben haben. "Beeil' Dich!", "Sei perfekt!", "Mach' es allen recht!", "Streng dich an!" und "Sei stark!" sind diese Inneren Antreiber laut Transaktionsanalyse. Daneben gibt es aber z.B. von Kaluza noch die beiden Beobachtungen "Sei vorsichtig!" und "Ich kann nicht!". Nach einer Erklärung der Herkunft und der Ausprägung der einzelnen Treiber - sowie einer Abgrenzung zu den sogenannten Glaubenssätzen - erläutert Christian auch anhand persönlicher Beispiele, wie diese grundsätzlich positiven Verhaltensmuster unter Stress auch umschlagen können und uns im Fortkommen behindern mögen. Um seine eigenen inneren Antreiber zu erkennen, kann der "Antreiber Test" helfen. Ihr findet ihn neben weiteren Erklärungen zu den Inneren Antreibern in einer gut strukturierten Darstellung auch der folgenden Seite von paragraph eins: hier. In der Folge nehmen Tim und Christian auch Bezug auf die folgenden älteren Episoden aus unserem Podcast: Nein sagen als Product Owner Verantwortung als Product Owner übernehmen Wenn ihr Kontakt zu Christian Klein aufnehmen möchtet und mehr mit ihm über dieses oder andere Themen sprechen möchtet, erreicht ihr ihn am Besten via E-Mail (christian.klein@paragraph1.de). Oder vernetzt euch auf LinkedIn mit ihm. Wie bewusst gehst du mit dem Thema "Innere Antreiber" oder Glaubenssätze um? Hast du dich schon mal dabei erwischt, dass sie dein Handeln in einer nicht hilfreichen Weise beeinflussen? Lass uns gerne daran teilhaben. Wir freuen uns, wenn ihr eure eigenen Erfahrungen oder Gedanken mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite teilt. Und falls euch der Podcast gefällt, freuen wir uns auch immer über eine Bewertung in der von euch favorisierten Podcast-App.

Tim und Oliver im Gespräch Zu Product Roadmaps gibt es in unseren Veranstaltungen immer sehr viele Fragen der Teilnehmenden. Obwohl wir bereits vor einiger Zeit eine immer noch aktuelle und interessante Folge zu Agile Product Roadmaps veröffentlicht haben, ist es wichtig, dass sich Tim und Oliver erneut zu dem Thema unterhalten. Denn bei ihnen geistert die Idee im Kopf herum, ob Product Owner nicht mit mehreren Product Roadmaps arbeiten sollten. Wichtig für die Einordnung dieses Gedanken ist eine Abgrenzung von Project und Product Roadmaps. Daher starten die beiden auch mit einer Unterscheidung von Produkt- und Projektdenken in die Episode. Nun sind die Informationsbedürfnisse der Stakeholder und Nutzer eines Produktes sehr heterogen. Denn alle brauchen verschiedene Daten auf sich stark unterscheidenden Detailierungsgraden, um selber zielgerichtet weiterarbeiten zu können. Tim und Oliver haben sich die gängigen Typen und Templates von Product Roadmaps angesehen und kritisch in Bezug auf die vorab analysierten Informationsbedürfnisse bewertet. Dabei stellen sie den Gedanken vor, ob es hilfreich ist, alle diese Infos in eine Roadmap zu packen oder ob mit mehreren Product Roadmaps arbeiten nicht zielführender ist. Natürlich hinterfragen sie die Idee kritisch. Ist der zu zusätzliche Aufwand gerechtfertigt, führen mehrere Product Roadmaps nicht zu Verwirrung? **Quellen aus der Folge ** ProdPad: https://www.prodpad.com/resources/roadmap-course/ Roman Pichler: GO Product Roadmap John Cutler on Twitter Die Produktwerker Box: Agile Product Roadmaps - das Ende der Gant-Charts Im LinkedIn-Post rund um das Thema dieser Folge gab es eine interessante Diskussion. Dabei hat die von uns geschätzte Kollegin Büşra Coşkuner (Product Management Coach) auf ihren Artikel Agile Roadmaps in Practice verwiesen, in dem sie ihren Ansatz mehrere Roadmap Sichten zu nutzen anschaulich darstellt (inkl. Visualisierung). Insofern können wir Euch diesen Artikel auch sehr empfehlen.