#28 - Erfolgreiche agile Transformation führt über Product Owner mit Carsten Rausch

Erfolgreiche agile Transformation führt über Product Owner mit Carsten Rausch

00:00:04: Und der andere Punkt ist vielleicht, dass ich Agilität, die kann ich irgendwie Bolzplatz oder Champions League spielen. Das funktioniert beides und es macht beides Spaß.

00:00:15: Carsten Rausch ist Business Coach für agiles Arbeiten bei einem der Top fünf Pharmakonzerne. Im Podcast sprechen wir über die Rolle des Product Owners für den Erfolg der agilen Transformation. Carsten, herzlich willkommen!

00:00:28: Ja, vielen Dank für die Einladung.

00:00:29: Du hast ja eine interessante Erfahrung gemacht und Hypothese mitgebracht. Und als Du mir das gesagt hast, dachte ich mir, das ist unbedingt eine Folge für den DNO Podcast wert. Und zwar, dass nämlich am Ende die erfolgreiche agile Transformation über Product Owner führt. Erzähl doch mal, wie kamst du zu dieser Einsicht? Und was bedeutet das für dich?

00:00:53: Ja, also erstmal sind es Erfahrungen, die ich mache, die kommen natürlich auch aus einem größeren Unternehmen, wo das - vielleicht können wir da nachher noch kurz drauf eingehen - wo das einfach auch den Umständen geschuldet ist. Aber bevor wir da hingehen, ist, glaube ich, wichtig festzustellen, dass die Transformation ist ja kein Spaß, es ist ja nichts, was wir machen, weil wir gerade Lust drauf haben. Wir machen ja auch nicht die Transformation um der Transformation willen, sondern wir wollen ja irgendwas erreichen. Irgendwas ist passiert. Draußen hat sich was verändert in der Welt, im Wettbewerb, beim Kunden, vielleicht auch bei uns intern. Aber so wie wir gerade arbeiten, sind wir halt nicht mehr so erfolgreich oder so zielführend. Und da kommen wir schon so ein bisschen in die Richtung, in die deine Frage geht. Wenn du agile Coaches hast, dann sind die ja häufig Menschen, die so überzeugt sind auch von dem agilen Arbeiten - und ich bin selber agiler Coach, deswegen bin ich auch sehr überzeugt vom agilen Arbeiten - die das aber dann eben auch häufig nach vorne stellen und sagen das ist der Grund, warum wir das Ganze machen. Während die POs Leute sind, die immer das Ziel, den Kunden, den Value im Kopf haben und in die Richtung arbeiten wollen. Deswegen glaube ich, dass es in großen Unternehmen und darauf würde ich mich jetzt auch vor allen Dingen erstmal beziehen, in größeren Unternehmen der erste Schritt sein muss, gute POs zu haben und die Rolle des POs gut zu beschreiben und auszugestalten, um eine Transformation erfolgreich machen zu können.

00:02:27: Also nicht erst mal eine Horde agiler Coaches reinführen. (lacht)

00:02:31: Genau. Ja, genau. Das ist ja genau der Punkt. Das ist ein großes Unternehmen. Und jetzt kommen alle und sagen, ja, wir müssen uns mal agil machen und agil arbeiten, was brauchen wir denn dafür? Agile Coaches. Super! Wie viel haben wir davon im Unternehmen? Keinen. Also welche Optionen haben wir jetzt? Irgendwie diese Skills und Capabilities bei HR oder diesen Abteilungen irgendwie nochmal definieren? Jobdescriptions raushauen, den ganzen Prozess starten oder ich muss irgendwelche Leute dazu verdonnern, es zu tun. Oder ich nehme mir halt die externen Berater von draußen. Und alles ist schlecht. Alles ist nicht gut. Warum? Weil es aus der Sicht von Unternehmensführern Overhead ist. Agile Coaches sind Overhead. Das sind Leute, die kommen jetzt. Die arbeiten eigentlich gar nicht an meinem Produkt richtig mit. Weiß gar nicht genau, was die machen. Das sind doch eigentlich so bessere Assistenten. Und warum soll ich jetzt da noch Headcount für schaffen in einer Situation, wo ich eh gerade irgendwie gucke, vielleicht in einer Krise bin oder was verändern will ja eben. Wenn ich die externen Berater nehme, dann sind die zwar da, die sind superteuer. Vor allen Dingen nehmen sie aber das ganze Wissen wieder mit, wenn sie gehen. Also das Investment lohnt sich wahrscheinlich gar nicht, wenn ich das so mache. Das heißt nicht, dass es nicht auch gut ist, mal externe Berater gerade in der Anfangsphase mit dazu zu nehmen oder als Leute, die auch so eine Situation mal spiegeln können, die einem auch beibringen können, wie man es denn eigentlich machen kann, die helfen, Erfahrungen zu sammeln. Also ich möchte das nicht schlecht reden, aber ich glaube, es ist ganz wichtig als Unternehmen, sich klar zu machen, wir wollen ja selber besser werden und müssen die Skills und Capabilities bei uns aufbauen.

