NBA39: Im Gespräch mit Martin über Agilität aus C-Level Sicht

Hallo und herzlich willkommen bei NoBullshit Agile. Mein Name ist Thomas. Ich bin Teil eines Agilenteams und bespreche jede Woche Themen aus der Agilentrojektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Man fokussnigt auf der Praxis, daher auch der Name NoBullshit Agile. In der letzten Folge habe ich über Missinterpretation und Kritik an Dora gesprochen. Wenn dich das interessiert, hör da gerne rein. Den Link dazu findest du wie immer in den Show Notes. Das hier ist die Folge 39 und heute habe ich mal wieder einen Gast, auf den ich mich sehr freue, nämlich den Martin. Bevor wir aber zu dem Gespräch kommen, was ich mit Martin geführt habe, ein bisschen Housekeeping. Wenn ihr Lust habt, am 12.11. um 19 Uhr treffen wir uns zuerst einen virtuellen Agilen User Group. Die Details dazu findest du in den Show Notes. Da habe ich eine einzelne Seite angelegt, die ein bisschen erklärt, wie das funktioniert, was die Idee dahinter ist, wie wir uns virtuell treffen und auch noch mal so ein Eikall-Event, was ihr euch runterladen könnt, um das in eurem Kalender zu importieren. So weit zur Vorrede, ich würde sagen, wir springen einfach mal in das Gespräch mit Martin. Hallo Martin, vielen Dank, dass du da bist. Vielen Dank, dass du dir Zeit genommen hast. Wir kennen uns ja, ja, in der virtuellen Welt, viel auf Mastodon gequatscht und ich freue mich, dass das geklappt hat. Hallo Thomas, ja, vielen Dank für die Einladung. Ich freue mich, dass wir jetzt auch mal so miteinander plaudern können und vielleicht auch nochmal ein, zwei interessante Sachen vielleicht besprechen können, die zu weiteren Diskussionen dann im Fettiverse oder sonst wofür führen. Ja, genau. Apropos Diskussionen, finde ich, wir beide glaube ich ganz toll. Kann auch gern konträr sein. Ich verlinke ja ein paar Sachen von deinen Profilen auch in den Show Notes und ich glaube, du freust dich auch immer auf Feedback. Das heißt, liebe Leute, wenn ihr Feedback habt, immer her damit. Absolut. Vielleicht magst du mal ein bisschen erzählen, was du so den lieblenden Tag gemacht hast oder machst, damit die Leute dich ein bisschen kennenlernen. Ja, Martin, mein Name, wie gesagt, bin im Produktbereich tätig seit über 20 Jahren, digitale Produkte, seit guten 15 Jahren, dezidiert in der Berliner Start-up Szene, also tendenziell junge Unternehmen, Venture finanziert, sehr schnell am Markt, tendenziell eher Produkt als Projektgeschäft. Ja, und habe da so alles durchlaufen und mitgemacht, was man da machen kann von Produktmanager, Produkt-Owner, Coach-Beratung bis zum Ziel-Level jetzt zum Schluss als CPO. Liebt meinen Job, mache ihn immer noch gerne und mache auch sozusagen neben mir Coaching-Beratungsarbeit sehr gerne, weil ich denke, wir müssen auch Leute, ich will nicht sagen Ausbilden, aber müssen auch sozusagen das Wissen in der Diskussion halten, A für Leute, die reinkommen in die Szene, B auch für uns, um uns zu updaten. Ja, das sozusagen das, was ich mache, wie gesagt, zuletzt CPO in einem Corporate Start-up, das zu einem großen Klinikkonzern hier in Deutschland gehört hat. Und ich spreche von Vergangenheit, weil auch DAX-Unternehmen haben hier und da mal gegen Wind und schauen, wo sie Geld sparen können. In dem Fall waren wir Teil von dem Rotstift und mussten leider unser Unternehmens schließen. Und das ist das Game, das ist leider so, wenn man in Start-ups geht, dann weiß man auch, was man sich einlässt. Aber gerade im E-Health-Gesundheitsbereich, das sind wir, ich will nicht sagen, die Deutschen sind immer hinterher, das alte Männer, Giammarnee im Prinzip, ist dann noch viel Raum für digitale Produkte, muss man jetzt neutral zu sagen. Und ich war auch der Meinung, dass wir interessante Sachen am Markt hatten, die geholfen hätten auch das Gesundheitssystem zu verbessern. Insofern tut es natürlich ein bisschen weh, wenn dann so ein Unternehmen geschlossen wird. Tut ihm weh, aber da tat es dann noch mal ein klein bisschen weh. Ja, kann ich gut verstehen. So viel vielleicht zu mir. Ja, aber ich vermute jetzt einfach mal korrigieren, ich gerne Agilität, wollen wir Agil sein, haben wir ein Umfeld, um Agil zu sein, war dann wahrscheinlich nie ein Thema. Ja, das ist eine spannende Frage, die hat sehr viele Layers grundsätzlich im E-Health-Bereich, um es mal jetzt so rum aufzuzeigen. Man ist ja sozusagen ein Medizinprodukt oder in irgendeiner Form zertifiziert, ISO zertifiziert und das hat gute Gründe. Das geht soweit, diese Zertifizierung, dass sich dann bis auf Ticket-Ebene runter sicherstellen muss, dass diese Veränderung, die im Ticket beschrieben ist, niemand sozusagen zu Schaden bringt. Ich muss quasi auf Ticket-Ebene eine Einstufung, Gefährdungseinstufung machen. Ich habe große Dokumentationspflichten vorab und nachgelagert. Nichtsdestotrotz, und das war auch für mich so ein bisschen die Motivation, den Job damals anzunehmen. Ich kam so von sehr kleinen, schnellen Kanban-Teams mit Liedheim von um da zwei Tagen. Hatte sehr viel Meinung zu dem Thema Agilität, Kanban und Scrum. Und wollte einfach auch mal in so einem Umfeld sehen, funktioniert das eigentlich, was ihr da alle so schlau ausgedacht hast? Und tatsächlich ist Agilität ein Thema. Agilität ist immer ein Thema in der Markt, wo ich sozusagen disruptiv sein muss oder disruptiver Markt, schneller Markt, der sich schnell verändert. Und was ja digitale Produkte auszeichnet, ist ja, dass der Marktzugang sehr, sehr gering ist. Das heißt, es tauchen neue Wettbewerber auf, die vielleicht sogar auch dein Produkt kopieren oder irgendwas besser machen als du, was du nicht gesehen hast. Also da reden wir immer über Agilität in irgendeiner Form. Und ich kann mir nicht vorstellen, auch bei allen Agilität ist Toddiskussion. Ich kann mal innovative Produktentwicklungen nicht vorstellen ohne irgendeine Form von Agilität. Was auch immer das dann heißen mag. Was auch immer das heißen mag, ja. Also das teile ich auf jeden Fall. Wir haben es auf Mastodon, ich habe es hier oft genug besprochen. Für mich steckt ein bisschen auch hinter der Frage. Zum einen, die ist, was uns die ganze Zeit um Ohren gehauen wird. Agilität sei Tod. Heiseartikel und je gelicher YouTube-Kanal. Schmeißt das raus? Meiner Meinung nach auch, weil das natürlich schön catchy ist. Da hast du dann dein Clickbait eingebaut. Aber ich kann es mir eben genau gut vorstellen. Gerade das, was du auch beschrieben hast, wenn man zu der Fundamentsfrage zurückkommt. Wann brauche ich Agilität? Wann will ich Agil sein? Dass es eben dann ein bisschen auch auf den Markt drauf ankommt. Also in dem Moment, genau wie du gesagt hast, zu viele Marktbegleiter, die im Zweifel fall auch Copycat sind. Da willst du schnell sein und du willst das Richtige an deinem Produkt tun. Das ist einem genau der Punkt, den ich in der Diskussion oft vermisse. Und ich war jetzt auch in den letzten zwei, drei Jahren auf verschiedene Meetups, Produktbezogene Meetups, wo ich dann halt solche Banalitäten erzähle. Also erstmal banal, aber du musst ja verstehen, was ist mein Produkt? Was ist mein Unternehmen? Sind wir jetzt sozusagen in einem hoch regulierten Markt, wie jetzt der Gesundheitsmarkt oder meinetwegen auch Banking? Bin ich im e-Commerce, wo ich auch mal was einfach live nehmen kann? Und wenn dann in der Wishlist, was nicht funktioniert, ist nichts passiert, außer vielleicht mal 10.000 Euro Umsatzverlust. So dass das eine und das andere ist, bin ich in einem Projektgeschäft. Das bedeutet was ganz anderes. Also entwickle ich Software von Kunden, der relativ wie oder weniger klare Vorstellungen hat, wie das dann aussieht oder was geliefert wird. Hin zu einer Produktentwicklung, die vielleicht bei Null anfängt, die bei Greenfield anfängt. Und das ist auch wieder was anderes, wie wenn ich jetzt in so einem Grown-Up bin. Das heißt, mein Greenfield Produkt ist jetzt in fünf Jahren komplett ausdiversifiziert. Ich bin auch 500 Mitarbeiter mit Arbeiterin gewachsen und habe natürlich eine ganz andere Blick auf das, was ich mache und eine Akilität, von welcher Ebene man das ja sehen mag. Oder halt die Praktik, wie ich arbeite. Also dieses H ist immer ein anderes oder in Nuancen anders, je nachdem. Und ich glaube, diesen Artikeln, ja okay, wollen natürlich auch erstmal was rauspusten, Clickbait und so weiter. Aber diese Nuancen, diese Zeit müssen wir uns nehmen, weil sonst entsteht kein Lerneffekt. Und ich kann viel erzählen von, ja, ich hatte eine Leathime von unter zwei Tagen. Ja, ja, klar. So, das waren die internen Kunden. Alle meine Kunden hatte ich im WhatsApp-Chat. Klar habe ich eine Leathime von unter zwei Tagen. So, kann ich das jetzt irgendwie auf dem Meetup als große Wahrheit und Sollzustand adressieren? Nein, natürlich nicht. Das funktioniert woanders nicht. Insofern würde ich mir halt in generell in der Diskussion halt mehr die Nuancen wünschen. Ja, genau. Und den Hintergrund dazu, viele Leute neigender zu zu sagen, okay, ich habe jetzt die Wahrheit oder das wäre die Wahrheit. Aber genau wie du sagst, ganz ehrlich, die Wahrheit hängt tatsächlich von viel zu vielen Faktoren ab. Und ich finde halt, es ist dann im Prinzip auch unfair zu sagen, das und das hat bei uns nicht funktioniert. Deswegen ist Agilität tot. Und was ich ja jetzt in letzter Zeit auch immer wieder sage, es gibt einfach auch genug Tätigkeiten, die brauchen keine Agilität. Wenn ich eine Routine-Tätigkeit durchführe, dann ist es overhead. Das ist so, ich habe letztens auf dem Macedon was gelesen, weiß gar nicht mehr von wem das war. Aber das Thema war ja, sorry, wir machen halt IT Support. Wir brauchen das alles nicht. Wir brauchen eine Hotline. So darum geht es. Wir brauchen Ticket System, was die Tickets gut verwaltet. Und warum sollten die auf irgendeine Art und Weise Agilität haben? Ich kenne es mir zum Beispiel in einem Scrum Sprit überhaupt nicht vorstellen. Ja, das Scrum für die Buchhaltung. Nein, bitte nicht. Ja, gut. Ich habe ja auch sozusagen systemtheoretischen Hintergrund, habe auch einen Master in Systemische Englisationen Beratung, habe ich jetzt plötzlich gemacht. Und für mich ist sozusagen jetzt aus der Sicht, aus der systemtheoretischen Sicht auch eher interessant zu fragen, was funktioniert. Also wie machen es die Leute, aus welchem Grund machen sie es und was funktioniert und was funktioniert vielleicht nicht so gut. Also diese steige Wertung von, ja, dein daily stand up geht 30 Minuten anstatt 10, Feuer über euch. Also da müssen wir halt auch vorsichtig sein. Und das ist mir halt auch sehr wichtig und vielleicht jetzt auch, wenn wir den Bogen schlagen zu einer Management Position oder auch nach See Level Position, das muss mir auch egal sein. Wie vielleicht dann in Team die Koordination vom Tagesgeschäft gemacht wird oder wie in Team geplant wird oder wie in Team auch sozusagen Fehler Suche gemacht wird oder was auch immer. Ja, das ist ein guter Punkt und tatsächlich vielleicht aus dieser Perspektive siehst du oder hast du jemals See Level, ich sage jetzt mal Management Ebene, irgendein Konflikt gesehen zwischen deinen Zielen aus See Level und den Zielen von dem Team oder Product Ownern oder Product Treibern. Kommst du da einen Konflikt, siehst du da oder hattest du da welche? Ja, das ist eine gute Frage. Ich glaube in der Produktrolle auch jetzt in der Executive oder Director oder was auch immer rollen, hast du wahrscheinlich nicht so die Konflikte mit Agilität in irgendeiner Form. Also gibt es auch jetzt natürlich, da gibt es Diskussionen um das Product Operations Model, hier was Marty Bacon sozusagen initiiert hat, was sich so was ein bisschen als Gegend Agilität verkauft wird, was ich aber gar nicht so sehe, im Gegenteil da steckt sehr viel Erbe von, also für mich ist es eine agile Form, die halt stärker im Produktfokus hat. Also ich sage mal so, für mich gab es jetzt sozusagen wenig Konflikte mit Teams wollen, Agil Abern wollen, Agil Praktik einführen, wollen Scram machen, wollen eine Lead-Time hinten ran schreien, mansticke, dann, die diesen Konflikt gab es nicht, diesen Konflikt gibt es eher sozusagen auf meiner Peer Ebene dann oder vielleicht auch ein Level drunter von Stake Holdern oder Abteilung oder wie auch immer, die das halt nicht kennen. Und da muss man auch sagen, da haben wir Agilisten einen schlechten Job gemacht, da auch irgendwie halbwegs eine klare Definition zu vertreten. Also da haben wir vielleicht keinen schlechten Job gemacht, aber da war vielleicht sozusagen zu viel Playerarbeit. Die Vorstellung, was Agilität ist, auch jetzt bei jemandem von Marketing, ich sage jetzt mal irgendwas, mag nicht das sein, was ich meine unter Agilität und das kann man den Leuten ja nicht vorwerfen, nicht sozusagen Teil von ihrer Fachexpertise. Deswegen habe ich dann immer versucht, solche Schlagwürder zu vermeiden, Agilität zu sagen, wie können wir jetzt sozusagen untereinander größtmöglichste Transparenz herstellen, sodass wir auch schnell reagieren können, wenn wir irgendwas sehen. Dann ist das eine wunderbar schöne Diskussion, die eigentlich niemand was dagegen haben kann. Also ich kann das so aus meinem Blickwinkel sagen, was wir machen, ist wir entwickeln Software und Customise Software für Kunden, nicht für uns. Und es gibt zwei Dinge, die ich erlebe und erlebt habe. Das erste, genau das, was du sagst, es ist immer besser oder zumindest hat sich es für mich bewährt, die Sprache der Kunden zu nutzen. Also nicht mit Agilem Bullshit anzufangen, sondern über Flexibilität zum Beispiel zu sprechen oder eben, wir können schnell Ergebnisse liefern und am Markt sein und Feedback bekommen. Und das zweite und das ist das, was mich einfach super stört, ist dadurch, dass es in Deutschland mittlerweile auch so weit ist, dass ich sage die Krankheit ist erstmal ganz neutral. Viele in einer Führungsunterriege beim Kunden sagen, okay, Scrum ist cool, ich bleibe jetzt einfach beim Weiß Scrum, weil es am weitesten verbreitet ist, weil, und jetzt komme ich eben die falschen Gründe, ich dann eine Messbarkeit bekomme, eine Kontrolle bekomme, sie sagen es dann nicht so. Da werden dann bei Kunden Leute durch Scrum Schulungen geschickt und die sind dann POs und wachen dann irgendwann auf, wenn sie in der Realität gelandet sind und ich denen dann sage, Mensch, Glückwunsch, dass du PO bist, dann kannst du ja schon mal anfangen, die Story zu schreiben und ich ergänze. Und dann kommt so ein, wieso soll ich denn jetzt die Story schreiben? Ist ja, naja, also der eine Sache vom PO ist ja, du hast da ein großes Domänenwissen, ich werde das sicherlich aus unserer Sicht gerne ergänzen und in meiner benordneten Tätigkeit, aber schlussendlich, das ist halt jetzt eine große Rolle. Und das Problem daran ist ganz einfach, dann sind wir wieder bei diesem Agilität ist tot und wo kommt das auf einmal her und auch bei dieser Diskussion Zahlen, Werte und Management und wenn die anfangen damit zu mischen, muss das nicht optimal sein, denn das Problem entsteht dann genau in den Momenten. Die Leute sind, die haben jetzt eine Schulung besucht, die haben jetzt einen Stempel bekommen von der Ebene über ihnen, so du bist jetzt PO Glückwunsch und wir machen jetzt Scrum, weil das ist cool, jetzt sie mal zu, aber sie bringen halt überhaupt nicht das Mindset mit und auch erst recht nicht das Verständnis dafür. Und ich meine damit nicht die Erfahrungen, die kann man natürlich in dem Moment nicht haben, aber warum mache ich das? Und das dann verkommt Agilität zum Wasserfall, nur mit einem Anstrich. Ja, da kommt vielleicht auch, da dreht sich das auch oder da schliegt sich vielleicht der Kreis und jetzt auch nicht falsch verstehen, ich bin jetzt glaube ich auch dann zehn Jahre in der Scrum Align, so nach im deutschen Dachverein und so weiter und so weiter. Ich sehe mich schon da auch Teil von, aber ich glaube sozusagen dieses Marketing auch von Scrum Align zu dieser alle heißen, die impliziert ja auch genau das. Also wenn es vielleicht nicht die Allianz ist, dann sind es vielleicht einzelne Beratungsfirmen, die halt genau das als in ihren Slydex haben als Verkaufseigument. Insofern ja nervt, wenn sozusagen das mit einer falschen Voraussetzung gestartet wird, nervt komplett, aber die Frage ist halt, müssen wir uns dann nicht auch ein bisschen an die eigene, also wir im Sinifon, wir Agilisten, müssen uns dann nicht ein bisschen an die eigene Nase fassen und diese ganze Product Operations Model Geschichte, die ich gerade erwähnt habe, die ist ja sozusagen aus dem Schmerz geboren, dass da jetzt Leute irgendeine Art von Produktarbeit machen, zumindest auf Delivery Seite oder vielleicht auch die komplette Bandbreite machen wollen oder einen Anspruch haben oder den Auftrag haben, aber halt nur so eine Scrum Basis Schulung haben und das reicht halt nicht. Und es ist auch gar nicht schlimm, wir fangen ja alle irgendwo an. Ach nix, aber im Prinzip, ich habe auch einige Schulungen schon gehalten, habe auch verschiedene Leute schon gecoached und so ein Basis-Tenor, der da immer wieder raushörbar ist, diese Erwartungen, die an mich oder die vielleicht auch ich selbst, an mich selbst als PO dann stelle, die sind irgendwie konflikter mit der Realität in irgendeiner Form. Und die haben natürlich, Leute wollen ihren Job gut machen, also 19 von 20 Leuten sagen, wollen ihren Job gut machen, die sind motiviert, die wollen, dass das irgendwie rundläuft und denen sozusagen auch diesen Schmerz rausnehmen, sagen ja okay, das ist, ah, du hast jetzt vielleicht mit Scrum ein sehr Delivery-Lastiges Werkzeug an der Hand, sage ich jetzt einfach als Wohne. Und du bist jetzt aber in einem Bereich, der jetzt vielleicht sinnvollerweise auf deinem Schreibtisch mitliegt, aber den kannst du halt nicht mit, ich weiß nicht, mit dem Stand-Up und der Retro-Lösen, sondern du musst dir halt ein strukturierten Research-Prozess überlegen, so was. Ja, genau. Und ich glaube, da muss sozusagen die Ausbildung und Ausbildung klingt immer viel, aber es sind halt auch diese kleinen Schulungen, diese zwei-Tageschulungen, die machen ja die Tür auf, die geben auch so ein bisschen Struktur vor, wo kann deine Reise hingehen, auch deine Lernreise, die muss da besser werden. Sorry, also da bin ich sehr offen für alles, aber an dem Punkt habe ich eine relativ starke Meinung, diese Schulungen, die sind oft gut gemeint, aber relativ schlecht in der Regel. Ja, genau. Ich habe halt auch noch das Problem, dieser Markt ist irgendwann überschwimmt worden, keiner kann heute das Wort Agila Coach mehr hören. Ja, und ich verstehe es auch. Es gibt so viele Modelle, so viele Unternehmen, die irgendwie in diesem Bereich sich versuchen, was aufzubauen oder was aufgebaut haben und viele Produkte da drumherum erfunden haben und Stufen auf Stufen auf Stufen erfunden haben und was ist der Eindruck, wenn man sich das anguckt, dass es alles super kompliziert. Man kann ja nur Fehler machen, wenn man jetzt in Richtung Agilität gehen will, man muss ein klares Playbook haben und dann entsteht so etwas wie Safe, wo das in das Paperwork Wahnsinn ist in meinen Augen. Nicht, dass ich da Erfahrung hätte, aber das ist mir alles viel zu kompliziert und darum geht es ja eigentlich in dem Fundament der Agilität überhaupt nicht. Ich habe meine Folge gemacht über SpaceX, weiß ich, ob du so Raumfahrt, Raumschiff, solche Sachen verfolgst und das ist sehr faszinierend. Ich mag Elon Musk halt gar nicht mehr, der verdient mir auch wirklich jeden Spaß daran, weil ich da eigentlich sehr viel Spaß dran hatte immer. Aber man sieht eben, was das Fundament von Agilität ist, nämlich Fail Fast zum Beispiel. Klar, in einer viel größeren Dimension, als man das im Unternehmen sich sonst leisten kann, aber sie kriegen so viel schneller, so viel mehr Erkenntnisse als sowas wie die NASA das jemals hätte schaffen können. Wenn du jetzt fragst, was könnte so oder wie würde ich jetzt den Kern auch von Agilität beschreiben? Jetzt auch mal unabhängig von Team Level oder von einem einzelnen Team. Das ist es halt für mich, das Unternehmen muss, also das Ziel von einem Unternehmen ist ja irgendwie am Markt zu bestehen. Und wie mache ich das, indem ich das richtige zum richtigen Zeitpunkt effektiv und effizient mache? Ich als Protokoller sage, eine radikale Kundenorientierung hat und eine Transparenz hat für Daten, sodass ich auch mitkriege, wenn sich am Markt was ändert. Weil oft ist das so, ja, da kommen Elektro-Autos und die Schneesen bauen ganz viele Elektro-Autos, aber ne, betrifft uns nicht. Das ist sozusagen, da funktioniert die interne Sensorik da nicht richtig, obwohl die Erkenntnisse im Raum ist, das sieht man sehr häufig in Unternehmen, großen wie klein. Fail Fast würde ich halt eher übersetzen, weil Fail Fast sage ich mal, okay, das ist eine sehr frühen Phase von der Produktentwicklung. Das wollte ich im Medizinbereich jetzt nicht machen. Korrekt. Würde ich übersetzen mit minimiertes Risiko so gut wie es geht, wie riecht es, minimiere ich das Risiko, indem ich kleine schnelle Arbeitspakete mache, die schnell validiere. Das ist im Prinzip Fail Fast. Würde ich jetzt halt nicht mit Devices im OP-Saal, würde ich eine andere Art von schnellem Feedback suchen. Da bin ich dankbar. Genau, das ist im Prinzip der Kerne so. Klar, die Frameworks haben einen Sinn und die geben dir sozusagen ein Handwerkzeug und sag okay, wie kannst du planen, wie kannst du sozusagen auch Brainstorming machen, wie kannst du sozusagen auch retrospectiv auf Dinge gucken, wie kannst du sicherstellen, dass du dich als Team verbessert im Prozess wie im Produkt. Okay, hier hast du ein Set an Werkzeugen, die haben in der Vergangenheit recht gut funktioniert, probiert die mal aus und abgeführt. Und wenn du sagst, hey, nach vier Monaten unser Planning ist krützer, wir machen das anders, ja, go for it und probier es aus und gibt dir einen Zeitraum, wodurch das wieder messen will, hat sich was verbessert, guckt drauf, macht es anders. Das ist für mich auch sozusagen Agilität auf Prozessebenen. Und deswegen meine ich, eigentlich ist mir egal, sozusagen aus CPO Blick, wie rum wir die Tickets am Bord hängen und ob die Montags oder mitforschen, was auch immer der T-Shirt sei, ist es draufgelehnt oder was auch immer, I don't care. Was mich aber schon interessiert ist, wie gehen die mit Fehler um, gucken die auch sozusagen auf Ausweiser, Arbein, die damit, das ist das, was mich interessiert. Also es geht immer wieder mal was schief, wie wie gehen die damit um, wird drüber gesprochen, wird verschwiegen, gibt's Report, wird mit mir gesprochen als CPO in der CPO Rolle. Das ist eigentlich das, was mich interessiert und das ist auch das, was glaube ich dann das Produkt und die Firma voran bringt. Ja, genau. Also ich kann das nur bestätigen. Ich bleibe mal ruhig bei Scrum. Ich finde den Scrum Guide halt gut, vor allen Dingen deswegen gut, weil er erstmal ein gutes Playbook ist. Und genau aus diesem Grund, ich habe eine Orientierung. Wenn ich jetzt uns angucke, wir machen kann man, wir Scrum irgendwann mal verlassen, da steht man erstmal da und guckt ja, was heißt denn den Flow optimieren. Da steht man anders da, als man sagt, okay, komm hier steht eine Rollenbeschreibung, hier steht sogar welche Rituale es gibt und wie lange die ungefähr sein sollen und so weiter und so fort. Das heißt, der Start ist einfach super und das macht Scrum definitiv gut. Aber genau diese Evolution an der Stelle, sich davon im Zweifel auch lösen, das passiert mir halt an manchen Stellen zu wenig. No size fits all. Was bringt uns diesem fundamentalen Ziel darunter oder darüber an, nämlich zum Beispiel schnell am Markt sein oder effektiv am Markt zu sein, was bringt uns näher, was führt uns davon weg und dementsprechend muss man meiner Meinung nach die Methode erweitern, anpassen oder verkürzen. So in dem Lebenszyklus, in dem man im Produkt oder im Team oder in Kombination davon gerade ist. Ich sage mal so, es gibt ja die Event- und Rollenbeschreibung und so weiter, was für mich sozusagen aber im Kern, dass immer noch prägend ist, auch für alles was ich mache und gemacht habe, ist ja eigentlich schon auch dieses Scrum Wert. Die sind sehr zentral, Focus, Commitment, Courage, Respekt, Openness. Da steckt so viel drin und aus diesen Prinzipien, wenn diese Prinzipien und kannst du auch noch andere dazuhängen oder nicht, aber mit den Prinzipien, wenn du sagst, deine Praktiken, wie du arbeitest, also das "how" sozusagen, aus diesen Prinzipien ableitest, ist mir eigentlich fast egal, wann dein Stand-up ist oder ob du haltest anders machst, obwohl ich jetzt den Daily Stand-up fast das wichtigste Ritual halte. Aber wie auch immer, was anderes auch aus den Säulen, aus den Scrum-Säulen, diese Empiresen, empirisches Framework, das ist mir auch sehr wichtig und das ist immer noch egal, ob Leute, wie das Ticket geschrieben wird, ob das eine User-Story ist oder nicht, I don't care im Prinzip, ist für mich wichtig, wird sozusagen eine Hypothese gebildet, während sozusagen zu der Hypothese Annahmen oder umgekehrt Annahmen und Hypothese wird es gebildet. So, was will ich eigentlich erreichen mit dem, was ich jetzt hier mache und auf was basiert das? Ja, es basiert darauf, dass wir annehmen, dass schwangere Frauen in Städten dessen das Verhalten haben. Okay, gut. So, dann haben wir diese Annahme, die müssen wir vielleicht auch nochmal separat validieren, aber mit den Annahmen machen wir Hypothese, bauen was und messen das hinten und definieren vielleicht auch die wichtigen Metriken dazu, auf was gucken wir, wann ist es ein Erfolg, wann ist es kein Erfolg, Erfolg ist wenn 30 Prozent draufklicken. Okay, jetzt haben wir 29 Prozent draufgeklickt. Was machen wir jetzt? Okay, nochmal eine Iteration oder zwei fahren, vielleicht kriegen wir es noch geredet. Also das ist so die, das was für mich, sage ich mal, aus Produktsicht eingespannender ist, wird das gemacht. Aber ein Team so, aber ein Team empirisch zu einem gewissen Punkt, aber in dem mit Daten haben sie auch ein Verständnis, wo es sind Lücken. Also manchmal hat man Daten, aber Daten kann auch heißen drei Leute haben im Kundenservice angerufen und waren sauer, weil was nicht funktioniert hat. Es sind auch Daten, aber es sind jetzt halt ein kleiner Datensatz, der aber viel bewirken kann unter Umständen. Also das ist eigentlich was für mich, das ist vielleicht jetzt nicht so core edge-high, aber das sind für mich diese Dinge, die sehr wichtig sind, die auch sozusagen zu dieser Openness führen. Ja, wir haben die Daten vorliegen, wir reden über die, wir reden über Annahmen, wir reden über die Hypothesen, auch Marketing kann das Dashboard aufmachen und sagen, auf welche Basis haben sie denn das jetzt gemacht. Also da steckt so viel drin und da brauche ich vielleicht dann gar nicht so sehr über einzelne Rituale Events streiten und sagen, ja, Scrum hier oder da, sondern sagen, ja, gehen wir einen Weg, wo wir einfach Dinge an Kunden bringen, wo wir sicherstellen, was wir machen, ist das Richtige. Ja, das findet in Edge-High oft auch gar nicht statt. Das Edge-High hat oft diesen grassen How-Prozessfunk, und fair, ist auch wichtig, aber es ist nur ein Drittel. Andere ist sozusagen was machen wir und warum wir haben, also sozusagen diese strategische Einordnung als Produkt oder auch als Unternehmen. Ja, wenn das Unternehmen sagt, so Leute, wir müssen unsere Custom Retention, also wir haben zu viele Leute, die abspringen, wir müssen die, die wir haben, halten, so das ist das strategische Ziel, dann muss sie mich dann halt auch dran messen lassen, dann ist auch egal, ob mein Stand-up 10 oder 20 Minuten geht. Aber im Prinzip, das was mir halt wichtig ist, diese Diskussion, und das ist für mich Agilität, weil sozusagen um die Agilienprinzipien oder um diese Prinzipien auch gebaut und gedacht ist. So, was hab ich geredet? Nee, vollkommen richtig. Und ich find so rum auch total sinnvoll. Also zum Beispiel Agiles Manifest, 12 Agile Prinzipien, als Unterbau zu verstehen zu, was ist mein Geschäftsziel? Und man kann sogar noch so eine Nebendimension aufmachen und wie wollen wir miteinander umgehen? Und das findet man auch wieder im Agil Manifest und in den 12 Prinzipien, das schließt sich alles überhaupt nicht aus. Und wenn man dann im ersten Schritt sagt, ich greif jetzt zu einer Methodik und man greift zu der Methodik Scrum, weil die erstmal gut definiert ist, dann passt das ja super gut zusammen. Zu sagen, wir wollen was ändern, die Welt ist modern, Transformation, solche Themen und jetzt müssen wir Scrum machen, dann ist es einfach viel zu kurz. Ja, also ich will jetzt auch das alles gar nicht schlecht reden. Die Dinge gibt es ja aus gutem Grund und die haben sich ja auch über zwei Jahrzehnte bewährt in vielen Kontexten. Und zu jedem neuen Team würde ich sagen, ja hier, nehmt Scrum, lauf los, nehmt vielleicht noch ein paar Kanbanmetriken mit, weil die ich sehr sinnvoll halte und mach mal und guck mal wo denn drei Monate landest oder ein Vier oder Sex oder was auch immer. Also die Dinge sind gut und sinnvoll. Aber ich gesagt, es kommt halt drauf an. Ja, aber das ist ja, ich finde das ist der entscheidende Satz und deswegen kann keiner von außen auch anfangen zu sagen, ihr macht das falsch. Ja, schwierig. Ja, genau. Ja, schwierig. Ja, spannend. Und das ist auch, da kommt vielleicht wieder sozusagen Systemtheorie durch, was sich dann auch vielen Akiläuden, ich habe jetzt die Seiten gewechselt. Keiner gemerkt. Was dann halt auch vielen Akiläuen vorwerft, dieses sehr preskriptive, so muss es sein, so wird es gemacht. Und ja, again, wenn man halt wo startet und sagt, lass uns mit Scrum starten und wir halten das so gut und richtig und das hat bisher auch funktioniert, dann mach's dann auch erst mal so. Gibt jetzt keinen Grund, jeden Tag irgendwas zu ändern. Nichtsdestotrotz, wenn was da ist und funktioniert, dann ist es gut. So, das ist meine einfache Regel. Was funktioniert ist gut erst mal. Ja, genau. Das ist ja verkürzt natürlich. Nein, aber das ist schon richtig. Und ich merke halt immer wieder bei Leuten auch Verunsicherung. Mach ich das richtig. Und den Leuten kann ich zumindest aus meiner Erfahrung sagen, wenn du dich damit beschäftigst, ja. Und dass die Leute versuchen irgendwie ein besseres Regelwerk zu haben. Ankerpunkt, an dem ich mich orientieren kann, mache ich das richtig. Dann haben die mein vollstes Verständnis. Der Podcast heißt nicht umsonst no bullshit, edge-eye, weil es mir hier auch neben der Diskussion oder überhaupt den Denkanstößen auch darum geht, den Leuten ein bisschen mal so auch die Basis wieder zu zeigen. Das Aufgeblähte vielleicht mehr zu reduzieren. Man kann ja dann ergänzen, wenn man an einer bestimmten Stelle ist, aber um das auch ein bisschen zu reduzieren. Ja, super spannend. Haben wir irgendwas vergessen? Gibt's irgendwas, wo du sagst, ah, das wollte ich Thomas schon immer um den Ohren hauen oder so? Ja, ich glaube, wir haben viel besprochen. Ich würde gleich auf eins nochmal kurz reinspringen. Auch ausgehen von der Diskussion auf Mastetone, die ich auch in ähnlicher Form, wo ich anders schon gelesen habe, ja, böses Management. Da würde ich mal sozusagen zurückgeben. Leute, nicht allen ist immer genau klar, was was meint. Und auch im Management versuchen Leute einen guten Job zu machen, nicht alle, aber die meisten würde ich mir behaupten. Und redet über echte Sachen, redet darüber, was nicht gut läuft oder redet darüber, was verbessert werden kann, redet über konkrete Dinge und redet nicht jetzt über oder benutzt nicht Wörter wie Agilität oder andere, die die alles und nichts bedeuten. Das ist gefährlich und führt in der Regel dazu, dass man daran voneinander vorbeireidet. Und es ist auch eure Aufgabe und da sprechen Agile coaches an, Product Owner, auch Leute aus dem Team. Wenn im Management sozusagen eure internen Team-Metritten, wie jetzt meinetwegen Story Points, nimmt lieber Lead Time und Cycle Time, aber anyway. Egal, wenn das Fall verstanden wird, wer soll es Ihnen erklären, wenn nicht ihr und erklären. Und das muss man immer wieder machen, das muss man immer wieder neu machen, das muss man immer wieder erneuern. Das ist nervig und lästig, aber das gehört einfach dazu. Nicht jeder, der BWL studiert hat, weiß, wie Teams sozusagen ihren Durchsatz erheben und sozusagen den nächsten Iteration planen. Müssen sie auch gar nicht, sollen sie auch gar nicht. Sie müssen nur wissen, hey, pass auf, die Dinge kommen, die kommen mit einer gewissen Regelmäßigkeit, 80 Prozent kommen in zwei Wochen und 20 Prozent, die restlichen 20 Prozent ausreisen kommen vielleicht später und manchmal passiert really bad shit, weil das ist so, also so in Wahrscheinlichkeiten sprechen. Und meine Erfahrung ist, dass das auch beruhigt, weil im Endeffekt, um es auf Marketing zurückzuspringen, da ist eine Kampagne, eine Plakat-Kampagne in in Städten Deutschlands geplant, Volumen 100.000 Euro. Die wollen nichts von von deinen Storypoints. Die wollen wissen, ist sozusagen, dass da, wenn wir die in Städte plakatieren und versteht es, versteht die Sorgen und redet miteinander über echte Dinge und nicht aber, aber weil wir machen, weil wir haben das so geschätzt und weil das sprinten oder irgendwie so was, das ist kein Gespräch, redet über echte Dinge. Genau, wer mal plätojägt. Ja, und das kann ich tatsächlich unterstützen. Das ist so, miteinander reden ist immer eine gute Sache, den anderen versuchen zu verstehen, bewährt sich auch gerade in heutigen Zeiten sowieso doppelt und dreifach. Super Abschluss, ich hab aber, weil ich das jeden Gast frage und jede Gastin noch eine Frage, was ist dein schönstes Agiles-Erlebnis? Ja, das gibt's ja viele. Ich bin eigentlich, ich, im Herzen bin ich so ein Team-Mensch. Also ich hab gern Leute um mich rum, die irgendwie geilen Scheiß werkeln und für mich ist eigentlich jedes Mal, wenn was rausgeht, dass irgendwie besonderes Produkt, besonders Feature, irgendwas Neues, irgendwie was was schwierig war, wo dann auch merkt, okay, Leute benutzen das, Leute ziehen dann wer draus. Das ist für mich jedes Mal freue ich mich da sehr drüber. Und ich sag mal jetzt im Gesundheitsbereich, viele Releases waren echt ein schwere Geburt, da reden wir schon gar nicht mehr über Sprint, sondern über Mondphasen. Wie auch immer, wenn dann die Sachen draußen sind und siehst, hey, die machen Sinn, die fühlen sich richtig an. Ich mach mein Dashboard auf und seht, da laufen Leute rein. Und ich sehe, wie das Team zufrieden ist und das Team auch sozusagen seine Bestätigung daraus zieht, dass es halt auch sinnvolle, gute Sachen macht. Das ist für mich eigentlich immer ein schönes Erlebnis und es muss auch mein Anspruch als Führungskraft sein, den Team sozusagen den Raum und auch sozusagen die strategischen Leitplanken mitzugeben, so dass halt das passieren kann, dass gute Sachen an Kunden kommen, die Kunden und Kunden benutzen können oder benutzen wollen. Ja, super. Ja, toll. Also finde ich richtig gut. Find ich, es ist ein ganz toller Abschluss für die Folge. Martin, ganz, ganz, ganz vielen Dank für deine Zeit. Danke dir Thomas. Ja, vielen Dank. Wir sehen uns und sprechen uns bestimmt noch meiner Folge, ne? Absolut, ich hoffe. Alles klar. Super. Vielen, vielen Dank Martin. Bis dahin. Bis dann. Ciao. Ja, und damit sind wir heute auch schon durch. Wie ist eure Meinung so? Könnt ihr euch in den Gesprächen irgendwo wiederfinden? Gebt Martin mir da gerne Feedback, steigt gerne mit anderen auch in die Diskussion ein. Wenn du Feedback hast, hast du mehrere Möglichkeiten. Du kannst mir eine Mail schreiben an nobs@gmail.com. Ich bin sehr aktiv auf Mastodon. Mein Mastodon Profil verlink ich in den Shownotes und begleiten zu dem Podcast gibt es ja auch einen Forum und zu jeder Folge lege ich da einen einzelnen Thread an. Auch da gerne lass uns diskutieren. Du kannst mir auch eine Sprachnachricht hinterlassen. Auch dazu findest du ein Link in den Shownotes. Zum Abschluss habe ich noch eine Bitte, wenn dir diese Folge gefallen hat, wenn sie dir vielleicht sogar was geholfen hat, dann teil die Folge gerne mit anderen. Bespricht das mit Kolleginnen und Kollegen, mit vorgesetzt mit anderen Teams. Teil die Folge gerne auf den Social Media Kanälen. Je mehr Leute wir mit dem Podcast erreichen, desto größer wird die Diskussion. Desto mehr Leute nehmen an der Diskussion teil und das ist eben der Hauptgrund, warum ich diesen Podcast überhaupt gegründet habe. Habt noch eine ganz tolle Woche und bis zum nächsten Mal. Bye. [Musik] [Musik]