Sohrab Salimi im Gespräch mit Tim Die Transformation hin zum Product Operating Model ist das neue zentrale Thema von Marty Cagan seit diesem Sommer. Er hat es Ende Juli in London im Rahmen des TRANSFORMED Workshops vorgestellt. Unser heutiger Gesprächsgast Sohrab Salimi war vor Ort in London und tauscht sich dazu mit Tim Klein. Tim war seinerseits im letzten Jahr drei Tage im Coach-the-Coaches Retreat von und mit Marty Cagan und seinen Kollegen der svpg. Dort wurden die ersten Ansätze zum Product Operating Model auch schon angesprochen. Das ganze wird sich dann ab kommendem Frühjahr (vermutlich März 2024) im neuen Marty Cagan Buch "TRANSFORMED" nachlesen lassen. Von Sohrab, der ein sehr gern bei uns gesehener und somit wiederkehrender Gast bei uns im Podcast ist, können wir also quasi von echtem Insider-Wissen, zumindest aber mit Infos aus erster Hand, profitieren. Falls ihr Sohrab noch nicht kennt: Sohrab ist Gründer & CEO der Scrum Academy GmbH und seit fast zehn Jahren Certified Scrum Trainer® sowie Certified Agile Leadership Educator der Scrum Alliance, wo er bis Ende 2020 Mitglied des Board of Directors war. Wer noch mehr wissen möchte, hört sich am besten nochmal eine der weiteren Folgen mit ihm an: Sohrab Salimi in Folge 11: "Product Owner als Agile Leader" Sohrab Salimi in Folge 54: "Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen?" (mit Markus Andrezak) Weitere passende Quellen zum Product Operating Model Vortrag von Marty Cagan "Moving to the product operating model" im Webinar der Product-Led Alliance Weitere Vorab-Infos zum kommenden Buch von Marty Cagan "TRANSFORMED" "10 takeaways from a day spent with 50 European product leaders talking about ‘Transforming to the Product Model’" - von Product Coach Nick Jemetta, den Tim letztes Jahr beim Coach-the-Coaches Event von Marty Cagan kennengelernt hat Agile Insights Interview von Sohrab Salimi im Gespräch mit Marty Cagan: Product Leadership Teresa Torres bei Product at Heart: Even You Can Do Continuous Discovery. Bringing the Discovery Habits to Every Organization Wenn du mit Sohrab Salimi direkt in Kontakt treten möchtest, folge ihm am Besten auf LinkedIn oder kontaktiere ihn über sein LinkedIn-Profil. Eine weitere Empfehlung ist seinen regelmäßigen LinkedIn-Newsletter zu folgen. Hier teilt es immer wieder (i.d.R. wöchentlich) tolle Leadership Tipps und Gedanken. Hast du bereits vom Product Operating Model gehört? Oder seid ihr anderweitig auf der Transformationsreise zu einem produktzentrierten Organisationsmodell? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels 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 (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Tim & Dominique im Gespräch "Wie groß ist ein Epic?" oder "Ab wann ist eine User Story ein Epic?" - mindestens eine dieser beiden Fragen hören wir tatsächlich in quasi jedem Training, wenn es um die Arbeit mit User Stories oder Product Backlog Management geht. Offenbar besteht einiges an Unsicherheit rund um dieses Thema. Also haben sich Tim und Dominique das Thema "Epic" in dieser Episode mal vorgeknöpft. Sie klären nicht nur den Unterschied zu User Stories, sondern erzählen auch vom historischen Hintergrund des Begriffs. Die Frage lautet nämlich eigentlich viel eher: Warum gibt es keine Saga und Novel mehr? …zumindest in Jira haben es diese anderen Begriffe nicht geschafft. Tim folgt eher die These (von Mike Cohn): "eine Story ist eine Story, ist eine Story…" Demnach ist ein Epic nur ein Label oder Kunstbegriff für eine sehr große Story. Aber andersrum: Wenn wir Stories aufteilen bzw. splitten, entstehen daraus doch ja auch nur wieder Stories. Und selbst wenn diese nochmals geschnitten werden müssen, kommen doch wieder nur (kleinere) Stories dabei heraus. Warum wir "nach oben" denn dann so ein "mythischer" Begriff verwendet. Dominique nutzt hingegen gerne Epics und berichtet im Gespräch davon ausführlich. Auch ein Umgang mit Epics in Jira wird von ihm entsprechend erläutert. Besonders spannend dürfte sein, was er macht, wenn nicht alle User Stories eines Epics umgesetzt werden. Einig sind sich beide, dass ein Epic einen Wert liefern muss. Es sei der Hinweis erlaubt, dass es im Skalierungs-Framework SAFe explizit den Begriff Epic verwendet. Dort ist es eine "significant solution development initiative") und es werden Business Epics und Enabler Epics unterschieden. Eine weitergehende Erklärung gibt es hier. Tim und Dominique gehen in dieser Episode aber bewusst nicht näher auf den Epic-Begriff in SAFe ein, sondern konzentrieren sich auf die aus dem Extreme Programming (XP) stammende Herkunft des Begriffes. Lieber beleuchten die beiden nämlich, welche Vorteile, aber auch welche Herausforderungen in der Arbeit mir Epics gibt. Und es ist auch spannend zu diskutieren, was denn fehlen würde, wenn man ganz auf die Verwendung von Epics verzichten würde. Wie in unserem Format üblich schließt die Folge mit einigen Tipps & Tricks zu diesem Thema. Passende Podcast-Folgen zum Thema "Epic" Erfolgreich mit User Stories arbeiten User Story Splitting: Wie geht das "richtig"? Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? Feature Breakdown: schnell User Stories finden und grob schätzen Passende Themen in unserer Produktwerker Box: In der Produktwerker Box findest du zu den typischen Herausforderungen von Product Ownern von uns empfohlene Literatur, Artikel, Videos, Tools, Übungen etc. - ein Blick in folgende Themenbereiche lohnt sich im Kontext dieser Episode: Gute User Stories schreiben bzw. formulieren User Story Splitting: Anforderungen schneiden Wie sind deine Erfahrungen mit Epics? Hast du vielleicht eine andere Sicht oder arbeitest ganz anders mit Epics als wir berichtet haben? Vielleicht hast Du auch spezielle Tipps zum Umgang mit Epics in den diversen Tools: Jira, Azure DevOps (Team Foundation Server), Redmine, Trello, Asana, … Wir freuen uns, wenn du deine Erfahrungen aus der Praxis 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 (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Büşra Coşkuner im Gespräch mit Tim Eine Folge zum Impact Mapping war dringend überfällig! Über diese sehr starke Praktik im Produktmanagement spricht Tim Klein daher mit Büşra Coşkuner aus Zürich. Sie ist Product Management Coach und eine der absoluten Expertinnen zum Impact Mapping im deutschsprachigen Raum. Tim liebt ja bekanntlich eh quasi alle Mapping Techniken, weil sie durch die Visualisierung für so viel mehr Klarheit sorgen und Entscheidungen sowie Zusammenhänge explizit machen. Daher setzt er diese Methode auch schon viele Jahre selber ein. Büşra hat den Ansatz aber nochmal weiterentwickelt (Adjusted Impact Map) und ist sehr erfahren in ihrer Anwendung mit Produktteams. Die Praktik wurde insbesondere durch Gojko Adzic und sein (sehr dünnes) Buch "Impact Mapping: Making a big impact with software products and projects" bekannt. Viele weitere Erklärungen und Ressourcen findet ihr auf impactmapping.org. Impact Mapping klärt insbesondere die Frage, was wir versuchen bzw. umsetzen könnten, damit bestimmte Akteure ihr Verhalten in einer Art und Weise verändern, die eine (positive) Wirkung auf ein von uns verfolgtes Businessziel haben könnte. Gemeinsam sucht man also Zusammenhänge von "Why" - "Who" - "How" und "What" und visualisiert sie in einer Art Mindmap. Während die ursprüngliche Idee in dieser Reihenfolge erfolgt, schlägt Büşra Coşkuner vor, auch mal eine "Reverse Impact Map" auszuprobieren. Das Vorgehen erklärt sie in ihrem entsprechenden Blog-Artikel. Ein weiterer guter passender Artikel von ihr beleuchtet den Outcome-Fokus sowie den Zusammenhang zu OKR (Outcome-focus with Impact Mapping). Es lohnt sich übrigens sehr, ihrem Blog zu folgen! Wie im Gespräch von Büşra bereits angeboten, hat sie uns dankenswerter Weise auch ihre zwei Templates aus den Übungen ihres Trainings zur Verfügung gestellt: Template 1: Wenn man z.B. schon weiß, dass man etwa bestimmtes umsetzen möchte, wäre ein Aufbau für einen Mini-Pitch: In order to achieve [IMPACT], we want to help/make [ACTOR] to/with [OUTCOME] with/by [OUTPUT]. Our riskiest assumptions are [ASSUMPTION 1], [ASSUMPTION 2], [ASSUMPTION 3]. …und falls dieser Detail-Level erwünscht ist: We'll test our assumption with these experiments: [EXPERIMENT 1], [EXPERIMENT 2], …[EXPERIMENT n] Beispiel: In order to Grow Mobile Advertising, we want to make Super-fans with mobile devices to Come back more frequently with Push Updates about my favorite artists. Template 2: Wenn wir es noch nicht wissen, weil da ganz fette Annahmen dahinterstecken und wir mehr Daten brauchen: We believe that by [doing this output] --> Solution for [these people] --> Actor we'll achieve [This Outcome] --> Impact which we believe will lead to [this business result] --> Goal We'll know if we are right, when we achieve [quant. or qual. indicators or results]. We'll test our assumption with these experiments: [EXPERIMENT 1], [EXPERIMENT 2], … [EXPERIMENT n] Beispiel: We believe that by Pushing Updates about favorite artists for Super-fans with mobile devices we'll make them come back more frequently which we believe will lead to a growth in mobile advertising. Weitere Podcast-Folgen und Quellen, auf die Tim und Büşra im Laufe des Gesprächs hinweisen: Data-Fluent Product Manager (mit Büşra) Outcome Goals & Product Discovery (mit Tim Herbig) Evidence Based Management - eine empirische Suche nach Wert (mit Boris Steiner und Glenn Lamming) Post zum Opportunity Solution Trees von Teresa Torres Falls Du mit Büşra Kontakt aufnehmen oder ihr folgen möchtest, kannst Du Dich über ihr LinkedIn Profil mit ihr verbinden. Kanntest du Impact Mapping bereits vorher? Hast du eventuell selbst schon mal an einer solchen Mapping Session in Präsenz oder Remote teilgenommen? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels 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 (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Felix Rink im Gespräch mit Oliver Felix Rink ist wie versprochen zum zweiten Mal Gast im Produktwerker Podcast. Er spricht mit Oliver über Flow Metriken und in wie weit diese für Produktmenschen hilfreich sein können. Nachdem die beiden vor einigen Wochen über Sinn und Unsinn von Vorhersagbarkeit in der Produktentwicklungen philosophiert haben, wird es in dieser Episode also wesentlich konkreter. Zu Beginn der Folge klären Oliver und Felix, was Flow überhaupt ist und welche Voraussetzungen erfüllt sein müssen, damit man Flow messen kann. Der Kanban Trainer bricht die Flow Metriken im Anschluss auf die vier wichtigsten Basis Metriken herunter. Besonders wertvoll für den eigenen Kontext sind Felix Ideen und Anregungen, in welchen Scrum Events und bei welchen Praktiken und Artefakten diese Flow Metrics die Verantwortlichkeit eines Product Owner unterstützen können. Im Detail geht es um das Sprint Planning und das Sprint Review, sowie die Arbeit mit dem Product Backlog. Wie gewohnt schließt die Podcastepisode mit Tipps und Tricks für deine tägliche Arbeit als PO ab. Felix empfiehlt in der Episode, Actionable Agile für Flow Metriken oder die Monte Calo Simulation einzusetzen. Actionable Agile - https://www.actionableagile.com Es gibt wie erwähnt auch Excel Alternativen. Felix empfiehlt zwei Templates: https://github.com/SkeltonThatcher/bizmetrics-book#example-spreadsheets https://www.focusedobjective.com/pages/free-spreadsheets-and-tools

Tim und Dominique im Gespräch In der Produktentwicklung spielen Kreativitätstechniken eine essenzielle Rolle. Sie dienen dazu, innovative Ideen zu generieren und den Entwicklungsprozess auf neue Bahnen zu lenken. In dieser Folge sprechen Tim und Dominique darüber, wie Kreativitätstechniken innerhalb der agilen Propduktentwicklung beispielsweise mit Scrum eingesetzt werden können. Viele setzen auf das altbewährte Brainstorming, aber es zeigt sich oft, dass diese Methode ihre Grenzen hat. Eines der Hauptprobleme liegt in der sozialen Erwünschtheit, die oft die Qualität der generierten Ideen beeinträchtigt. Brainstorming, führt regelmäßig dazu, dass Teilnehmende sich selbst zensieren oder Ideen aus Angst vor Ablehnung zurückhalten. Hier setzt das Brainwriting an, eine Alternative, die in diesem Kontext häufig als hilfreicher erachtet wird. Durch die Möglichkeit, Ideen schriftlich zu notieren, wird der soziale Druck reduziert. Alle Teilnehmenden können ihre eigenen Gedanken ohne Hemmungen aufschreiben, was zu einer größeren Bandbreite kreativer Ansätze führt. Ein weiterer Ansatz, der sich bewährt hat, ist die 635-Methode. Hierbei formulieren sechs Teilnehmende jeweils drei Ideen in fünf Minuten. Diese Ideen werden dann an die nächsten sechs Teilnehmenden weitergereicht, die darauf aufbauend neue Ideen generieren. Durch diese iterative Vorgehensweise entstehen in kurzer Zeit eine Vielzahl an Ideen, ohne dass der Einfluss sozialer Faktoren die Kreativität einschränkt. Da an der Produktentwicklung aber viele Köpfe beteiligt sind, bieten sich auch Techniken an, bei denen Menschen jeweils die gleiche Denkperspektive einnehmen. Beispielsweise haben sich Edward de Bonos Denkhüte als nützliches Instrument erwiesen. Diese metaphorischen Hüte repräsentieren verschiedene Denkrichtungen, die in der Gruppe durchgespielt werden können. Jeder Hut steht für eine andere Sichtweise: neutral, emotional, optimistisch, kritisch, kreativ und strukturiert. Indem die Teilnehmenden bewusst in diese verschiedenen Rollen schlüpfen, entsteht eine facettenreiche Betrachtung des Problems, die zu vielseitigen Lösungsansätzen führen kann. Dominique empfiehlt hier aber, dass alle Teilnehmenden immer die gleiche Perspektive einnehmen und nicht einjeder einen anderen Hut zur gleichen Zeit trägt. Eine weitere Methode, die sich bewährt hat, ist die Walt-Disney-Methode. Sie nutzt die Rollen des Träumers, Realisten und Kritikers, um eine Idee aus unterschiedlichen Blickwinkeln zu betrachten. Dadurch werden sowohl visionäre Ansätze als auch praktische Umsetzbarkeit beleuchtet, was zu ausgewogeneren und umsetzungsfähigen Ideen führen kann. -- Empfehlungen -- Wir möchten euch an dieser Stelle das Buch "How to have creative ideas" (ISBN 978-0-09-191048-8) von Edward de Bono empfehlen. Als persönliche Empfehlung von Dominique hier noch ein hervoragender Vortrag von John Cleese zum Thema Kreativität im Management: https://www.youtube.com/watch?v=Pb5oIIPO62g&ab_channel=VideoArts Passend zum Thema Kreativität hier ein paar weitere Folgen: Als Product Owner im Sprint Review (https://produktwerker.de/als-product-owner-im-sprint-review/) Mit Storytelling andere von Deinen Produktideen überzeugen (https://produktwerker.de/storytelling-fuer-product-owner/) Visual Leadership für Product Owner (https://produktwerker.de/visual-leadership-product-owner/)

Rainer Gibbert im Gespräch mit Dominique Im Verlauf des Produktlebenszyklus müssen wir immer wieder Teile des Produkts verändern, aktualisieren oder an neue Erkenntnisse anpassen. Dies ist notwendig, um auch in Zukunft den Mehrwert unseres Produkts zu erhalten oder vielleicht sogar noch mehr Wert zu schaffen. Auf der anderen Seite haben Menschen, die unser Produkt schon länger nutzen, Zeit investiert, um die Bedienung zu erlernen. Jede Veränderung am Produkt bedeutet daher einen neuen Lernaufwand. Verständlicherweise lehnen Menschen Veränderungen ab, wenn sie den Nutzen nicht erkennen, nicht verstehen oder zumindest nicht nachvollziehen können. In dieser Folge spricht Dominique mit Rainer Gibbert, Leiter der Produktentwicklung bei der Star Finanz GmbH. Rainer hielt auf der Workings Products 2023 einen Vortrag zu diesem Thema. Immerhin ist er momentan für ein Produkt verantwortlich, das bereits seit 25 Jahren existiert. Viele Menschen haben sich an die Benutzung gewöhnt. Rainer diskutiert darüber, wie man damit umgehen kann, wenn Produktänderungen abgelehnt werden, und er erläutert, wie man diese Änderungen erfolgreich einführen kann. Er teilt mit, welche Vorbereitungen getroffen werden müssen, damit möglichst viele Menschen auf die neuen Funktionen, Änderungen und allgemeinen Anpassungen umsteigen. Wenn ihr nach dem Podcast noch einige Erkenntnisse nachlesen möchtet, empfehlen wir euch Rainers Artikel auf https://www.produktbezogen.de/produktaenderungen-warum-nutzer-sie-hassen/. Weitere Informationen zu Rainer findet ihr auch auf seinem LinkedIn-Profil unter: https://www.linkedin.com/in/rainergibbert/ Wenn ihr eigene Erfahrungen zu dem Thema gesammelt habt, lasst es uns gerne auf LinkedIn oder auf dem Blogbeitrag zu dieser Folge wissen. Wir freuen uns auf eure Erfahrungen.

Tim & Dominique im Gespräch Ist ein Proxy Product Owner sinnvoll? Wann und warum kann es diese Rolle geben? Wie kann man dieses Anti-Pattern überwinden oder im Zweifel auch damit umgehen? Zunächst mal erklären Tim und Dominique, was ein Proxy Product Owner ist bzw. was dies bedeutet. Auch die vielfältigen Gründe weshalb eine solche Rolle in bestimmten Situationen anzutreffen ist, werden erläutert. Besonders oft, sieht man eine solche Aufstellung, wenn das Scrum Team von einem Dienstleister gestellt wird, die Product Ownerin aber vom Auftraggeber gestellt wird. Letztlich ist der Einsatz einer Proxy Product Owner Rolle jedoch ein Anti-Pattern in Scrum. Insofern diskutieren die beiden, zu welchen Problemen es in der agilen Produktentwicklung durch solch eine Konstellation kommen kann. Spannend sind dann die Empfehlungen von Dominique und Tim, wie die Situation überwunden werden kann, also wie man diese "organisatorische Schuld" und somit die Proxy Product Owner Rolle wieder loswerden kann. Letztlich ist der Einsatz eines Proxy-PO auch recht nah dran an der Frage, ob und wie eine Arbeit mit zwei Product Ownern in einem Team möglich ist - dies war das Thema der letzten Folge. Im Zweifel also auch hier nochmal reinhören. Manchmal mag es aber auch Situationen geben, in denen - zumindest für einen bestimmten Zeitraum - mit dieser Rolle gelebt werden muss. Auch hierfür geben die beiden Empfehlungen ab, wie man dies möglichst gut meistern kann. Das Gespräch endet wie gewohnt mit Tipps & Tricks im Umgang mit der Herausforderung "Proxy Product Owner". Diese Podcast-Episoden passen zum Thema bzw. wurden erwähnt in dieser Folge erwähnt: Den Wert des Produktes maximieren Ein Scrum Team, zwei Product Owner. Geht das? Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Der Product Owner aus Sicht eines Dienstleisters Zusammenarbeit mit dem externen Team eines Dienstleisters Warst du auch schon mal als Proxy-PO im Einsatz oder hast eine solche Situation in einem Team erlebt? Was war der Grund, dass dort ein Product Owner Proxy eingesetzt wurde? Und welche Erfahrung habt ihr dabei gemacht? Vielleicht hast du noch weitere gute Tipps, wie der Einsatz einer solchen Rolle sinnvoll und wertstiftend gelingen kann. Wir freuen uns, wenn du deine Erfahrungen aus der Praxis 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 (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Dominique & Tim im Gespräch Es gibt Situationen, in denen eine Organisation sich entscheidet, zwei Product Owner einem Scrum Team zuzuordnen. Also zwei Menschen sollen sich diese Verantwortlichkeit teilen: gemeinsam das Product Backlog managen, gemeinsam mit dem Scrum Team die Scrum Events durchführen usw. - auch wenn der Scrum Guide das definitiv anders beschreibt: Ein Team sollte genau eine Product Ownerin ("The Product Owner is one person, not a committee.") und ein Product Backlog haben. Aber in der gelebten Realität sieht man das schon mal anders. Wie kommt es dazu und geht das denn überhaupt? Tim und Dominique nennen in dieser Podcast-Folge die Gründe, wegen derer sich Organisationen für mehr als eine Product Ownerin entscheiden. Anschließen diskutieren sie die Risiken und Schwächen einer solchen Situation - insbesondere vor dem Hintergrund ihrer eigenen Erfahrungen mit solchen Konstellationen. Tim berichtet z.B. von einem Versuch, vier PO für ein Team zu installieren. Der Versuch scheiterte allerdings ziemlich schnell. Natürlich zeigen die beiden auch Lösungsansätze auf, um die Situation zu überwinden und diese "organisatorische Schuld" abzubauen. Wie kann es gelingen, das ganze auf nur einen Product Owner zu reduzieren? Abschließend besprechen die beiden aber auch, was geschehen müsste oder gegeben sein muss, um (zur Not) auch mit mehr als einem PO zu arbeiten. Diese Podcast-Episoden passen zum Thema bzw. wurden erwähnt: Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Product Owner in Teilzeit Wie die Produktvision hilft, Product Ownern eine Richtung zu geben Warum scheint die Product Owner Rolle so schwer zu sein? (Gast: Markus Andrezak) Hast du das auch schon mal erlebt: zwei PO in einem Scrum Team? Was war der Grund, dass ihr euch so aufgestellt habt? Und welche Erfahrung habt ihr dabei gemacht? Vielleicht hast du noch gute Tipps, wie eine solche Konstellation gelingen kann. Wir freuen uns, wenn du deine Erfahrungen aus der Praxis 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 (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Laura Marwede & Dominique im Gespräch Wenn wir mit mehreren Teams an einem umfangreichen Projekt arbeiten, stellt sich oft auch im Design die Frage nach einer systematischen Vorgehensweise. Eine strukturierte Möglichkeit hierfür ist die Implementierung eines Designsystems. In dieser Folge wollen wir untersuchen, wann sich ein Designsystem in der Produktentwicklung lohnt und vor allem aus der Sicht der Product Owner beantworten. Dafür haben wir Laura Marwede eingeladen, Head of UX & Strategy bei TEAM23, die sich mit ihrem Team bereits seit geraumer Zeit mit diesem Thema beschäftigt. Sie ist somit die ideale Person, um Dominique in dieser Episode Rede und Antwort zu stehen. Der potenzielle Mehrwert von Designsystemen liegt darin, dass sie einen konsistenten und strukturierten Ansatz für die Gestaltung und Entwicklung von Produkten bieten. Sie bestehen aus einer Sammlung von Komponenten, Stilen, Richtlinien und Prinzipien, die als Grundlage für das gesamte Design einer Anwendung oder eines Produkts dienen. Designsysteme fördern die Konsistenz und Einheitlichkeit in der Produktentwicklung. Durch die Verwendung vordefinierter Komponenten und insbesondere Stile können wir als Product Owner sicherstellen, dass das Erscheinungsbild und die Benutzererfahrung unserer Produkte einheitlich sind. Zudem können Designsysteme den Entwicklungsprozess beschleunigen, da wir nicht jedes Mal von Grund auf neu beginnen müssen. Ein Großteil der Gestaltungsentscheidungen ist bereits getroffen, was Zeit und Ressourcen spart. Es gibt jedoch auch potenzielle Nachteile bei der Verwendung von Designsystemen. Insbesondere der anfängliche Aufwand für die Erstellung eines Designsystems sollte nicht unterschätzt werden. Es erfordert Zeit und Ressourcen, um die richtigen Komponenten und Stile zu definieren und das Designsystem aufzubauen. Wenn dann jedoch immer wieder Diskussionen über das Design entstehen, wird der eigentliche Vorteil eines Designsystems nicht realisiert. Wann sollten wir als Product Owner also Designsysteme nutzen? Die Antwort ist: Es kommt drauf an. Wenn ein Produktteam wächst und das Produkt selbst eine gewisse Größe erreicht hat, kann die Einführung eines Designsystems die Zusammenarbeit erleichtern und die Konsistenz sicherstellen. Es wird dann zu einem nützlichen Werkzeug für die Produktgestaltende.

Tim und Oliver im Gespräch Findet euer Sprint Review ohne Stakeholder statt? Oder kommen sie nur sporadisch? Tatsächlich ist das ein häufiges Problem in der Praxis und führt in der Arbeit mit Scrum zu ernsthaften Problemen. Tim und Oliver besprechen zunächst die Gründe, warum diese Situation eintreten kann. Danach diskutieren sie, welche Effekte das Fehlen von Stakeholdern im Sprint Review auf den Erfolg der agilen Produktentwicklung haben kann. Natürlich sind die Ideen und Vorschläge der beiden, wie man die Situation ändern kann, besonders spannend. Wie kann es gelingen, dass (wieder) mehr Stakeholder regelmäßig beim Sprint Review dabei sind und aktiv ihr wertschätzendes und konstruktives Feedback einbringen? Wie kann man es dem Umfeld bewusst machen, dass es wichtig ist, zu kommen und Feedback auf den aktuellen Stand der Entwicklung zu geben. Dabei ist auch wichtig, den Stakeholdern auch mit Respekt auf Augenhöhe zu begegnen und ihnen explizit zu sagen, wenn nichts Wesentliches für ihren Bereich in diesem Sprint dem Inkrement hinzugefügt wurde. Aber auch für den Fall, dass das alles nicht hilft und am Ende dann doch das Sprint Review ohne Stakeholder stattfinden muss, hauen die beiden noch einige, z.T. sehr kreative, Tipps raus. Diese Podcast-Episoden passen zum Thema "Sprint Review ohne Stakeholder" bzw. wurden erwähnt: Als Product Owner im Sprint Review Seine Stakeholder kennen und richtig analysieren Umgang mit schwierigen Stakeholdern Stakeholder Community Wer nimmt User Stories ab? Dein Freund der Scrum Master Warum scheint die Product Owner Rolle so schwer zu sein? (Gast: Markus Andrezak) Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Hast du auch das Problem, dass eure Stakeholder nicht zum Sprint Review kommen? Wie geht ihr damit um und welche guten Tipps habt ihr noch für uns und alle anderen Product Owner? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis 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 (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]