00:04:14: Ich bin froh, dass du jetzt eine Lanze für die Externen brichst, sonst wäre das jetzt eine sehr kurze Episode geworden, Carsten. (lacht) Hätte ich mich schneller verabschiedet, als du angefangen hast. Aber was macht denn deiner Meinung nach einen guten Product Owner aus? Oder wie finde ich den? Wenn ich sage, okay, jetzt mal so in diesem bisschen stereotypen / vereinfachten Denken, zu sagen, naja, jemand der agiles Arbeiten nicht versteht, guckt da vielleicht drauf und denkt sich, okay, irgendwie Product Owner und Coaches... So Sachen vielleicht. Und agile Coaches sind eher Overhead. Product Owner ist ja auf jeden Fall eher eine interne Rolle. Optimalerweise auch von Anfang an. Woran mache ich das fest? Wer ist dafür geeignet?

00:04:57: Lass mal einen Schritt zurückgehen. Ich glaube, das erste, was du brauchst, ist ein Verständnis im Unternehmen dafür, dass es einen Unterschied macht, ob du von einer Position oder einer Rolle sprichst. Wir haben das für uns so beschrieben... Eine Position ist der Stuhl, auf dem du sitzt und du kannst halt immer nur auf einem Stuhl sitzen. Und eine Rolle ist der Hut, den du trägst und du kannst mehrere Hüte auch gleichzeitig tragen. Oder sie wechseln ständig. Und das ist wichtig, weil gerade in großen Unternehmen gibt es ja die Rolle oder die Position des Produktmanagers und das ist Rolle und Position in dem Fall. Und jetzt kommt plötzlich was dazu. Also, der Product Owner hat ein bisschen noch andere Skills und Capabilities, die wir brauchen. Und jetzt einfach hinzugehen und zu sagen, ja super, dann ist der Product Manager jetzt der Product Owner. Wir finden das cool, dass es da einen neuen Begriff für gibt. Und den geben wir jetzt einfach dem Menschen so mit. Ohne Weiteres. Das funktioniert nicht. Und dann hast du häufig auch die Situation, dass Experten zu Product Ownern gemacht werden.

00:05:56: Was immer so ein bisschen den Bias hat, dass die Experten ja sich schon auch als Experten halten, deswegen gar nicht unbedingt auch offen sind für neue Thesen, für Kundenbedürfnisse oder nochmal rauszugehen, ständiges Testen. Und natürlich ist der optimale Product Owner jemand, der irgendwie so eine Product Vision / Strategie entwickeln kann und die auch verinnerlichen kann. Jemand, der natürlich auch ein großes Wissen hat über Kunden und Produkt. Ja, idealerweise narrative Geschichten drum erzählen kann, kommunizieren kann, Probleme lösen kann, super zuhören kann usw... also, all diese Sachen. Das ist so die Longlist der Dinge, die ich mir wünsche. Aber ich glaube, am Ende ist es jemand, der in der Lage ist, nicht nur My Product, sondern Our Customer zu denken. Also so ein bisschen auch diese Breite hat, nicht nur zu sagen, mein Ding muss jetzt irgendwie raus, sondern immer in der Lage ist, zu sagen, okay, was ist denn mein Wertbeitrag - aber im Großen und Ganzen, im Enterprise Denken eines Unternehmens. Und das sind die Leute, die ich mir wählen würde.

00:07:17: Wie wichtig schätzt Du dabei noch ein, dass so jemand extrem gut priorisieren muss? Und priorisieren heißt ja am Ende, ich treffe eine Entscheidung, was ist jetzt wichtiger? Und Entscheidung heißt, ich scheide mich vielleicht auch erstmal von Dingen, die zwar verlockend klingen, aber wo ich sage, es sind einfach momentan nicht die Kapazitäten für da. Und das kann ja wiederum heißen, ich gehe auch mal bewusst in den Konflikt mit anderen Stakeholdern, die vielleicht andere Aspekte, die ich als geringer werthaltig einstufe für wichtiger halten, als ich das tue.

00:07:49: Also, genau alles das, was du sagst. Ja, es muss jemand sein, der Entscheidungen trifft, der ein Rückgrat hat oder die ein Rückgrat hat und zu sagen,"Ist schön, was du mir sagst, lieber Stakeholder, ich mache es aber anders." Ich habe das gehört, treffe aber jetzt eine andere Entscheidung dazu. Und das ist eigentlich spannend, weil wir da so ein bisschen auf die Basis von Ownership auch kommen. Das führt dann dazu, dass jemand auch jetzt sagt, ich übernehme eine Ownership. Was kann das Unternehmen bereitstellen, damit es passiert?

00:08:29: Und vor allem nicht dieses, ja, dieses Verwechseln. Das ist ja jetzt kein privates Eigentum, sondern ich agiere immer noch im Kontext einer Organisation, die auch ein Portfolio von Produkten hat, die eine Strategie hat. Also diesen Punkt zu treffen, zu sagen, ich mache hier nicht Wilder Westen und mache so ein bisschen, was ich will, weil das ist mein Produkt. Und auf der anderen Seite nicht hintenüber zu fallen und zu sagen, ich nehme jeden Wunsch entgegen und vermeide jeden Konflikt und schieb einfach nur durch, was an potenziellen Requirements auch überhaupt an mich herangetragen wird. Wie ist denn deine Erfahrung? Jetzt ist natürlich, wenn wir sagen jetzt so einfach ein Produkt, ja, aber ein Produkt, wenn mein Unternehmen oder ich habe ein Startup, ich habe eine Softwareplattform, dann ist es ja einfach. Ich habe ein Produkt. Aber jetzt hat ja ein Unternehmen wie Ihr, das hat ja Tausende von Produkten. Also, ich muss ja auch erstmal zu einer Definition kommen, was sehen wir denn überhaupt als ein Produkt an, wenn wir infolgedessen überhaupt über sinnvolles Product Ownership sprechen wollen? Also wie sind da deine Erfahrungen? Da ist ja ein ungeheures Kontinuum im Sinne von "ich werde sehr kleinteilig" bis hin zu "ich werde vielleicht wieder so globalgalaktisch", dass ich eigentlich eher ein Portfolio betrachte, aber nicht mehr ein wirklich gut handhabbares Produkt.

