Die Produktwerker

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.

Heiko Stapf im Gespräch mit Oliver In dieser Folge ist Heiko Stapf bei uns zu Gast. Heiko ist für uns einer der Experten für agiles Produktmanagement im deutschsprachigen Raum und zeitgleich erfahrener Certified Scrum Trainer der Scrum Alliance. Aus seinen Product Owner Trainings hat er die spannendsten Fragen der Teilnehmer mitgebracht, die er gemeinsam mit Oliver diskutiert. Im ersten Teil der Episode dreht sich alles um Vorhersagbarkeit und Planung. Was sollte ich als Product Owner tun, wenn vor allem aus dem Management viel Verbindlichkeit und Commitment von mir erwartet wird? Welche Auswirkungen hat diese Erwartungshaltung auf Product Roadmaps. Eine weitere spannende Frage aus dem PO Training ist die Frage nach der Priorisierung, vor allem des Product Backlogs. Die Diskussion führt Heiko und Oliver dann zwangsläufig zur Zusammenarbeit mit Stakeholdern. Wie sollte ich priorisieren, falls meine Stakeholder konkurrierende Ziele haben? Insgesamt sehr spannende Themen mit Relevanz für jeden Produkt Owner. Und eine angeregte Diskussion zwischen den beiden, aus der du hoffentlich den einen oder anderen Impuls mitnehmen kannst. Im Gespräch verweisen die beiden auf folgende Quellen: John Cutler: Suitably Detailed Roadmap Items‌ Martin Eriksson: The Decision StackThe Decision Stack

Dominique und Tim im Gespräch Im Alltag müssen wir alle ständig mit anderen Menschen interagieren, sei es Small Talk, eine heiße Diskussion oder einfach nur das stille Zuhören eines Gegenübers. Dabei kommt es dauerhaft, auch wenn es nur unterbewusst ist, zum Einsatz unserer Social Skills. Als Product Owner*in ist man da nicht ausgeschlossen. Ob man mit einem Scrum Team arbeitet oder sich mit Stakeholdern austauscht, Social Skills können den Unterschied zwischen einem guten und einem schlechten PO machen. Darum unterhalten sich Tim und Dominique dieses mal über die verschiedenen Social Skills und sozialen Kompetenzen die vor allem für POs relevant sind. Dabei erkunden sie Unterschiede zwischen Hard und Soft Skills, und teilen ihre Gedanken über unterschiedliche Social Skills wie Empathie oder dem aktiven Zuhören. Dabei kommen sie aber auch zu Fragen wie "Ist Humor ein Social Skill?" oder "Kann man Social Skills einfach so lernen?". Selbst außerhalb der Rolle als PO ist es nicht schlecht sich seiner Social Skills bewusst zu sein, daher kann man viele Aspekte dieser Folge auch nutzen, um selbst mehr über die interaktion mit anderen Menschen nachzudenken. Quellen/Bücher: https://www.harvardbusiness.org/5-key-human-skills-to-thrive-in-the-future-digital-workplace/ Der KODE® KompetenzAtlas (https://www.kodekonzept.com/wissensressourcen/kode-kompetenzatlas/) Empathie. In: Dorsch: Lexikon der Psychologie. Hogrefe Verlag, Göttingen 2017, ISBN 978-3-456-85643-8 Geoff Watts: Product Mastery (https://www.inspectandadapt.com/product/product-mastery) Roman Pichler: Leadership im Produktmanagement (https://dpunkt.de/produkt/leadership-im-produktmanagement/) Relevante Podcast-Folgen: Wie kann ich mit mehr Präsenz als Product Owner auftreten? (mit Alexandra Klingor) https://produktwerker.de/mehr-prasenz-als-product-owner/ Herausforderungen zwischen Product Owner & Developer (mit Bernd Joussen) https://produktwerker.de/herausforderungen-productowner-developer/ ‌

