Latest / einfach gelöst / #14: Roman Pichler – Im Produktmanagement die Kontrolle behalten
Transcript
- Stefan Roock (it-agile): Hallo und herzlich willkommen zum IT Agile Podcast Einfach gelöst. Und diesmal habe ich einen alten Freund, also Betonung auf Freund, nicht auf alt hier. Freue mich, dass Roman Pichler sich bereit erklärt hat, mir eine halbe bis dreiviertel Stunde zu quatschen. Hallo, Roman. Roman: Ja, Hallo Stefan, freut mich auch sehr, hier zu sein. Danke für die Einladung. Stefan Roock (it-agile): Ja, gerne. Für den unwahrscheinlichen Fall, dass sich irgendjemand noch nicht kennt, magst du dich kurz vorstellen? Roman: Ja, also was soll ich zu meiner Person sagen? Ich bin tatsächlich mittlerweile nicht mehr ganz jung. lebe seit etlichen Jahren in Großbritannien, komme ursprünglich aus Deutschland, bin in der Nähe von München aufgewachsen und ja, habe dann nach meinem Studium angefangen als Softwareentwickler, bin dann Stefan Roock (it-agile): Nein. Roman: zu Siemens gegangen, den zentralen Bereich, der damals Corporate Technology hieß und habe dann Prozessberatung gemacht und bin über diese Schiene zu den agilen Methoden gekommen. Und obwohl ich dann noch für eine Zeit lang im operativen Geschäft bei Siemens tätig war, habe ich mich dann selbstständig gemacht und über die Agilität, mit der Agilität dann das Thema Produktmanagement, Product Ownership entdeckt und ja bin in dem Bereich jetzt seit vielen Jahren. unterwegs. Stefan Roock (it-agile): Und wann bist du bei Siemens mit Agilität in Berührung gekommen? Roman: Ja, das war tatsächlich, glaube ich, so vor ungefähr 25 Jahren. Da war ich in einem Projekt involviert, wo wir versucht haben... im Bereich der Medizintechnik ein Produktneuentwicklungsprojekt zu unterstützen. Das war sehr ambitioniert. Es ging ⁓ ganz neue medizintechnische Software. Aber gleichzeitig sollte auch ein Stück weit Infrastruktur entwickelt werden. Damals ganz hippe Technologien wie Komponententechnologie eingesetzt. Man hat sogar überlegt, eigenes Containermodell zu entwickeln. ist so bisschen, als ob man heute seine eigene LLM schreiben würde. Vielen Ja und in dem Zusammenhang haben wir festgestellt, dass so die bewährten traditionellen Siemens Entwicklungsprozesse für so ein technologisch auch ambitioniertes neues Produkt nicht wirklich hilfreich waren und haben gesagt Mensch, wie wäre es denn, wenn wir da so dieses coole hippe neue agile Zeugs mal anwenden und haben versucht zumindest einige Praktiken aus Extreme Programming einzusetzen, was letzten Endes nicht so erfolgreich war. Aber ich habe viel dabei gelernt. Stefan Roock (it-agile): Warum war das nicht erfolgreich? Roman: Letzten Endes war die Produktentwicklung nicht von Erfolg gekrönt. Das Produkt ist dann auf Markt gekommen mit etlicher Verspätung. Es war auch ziemliches Politikum. Ich will es da nicht zu weit ausholen. Es hatte auch damit zu tun, dass sich dieser Medizintechnikbereich neu aufgestellt hat. Da gab es auch eine Akquise, eine große. Aber letzten Endes ist das Produkt dann mit etlicher Verspätung auf den Markt gekommen, aber war überhaupt nicht erfolgreich und konnte sich dann auch leider nicht durchsetzen. Das war das erste Mal, ich wirklich mit Agilität und mit den Regeln, Methoden in Kontakt gekommen bin. So einzelne Entwicklungspraktiken hatte ich davor schon Ende der 90er Jahre kennengelernt, aber jetzt nicht wirklich so systematisch. Also so Dinge wie, dass man Pair Programming gemacht hat oder das man regelmäßig kontinuierlich integriert hat, aber das wurde dann nicht als Continuous Integration bezeichnet, das wurde auch nicht als Pairing oder Pair Programming bezeichnet. ja, insofern würde ich sagen, so ungefähr vor 25 Jahren. Stefan Roock (it-agile): Und obwohl die Entwicklung am Ende nicht erfolgreich war, bist du ja irgendwie bei dem Thema geblieben. Roman: Genau, bin ich bei dem Thema geblieben und es war auch sozusagen mein erster richtiger Einstieg in den Bereich Produktmanagement, weil ich dann tatsächlich auch im Rahmen dieser Unterstützung dieses Beratungsprojektes dann mit dem Produktmanagement-Team und den Produktmanagern zusammengearbeitet habe und dabei eben gemerkt habe, dass einerseits Entscheidungen, das Produkt betreffen, Entscheidungen über Markt, Entscheidungen über welche Kundenbedürfnisse wir adressieren, welche Geschäftsziele wir haben, mit welchen Featuren wir jetzt tatsächlich das Produkt in den Markt einführen wollen und wahrscheinlich wichtig sind. Mindestens genauso wichtig wie die technischen Entscheidungen, die wir treffen. Und ich habe auch gemerkt, dass es ein Bereich ist, mir einfach Spaß macht. Also etwas, wichtig ist und das mir Spaß macht. Stefan Roock (it-agile): Genau, nach den Anfängen von Agilität hast du dich dann sehr früh schon mit dem Thema Produktmanagement beschäftigt. Roman: Ja, das ist eine gute Frage. Ich reflektiere jetzt gerade mal, wann ich damit angefangen habe. ich denke so ⁓ 2007, 2008 habe ich dann angefangen, auch so im Rahmen jetzt der Scrum Community. mich stärker ⁓ den Bereich Product Ownership und Product Ownerrolle und entsprechende Praktiken zu interessieren und habe dann, glaube ich, so 2008 rum angefangen an meinem Buch Agiles Produktmanagement mit Scrum zu schreiben. Also verhältnismäßig früh, wie gesagt, war und ist ein Themenbereich, der mich sehr interessiert, den ich einfach wirklich wichtig erachte und Dann war es auch so, dass ich sowohl bei meiner Tätigkeit bei Siemens in verschiedenen Bereichen als auch ich war zuvor bei Intel in der Softwareentwicklung, in der IT, Produktmanagement Prozesse kennengelernt habe, die aus meiner Sicht nicht wirklich effektiv waren. Also bei Intel zu meiner Zeit war das sehr ad hoc würde ich sagen. ging darum, hauptsache wir erreichen die Ziele, hauptsache es kommt die Software bei rum. Wie wir das machen ist eigentlich sekundär. Und bei Siemens war es fast umgekehrt. Also da stand der Prozess vor fast allem. war der Prozess fast wichtiger als das Ergebnis, würde ich sagen. Und die Prozesse waren, ich hatte es schon gesagt, schwergewichtig. Das galt auch für die Produktmanagementprozesse. Und es war wirklich so, dass ein Produktmanager dann in einem gewissen Grad Marktforschung gemacht hat, Business Case gemacht hat, eine Roadmap-Planung gemacht hat, eine Anforderungsspezifikation geschrieben hat, die wurde dann gefuehrt und wurde dann wirklich an die Entwicklung übergeben. Und Produktmanager waren dann im Wesentlichen nur noch involviert in die eigentliche Entwicklung der Software, wenn es irgendwelche Change-Requests gab. Aber auch so Rückfragen aus der Entwicklung an das Produktmanagement gab es eigentlich nicht. Das hat dann Projektleiter im Wesentlichen abgefangen und beantwortet. Und Für mich hat das gar nicht eigentlich mit den agilen Arbeitsweisen zusammengepasst. Und von daher habe ich dann angefangen relativ früh eigentlich Agilität als eine Chance zu sehen für eine alternative Art und Weise auch des Produktmanagements. Und gleichzeitig mich gefragt Mensch, wie müsste Produktmanagement denn aussehen und welche Veränderungen wären denn notwendig, überhaupt jetzt so Ideen wie kollaboratives Arbeiten, teambasiertes Arbeiten ist vielleicht das einfachere Wort. Stefan Roock (it-agile): Ja, Roman: auch nicht mit einer festen Anforderungsspezifikation zu arbeiten, sondern Anforderungen zu entdecken und Produkte inkrementell zu bauen, damit sowas überhaupt möglich ist, damit sowas überhaupt mit Produktmanagement zusammen geht. Stefan Roock (it-agile): Okay, cool. Das erinnert mich noch, in meinem Anfang war ich ja an der Uni und da war immer schon iterativ inkrementelles Arbeiten, zumindest in dem Fachbereich, wo ich war, Softwaretechnik, en vogue. Und Agilität hat für mich dann so ein bisschen die methodische Unterfütterung von einem relativ abstrakten Konzept geliefert. Und ich weiß aber noch, dass in diesem Bereich Dinge, wir haben das nicht Produktmensch mit genannt, ich kann den Begriff auch nicht, aber Dinge, die darin überlappen, das war immer heiß diskutiert, ob man sich als ITler so weit aus dem Fenster lehnen will, ⁓ da mitzureden oder ob das nicht einfach der Job ist, zu sorgen, dass man das umsetzt, was einem präsentiert wird und dass man das vernünftig gebacken kriegt. Und ich hatte immer schon die Tendenz zu sagen, das alleine irgendwas zu liefern reicht nicht aus. Also wir müssen uns mit diesem anderen Bereich auch auseinandersetzen. da scheinen wir irgendwie ähnliche Überlegungen gehabt zu haben. Das lässt sich halt nicht gut trennen. Also zu sagen, du machst irgendwie Produktmanagement ohne Delivery perfekt und dann machst du Delivery ohne Produktmanagement perfekt, das ist aus seiner Gehensichtweise wahrscheinlich bisschen seltsam. Roman: Ja, das ist richtig. Stimmende Erfolg kommen zu, die zwei Sachen müssen zusammenpassen und das erinnert mich so ein bisschen. Meine Herren, jetzt kommen wirklich die ganz alten Geschichten hier aus der Klamottenliste. Aber ich habe vor vielen, vielen, vielen Jahren mal ein Seminar zur objektorientierten Analyse und Design besucht und da wir erst Use Cases geschrieben und dann die Nomina unterstrichen und dann wurden... erste Use-Case-Klassen abgeleitet. Und warum erwähne ich das? Naja, weil die Idee, dass technische Entscheidungen und dass technische Entscheidungen auf letzten Endes Produktentscheidungen basieren sollen, eine sehr, alte ist und objektorientierte Analyse und Design ist jetzt eine Methodik, ⁓ das Ganze zu verzahnen. Also insofern glaube ich, ist es was, was auch das agile Zeitalter, wenn wir es so wollen, oder agile Methoden Wie sagt man denn auf Deutsch? Naja, denen vorangeht. Älter ist. Ja, aber auf jeden Fall nicht. Die zwei Dinge müssen zusammengehen und deswegen, glaube ich, gibt es ja auch jetzt in der allgemeinen Welt in Scrum so eine Rolle wie den Product Owner oder Rolle. Was heißt Rolle? Inzwischen ist es ja eine Verantwortlichkeit. Glaube ich. Stefan Roock (it-agile): Genau, jetzt hast du den Product ohne angesprochen, aber bisher hast du die ganze Zeit nur vom Produktmanagement gesprochen oder Produktmanager. Ist das das gleiche? Gibt es Unterschiede aus deiner Sicht? Roman: Ja, das ist auch wieder eine gute Frage. Für mich ist es so, dass... die ersten Product Euner, mit denen ich zusammengearbeitet habe, im Wesentlichen Produktmanager waren. Und von daher habe ich eigentlich immer die Product Euner-Rolle oder das Product Euner-Sein als mit Produktmanagement, mit agilen Produktmanagement gleichgesetzt. Also für mich war ein Product Euner immer jemand, der ein Produktmanager ist und agile Praktiken, agile Methoden einsetzt. Ich habe dann nie verstanden, dass Leute gesagt haben, hier haben wir einen Product Owner und dann gibt es separat noch einen Produktmanager, bis dann tatsächlich sich so ein Framework wie SAFE angefangen hat zu etablieren. ja, ich denke, mittlerweile ist es schon so, dass viele Leute, wenn sie den Begriff Product Owner hören, eher an eine technische Rolle, eine interne Rolle denken, jemanden, der sich eher dann ⁓ Anforderungen, ⁓ Product Backlog, Product Backlog Management kümmert oder Teile dessen. Und wenn Leute Product Owner hören, dann denken sie eher an jemanden, eine Person, sich ⁓ strategische Produktentscheidungen kümmert, also Produktstrategie, Produkt-Roadmap, Geschäftsmodell, Kunden, Markt, Wettbewerbsanalyse, all diese Dinge, aber vielleicht dann weniger mit agilen Entwicklungsteams zusammenarbeitet. Aber dann haben wir natürlich wieder diese Trennung, was heißt natürlich, dann haben wir eine Trennung zwischen ja externen Produktmanagement und internen Produktmanagement und damit auch vielleicht zwischen strategischen Produktmanagemententscheidungen und der Delivery. Also dann möglicherweise so eine Lücke oder so ein Graben. Stefan Roock (it-agile): Wie ist denn dein Gefühl oder deine Wahrnehmung, was sich dann in den letzten 25 Jahren verändert hat, sowohl was Agilität als solches angeht, wie auch das Thema Product Management, Protagonisthip? Also ist es wirklich besser geworden? Roman: Ja, es hat sich viel und wenig verändert, glaube ich. Also ob es jetzt unter dem Strich besser geworden ist, weiß ich ehrlich gesagt nicht. Also ich glaube schon, dass agile Methoden nachhaltige Veränderungen herbeigeführt haben, auch im Bereich Produktmanagement. Also die Idee eben, dass man Produkt iterativ incrementell entwickelt und dass man ist ja jetzt auch gerade nicht mit dem, wie soll ich sagen, im Kontext jetzt von KI ein großes Thema ausführbare Spezifikationen. Das Product Backlog ist ja eine Ausführung spazifikation aus meiner sicht die idee ist ja dass wir am anfang nur ein skizzenhaftes backlog erstellen und dann anfordern entdecken darüber entdecken dass wir tatsächlich auch erste produktversionen produkt incrementen bauen uns feedback einholen von von stakeholders von ausgewählten anwendern und kunden Also das sind schon, denke ich, schon, haben agile Methoden, agile Ideen, Konzepte viel bewirkt. Andererseits glaube ich aber auch, dass grundlegende Herausforderungen im Bereich Softwareentwicklung und auch Produktmanagement von bisher nicht wirklich gelöst wurden und auch die agilen Vorgehensweisen nicht wirklich erfolgreich waren. Also es gibt ja den Grund, warum in Scrum die Rolle Product Owner als Produktquasi Besitzer oder Besitzerin, wörtlich übersetzt, bezeichnet wird. Die Idee ist, dass die Person, die diese Rolle oder Verantwortung inne hat, auch bevollmächtigt ist, Entscheidungen zu treffen und entsprechend respektiert ist in der Organisation. Und das ist besonders wichtig. Ich es ist immer wichtig und das ist ja eigentlich auch eine grundlegende Idee mit einem klassischen Produktmanager oder Produktmanagerin. Aber es ist eben besonders wichtig in einem agilen Kontext, wo wir schnell entscheiden können, wollen und wo wir normalerweise in der Gruppe entscheiden oder wo wir zusammenarbeiten wollen. mehrere Leute haben, die vielleicht auch von unterschiedlichen Fachbereichen, Abteilungen, Unternehmensbereichen kommen und unterschiedliche Sichtweisen und Ideen haben. ist es nicht immer möglich, dass alle gleicher Meinung sind, ist auch nicht wünschenswert und es ist manchmal schwierig, Konsens zu erzielen. Dann ist es sinnvoll, dass eine Person tatsächlich entscheiden kann und das sollte der Product Owner sein. Nur wenn ich mir heute anschaue, was ich häufig sehe, wenn ich mit Kunden zusammenarbeite, dann ist es so, dass die Bevollmächtigung im Bereich Produktmanagement nicht so weit ist, es sinnvoll und wünschenswert wäre. Häufig ist es immer noch so, dass egal wie die Rolle bezeichnet wird, ob wir jetzt über Produktmanager oder Product-Euner sprechen, die Rolle doch eher taktisch geprägt ist. Also gucken muss, was wollen die Stakeholder. Es passiert mir immer wieder, dass ich Produktmanager und Product-Owner treffe, die zu mir sagen, aber meine Stakeholder sagen, aber ich muss doch mich ⁓ meine Stakeholder kümmern, aber ich muss doch meine Stakeholder glücklich machen. Und das sollte nicht der Job von einem Produktmanager und Product-Owner sein, sondern unser Job sollte sein, dass wir den Wert, den Produkt kreiert, möglichst maximieren. Und das bedeutet eben auch dann, diese Bevollmächtigung zu haben oder die Bevollmächtigung zu haben. Nein sagen, nein zu sagen, wenn Stakeholder mit Wünschen, Ideen und Anforderungen kommen. Aber für viele Personen, für viele Produktleute ist das in der Praxis sehr, sehr schwierig. ja, ich denke, das ist sozusagen so ein systemisches Problem im Bereich Produktmanagement, das seit langem existiert, aber wie gesagt, wo bisher auch agile Vorgehensweisen nur bedingt wirklich was bewegt haben. Stefan Roock (it-agile): Was denn deiner Wahrnehmung nach der Grund dafür, dass das so schwierig ist? Roman: Ich denke es hat damit zu tun, wie Produktmanagement verstanden wird, wie Produktmanagement gesehen wird, wie Produktmanagement auch in Unternehmen eingesetzt wird. Da gibt es, finde ich, Parallelen zu agilen Methoden. Ich glaube, dass sowohl Produktmanagement als auch Agilität in den letzten zehn Jahren in einer gewissen Weise gehypt wurde. Dass viele Unternehmen sich sehr viel von Agilität und von der Einführung von Produktmanagement gerade für digitale Produkte versprochen haben, aber letzten Endes auch ein Stückchen weit enttäuscht sind. Vielleicht weil zu viel versprochen wurde, vielleicht aber auch, weil dann Agilität und Produktmanagement nicht immer richtig eingeführt und angewandt wurde. Und meine Beobachtung ist die, dass viele gerade etablierte größere Unternehmen sich in so einem Zwischenstadium, in so einer Zwischenwelt befinden, zwischen den alten Arbeitsweisen und einer modernen, agilen, digitalen Welt, in der auch ein effektives Produktmanagement existiert. Und naja, manche Unternehmen haben dadurch zumindest lokale Verbesserungen erzielt, aber manchen Unternehmen gibt damit auch die Struktur und systematisches Planen und Vorgehen, wie es eine alte traditionelle Welt bietet, geht denen ab. Ich glaube, dass wir als Community, sowohl als agile Community als auch als Produktmanagement Community unterschätzt haben, wie disruptiv, wie schwierig letzten Endes ein erfolgreiches Etablieren agiler Vorgehensweisen und ein Etablieren von einer erfolgreichen effektiven Produktmanagementsfunktion ist. Auf Englisch sprechen wir ja auch gerne über Product Operating Model. Also tatsächlich, dass wir produktbasiert arbeiten und nicht mehr primär in Projekten denken. Dann brauchen wir auch entsprechende Rollen, brauchen wir eine entsprechende Bevollmächtigung, wir brauchen auch eine entsprechende Unterstützung der Leute und die Leute brauchen auch, so muss man auch ganz klar sagen, entsprechendes Wissen und entsprechende Fähigkeiten. Stefan Roock (it-agile): Du hast ja gesagt, angefangen hast du mit XP, dann bist du irgendwann Scrum Trainer geworden, einer der ersten deutschsprachigen Certified Scrum Trainer. Roman: Hm. Stefan Roock (it-agile): noch ausgebildet von Kent Schwäber höchstpersönlich, glaube ich. Roman: So ist es. ⁓ Stefan Roock (it-agile): Hast du da vielleicht noch die eine oder andere Geschichte aus Anfangszeiten? Roman: Naja, Scrum glaube ich, habe ich das erste Mal, ich habe es das erste Mal von Scrum gehört oder wenn es das erste Mal über ein Paper gestolpert, in dem Scrum beschrieben wurde. Ich glaube, es muss 2000 gewesen sein. Und da dachte ich mir, ja, das ist ja ganz nett, aber das kann man nicht ernst nehmen. Es ist vielleicht ein leicht gewichtiges Projektmanagement, Rahmenwerk, aber zu mir kann es nicht taugen. Und ähm... Für mich war XP einerseits die Methode, über die mehr Wissen verfügbar war. Also erkent.beck hat ja dann auch das Buch Extreme Programming Explained veröffentlicht und ja die Methode die bekannter war und auch die Methode die jetzt gerade aus Entwicklungssicht mehr Konkretes geboten hat. Also was weiß ich eben so was wie Per-Programming oder sowas wie Refactoring oder sowas wie 40-Hour-Week und konkrete Empfehlungen, die so in dem Kontext Instagram-Mail eigentlich nicht existieren. ich habe dann mit einem Kunden Das muss 2004 gewesen sein, Kunden unterstützt, den internen Kunden unterstützt. Damals hatte Siemens ja noch einen Telekommunikationsbereich, im Bereich Enterprise Telecommunications ein neues Softwareprodukt zu bauen. Und da kam der Kunde auf uns zu und hat gesagt, wir wollen also ganz bewusst jetzt nicht den traditionellen Entwicklungsprozess bei uns benutzen, sondern wir wollen was iterativ Inkrementelles machen. Und der Kunde wollte mit dem Rationale Unified Process starten. Und dann haben wir also den RUP, den Rational Unified Process, der da mal also um diesen Zeitpunkt, so 2004, relativ populär war, ganz stark angepasst, versucht eine sehr leichtgewichtige Version daraus zu generieren und haben dann aber auch extreme programming Elemente integriert, also wie beispielsweise pairing, continuous integration und refactoring, weil wir gedacht haben, Mensch, die sind einfach so wertvoll, die würden wir da auch gerne sehen. Ja, und dann haben wir angefangen, in diesem Prozess zu leben und haben dann sehr schnell mit gerade im Rahmen der Iterationsplanung Schwierigkeiten gekretet und dann habe ich übers Wochenende doch noch mal mich in die Scrum Literatur, die ich finden konnte, vertieft und bin am Montag zum Kunden gekommen und habe gesagt, okay, vielleicht sollten wir doch irgendwie hier noch Scrum integrieren in unserem Prozess. Und letzten Endes war es dann ein Scrum-basierter Prozess, wo wir so lose Phasen verwendet haben, ⁓ uns ein bisschen zu orientieren, bisschen auch ein Planungsgerüst zu haben und dann eben Extreme Programming Entwicklungspraktiken. nicht zu Scrum G kommen sozusagen aus der Not. Ich wollte nicht, aber ich musste. Es ging nicht anders. Stefan Roock (it-agile): Hahaha! Naja, im Grunde ist es ja beste agile Denkweise, irgendwas zu benutzen, was ein real existierendes Problem löst. nicht irgendwelchen romantischen Vorstellungen nachzuhängen, wie Dinge sein könnten. Roman: So kann man das sehen. Mh, mh, mh. Stefan Roock (it-agile): Ich hatte übrigens in der Vorbereitung auf diese Podcast rund ⁓ 25 Jahre agil auch nochmal so ein paar alte Internetartikel oder Blogposts gelesen. Und da gab es etwas, wo früher was damals an mir vorbei gegangen ist, dass es die Befürchtung gab aus der agilen Community, also insbesondere rund ⁓ extreme programming, dass der Rational Unified Process sich XP einverleiben würde. Da gab es so große Diskussionen. Am Ende war man so ein bisschen desillusioniert, weil herauskam, dass man das so oder so nicht verhindern könnte. Also auch nicht mit Trademarks oder so. Das ist vielleicht so bisschen wie safe heute. Aber sie haben es ja nicht gemacht. Wahrscheinlich war dann der Zenit von Rupp zu schnell überschritten, als dass das noch hätte passieren können. Roman: Ja, ist eine gute Frage. Ich weiß auch nicht, warum sich der Russian Unified Prices nicht noch länger behaupten konnte oder vielleicht stärker durchgesetzt hat. Ich denke, einigen großen Banken war er dann noch länger im Einsatz. Aber insgesamt hat er dann doch relativ schnell an Popularität eingebüßt. Naja, denke aus Agilersicht ist das jetzt nicht allzu bedauerlich. Stefan Roock (it-agile): Hahaha. Roman: Ich meine, ist nicht so, dass der Rational Unified Process jetzt nur Mist ist. Da gibt es, denke ich, schon noch einige sehr sinnvolle Ansätze und Konzepte und sehr sinnvolle Überlegungen. Und ein Stückchen weit ist er wirklich so ein Zwischenschritt zwischen einem traditionellen Entwicklungsprozess und einem Agilen. Und ich denke, als solches hat er auch seinen Platz in der Prozesshistorie, wenn es die denn so gibt. Stefan Roock (it-agile): Definitiv. könnte, also meine Zuschreibung wäre, ich habe mich damals, das ist ja irgendwann entschieden, als ich noch erschienen, als ich an der Uni war, habe mich damit dann beschäftigt. Und ich fand, das schien alles plausibel, aber auch irrsinnig kompliziert. das ist ja so bisschen so eine Richtungsentscheidung bei vielen prozessualen oder methodischen Geschichten. Baue ich sozusagen das große Ding in der Hoffnung, dass die Leute das dann auf das runtertailern, was sie brauchen? Oder habe ich eher so den Ansatz von Agile oder Extreme Programming do the simplest things that could possibly work. Und wenn es nicht funktioniert, dann mache ich es so kompliziert, dass es funktionieren kann, aber nicht komplizierter. Und aus der V-Modellecke weiß man das ja auch, dass die Leute sich sehr schwer damit getan haben, Dinge rauszustreichen, weil man vielleicht Angst davor hat, dass man irgendeinen Vorteil nicht kriegt, den man gerade übersieht. Und dann sind die Sachen halt tendenziell alles vielleicht dann doch zu schwerfällig. Und vielleicht war es trotzdem auch ein notwendiger Zwischenschritt, ⁓ so etwas wie Agile überhaupt denken zu können. Vielleicht wäre der andere Wechsel zu krass gewesen. Roman: Heutzutage müssen wir uns zum Glück über solche Dinge keine Gedanken mehr machen, denn wir haben ja jetzt KI-basierte Tools, die ganze Arbeit übernehmen. Prozesse sind nicht mehr wichtig. Stefan Roock (it-agile): Genau. Dazu können wir gleich noch kommen. Ich wollte dich aber einmal noch fragen, welche mehr oder weniger vergessene agile Methode hat eine zweite Chance verdient aus deiner Sicht? Und warum? Roman: Ja, mit dieser Frage bringst du mich ein wenig in Bedrängnis, denn ⁓ ehrlich zu sein sind die einzigen Zweiergelmethoden, die ich wirklich ausprobiert habe und von daher auch behaupten kann zu kennen Extreme Programming und Scrum. Ich habe zu DSDM gelesen. Ich habe zu den Crystal Ansätzen oder Prozess Sammlungen gelesen, aber keine praktischen Erfahrungen. ähnlich sieht es mit Feature Driven Development aus. Ja, und ich weiß nicht, ganz ehrlich gesagt, nicht, ob es sinnvoll wäre, jetzt eine von den quasi alten etablierten Methoden wieder zum Leben zu erwecken. denke, wichtig ist es für die Agile Community nach vorne zu schauen und zu überlegen, wie entwickeln wir die Ansätze, die wir haben, und welche helfen uns jetzt auch in der veränderten Welt, in der wir uns jetzt befinden. Also in letzten 25 Jahren hat sich ja wirklich eine ganze Menge getan. Stefan Roock (it-agile): Mhm. Genau, und dann sind wir wahrscheinlich direkt beim Thema KI. Du hast es ja schon angesprochen. Was ist denn deine Sichtweise da drauf? Roman: Ja, ich tu mich so ein bisschen schwer, weil... der Bereich sich so schnell verändert und ich es wirklich persönlich schwierig finde, jetzt einschätzen zu können, wie weit die Technologie oder die Technologien sind. jetzt in meinem Bereich Produktmanagement ist es sicherlich so, dass jetzt auch dann in den letzten Jahren und Monaten immer wieder neue quasi Trends aufgekommen sind von prompt engineering alle produktleute müssen jetzt total toll prompt engineering machen können verstehe ich noch dann wipe kauding also du musst jetzt unbedingt wipe kauden weil sonst bleibst du auf der strecke und eigentlich brauchst du vielleicht gar kein entwicklungsteam mehr du kannst jetzt alles alleine machen und das neueste ist irgendwie zu sagen ja nein ich mache jetzt kontext engineering und ich baue mir meine meine klaut meine clothes skills zusammen Und also insofern, finde, es ist so ein Moving Target einerseits. Andererseits glaube ich, dass KI-basierte Werkzeuge wirklich ein großes Potenzial haben, gerade im Bereich Produktmanagement. Ich glaube aber auch aufgrund der Technologie, soweit ich das beurteilen kann, dass wir einfach auch Beschränkungen haben, die wir anerkennen müssen. und ein Stückchen weit immer noch sehr viel Hype ⁓ das Thema KI oder beim Thema KI existiert. Und Letzteres halte ich für nicht hilfreich. Ja, das war jetzt eine sehr allgemeine Antwort. Stefan Roock (it-agile): Man könnte auch sagen differenziert. Roman: Also Naja, ich denke, für viele Produktmanager ist es ja so oder für viele Produktleute ist es ja so, dass sie sich in einer Situation befinden, wo sie eigentlich zu viel Arbeit haben, aber vielleicht nicht immer die Bevollmächtigung, die sie brauchen, habe ich schon angesprochen, hatten wir schon diskutiert. Und vielleicht manchmal auch nicht, wenn wir ehrlich sind, das Wissen in der Tiefe und Breite, hilfreich wäre. Und da ist es natürlich schon unwahrscheinlich. verlockend auf KI-basierte Tools zurückzugreifen und dann ein Stückchen weit auch KI-basierten Tools zu vertrauen. Und die Tools zu benutzen, spricht ja überhaupt nichts dagegen. Und Arbeitsprozesse oder Tätigkeiten zu automatisieren, die Sinn machen, die nützlich sind. Warum sollten wir das nicht tun? Ich meine, das machen wir seit Jahrzehnten. Und insofern sehe ich da KI ein Stückchen weit als ein weiterer Schritt hin zur in der Automatisierung unserer Arbeitswelt. Aber ich denke, wichtig ist tatsächlich die Kontrolle zu behalten, wichtig ist zu verstehen, warum ich was tue und was hier getan wird, auch wenn ich es persönlich nicht tue, auch wenn ich das jetzt im Prinzip an Programme delegiere. Und es ist ganz egal, ob das jetzt KI ist oder nicht. Ich als Produktperson, ich muss letzten Endes am Steuer sitzen und Ich muss eben verstehen, welche Entscheidungen ich für mein Produkt wann fällen muss, damit ich tatsächlich dann auch Wert schaffe für Kunden und Anwender und für mein Unternehmen. Und von daher darf ich nicht den Fehler machen, dass ich mich zu sehr von neuen KI-basierten Technologien ablenken lasse und zu viel Zeit, sage ich jetzt mal, mit dem Explorieren, Experimentieren oder Spielen verbringe. So faszinierend das auch manchmal sein mag. Und andererseits, dass ich nicht den Fehler mache, dass ich Verantwortung abgebe und sage, naja, das entscheidet die KI und ich bin halt da irgendwie dabei. Also das glaube ich ist nicht hilfreich, denn generative KI, so wie ich die Technologie verstehe, ist halt letzten Endes Pattern Matching und Statistik. Und wir wissen alle, mit dem, wie soll ich sagen, mit dem Setup, das wir aktuell haben, immer wieder falsche Ergebnisse zustande kommen können. Und von daher haben wir einfach keine Garantie, dass die Ergebnisse, die eine KI generiert, tatsächlich auch korrekt sind. Wir haben eine gewisse Wahrscheinlichkeit. Und was dazu kommt, finde ich, das, naja, das Zwischenmenschliche, das für mich im Produktmanagement so unwahrscheinlich wichtig ist, also tatsächlich auch ein direktes, ein unmittelbares Verständnis. der Bedürfnisse von Anwendern und Kunden zu erlangen, das ist durch KI nicht möglich. KI kann nur Daten analysieren und auch bestehen auf basierenden Daten, Vorhersagen machen. Aber es ist für eine KI nicht möglich, wirklich zu verstehen, wie Menschen ticken. Und es ist vor allem auch für eine KI nicht möglich, mit genuin neuen Ideen zu generieren und damit sowas wie disruptive Innovationen zu unterstützen. Also da haben wir halt auch wirklich mit den aktuellen Technologien ganz wichtige Einschränkungen gerade für den Bereich Produktmanagement, die wir anerkennen müssen, abgesehen von ein paar rechtlichen und umwelttechnischen Aspekten. Aber die gelten ja für alle KI-Notzer. Stefan Roock (it-agile): Ja. und Die, äh, eins der größten Probleme, das du ja angesprochen hast, löst die KI dann ja auch nicht. Also wenn der Product Owner, Produkt Manager nicht empowered ist, Entscheidungen zu fällen, dann wird das nicht besser dadurch, dass er eine KI benutzt, Roman: Das ist ganz korrekt. Dann fällt im Zweifelsfall die KI die Entscheidungen. Als Product Euler gehe ich dann zu meinem Chef und sage, naja, die KI sagt oder hier sind die Empfehlungen, die die KI generiert hat und warte dann, was mein Chef entscheidet, basierend auf den Vorschlägen, die die KI erarbeitet hat. damit besteht die Gefahr, dass ich halt ein Stückchen behalte meinen eigenen Job, wie soll ich sagen, meine eigene Leistung tatsächlich schmälere und meinen eigenen Job tatsächlich dann auch irgendwo. Na ja, wie sagt man denn auf Deutsch? Stefan Roock (it-agile): Hahaha! Roman: dass ich dann irgendwann vielleicht herausstelle, dass meine Tätigkeit doch nicht ganz so wichtig für das Unternehmen ist, wie bisher angenommen, wenn die KI ⁓ so viel kann. Also ich glaube, insofern ist es im Interesse jetzt von jeder Produktperson, von jedem Product Owner dann wirklich auch entsprechend, wie ich gesagt habe, das Steuer in der Hand zu halten und einfach auch entsprechend Wissen aufzubauen über die Entscheidungen, die gefällt werden müssen und wie die Entscheidungen zustande kommen. Stefan Roock (it-agile): Wenn letztlich die Leute nur Backlog-Manager sind, dann ist wahrscheinlich die Gefahr hoch, die, also da lässt sich wahrscheinlich das fast vollständig automatisieren. Roman: Ja, sicherlich, solange wir jetzt über Produkte sprechen, wo du keinen sehr großen Innovationsgrad hast. Ich glaube, das ist halt auch das, was denke ich jetzt in der Diskussion, so wie ich sie wahrnehme, auch vielleicht noch nicht differenziert genug betrachtet wird. Ich denke, es hängt wirklich immer davon ab, mit welchem Innovationstyp wir es zu tun und wo steht ein Produkt auch in seinem Lebenszyklus. Wenn ich jetzt ein Produkt habe, das einer Kategorie angehört, die lange, wo wir Softwareprodukte, digitale Produkte haben, die existieren seit Jahren, vielleicht Jahrzehnten und wir sprechen über ein Produkt, das ist relativ reif, ja dann kann ich glaube ich auch sehr viel automatisieren mittlerweile. Ich würde sagen, es ist trotzdem wichtig, dass Menschen involviert sind, weil eben die aktuellen Technologien auch gerne mal Fehler produzieren und hallucinieren. Aber kann ich sicherlich sehr viel automatisieren. ich jetzt, ich schon angekündigt habe, wie schon erwähnt, eine disruptive Innovation umsetzen will, also denken wir an sowas wie das erste iPhone oder die Nintendo Wii oder Twitter, die ursprüngliche Version von Twitter, dann wird mir eine KI einfach nicht helfen können. Also sicherlich nicht initial, wenn es darum geht, Ideen zu kreieren und initial zu, nur sehr bedingt und initial zu validieren. Denn damit kreier ich ja auch einen neuen Markt. und wie Clayton Christensen schon vor vielen Jahren gesagt hat, Märkte, die nicht existieren können, auch nicht analysiert werden. Und das andere ist, wenn ich jetzt ein neues Produkt entwickle oder gerade in den Markt eingeführt habe, dann habe ich halt auch so viel an Unsicherheit und häufig auch so viel an Veränderung, dass es aus meiner Sicht wirklich sehr sinnvoll ist, sowas wie einen Backlog gemeinsam kollaborativ zu füllen und auch dann zu verändern und weiterzuentwickeln. Das hilft dann tatsächlich auch, das Wissen eines interdisziplinäres besetzten, agilen Entwicklungsteams abzugreifen. Es hilft, gemeinsames Verständnis zu entwickeln. und vermeidet Missverständnisse. Wir wollen ja weg von der Situation, wie wir sie früher hatten. Anforderungsspezifikation, Lastenpflichtenheft, ich habe das schon erwähnt, wird über den Zaun geworfen und dann muss die Entwicklung halt daraus machen. was sie kann. Das wäre schade, wenn ich jetzt meine tollen KI-basierten Tools habe, die dann irgendwelche Jira-Boards automatisch füllen. Aber letzten Endes müssen es dann doch irgendwelche Menschen einprogrammieren, es sei denn natürlich, automatisieren das auch. Das können wir ja mittlerweile auch zumindest verzeihen. Stefan Roock (it-agile): So, jetzt haben wir zurückgeguckt, wir haben auf Produktmanagement geguckt, wir haben auf KI geguckt. Was hast du denn gerade so an neuen heißen Scheißanwickel? Also gibt es neues Buch, neues Thema, mit dem du dich beschäftigst? Roman: Heißer Scheiß, ho! Naja, ein Thema, das mich schon seit einer Zeit interessiert und wo ich auch versucht habe, den letzten Monaten, in gewissen Weise auch in den letzten ein, zwei Jahren mehr zuzuarbeiten, ist alles, mit Portfolio-Management, Portfolio-Strategie zu tun hat, auch Portfolio-Roydments. Und in dem Zusammenhang auch, wie hängen verschiedene Strategien und verschiedene Pläne, auch verschiedene Ziele oder wirkungsbasierte Ziele zusammen. Wie hängt beispielsweise eine Unternehmensstrategie mit einer Portfolio- und einer Produktstrategie zusammen? Wie kann ich das geschickt verheiraten? Welche Frameworks und Modelle gibt es dafür? Also das ist ein Bereich, der mich sicherlich interessiert. Und dann plane ich schon seit längerer Zeit mein Buch zum Thema Produktleadership zu aktualisieren. Bin aber nicht dazu gekommen, aber ich hoffe, dass ich dieses Jahr damit anfangen kann. Das ist so mein aktuelles Buchprojekt. Ach ja, noch ein Thema hatte ich ganz vergessen, das mir sehr am Herzen liegt und wo ich auch zu relativ viel gearbeitet habe. Gerade letztes Jahr sind Produktteams im Sinne von die aus einem Product Owner bestehen, Entwicklungsteamrepräsentanten. Ich empfehle auch gerne dann erweiterte Product Teams zu formen und ausgewählte Interessenvertreter einzuladen. Das ist für mich auch ein wichtiges Thema, gerade strategische Themen erfolgreich dann in Unternehmen umsetzen zu können. Wir brauchen ja immer Prozesse, Methoden, brauchen entsprechende Tools, Werkzeuge, Technologien, aber wir brauchen natürlich auch nicht nur die richtigen Mitarbeiter, sondern auch die richtigen Teams von Mitarbeitern und da spielen eben Produktteams aus meiner Sicht eine ganz wichtige Rolle. Stefan Roock (it-agile): Das heißt, so Produktteam, also wenn wir jetzt für die Entwicklung mehr als ein Entwicklungsteam bräuchten, dann wären wir dieses Produktteam quasi mit mehreren Entwicklungsteams verknüpft, indem da Vertreter sind. Roman: Korrekt, korrekt. Genau, also für mich ist ein Produktteam nicht identisch mit einem Entwicklungsteam, das ist eher die Ausnahme, die Regel, sondern wenn ich drei Entwicklungsteams hätte, dann würden die Entwicklungsteams Repräsentanten in das Produktteam entsenden. Dann habe ich Schlüssel-Stakeholder, also Stakeholder, deren Wissen und deren Unterstützung wichtig ist, damit die richtigen Produktentscheidungen getroffen werden können, die vielleicht auch aktiv am Produkt mitarbeiten müssen. Also denken wir an den Vertriebsmitarbeiter oder jemand aus dem Bereich Marketing oder Support. Und zusammen mit dem Product Owner und Product Manager treffen dann die Produktteam-Mitglieder oder trifft das Produktteam dann hoffentlich einvernehmlich wichtige Produktentscheidungen, also kümmert sich ⁓ Produktstreit kümmert sich aber auch ⁓ Ziele und eine zielbasierte Product-Roadmap. Die Idee ist damit eben auch so einen Bereich, der wissen wahrscheinlich alle, uns zuhören, der ja unwahrscheinlich wichtig ist, nämlich Stakeholder-Management mit einzubeziehen in eine kollaborative, ein Stückchen weit agile Vorgehensweise und wegzukommen von einem Ansatz, wo Wir entweder den Fehler machen, dass wir auf Zuruf arbeiten und das tun, was die Stakeholder uns sagen und andererseits versuchen die Stakeholder ganz auszublenden, ganz weit wegzuschieben, sondern zu sagen, wir beziehen die Stakeholder aktiv mit ein. Wir versuchen hier wirklich auch eine gute Arbeitsbeziehung zu entwickeln, dauerhafte Bindung. zu etablieren und tatsächlich so etwas wie ein mehr oder weniger stabiles Team zu bauen, das dann eben ergänzend zu den Entwicklungsteams agiert. Stefan Roock (it-agile): Cool, dann danke ich dir vielmals für deine Zeit und die interessanten Perspektiven und Einsichten. Roman: Sehr gerne. hat mich sehr gefreut, dir zu raten, mit dir zu sprechen. Danke für die Einladung. Nochmal. Stefan Roock (it-agile): Dann stoppe ich jetzt die Aufnahme.