00:09:58: Ja, jetzt kann man natürlich irgendwie nach den Worten und den Theorien gehen. Ich persönlich bin da ziemlich pragmatisch und sage, also für mich ist es auch schon ein Produkt, wenn es ein Output einer Initiative ist, intern gesprochen. Weil in so einem großen Unternehmen sind ja nicht alle direkt beim Kunden, sondern fast die meisten sind ja irgendwie für interne Dinge zuständig. Und was wir uns immer wieder vor Augen halten müssen, ist A) Was braucht der Kunde da draußen? Alleine das Wort Kunde wird in so einem großen Unternehmen schon, ja, ich möchte sagen missbraucht, aber viel zu oft gebraucht. Da werden nämlich von internen Kunden gesprochen und das ist so das erste, was ich versuche den Leuten beizubringen. Intern lass uns von Klienten sprechen, extern von Kunden, damit uns immer klar ist, der Kunde braucht das und das. Dann was sind denn eigentlich die Value Streams, die wir haben als Unternehmen? Worauf zahlt es ein? Und da ist es eben wichtig, immer wieder darauf hinzuweisen, Effektivität kommt vor Effizienz. Und das ist eines der Hauptprobleme, das ich sehe, dass es eben viele Squads mit Product Ownern gibt, die vor allen Dingen ein Effizienzproblem lösen wollen. Aber wir haben eigentlich noch gar nicht genau definiert, was ist denn das Effektive?

00:11:22: Das heißt, ihr arbeitet mit dieser Begrifflichkeit sowohl - ich sage dazu gerne auch mal - an den echten Produkten, also die, die wirklich an den Kunden gehen, aber auch internen Vorhaben, wo dann, keine Ahnung, irgendein technisches System zur Verfügung gestellt wird und versucht das aber immer auf einer, ja auf einer End-to-end Denke dann zu realisieren.

00:11:46: Ja, es ist eine Rolle. Für uns ist Product Owner eine Rolle und kein Job. Also, deswegen können viele Leute auch Product Owner Rolle mit den Verantwortlichkeiten, also Rechten und Pflichten, die damit einhergehen, übernehmen, auch wenn es nur kleinere Projekte sind, auch wenn sie nur kürzer sind. Genauso wie die langen Entwicklungsprojekte, die wir haben, die teilweise über 5 bis 8 Jahre allein in der Entwicklung hängen. Diese Projekte, die brauchen ja auch einen Product Owner. Das unterscheiden wir jetzt so nicht unbedingt, und eigentlich haben wir kein Problem damit, muss ich sagen.

00:12:24: Wie stellt ihr denn sicher, dass die Product Owner dann aber auch in dieser Rolle diese Freiheiten haben, diese Entscheidungen auch zu treffen? Weil ich kann mir vorstellen, dass je nach Organisation ist ja auch eine Transformation, das heißt, da verändert sich an der Stelle ja ganz schön viel. Also, es gibt ja viele Organisationen, da hat dann der Vertrieb teilweise, die Wahrnehmung, wir sind alleine für den Kunden verantwortlich, also, alles geht über unseren Tisch. Und auf einmal fängst du vielleicht an mit Product Ownern zu hantieren, die vielleicht auch mal im Idealfall ja auch direkt den Kontakt mit dem Kunden suchen, um überhaupt zu verstehen, was ist überhaupt hier dem Kunden genau wirklich wichtig? Also sehr viele Reibungspunkte. Wie geht ihr damit um, A) dem Product Owner immer wieder den Rücken zu stärken, aber auch gleichzeitig dafür zu sorgen, weil der braucht ja auch eine starke Vernetzung mit den Stakeholdern, sonst ist er wieder auf der grünen Wiese und macht so ein bisschen, was er will. Wie stellt ihr das sicher, dass diese Rolle wirklich gut funktioniert?

