Transcript
Lucas Dohmen: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ-Podcast. Heute wollen wir über “Product-Ownership” sprechen und dafür habe ich mir zwei Gäste eingeladen: Jan und Jessica. Hallo!
Jan Körnich: Hallo, Lucas.
Jessica Strobach-Möckel: Hallo, Lucas.
Lucas Dohmen: Magst du dich kurz vorstellen, Jan? Wer bist du und was machst du bei INNOQ?
Jan Körnich: Ich bin Jan und jetzt seit drei Jahren bei INNOQ als Senior Consultant. Ich bin einer der Kollegen, die nicht programmieren, sondern eine, wie wir es bei uns nennen, “P-Rolle” übernimmt. Das bedeutet zum Beispiel die Product-Owner-Rolle oder die Projektleiter-Rolle.
Lucas Dohmen: Und du, Jessica?
Jessica Strobach-Möckel: Ich bin seit einem halben Jahr bei INNOQ und auch in einer fachlichen Rolle eingestellt, d.h. ich bin keine Entwicklerin, sondern habe eine der Rollen, die Jan eben genannt hat. Davor war ich bereits 10 Jahre im Projektmanagement im Bereich der Softwareentwicklung als Schnittstelle zwischen Fachbereich und Entwicklung unterwegs.
Lucas Dohmen: INNOQ ist ja eher eine Beratungsfirma. Wenn ich jetzt aber Product-Owner höre - wie passen diese zwei Sachen zusammen?
Jan Körnich: Sie passen sogar ganz gut zusammen. Ich glaube, wir sollten vorher auch kurz die Geschichte erzählen, wie das Thema Product-Ownership auch für INNOQ ein Thema wurde, denn eigentlich kommen wir da nicht her. INNOQ ist ursprünglich durch hochwertige Softwareentwicklungsleistung und Architekturberatung groß und bekannt geworden. Bis vor 15 Jahren waren das auch lange die Schwerpunkte. Mittlerweile feiern wir den 20. Geburtstag und vom Zeitpunkt her passt es also ganz gut. Vor fünf Jahren haben unsere Geschäftsführer und Principal Consultants gemerkt, dass da vielleicht noch eine Ecke fehlt und zwar an zwei Stellen: Zum einen fingen Kunden von selbst an nachzufragen, ob es jemanden gäbe, der so ein Projektteam auch fachlich oder methodisch unterstützen könnte. Zum anderen haben die Kollegen in den Projekten beim Kunden vor Ort gemerkt, dass in Papierform zwar klar ist, wie es laufen sollte, aber gerade bei den Rollen im Projektmanagement und Product-Ownership läuft es beim Kunden, gerade dann wenn sie noch nicht lange agil oder moderne Softwareentwicklungsmethoden verfolgen, noch nicht so, wie man es eigentlich erwartet hat. Im Endeffekt wurden dadurch gewisse Aufgaben von den Teammitgliedern übernommen, obwohl sie da nicht ihre Expertise sahen. Und es war aus INNOQ-Erfahrung in ganz vielen Projekten so, dass das Team gewisse Lücken beim Kunden gestopft hat. Daraus hat sich die Idee entwickelt, in dieser Sache aktiver werden zu müssen: Dass auch bei INNOQ Menschen arbeiten müssen, die solche Rollen übernehmen wollen und können.
Lucas Dohmen: Was versteht ihr denn unter Product-Owner? Was bedeutet es für euch?
Jan Körnich:: Da kann man ganz klassisch dran gehen. Wenn man sich Scrum anschaut, ist der Product-Owner klar definiert. Der Product-Owner ist derjenige, der das “Product owned”, der für das Produkt entscheidet, der herausfindet, was das Produkt sein soll und eine hohe Entscheidungsfreiheit hat. Wie groß diese Freiheit ist, kommt auf das konkrete Umfeld an. Es gibt “Scrum-Gurus”, die Steve Jobs gerne als Beispiel für so einen “Über-Product-Owner” bringen. So weitgehende Entscheidungsfreiheit klappt natürlich häufig nicht, aber man kann sie graduieren, in dem man strategische Vorgaben macht. Zum Beispiel, dass ein Produkt in einem bestimmten Bereich entwickelt werden soll und dieser Bereich dem Product-Owner übergeben wird. Auf dieser Basis oder den Ergebnissen darüber, was so ein Produkt sein soll, arbeitet der Product-Owner mit dem Entwicklungsteam zusammen, um das Produkt Schritt für Schritt mit dem Team zu entwickeln. An dieser Stelle vermischt es sich auch mit Projektmanagement.
Lucas Dohmen: Gibt es Product-Ownership jetzt nur in agilen Projekten, wenn man Scrum macht? Oder geht es um eine allgemeine Rolle, die es immer gibt?
Jan Körnich: Aus meiner Sicht gibt es diese Rolle immer. Ich habe vor langen Jahren als Projektleiter viele Projekte im Wasserfall-Modus gemacht und da gab es auch die Erwartung, dass ich dem Team die fachliche Richtung vorgebe. Das Wasserfall-Modell hat viele andere Nachteile, weshalb sich die agilen Entwicklungsparadigmen, auch wenn der Begriff etwas verbraucht ist, schon durchgesetzt haben. Keiner möchte mehr Dinge entwickeln, die dann nicht genutzt werden, was bei Wasserfall-Projekten häufig ein Problem war.
Lucas Dohmen: Ja, das stimmt.
Jan Körnich: Diese Rolle gib es implizit also immer. Es gibt immer jemanden, der entscheidet, was das Produkt sein soll. Letztendlich sehen wir drei Sektoren, die für das Product-Ownership maßgeblich sind und die man schon mal vorab erwähnen kann: Zum einen das “Empowerment”, also die Bevollmächtigung des Product-Owners Entscheidungen für das Produkt zu treffen. Der nächste Punkt ist die Verfügbarkeit des Product-Owners für das Entwicklungsteam. Ein Product-Owner, der zu selten anwesend ist, könnte ein Problem sein. Letztendlich braucht ein Product-Owner auch Skills. Da ist es sehr sinnvoll einerseits domänenspezifisches Wissen über das zu entwickelnde Produkt zu haben und andereseits methodische Skills zu besitzen. Über diese werden wir später noch reden.
Lucas Dohmen: Auf jeden Fall!
Jan Körnich: Diese Referenz haben wir uns auch nicht selbst ausgedacht, da gibt es Literatur. Ich beziehe mich da auf einen guten Blogartikel von Roman Pichler, den wir auch in den Shownotes verklinken. Er beschreibt in seinem Blogartikel die Grundzüge zur Arbeit eines Product-Owners ganz gut. Der Artikel richtet sich dabei sehr an Unternehmen, die eine eigene Softwareentwicklungsorganisation aufbauen wollen und da sind wir als externe Berater, die in die Unternehmen kommen, in einer etwas anderen Situation. Und das ist auch das Thema dieses Podcast: Wie können wir in einer Rolle, die idealerweise vom Kunden besetzt werden sollte, unterstützen, um eine gute Produktentwicklung zu erreichen?
Lucas Dohmen: Bevor wir in diese drei Bereiche genauer reinschauen, interessiert es mich noch, ob es für uns noch eine Rolle als Product-Owner zu besetzen gibt, wenn der Kunde bereits einen Product-Owner hat. Schließt sich das aus oder “ersetzen” wir ihn?
Jessica Strobach-Möckel: Ersetzen ist in keinem Fall unser Anspruch. Wenn es aber dem Kunden an einer dieser erwähnten Ecken oder Merkmale, die ein Product-Owner unserer Meinung nach braucht, um effizient zu arbeiten, hapert, dann können wir schon in dieser Lücke einspringen. Wenn es zwar einen fachlichen Ansprechpartner gibt, der sich zwar bestens auskennt, aber in verschiedensten Projekten unterwegs ist und dadurch faktisch keine Zeit hat, täglich im agilen Prozess mit dem Entwicklungsteam zu arbeiten, dann können wir da eine Lücke schließen und unterstützen. Man kann zum Beispiel Stories schreiben und einen “Zwischenansprechpartner” bilden, damit es funktioniert.
Jan Körnich: Unsere Erfahrungen aus früheren Projekten zeigen, dass das Verständnis darüber, was ein Product-Owner ist, von Organisation zu Organisation oder von Mensch zu Mensch, bis hin von Scrum-Guru zu Scrum-Guru, unterschiedlich ist. Ich könnte mir Situationen zu Anfang eines Projekts vorstellen, in denen man es haarklein herunterbricht um ein gemeinsames Verständnis zu erreichen. Tatsächlich passiert das aber häufig nicht, da durch Termindruck das Projekt schnell starten muss. Aus unserer Erfahrung hat es sich als hilfreich erwiesen, dass von unserer Seite mindestens am Anfang jemand dabei ist, der auch einen internen Product-Owner mitbegleitet. Mit dem Ziel, diesen dann auch möglichst schnell selbständig weiter machen lassen zu können. Ich denke, diese Vermittlungsaufgabe zwischen unserem und dem Kundenverständnis vom Product-Owner ist am Anfang eines Projekts sehr wichtig und sinnvoll.
Lucas Dohmen: Dann lasst und jetzt in diese drei Ecken des Dreiecks hereinschauen und mit dem Empowerment starten. Was muss ich mir darunter vorstellen?
Jan Körnich: Wie bereits erwähnt ist ein ganz wichtiger Aspekt beim Product-Owner, dass er das “Product ownen darf”, dass er innerhalb der ihm gegebenen Grenzen frei entscheiden kann. Natürlich muss er seine Entscheidungen dem Management gegenüber auch erklären. Er darf zwar nicht willkürlich entscheiden, aber er muss einen großen Entscheidungsspielraum haben. Das ist speziell bei Unternehmen, die gerade erst anfangen modernere Softwareentwicklungsmethoden zu verwenden, noch nicht so in den Köpfen drin. Wir erleben beispielsweise häufig die Situation, dass sich ein Kunde schon sehr gute Gedanken darüber gemacht hat, was er haben will und vielleicht sogar schon eine Spezifikation geschrieben hat. Dann geht es aber an die Entwicklung und moderne Softwareentwicklung ist ganz stark von Priorisierung getrieben. Von Wertbetrachtungen und der Frage, wann was gemacht wird. Zum Beispiel welche Features sofort gebraucht werden, da an der Stelle ein großer Mangel im Unternehmen besteht, und welche später kommen können. Das sind Entscheidungen, die ein Mensch mit entsprechender Vollmacht treffen oder herbeiführen muss, denn manchmal gibt es auch noch andere Gremien, die letztendlich entscheiden und da ist einer dabei, der das Ganze vorantreiben muss. Aus meiner Erfahrung ist das häufig ein Problem. Man hat einen Ansprechpartner, der zwar sehr gut Bescheid weiß, aber in einer Situation, in der er entscheiden muss, was aus dem Lastenheft angefangen wird, nicht entscheidet. Es ist auch häufig eine kulturelle Sache. Man muss jemandem, der beim Kunden diese Aufgabe übernimmt, auch den Mut geben es zu tun: Du musst es einfach tun und du darfst es auch tun! Und wir hatten das Thema eben auch: Ist es sinnvoll, dass einer von uns von INNOQ diese Product-Owner-Rolle übernimmt und da würde ich sagen, das ist keine gute Idee, weil uns da an vielen Stellen ganz klar etwas fehlt. Uns fehlt die Vernetzung in Unternehmen, uns fehlt sicherlich häufig das Know-How, aber wirklich diese Rolle anzunehmen und zu leben und einem Product-Owner beim Kunden oder einem Menschen, der diese Rolle übernehmen soll, klarzumachen, was da eigentlich dranhängt, da denke ich haben wir eine ganz wichtige Aufgabe gerade am Projektanfang.
Lucas Dohmen: Wir als Externer haben ja nicht die Möglichkeit den Kunden zu empowern, dafür fehlt uns die Macht, aber du sagst, es ist eher ein Ermutigen und Treiben in die Richtung?
Jan Körnich: Genau. Ich glaube, wie gesagt, diese modernen Softwareentwicklungs-Methoden beruhen wirklich darauf, dass Rollen selbstständig Entscheidungen treffen. Und gerade bei Unternehmen, die mit diesen Methoden anfangen, muss das erst gelernt werden. Besonders in dieser Rolle ist es sehr, sehr hilfreich, wenn jemand von außen das dann wirklich nochmal klarmacht. Sowohl demjenigen, der diese Rolle übernehmen soll, auch zum Beispiel dem Management.
Lucas Dohmen: Ist das dann auch vielleicht etwas, wo ihr auftretet und sagt: Unserer Erfahrung nach kann das gar nicht funktionieren ohne Empowerment. Und deswegen eine Organisationsveränderung herbeiführt? Oder wie muss ich mir das vorstellen?
Jessica Strobach-Möckel: Wir würden halt gucken, wie es aktuell um diesen Product-Owner, der da ist, bestellt ist und wenn wir merken, dass der kein Empowerment hat, dann würden wir schon den Finger in die Wunde legen und aufzeigen, was das bedeutet. Im besten Fall ist es ja so, dass er viel langsamer ist, wenn er jede Entscheidung in irgendwelchen Gremien, die nur alle paar Monate stattfinden, absegnen lassen muss. Das passt ja mit der agilen Arbeitsweise nicht zusammen, wenn ich alle zwei Wochen meinen Sprint priorisieren will und vorwärts kommen will. Da kollidieren dann zwei Welten. Und dann muss man das eben aufzeigen - an beiden Stellen, eben einmal beim Management, damit er die Ermächtigung kriegt und dann eben auch bei der Person selbst, damit sie sich das zutraut.
Jan Körnich: Und ich denke von diesen drei Dimensionen, die wir heute besprechen, ist der kulturelle Aspekt sicherlich der schwierigste und vielleicht auch der für einen Kunden am schwierigsten zu akzeptierende. Letztendlich ist das aber fast der entscheidende Punkt. Gerade wenn du auch effizient entwickeln willst, wie Jessica eben sagte - eben nicht ewig lange Entscheidungsprozesse haben willst, gerade wenn meinetwegen Termindruck besteht. Ich bin da ganz zuversichtlich, dass sich das in ganz vielen Unternehmen auch mehr und mehr durchsetzt, aber es gibt immer noch Fälle, gerade wenn Unternehmen damit anfangen, in denen das eben der Knackpunkt ist.
Lucas Dohmen: So eine Kultur besteht ja auch schon sehr lange. Da ist es schwer, sich davon zu lösen.
Jan Körnich: Das sind dann ebenfalls Sachen, bei denen wir unterstützen müssen, das kann keine Revolution sein. Ein “Hurra, wir haben jetzt einen Product-Owner und der macht alles und braucht auch irgendwie das Management nicht mehr zu fragen” wird nicht funktionieren. Aber auch da gibt es Wege und Methoden so etwas sukzessive zu machen. In dem Fall müssen wir tatsächlich auch auf unsere Kultur gucken, wir kommen ja mit unseren Entwicklungsteams auch mit einer gewissen Kultur zum Kunden. Und auch das muss moderiert werden. Wir sind, glaube ich, schon ein sehr selbst organisiert und agil arbeitendes Unternehmen. Wenn wir dann zu einem Kunden kommen, die das auch machen möchten, aber da noch nicht so richtig angefangen haben - das wird unmoderiert nicht funktionieren. Da sehen wir, die “P-Rollen” von INNOQ, einen ganz großen Mehrwert, den wir beim Projektstart leisten können und eigentlich auch sollten.
Lucas Dohmen: Ist das dann auch so ein bisschen die Rolle eines agilen Coaches oder ist das etwas ganz anderes?
Jan Körnich: Ja, das geht in die Richtung. Heute ist ja unser Schwerpunkt Product-Owner, von daher fokussieren wir uns da denke ich auf diese Rolle, aber ich glaube, das kommt dann auch in Folge-Podcasts zum Thema durchaus vor, dass wir da auch andere Ecken haben, wo wir die “P-Rollen”-Kollegen von INNOQ unterstützen können.
Lucas Dohmen: Gut, dann würde ich sagen, das nächste Thema ist die Verfügbarkeit: Was müssen wir uns darunter vorstellen?
Jessica Strobach-Möckel: Die Projekte, die ich in meiner Zeit beim Projektmanagement erlebt habe, hatten an der Stelle Verfügbarkeit fast alle ein Problem. Es ist nicht so, dass es in den Unternehmen keinen gab, der fachlich Ahnung hatte von dem, worum es geht. Es war eher so, dass es sich auf wenige Köpfe verteilt hat. Und es gibt nicht nur ein Projekt, das gleichzeitig gestartet wird, sodass sich oftmals die Fachexperten, aus denen in der agilen Welt oft die Product-Owner werden, verteilen mussten und das widerspricht ein bisschen dem Idealbild. Denn der Product-Owner soll ja nah am Team sein, immer verfügbar für Rückfragen und an allen agilen Events entsprechend teilnehmen und das beißt sich meiner Erfahrung nach ganz oft. Ich denke auch nicht, dass es immer klappt, dass man diese komplett frei macht, gerade wenn es wenige Leute gibt, die da Ahnung von haben. Das wäre natürlich ideal und es wäre vermutlich auch das erste, das man fragt. Aber wenn das eben nicht klappt, dann kann jemand mit einer solchen “P-Rolle” von INNOQ durchaus unterstützen und zum Beispiel einfaches Requirement-Engineering machen, sich das Wissen gebündelt in Block-Terminen bei dieser Person holen und sich dann hinsetzen und beispielsweise die Stories schreiben, sodass der den Rücken frei bekommt. Das wäre dann ja wirklich fast schon Business-Analysten-Tätigkeit und wenn man da einmal drin ist, dann kann man vielleicht die eine oder andere Sache dem Entwicklungsteam schon ohne Rückfragen beantworten und so diese Brücke schlagen.
Lucas Dohmen: Also so ein bisschen als Bindeglied zwischen dem Scrum-Team und dem Fachbereich?
Jessica Strobach-Möckel: Genau, so würde ich es sehen an der Stelle.
Jan Körnich: Ja und ich glaube das Verfügbarkeitsthema ist eben auch das, was uns in früheren Projekten häufig begegnet ist. Dass der PO, so gut er in den Domänen und auch in den Anforderungen Bescheid wusste, eben nicht da ist. Der Effekt ist: Das Team organisiert sich dann halt selbst. Das ist auch gut und richtig so. Du willst ja nicht herumsitzen und warten, bis der PO mal wieder zu Besuch kommt. Eine Organisation kann sich aber halt nicht so schnell ändern. Du fängst ein neues Projekt an und es ist so, wie Jessica sagt: Die POs, die dann nominiert werden, die haben noch andere Jobs. Die werden in den seltensten Fällen nur für dieses neue Projekt freigestellt, die betreuen das so nebenbei. Das funktioniert aber eben auch nicht. Nichtsdestotrotz wollen die Firmen ja schnell mit ihren Themen vorankommen. Da können wir also natürlich, genauso wie Jessica das beschrieben hat, wirklich helfen. Das ist dann eigentlich eine eingeschränkte PO-Rolle. Da ist vielleicht schon eine Spezifikation vorgegeben, wo ganz viel drinsteht, wo gewisse Punkte aber noch interpretiert bzw. weiter ausgearbeitet werden müssen. Was vielleicht kein ganz so tiefes Domänen-Know-How erfordert, sondern das, was sich ein Interims-PO - würde ich ihn mal nennen - auch relativ schnell erarbeiten kann. Entweder kann dieser PO, der dann extern wäre, auch kleine Sachen selbst entscheiden oder er hat eben größere Themen, die er schneller vorantreiben kann, wo er vielleicht den PO suchen muss, wo der sich gerade versteckt. Aber damit ist eben das Team entlastet, was wiederum andere Aufgaben hat.
Lucas Dohmen: Aber trotzdem ist es ja so, wenn man einen externen PO hat, der sehr viel verfügbar ist, aber ein geringeres Empowerment hat, weil er ja auch extern ist, dann wird der ja nicht alle Rollen einnehmen können. Er wird ja nicht priorisieren können an manchen Stellen, weil ihm da Empowerment fehlt, oder?
Jan Körnich: Genau. Aber das sind halt wieder so Reifestufen, die es eigentlich in allen Jobs gibt. Es gibt Sachen, wie zum Beispiel einfaches Fehler-Handling, wo sich ein Entwicklungsteam vielleicht unsicher ist. Das kann sich ein externer PO relativ schnell zutrauen und sagen: Hier, mach das einfach so. Wenn es jetzt darum geht, wirklich eine strategische Entscheidung zu treffen wie “Navigieren wir jetzt nicht von Seite A nach Seite B, sondern wir navigieren jetzt direkt nach Seite Z”, die ja auch End-User-Auswirkungen hat, dann muss man natürlich auch wissen, wer das sinnvoll entscheiden kann. Das haben wir im Team mit unserer Erfahrung auch eigentlich ganz gut drauf, zu wissen: Wo können wir selbst entscheiden und wo müssen wir den Kunden auf jeden Fall noch einbinden? Und das kann man, glaube ich, auch mit dem Kunden besprechen bzw. vereinbaren. Bis zu welchem Punkt entscheidet der externe PO? Man muss dann auch vereinbaren, wie man sich als Unterstützungs-PO mit dem Kunden-PO abgleicht. Die Verfügbarkeit muss der Kunden-PO dann auf jeden Fall haben. Dass er sich mit dem Kollegen von INNOQ, der ihn unterstützt, regelmäßig abgleicht.
Jessica Strobach-Möckel: Das ist aber meiner Erfahrung nach auch gar nicht das Problem. Und wenn man dann definiert hat, bis wohin man selbst entscheiden darf und ab wann vielleicht nicht mehr - es sei denn man hat es einfach im Gefühl - dann kann man ja einfach mit der Entscheidungsvorlage auf den PO zugehen und wenn dieser grundsätzlich für Fragen verfügbar ist, dann geht das auch relativ schnell, da sehe ich kein Problem.
Lucas Dohmen: Das heißt, man baut so eine Entscheidungsvorlage, damit der Prozess der Entscheidung einfach weniger Zeit kostet?
Jessica Strobach-Möckel: Ja. Ich denke das Team oder die “P-Rolle” von INNOQ, die haben dann schon die Idee, wie es am besten gehen könnte und wenn man die Vor- und Nachteile aufzeigt, dann tut sich der Product-Owner auch leichter, das zu entscheiden.
Lucas Dohmen: Okay und als letzten Teil hattet ihr die Skills identifiziert, was kann ich mir darunter vorstellen, das ist ja ein sehr breiter Begriff?
Jan Körnich: Da könnten wir jetzt ganz detailliert werden. Ich glaube wichtig ist nochmal die Differenzierung in Domänen-Wissen und methodisches Wissen; Domänen-Wissen muss wirklich beim Kunden liegen. Natürlich können wir uns das auch erarbeiten, ich bin in meinem jetzigen Projekt inzwischen auch drei Jahre beim gleichen Kunden, ich habe da jetzt natürlich auch Domänen-Wissen. Aber am Anfang eines Projektes steht glaube ich außer Frage, dass der Kunde das Domänen-Wissen hat und mit bereitstellen muss. Es gibt vielleicht so ein paar Themen, wo INNOQ sagen könnte “Das haben wir genauso gut wie der Kunde”, aber wenn wir jetzt zum Beispiel in einen produzierenden Betrieb gehen, da wird es glaube ich knapp. Ein IT-Unternehmen wäre vielleicht etwas anderes. Was wir da natürlich mitbringen sind methodische Sachen. Wie schreibt man eine User-Story, zum Beispiel. Wie strukturiert man ein Backlog? Wie teilt man Anforderungen nochmal so auf, dass das Entwicklungs-Team sie priorisiert nach und nach entwickeln kann, sodass Schritt für Schritt ein neues Produkt entsteht?
Jessica Strobach-Möckel: Genau, das geht ja dann auch in die Events im agilen Prozess ein. Wie können wir die effektiv gestalten? Gerade bei den Kunden, die noch nicht soviel Erfahrung haben, sehen wir ja von außen viel schneller, wo es vielleicht noch hapert oder was man vielleicht noch effizienter gestalten kann. Und bei den Stories, da stimme ich Jan zu, da gibt es oft noch Aufholbedarf. Wo derjenige früher im Wasserfall-Prinzip tolle Konzepte geschrieben hat, aber heute noch nicht genau weiß, worauf es in einer User-Story ankommt. Da können wir dann genau ansetzen und helfen und haben methodisch auch einen immensen Wissenstransfer.
Lucas Dohmen: Das heißt also dem Kunden-PO dies beizubringen, aber ihn auch dabei zu unterstützen, es zu machen, falls gerade Zeit fehlt.
Jessica Strobach-Möckel: Je nachdem, wie das Projekt aufgestellt ist, genau. Beides möglich.
Jan Körnich: Ich glaube beim Methodischen ist jetzt auch der Moment gekommen, um ein bisschen zu teasern auf einen unserer geplanten Folge-Podcasts, wo wir vielleicht nochmal ein bisschen detaillierter sehen, wie wir Projekte oder Produktentwicklung sonst noch unterstützen können. Heute haben wir sehr auf den Product-Owner geguckt, das betrifft aber natürlich auch Arbeit in den Entwicklungsteams, die Situation haben wir ja auch, dass wir mit Kunden-Entwicklungsteams zusammen arbeiten. Manchmal sind das so Konstellationen: Ein Team von INNOQ, eins vom Kunden oder ein gemischtes Team - also INNOQ-Mitarbeiter plus Kunden-Mitarbeiter - und da muss ja auch etwas passieren, damit das Team vernünftig arbeitet. Wir haben überlegt, es gibt so eine Rolle des Product-Facilitators, das ist Work in Progress, vielleicht kommt das noch anders. Aber das ist jemand, der in verschiedenen Versionen Produkt- und Projektentwicklung unterstützt, wenn es Lücken beim Kunden gibt. Schön ist natürlich, wenn man die Lücke gleich kennt, aber wir haben immer wieder die Erfahrung gemacht, dass Lücken da sind, die jemand von uns unterstützen muss und eigentlich finden wir das nicht gut, dass das Entwicklungsteam, das Software entwickeln soll, das Architekturen bauen soll, diese Aufgaben dann übernimmt.
Lucas Dohmen: Also es geht auch darum, das Team von diesen Aufgaben zu befreien, die sonst immer in das Team reinlaufen würden?
Jan Körnich: Genau. Das Team soll seine Arbeitszeiten natürlich möglichst effektiv verwenden. Das kann es nicht, wenn es auf einmal an Grenzen stößt und dann eigentlich häufig auch ohne große Begeisterung, aber weil es halt notwendig ist, diese Aufgaben übernimmt und löst.
Lucas Dohmen: Nochmal ganz kurz zu den methodischen Skills. Mit meinem Laien-Verständnis vom agilen Prozess ist das ja eigentlich eine der Aufgaben des Scrum-Masters: Methodisch zu unterstützen. Habe ich das vielleicht falsch verstanden oder ist das irgendwie eine Grauzone, wo die beiden Rollen ein bisschen ineinander über fließen?
Jan Körnich: Ich sage jetzt etwas Böses: Ich habe noch nie einen Scrum-Master getroffen, der in Bezug auf Product-Ownership methodisch gut unterstützen konnte. Die gibt es bestimmt auch, aber ich glaube die sind dann eher spezialisiert auf diese Rolle. Der Scrum-Master ist ja tatsächlich sehr für diese organisatorischen Dinge zuständig, auch die Scrum-Events zum Beispiel. In der Theorie weiß der natürlich auch, was ein Product-Owner macht, aber ich habe da noch keinen gefunden, wo ich gesagt hätte, dass der das besonders gut kann. Das liegt auch einfach daran, dass viele Kollegen, die jetzt Product-Owner sind, eigentlich einen Background als - der Begriff fiel heute auch schon - Business-Analyst haben. Und das ist auch ein eigener Skill. Von daher kenne ich viel eher Leute im Bereich Product-Ownership, die coachen, die aus diesem Bereich kommen. Von daher kann es sein, dass das ein Scrum-Master macht, aber ich kenne da nicht soviele.
Jessica Strobach-Möckel: Wie Jan schon sagt: Der Scrum-Master ist ja auf der Moderationsebene unterwegs, um die Hindernisse für das Team aus dem Weg zu räumen, aber wenn es um die methodischen Themen beim Product-Owner geht, sind wir eben im Anforderungs-Managment, im Requirements-Engineering und an der Stelle gerät der Scrum-Master denke ich an seine Grenzen, weil das ja eigentlich auch gar nicht seine Rolle ist: Dem Product-Owner zu erzählen, wie man Stories schreibt.
Jan Körnich: Um es nochmal zuzuspitzen: Der Scrum-Master sagt dem Team ja auch nicht, wie es entwickeln soll. Das ist eigentlich genau das gleiche. Eigentlich ist es an der Stelle auch gegenüber der Rolle des Scrum-Masters nicht fair zu erwarten, dass er die Stories schreibt, außer dass er vielleicht sagt “Du musst jetzt einen Backlog aufbauen”. Dass er denen dann auch noch im Detail erklären kann “Wenn du das machst, dann ist die Story besonders gut und wenn du ein Epic hast, kannst du das so oder so schneiden”, das ist glaube ich nicht der Schwerpunkt der Scrum-Master-Aufgabe. Der hat eine Idee davon, aber geht nicht so in die Tiefe.
Jessica Strobach-Möckel: Und der hat ja auch gar nicht das Domänen-Wissen - selbst wenn eine Story die Elemente hat, die sie grundsätzlich braucht - er könnte gar nicht beurteilen, ob sie gut ist. Würde ich behaupten. Ob das fachlich und vom Prozess her passt. Im Requirements-Engineering übernehme ich ja auch nicht die Anforderungen eins zu eins, sondern ich hinterfrage sie und schaue mir den Prozess und die Use-Cases an und schaue: Wie ordnet es sich ein? Um dann zu gucken: Was ist die beste Lösung? Das kann man einfach von einem Scrum-Master nicht erwarten. Aber der Product-Owner braucht oft an der Stelle Coaching.
Jan Körnich: Ich denke, dass sich bei den Skills das Domänen-Wissen und das Methodische treffen. Das ist eben auch nicht scharf zu trennen. Du kannst natürlich methodisch etwas erzählen, aber das kann für die Domänen vollkommener Unsinn sein. Jemand, der da berät, muss sich schon auch mit beiden Sachen ein bisschen beschäftigen.
Lucas Dohmen: Okay! Dann danke ich euch erst einmal. Haben wir noch irgendwas vergessen, das noch erwähnt werden sollte?
Jan Körnich: Ich weise nochmal auf unsere Folge-Podcasts hin, die dann hoffentlich so in den nächsten Wochen und Monaten kommen. Wir bei INNOQ entwickeln gerade so ein paar Bausteine, wie man so einen Projektaufsatz gut gestalten kann, da werden wir noch einen Podcast demnächst drüber machen und dann werden wir noch einen Podcast über diesen ominösen Product-Facilitator machen.
Lucas Dohmen: Ich bin gespannt und werde euch auf jeden Fall nerven, bis es passiert.
Jessica Strobach-Möckel: Sehr gerne.
Lucas Dohmen: Vielen Dank den Zuhörern und Zuhörerinnen und bis zum nächsten Mal!
Jan Körnich: Tschüss!
Jessica Strobach-Möckel: Ciao!