Steffi Götten im Gespräch mit Dominique OKR als Methodik um Ziele zu setzen und zu verfolgen ist seit einigen Jahren auch bei uns in Deutschland in aller Munde. Daher, eigentlich schon lange überfällig, wollen wir uns auch mit dem Thema OKR beschäftigen und haben uns eine Expertin eingeladen, die langjährige Zuhörer*innen bereits kennen dürften. An der Seite von Dominique steht Stefanie Götten als Expertin und sie tauschen sich zum Thema mit einem klaren Fokus aus: Was bedeutet die Einführung von OKR für uns in unserer Verantwortung als Product Owner. Stefanie war bereits bei uns im Podcast zu Gast. In der Folge "Dein Freund der Scrum Master" (https://produktwerker.de/dein-freund-der-scrum-master/) war sie schon einmal bei uns zu Gast. Mehr zu Stefanie findet ihr unter https://www.linkedin.com/in/stefanie-g%C3%B6tten/. Welche Erfahrungen hast du rund um die Einführung und Nutzung von OKR gesammelt. Teilst du unsere Meinungen und Erfahrungen oder widersprichts du? Lass uns gerne daran teilhaben. Wir freuen uns, wenn du dein eigenes Verständnis mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite teilst. Und falls dir der Podcast gefällt, freuen wir uns auch immer über eine Bewertung in der von dir favorisierten Podcast-App.

Dominique im Gespräch mit Oliver Fragt man drei Product Ownerinnen, was sie als ihre Verantwortlichkeit ansehen, so erhält man vier sehr unterschiedliche Antworten. In vielen Fällen ist eine Ursache für die Vielfalt der Rolleninterpretationen, dass manche als Product Owner im Scrum Kontext arbeiten und andere wiederum als SAFe Product Owner. Es ist also an der Zeit, dass Oliver und Dominique über die Gemeinsamkeiten und Unterschiede sprechen. Denn aus ihrer Perspektive ist es dieses Thema eines der großen Missverständnisse - ein Scrum PO ist etwas komplett anderes als ein SAFe PO. Und nachdem einige Beiträge und Meinungen in den letzten Wochen in die Timeline der beiden gespült wurden, auch ein guter Zeitpunkt die eigene Sichtweise zu konkretisieren. Dominique und Oliver starten mit einer Reflexion eines Beitrags von Roman Pichler zu "Six Types of Product Owner", der in diesem Podcast schon einmal in der einen oder anderen Episode zitiert wurde. Fokus legen beide aber auf den Scrum PO und den SAFe Product Owner. Wo liegen die Gemeinsamkeiten, welche Unterschiede findet man. Nach einem Blick in den Scrum Guide und in die detaillierteren Erläuterungen in SAFe wird auf die eine oder andere Äusserung von Kollegen referenziert, u.a. Sohrab Salimi oder Heiko Stapf. Natürlich artikulieren Oliver und Dominique auch sehr klar ihren eigenen Standpunkt und klären, dass auch in diesem Podcast sehr häufig der Scrum Product Owner im Mittelpunkt der Diskussionen steht. Wie immer schließt diese Episode mit einigen konkreten Tipps & Trick ab.

Nam Hoang-Dong im Gespräch mit Tim Nam Hoang-Dong berichtet über seine Erfahrung als Product Leader einer Retained-Organisation im Gespräch mit Tim, d.h. wie sich die Steuerung eines großen externen Dienstleisters als Produktverantwortlicher anfühlt. Nam hat eine langjährige Erfahrung im Handel (MediaMarkt, ESPRIT, Thalia) und spricht in dieser Folge v.a. über die Zeit bei Esprit in die auch die agile Transformation des damaligen Dienstleisters fiel. Als Retained-Organisation wird dabei eine (meist) kleinere Einheit verstanden, die den beauftragten Dienstleister steuert. In der Praxis geschieht dies häufig nach Outsourcing-Prozessen. Hier im Beispiel vom Fashion-Händler ESPRIT wurde das ganze Online-Business über viele Jahre in dieser Form aufgebaut und betrieben. D.h. auch die (agile) Produktentwicklung des ESPRIT Onlineshops geschah auf diese Weise. Tim war damals auf der Seite des Dienstleisters im Einsatz und hat die Veränderung der Dienstleister-Beziehung daher aus anderem Blickwinkel beobachten können. Mit einigen Jahren Abstand kommt es somit zu einer interessanten Reflexion der Transformation. Aber auch die Frage, was Nam aus dieser Erfahrung an Learning in seine neue Rolle als IT-Verantwortlicher bei Thalia mitgenommen hat, spielen im Gespräch eine Rolle. In Summe ergibt sich also ein toller Erfahrungsbericht eines Product Leaders im Handelskontext aus dem sicherlich einige Impulse gezogen werden können. Folgendes Buch nennt Tim im Verlauf des Gesprächs: Robbin Schuurman/Willem Vermaak: 50 Arten, Nein zu sagen Im Zusammenhang mit dieser Podcast-Episode über die Arbeit als Retained-Organisation möchten wir euch auch nochmal diese älteren folgen im Kontext der Dienstleister-Zusammenarbeit als Herz legen: Zusammenarbeit mit einem externen Team vom Dienstleister Der Product Owner aus Sicht eines Dienstleisters Als Product Owner auf Seiten einer Agentur Wenn ihr mit Nam Hoang-Dong persönlich in Kontakt treten möchtet oder weitere Fragen an ihn habt, freut er sich über eure Anfrage bzw. Nachricht auf seinem LinkedIn-Profil. Welche Learnings habt ihr aus der Zusammenarbeit mit und Steuerung von Dienstleistern gezogen? Kennt ihr vielleicht auch solch ein Konstrukt einer Retained-Organisation? Lasst uns gerne an euren Erfahrungen, Tipps oder auch eurer Meinung teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Oliver im Gespräch mit Dominique Wer kennt sie nicht, die kleinen Life Hacks, die durch minimale Veränderungen das Leben ein klein wenig leichter machen sollen. Der Ansatz der Culture Hacks dient dazu die Kultur einer Organisation zu verändern, aber eben mit kleinen Schritten. Gleichzeitig beziehen sich Culture Hacks auf Veränderungen im informellen Bereich. Es geht eben nicht darum direkt eine neue Rolle, neue Meetings oder andere Formalismen einzuführen. Oliver und Dominique sprechen in dieser Folge über Culture Hacks, die nach ihrer Erfahrung gut auf die Kultur der Organisation einwirken können. Sie stellen aber auch heraus, dass Culture Hacks immer Experimente sind und kein Erfolgsversprechen mit sich bringen. Beispielsweise kann man versuchen die Kultur der Organisation mittels geteilter O-Töne der Menschen, die das Produkt benutzen, mehr Richtung Erlebnisorientierung zu bringen. Wenn Mitarbeitende durch viele Meetings keine Zeit haben sich zu einem allgemeinen PO-Austausch zu treffen, bietet sich vielleicht ein gemeinsames Mittagessen an. Oder man teilt seine persönlichen Gedanken über aktuelle Produktthemen häufiger per SMS, Instantmessaging oder Mail und versucht so Gespräche anzustoßen. Rund um das Thema Kultur haben wir noch ein paar weitere spannende Folgen für euch: Diversity in der Produktentwicklung (https://produktwerker.de/diversity-in-der-produktentwicklung/) Die Relevanz von UX den eigenen Stakeholdern vermitteln (https://produktwerker.de/die-relevanz-von-ux-vermitteln/) Auf Business oder Nutzer fokussieren als PO? (https://produktwerker.de/business-oder-nutzer/) Falls ihr noch weitere Tipps habt, wie man mit kleinen Maßnahmen die Kultur deiner Organisation verändern kann, lasst es uns gerne wissen. Wie sind eure Erfahrungen und welchen Herausforderungen musstest ihr euch dabei stellen? Wir freuen uns, wenn ihr eure eigenen Sichtweisen mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker) teilt.