00:13:26: Also nochmal zurück zu deinem Punkt, den du eben angebracht hast. So dieser Sweet Spot zwischen Autonomie und Alignment. Wenn ich nur Freiheiten gebe, dann endet das ganze im Chaos. Wenn ich nur Alignment mache, dann habe ich ein Micromanagement. Das heißt, wir müssen zuerst bei den Leadern anfangen und mit denen besprechen, was bedeutet das, Product Owner zu sein. Wir drehen die Kommunikationswege um. Also, es geht nicht mehr darum, die Product Owner einzuladen in ein Leitungsteam-Meeting und dort auf der Agenda von 10:15 bis 10:45 ihre schönen Slides präsentieren zu lassen, sondern den Leadern klar zu machen, ihr seid eingeladen im Review der Product Owner. Ihr könnt daran teilnehmen, es steht euch frei, ob ihr das wollt oder nicht. Also, solche Veränderungen sind extrem wichtig. Wir haben dann festgestellt, dass unter diesem etwas schwierigen Begriff Empowerment dann doch wieder auch sehr viel Unsicherheit entsteht, weil es vielleicht auch zu viele Freiheiten gibt. Das heißt, dieses ganze Thema Room to maneuver, positiv gesprochen Freedom to operate oder negativ gesprochen Guardrails, diese Thematik zu definieren, das ist dein Freiraum, in dem darfst du frei dich bewegen, das frühzeitig und glasklar zu kommunizieren. Das ist eine der Haupt- und wichtigsten Dinge, die wir tun müssen. Und wir versuchen das systematisch eben mit OKRs. Es gibt noch andere Zielsysteme, die wir auch haben, die so ein bisschen auch intern gebaut sind. Aber am Ende läuft es alles auf so ein ähnliches System hinaus, wo wir versuchen, es auf zwei Flight Leveln zu halten. Im Flight Level drei, also ganz oben beim Leadership Team die strategischen OKRs und dann im Flight Level eins die Product OKRs als Contribution. Wir versuchen immer das als Contribution Statement zu den strategischen OKRs zu formulieren. Das ist eigentlich dann der Gestaltungsspielraum, um ein deutsches Wort zu verwenden, den wir den den POs geben.

00:15:42: Woran würdest Du - hast jetzt auch schon man sieht es dir nicht an, aber du hast ja auch schon ein paar Jahre hinter dir in der Organisation - wo sagst Du denn vielleicht auch so, daran sieht man wirklich, dass sich was zum Guten verändert hat? Also, dass ich auch dieser Weg lohnt / auszahlt. Hast Du da so spezielle Punkte, wo Du das schon für dich heute festmachen kannst?

00:16:08: Ja, allerdings ist es nichts schnelles. Also ich glaube, den Zahn muss man jedem von vornherein ziehen, zu sagen, ja, morgen wird alles anders und alles ist besser. Das ist ein langwieriger Prozess. Zwei, drei Jahre ist, so glaube ich, eine gute Zeit, die man braucht. Es wird, glaube ich, schon relativ schnell haben die Leute einen Rhythmus gefunden. Also, so dieses wieder resozialisieren in die Kindheit und wieder experimentieren und lernen zu dürfen, das ist relativ schnell wieder da. Das kriegst du schnell wieder hin in den Köpfen. Und dann fängt eigentlich so der Spaß an, weil es macht nämlich echt Spaß, wenn man so als Product Owner arbeitet und oder als Squad arbeitet. Und daraus kommt dann die Motivation und dann kommen meistens die Punkte, an denen dann dieses hochmotivierte Squad und der hochmotivierte Product Owner oder Product Ownerin an ihre Grenzen stoßen in so einem Unternehmen. Und da braucht es dann einfach frühzeitig Menschen, die darauf achten und diese Hürden aus dem Weg räumen und die sich dessen bewusst sind. Und das braucht einfach ein Leitungsteam, das da dahinter steht und sagt ja, wir wissen, das dauert ein bisschen und wenn es eskaliert, wir kümmern uns dann drum.

00:17:40: Oder Agile Coaches.

00:17:41: Oder auch agile Coaches dann, genau ja. Und woran stellt man es dann am Ende fest? Wenn du so als Leader... Also, ich versuche es mal so um den Product Owner rum zu gestalten, also die Squad selber, die mit einem Product Owner arbeitet oder Product Ownerin, die einfach motiviert ist, die sind selber voll dabei und die sagen auch, hey, das macht Spaß und das ist zielführend und wir kommen da hin. Die Leader stellen es meistens fest, wenn eben sie plötzlich diese Einladungen bekommen zu den Reviews, wenn sie merken, hey, ich kann die laufen lassen. Die haben inzwischen mehr Informationen bei sich gesammelt, als ich als Leader und Experte jemals vorher hatte. Und deswegen ist es besser, ich lasse denen die Entscheidung, weil die haben einfach mehr Informationen, die können bessere Entscheidungen treffen und dann anfange, mich um andere Dinge zu kümmern. Also, wenn die Leader merken, oh, ich kann mich ja plötzlich um andere Dinge kümmern, dann merkst du okay, jetzt ist was da. Und dann kommt natürlich der endgültige, der wirklich relevante Punkt dazu. Sind die Kunden zufrieden mit dem, was da kommt? Und wir messen das mit NET Promoter Scores und und allen möglichen anderen Tools recht breit und recht viel. Das heißt, wir haben auch recht regelmäßig da einen Feedback-Mechanismus.

00:19:05: Ich würde gerne mal auf einen Aspekt gehen, weil wir eben nochmal den Leader angesprochen hast. Der Leader definiert sich ja aus einer Position heraus.

00:19:15: Okay?

00:19:16: Für dich? Können wir das so sagen?

00:19:17: Nee, weiß ich nicht. Ich finde eben, wenn du die Rolle als Coach nimmst oder die Rolle Product Wwner, das sind für mich auch Leader. Das sind sie aber aus einer Rolle heraus, nicht aus einer Position.

00:19:29: Ja. Ihr habt gewisse Positionen nach wie vor in der Firma? Und wenn ich das jetzt mal auf diese eine Situation beziehe, die du eben gerade skizziert hast. Der Product Owner ist im Lead, der hat eine hohen Entscheidungsautonomie, ist aber am Ende dann auch verantwortlich dafür, dass beim Kunden auch wirklich Wert ankommt und beim Unternehmen auch was hängenbleibt. Und die Leader, ja, gehen eigentlich in eine Review, um sich dann auch über den Fortschritt zu informieren. Das heißt ja, - und da würde mich deine Erfahrung interessieren - es braucht nicht nur Transformationsarbeit auf Ebene des Product Owners, das hast Du ja eben schon so ein bisschen skizziert, also diese Entdeckerfreude, vielleicht aber auch den Mut, mal Entscheidungen zu treffen, die Bereitschaft zu haben, hey, ich kann auch mal daneben liegen. Aber es ist nicht schlimm, das passen wir halt wieder an. Aber wieviel Arbeit braucht das auf Leuten, die eher aus einer Position herauskommen und vielleicht auch da in den letzten 20 Jahren stark sozialisiert sind, dass auf einmal gewisse Dinge nicht mehr in ihrem Entscheidungsbereich liegen. Also, wieviel Arbeit braucht es mit diesen Stakeholdern, dass diese Transformation ja auch auf der Ebene stattfindet? Weil ich kann ja nicht nur Product Owner einführen und kann das ganze Drumherum komplett ignorieren.

00:20:53: Also, wenn ich pragmatisch sage... Product Owner, den schicke ich irgendwie drei, vier Tage auf einen Product Owner Kurs, dann ist die Theorie da und dann soll er irgendwie "see one, do one, teach one" so mal einfach Erfahrungen sammeln. Wenn das der Aufwand für den Product Owner ist, dann habe ich bei einem Leader vielleicht 10 bis 20 mal so viel Aufwand. Und das sieht man auch an der Anzahl der Programme, die wir führen, um Leadern zu erklären, was es denn bedeutet, ein Leader in einer Organisation, in einer agilen Organisation zu sein. Das ist nicht trivial. Das sind ja Leute, die sozialisiert worden sind in einer gewissen Art und Weise erfolgreich sind ja auch wie sie dahin gekommen sind und jetzt das zu verändern, das ist nicht so trivial. Und das ist auch nicht so einfach, einen Product Owner zu führen. Also, wo höre ich denn da auf und wo fange ich wieder an? Als Leader ist es ja auch so, du brauchst eine gewisse Art von Informationen als Leader, weil du wirst ja auch noch Entscheidungen treffen. Du willst jetzt aber nicht ständig hingehen und nachfragen, weil das ist ja schon wieder Micromanagement. Ja, also dieses Dilemma, in dem du plötzlich steckst, das ist super schwierig.

00:22:14: Weil das hört ja auch nie auf. (lacht)

00:22:16: Es hört nie auf und es ist immer falsch, egal was du, wie du es machst und was du machst. Ja, und es gibt da keinen goldenen Weg, glaube ich. Aber einfach sich damit zu beschäftigen und auch da als Leader in diesen Lernmodus reinzugehen.

00:22:33: Ich hatte letztens ein ähnliches Gespräch, da ging es tatsächlich auch darum, wo greife ich ein, also wo weiß ich vielleicht schon, möglicherweise aufgrund meiner Erfahrung, hey den Weg, den wir gerade einschlagen, ich würde sagen, ich würde es anders machen. Und wie weit lasse ich das laufen? Jetzt sind natürlich, da sind wir natürlich so in einem agilen Prozess drin. Wenn ich in einem Zwei-Wochen-Zyklus arbeite, kann ich sagen, komm, lass ihn die Erfahrung selber machen. Wenn ich aber eher auf so einer strategischen OKR Ebene bin und denke mir, drei Monate dauert das jetzt, bis der Product Owner und seine Squad diese Erfahrung gemacht haben. Das ist schwierig. Da gibt es wahrscheinlich auch keine pauschal gute Antwort drauf.

00:23:18: Nee, glaube ich auch nicht. Also, ich glaube das eine ist eben, diese Sprints sind ja auch eine Methode, sich das Leadership und die ständigen neuen Ideen des Leadership mal vom Hals zu halten, zumindest für einen gewissen Zeitraum. Das ist auch ein Schutz für die Entwickler oder die Leute, die in diesen Squads arbeiten. Dann kommt aber der Review und ich glaube, das ist der entscheidende Punkt. Und da kommt es eben darauf an, dass die Leader, die eben aus ihrer Erfahrung sagen, glaub nicht, dass das so funktioniert, das in der richtigen Art und Weise adressieren in den Reviews und was sie immer noch als Tool haben, ist dieses Room to Maneuver. Sie können, sobald sie merken, mein Room to Maneuver ist überschritten, dann müssen sie eingreifen. Das ist wichtig, das zu tun und das nicht einfach laufen zu lassen. Also, das würde ich schon erwarten, ja.

00:24:07: Was sind denn in diesem Gesamtprozess... Jetzt hast du eben schon sehr interessanterweise gesagt, der Aufwand, jemanden, der immer noch eher aus einer Position heraus auf die Organisation kommt, ist um ein 10 bis 20 mal höher als denjenigen zu schulen oder denjenigen fit darin zu machen, zu sagen, hey, du denkst und arbeitest jetzt hier in der Rolle eines Product Owners, aber was sind sonst noch vielleicht Hürden? Dinge, auf die ich achten muss. Du sagtest eben schon, hey, es dauert zwei, drei Jahre. Das ist kein Quick Win. Wo sind so die größten Blocker, wo du sagst, okay, da hätte ich vielleicht auch vorher gar nicht mit gerechnet. Das ist ein dickes Brett, das wir hier bohren.

00:24:46: Ich glaube, das aller, aller größte Hindernis ist das Incentive System, also die Belohnungen, die du bekommst. Wenn du also in einer Firma arbeitest, in der du anhand der Anzahl deiner Mitarbeiter auch deine Gehaltsstufe definiert wird. Dann hast du kein Interesse daran, auch zu sagen, hey, ich erweitere einfach so meine Skills Map, meine Capability Map und werd ein Product Owner, wo ich eigentlich keinen direkt führe, sondern einfach erstmal nur einer Squad vorstehe. Und andere Incentives, die dann auch noch detaillierter in dieses was ist denn ein Output, was ist ein Outcome reingehen, wenn ich dafür belohnt werde, einen Output zu kreieren, also ein Produkt aus meiner Product Supply Organisation raus durch die Tür rauszuschieben in die Märkte, es aber total egal ist, wie gut es ist, weil Service und Maintenance ist ja nicht mein Job, sondern das machen ja die anderen. Dann habe ich ein Problem für das Gesamtbild. Also, ich würde wirklich allen raten, sich das Performance und Incentive System komplett nochmal anzuschauen und sich zu überlegen, was widerspricht da jetzt eigentlich dem, was wir erreichen wollen.

00:26:11: Wenn wir da schon dabei sind, das wäre jetzt schon der erste Tipp, aber was wäre denn sonst noch? Hinweise von dir, Tipps? Wenn wir jemanden haben, der sagt Mensch, was der Carsten erzählt, der Diehl hat kluge Fragen gestellt, der Carsten hat super Input geliefert - will ich auch machen! Das wären so die ersten drei Dinge, über das Performance und Incentive Management System, von denen du sagst, das solltest du machen, wenn du Product Ownership als nennen wir es mal Führungsinstrument, aber auch als Rolle in deiner Organisation etablieren willst.

00:26:46: Ich würde gerne noch eine Sache sagen, bevor ich konkret auf die Frage antworte, weil wir das so noch nicht jetzt eben diskutiert haben. Aber es ist noch wichtig. Wenn du Product Owner etablierst, dann wirst du irgendwann automatisch dazu kommen, agile Coaches zu brauchen, weil die Product Owner diese ganze Aufgabe, also Squad Lead, Backlog, Priorisierung, Entscheidungen treffen, Stakeholder Management das geht gar nicht in einer Rolle. Und wenn du gute Product Owner hast, wenn die das merken, die kommen irgendwann an den Punkt, wo sie merken, ich kann nur noch besser werden oder so gut bleiben, wenn ich entsprechend Unterstützung habe und dann kommt der agile Coach als Rolle ins Spiel. Dann werden die das pullen. Dann kommt der Pull danach. Und dann ist es häufig ein Squad Member, dem man dann sagt, hey, kannst du das erst mal übernehmen? Und das ist natürlich das Ideal, wenn du jemanden hast, der auch als als agile Coach weiß, worum es geht, die Organisation kennt, die Produkte kennt, die Prozesse kennt und das wollte ich nur noch auch nochmal sagen, dass natürlich das Idealbild ist, ein agiles Team zu haben, inklusive agile Coach. Ich würde nur beim Product Owner anfangen. Das wollte ich noch vorwegschicken.

00:28:07: Also schon jetzt hast du eine Lanze für Berater, für Product Owner und jetzt auch noch für agile Coaches geschlagen.

00:28:12: Und für Leader eigentlich auch noch, oder?

00:28:14: Und für Leader auch noch. Die brauchen wir auch noch weiterhin.

00:28:18: Das entspricht so gar nicht meinem Naturell. (lacht) Nee, ich denke, ich würde im Kleinen immer anfangen. Also gerade in so riesen Unternehmen ist es meistens schwierig, so ein Riesending, ein riesen Fass aufzumachen. Wir hören ja viel von irgendwelchen Frameworks, die schwer in Mode sind, die dann über die gesamte Organisation gestülpt werden und wo man das Gefühl hat, man ist dann irgendwie safe, um ein kleines Wortspiel zu verwenden, wo dann aber am Ende man doch dann sieht, ja, es hat gewisse Vorteile, wie man spricht dieselbe Sprache, die Terminologie ist gleich, die Rhythmen, die man einführt in einem Unternehmen, sind die gleichen. Und ich muss gar nicht viel verändern, weil meine hierarchische Organisation funktioniert in so einem Framework ja trotzdem noch ganz gut. Aber was ich dann eben als Beiwerk habe, ist, dass eben Product Owner gar nicht mehr so selbstständig und entscheidungsfähig sind in solchen Frameworks. Und darauf muss ich achten. Und deswegen mein Tipp immer, probiert es alle erstmal im etwas Kleineren, auch wenn wir von skalierten Frameworks sprechen, versucht es nicht über die gesamte Firma, 30.000 Leute oder 50.000 Leute auszurollen, sondern probiert es erst mal in einem kleineren Bereich und lernt.

00:29:41: Sonst noch Tipps? Klein anfangen, Performance Incentive Systeme haben wir uns ja schon angeschaut...

00:29:48: Ja, also ich finde eben, sich über das Goal Setting Gedanken zu machen, auf welchen Ebenen. Für uns einfach aus der Erfahrung heraus war auch wie viel, also wir haben wirklich eine sehr, sehr gute Erfahrung damit, es absolut zu fokussieren. Also 3 bis 5 strategische OKRs und ein Quartals-OKR für das Product Team. Das ist eigentlich das, was sich für uns als wirklich machbar und gut herausgestellt hat. Also, da nicht eine wissenschaftliche Arbeit draus zu machen. Das würde ich noch empfehlen. Wir haben - und das ist ein reiner Luxus bei uns - so, ja, sechs, sieben Business Coaches, also Menschen, die sich um das Thema Business Agility kümmern. Für alle, die also quasi so ein bisschen Third Level Support sind, wo alle anrufen können, auch die agilen Coaches sich melden können und sagen können, hey, ich brauche noch ein bisschen Support oder wie komme ich denn hier weiter? Das sind sehr erfahrene Mitarbeitende, international aufgestellt. Das ist noch ein Riesenvorteil. Ich weiß nicht, ob man sich das leisten kann oder will, aber wir sehen ein riesen Mehrwert und ein riesen Impact.

00:31:10: Ja, sehr schön. Dann würde ich mich mal an ein Schleifchen wagen. Eine kurze Zusammenfassung. Also ich bin ja gestartet mit der Überlegung, der Hypothese deiner Beobachtung, dass die erfolgreiche Transformation im Allgemeinen, agile Transformation im Speziellen über Product Owner führt. Also nicht, wie oft praktiziert, über agile Coaches. Und da hast du uns auch eingangs direkt einen guten Grund dafür geliefert. Weil die Transformation ja kein Selbstzweck ist, sondern Umfelder haben sich verändert, Märkte verändern sich, ein Unternehmen braucht neue Operating Modelle, ein neues Setup, um einfach auch ein Stück weit auf veränderte Rahmenbedingungen überhaupt eingehen zu können. Ein zweiter wichtiger Punkt, was macht einen guten Product Owner aus? Also erstmal hat er überhaupt den, Du hast es genannt "Freedom to operate", "Room to maneuver". Den ist er aber auch bereit auszunutzen, ohne dabei eine Grenze zu überschreiten. Diese Grenze nennen wir dann oft auch so, was habe ich eigentlich für ein Alignment in Bezug auf die strategische Gesamtausrichtung meines Unternehmens? Alignment, aber auch die Unterscheidung - hast Du ja relativ klar gemacht - Product Owner ist eine Rolle und gleichzeitig haben wir immer noch Positionen innerhalb einer Organisation. Also, ich bin möglicherweise ein Stück weit immer auch noch Teil einer hierarchisch geführten Organisation. Und habe aber die Rolle eines Product Owners und da brauche ich ja doch eine gewisse Sensibilität auch dann dafür, wie ich damit umgehen kann. Ganz wichtiges Merkmal aber, dass ich bereit bin, auch so ein bisschen Rückgrat, Entscheidungsfreude auch mitbringe und auch mal bereit bin, überhaupt gewisse Konflikte auch mal auszuhalten. Also, wenn Wünsche an mich herangetragen werden, die ich vielleicht jetzt nicht für die werthaltigsten halte.

00:33:12: Ihr definiert ein Produkt in unterschiedlichsten Kontexten, also sowohl ein echtes Produkt, was tatsächlich an den Kunden geht, dann redet ihr auch von einem Kunden. Aber gleichzeitig auch von internen Initiativen und Vorhaben. Da sind es dann aber nicht Kunden, sondern eher die Klienten. Aber ihr beide arbeitet mit dieser Rolle. Das fand ich bemerkenswert. Sowohl, sage ich mal, an die marktorientierten Produkte als auch an intern gerichtete Initiativen und Vorhaben. Ein für mich extrem wichtiger Punkt bezogen auch auf den Aufwand und die Blocker und die Hürden, die ich eigentlich überkommen darf, ist der Aufwand der eigentlich in der Ausbildung, im Coaching, in der Begleitung von Leadern steckt, also denen immer wieder auch die Mittel mit mitzugeben und zu sagen, was heißt das eigentlich, einen Product Owner zu führen? Wo werde ich genau eingriffig / übergriffig? Wo lasse ich sie auch vielleicht mal laufen? Ein weiterer wichtiger Punkt, ihr verknüpft das mit einem Ziel, einem OKR System, zu sagen Flight Level drei, da haben wir nach wie vor unser Leadership Team eher definiert heraus aus einer Position. Also, das nennt ihr strategische OKRs. Flight Level eins sind dann die Product Owner und ihre Squads, die auf einer Dreimonatsebene ihre OKR definieren. Bemerkbar macht sich gutes Product Ownership vor allem darin, - ich habe mitgenommen - hohe Motivation. Also, es macht einfach Spaß. Um Gottes willen, ja, Spaß auf der Arbeit. Der Kunde ist zufriedener, glücklicher. Und konkrete Schritte, wenn ich mich als Unternehmen ab morgen dahin bewegen will.

00:35:10: Performance und aktuelle Zielsystem mal angucken. Also, heißt ja nichts weiter, wie intensiviere ich momentan Leute, aber auch wie führe ich eigentlich Leute? Klein anfangen, statt zu sagen, wir sind jetzt hier in der Glückseligkeit, wir machen direkt mal skaliertes was auch immer, um uns safe zu fühlen. Einen hohen Fokus herbeizuführen. Also zu sagen, nicht wir haben immer noch 37 Prioritäten, sondern da wirklich mal selber für sich in die Klausur zu gehen und zu sagen, was sind jetzt wirklich die wichtigen Businessziele? Und zu guter Letzt immernoch dann zu sagen, ja, hier ist eine Lanze für die Coaches gebrochen im Sinne von irgendwann merkt der Product Owner einfach, dass er für ein gutes Ausfüllen dieser Rolle irgendwie Begleitung braucht. Und da schließt sich dann der Kreis wiederum zu den agilen Coaches, weil auch ohne die gelingt eine solche Transformation nicht. Irgendwas vergessen, von dem du sagst, da sollten wir aber unbedingt nochmal darauf hinweisen?

00:36:15: Ja, zwei Sachen. Also, ich glaube das eine, dass die Komplexität von Leadern nochmal herausarbeiten, weil es eine Rolle und eine Position ist, ist beides. Und das den Leuten auch mal wieder bewusst zu machen, was ist Aufgabe in ihrer Rolle, was haben sie als Aufgabe in ihrer Position auch? Und das ist auch ein Dilemma, dem ich mich irgendwie oder Polaritäten, vielleicht sogar manchmal, in denen ich mich als Mensch befinden muss. Und der andere Punkt ist vielleicht, dass ich Agilität kann ich irgendwie Bolzplatz oder Champions League spielen. Also, das funktioniert beides und es macht beides Spaß irgendwie. Und es ist beides irgendwie auch cool und gut. Und deswegen ist es auch gar nicht schlimm, erst mal mit Bolzplatz anzufangen und es dann von dort weiterzuentwickeln und dann sagen, komm, jetzt mach mal die richtigen Tore, ich brauch noch einen Schiedsrichter dazu und so weiter. Und deswegen glaube ich, kann das schon gut funktionieren.

00:37:15: Schöne Metapher. Solange du einen Ball hast und dich darauf verständigst, wir spielen hier nicht mit den Händen. (lacht)

00:37:20: Das sind die Grundregeln. Aber das ist ja so witzig. Es gibt ein paar Grundregeln, genau. Und ja, eine kleine Anekdote, weil ich mache noch nebenbei diesen Fußballcoach und...

00:37:36: Für Kinder?

00:37:37: Für Kinder, genau. Ja, klar, für die Kleinen. ...Und versuch das irgendwie so auch mit meinem Coaching Alltag immer wieder abzugleichen, zusammenzubringen, das hervorragend funktioniert witzigerweise, es keinen großen Unterschied macht, ein Leadership Team zu coachen oder eine F-Jugend. Aber ich hatte die Situation erst letzte Woche beim Training. Da kam ein Vater zu mir und sagte, ja, aber warum spielen die eigentlich auf zwei Tore? Macht doch gar keinen Sinn. Ja, DFB hat dieses neue Spielform eingeführt, die ich genial finde persönlich. Da spielen die Kleinen eben auf zwei, also auf vier kleine Tore insgesamt. Und dann habe ich gesagt, na ja, weil es in diesem Kinderfußball in der Situation nicht darum geht, dass die passen, schießen, dribbeln, lernen, sondern es geht darum, dass sie wahrnehmen und entscheiden. Also ich nehme wahr, dass ein Tor vielleicht gerade besetzt ist oder da mehr andere Spieler stehen und eins ist frei. Also, das nehme ich erst mal wahr und dann entscheide ich mich ganz bewusst, etwas zu tun. Und das trainieren wir auch, das Wahrnehmen und Entscheiden trainieren wir. Nicht das Dribbeln, Schießen oder Passen, das kommt nebenbei, das kriegt man nebenbei mit. Und ich glaube, das ist beim Agilen oder bei so einer Transformation, bei so einer Veränderung, dass es auch darum geht, wahrnehmen und entscheiden zu coachen, zu trainieren und weniger das ganz konkrete methodologische Machen. Ja, wie ein Hackathon jetzt genau funktioniert oder so Sachen... Das ist whatever.

00:39:07: Und wenn wir schon bei der Reform des Kinderfußballs sind, auch viel mehr Berührungspunkte zu haben.

00:39:15: Ja, das stimmt.

00:39:16: Also ja, man reformiert das ja, damit Kinder halt nicht viele Ballkontakte haben, weil das hat Hermann Gerland ja immer so schön gesagt. Also, was glaubt man eigentlich, wer ein besserer Kicker wird? Der, der den Ball 100.000 mal annehmen musste und abspielen musste und 100.000 Entscheidungen getroffen hat, ob er ins Dribbling geht oder doch lieber spielt. Oder jemand, der es nur 10.000 mal gemacht hat. Das ist jetzt auch keine riesen Wissenschaft und im agilen Arbeiten würde ich auch sagen - um diese Metapher mal fortzuführen - ich schaffe mehr Berührungspunkte. Also, mehr mit dem, ja, auch Product Ownership, mehr mit dem, worauf es eigentlich ankommt, dem Kunden oder auch meinem internen Klienten eine Leistung bereitstellen, die ihm Wert generiert. Punkt. Und das macht Spaß. Hoffentlich.

00:40:05: Ja, und du hast das wunderschön erklärt. Und das heißt, wir machen dann irgendwann mal einen Podcast über Agilität und Fußball.

00:40:11: Sehr gut. Das klingt nach einer guten Idee. Da fangen wir jetzt direkt dran, drüber nachzudenken. Aber für heute machen wir jetzt Schluss. Vielen, vielen Dank. Bis zum nächsten Mal.

00:40:21: Ciao.