NBA39: Im Gespräch mit Martin über Agilität aus C-Level Sicht
Shownotes
Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile oder ihr hinterlasst mir eine Sprachnachricht: +4950329677123
Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/58-nba39-im-gespraech-mit-martin-ueber-agilitaet-aus-c-level-sicht
—
Mein Gast Martin
NBA38: DORA Teil II: Missinterpretation und Kritik
Agile Usergroup
NBA09: Agilität von SpaceX
Zusammenfassung
In dieser Folge spreche ich mit Martin - der unter anderem Jahre als CPO in einem Medizin-Startup gearbeitet hat - über seine Erfahrungen und seine Sicht auf Agilität.
Transkript
Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt auf der Praxis, daher auch der Name No Bullshit Agile.
In der letzten Folge habe ich über Missinterpretationen und Kritik an Dora gesprochen. Wenn dich das interessiert, hör da gerne rein. Den Link dazu findest du wie immer in den Shownotes. 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, das ich mit Martin geführt habe, ein bisschen Housekeeping.
Wenn ihr Lust habt, am 12.11. um 19 Uhr treffen wir uns zu unserer virtuellen Agilen User Group. Die Details dazu findest du in den Shownotes. Da habe ich eine Seite angelegt, die erklärt, wie das funktioniert, was die Idee dahinter ist, wie wir uns virtuell treffen und auch noch ein iCal-Event, das ihr euch herunterladen könnt, um es in euren Kalender zu importieren. Soweit 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, haben 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 ein, zwei interessante Sachen besprechen können, die zu weiteren Diskussionen dann im Fediverse oder sonstwo 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 Shownotes 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 lieben langen 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, Product Owner, Coach-Beratung bis zum C-Level, jetzt zum Schluss als CPO. Liebe meinen Job, mache ihn immer noch gerne und mache auch Coaching-Beratungsarbeit sehr gerne, weil ich denke, wir müssen auch Leute – ich will nicht sagen ausbilden – aber wir müssen das Wissen in der Diskussion halten, a) für Leute, die neu in die Szene kommen, und b) auch für uns, um uns upzudaten.
Ja, das ist 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 hier und da mal Gegenwind haben und schauen, wo sie Geld sparen können. In dem Fall waren wir Teil vom Rotstift und mussten leider unser Unternehmen schließen. Und das ist das Game, das ist leider so, wenn man in Start-ups geht, dann weiß man auch, worauf man sich einlässt. Aber gerade im E-Health- und Gesundheitsbereich, da sind wir – ich will nicht sagen, die Deutschen sind immer hinterher, das alte Mantra – im Prinzip ist da noch viel Raum für digitale Produkte, muss man neutral sagen. Und ich war auch der Meinung, dass wir interessante Sachen am Markt hatten, die geholfen hätten, das Gesundheitssystem zu verbessern. Insofern tut es natürlich ein bisschen weh, wenn so ein Unternehmen geschlossen wird. Tut einem weh, aber da tat es dann noch mal ein klein bisschen weh.
Ja, kann ich gut verstehen. Soviel vielleicht zu mir.
Ja, aber ich vermute jetzt einfach mal, korrigiere mich 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 so aufzuzeigen, ist man ja ein Medizinprodukt oder in irgendeiner Form zertifiziert, ISO-zertifiziert, und das hat gute Gründe. Diese Zertifizierung geht so weit, dass ich bis auf Ticket-Ebene sicherstellen muss, dass die Veränderung, die im Ticket beschrieben ist, niemandem schadet. Ich muss quasi auf Ticket-Ebene eine Gefährdungseinstufung machen. Ich habe große Dokumentationspflichten, vorab und nachgelagert.
Nichtsdestotrotz, und das war auch für mich die Motivation, den Job damals anzunehmen: Ich kam von sehr kleinen, schnellen Kanban-Teams mit Leadtime von um die zwei Tage, hatte sehr viel Meinung zu dem Thema Agilität, Kanban und Scrum und wollte einfach mal in so einem Umfeld sehen: Funktioniert das eigentlich, was ihr da alle so schlau ausgedacht habt? Und tatsächlich ist Agilität ein Thema. Agilität ist immer ein Thema in einem Markt, in dem ich disruptiv sein muss, oder einem disruptiven Markt, einem schnellen Markt, der sich schnell verändert. Was digitale Produkte auszeichnet, ist, dass der Marktzugang sehr, sehr gering ist. Das heißt, es tauchen neue Wettbewerber auf, die vielleicht sogar auch dein Produkt kopieren oder irgendetwas besser machen als du, das 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-tot-Diskussionen – ich kann mir innovative Produktentwicklung 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, die uns die ganze Zeit um die Ohren gehauen wird: Agilität sei tot. Heise-Artikel und jeder 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 nicht 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 auch ein bisschen auf den Markt ankommt. Also in dem Moment, genau wie du gesagt hast: zu viele Marktbegleiter, die im Zweifelsfall auch Copycats sind. Da willst du schnell sein und du willst das Richtige an deinem Produkt tun. Das ist genau der Punkt, den ich in der Diskussion oft vermisse. Und ich war jetzt auch in den letzten zwei, drei Jahren auf verschiedenen 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, das ist das eine und das andere ist: Bin ich in einem Projektgeschäft? Das bedeutet was ganz anderes. Also entwickle ich Software für einen Kunden, der relativ viel 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 mit 500 Mitarbeiterinnen und Mitarbeitern gewachsen und habe natürlich einen ganz anderen Blick auf das, was ich mache und eine Agilitä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 Leadtime 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 Leadtime 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 generell in der Diskussion halt mehr die Nuancen wünschen.
Ja, genau. Und den Hintergrund dazu: Viele Leute neigen dazu 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 Mastodon 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 ein Ticket-System, das 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 Sprint überhaupt nicht vorstellen. Ja, das Scrum für die Buchhaltung. Nein, bitte nicht.
Ja, gut. Ich habe ja auch sozusagen einen systemtheoretischen Hintergrund, habe auch einen Master in systemischer Organisationsberatung, habe ich jetzt kürzlich 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 starke 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 C-Level-Position, das muss mir auch egal sein, wie vielleicht dann ein Team die Koordination vom Tagesgeschäft macht oder wie ein Team plant oder wie ein Team auch sozusagen Fehlersuche macht oder was auch immer.
Ja, das ist ein guter Punkt und tatsächlich vielleicht aus dieser Perspektive: Siehst du oder hast du jemals auf C-Level – ich sage jetzt mal Managementebene – irgendeinen Konflikt gesehen zwischen deinen Zielen als C-Level und den Zielen von dem Team oder Product Ownern oder Product Treibern? Kommst du da in 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-Rolle, 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 Cagan sozusagen initiiert hat, was sich so ein bisschen als Gegen-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, die agil arbeiten wollen, agile Praktiken einführen wollen, Scrum machen wollen, eine Lead-Time hinten ranschreiben möchten etc. Diesen Konflikt gab es nicht. Diesen Konflikt gibt es eher sozusagen auf meiner Peer-Ebene dann oder vielleicht auch ein Level drunter von Stakeholdern oder Abteilungen 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 aus dem Marketing, ich sage jetzt mal irgendwas, mag nicht das sein, was ich unter Agilität verstehe, und das kann man den Leuten ja nicht vorwerfen, das ist ja nicht sozusagen Teil ihrer Fachexpertise. Deswegen habe ich dann immer versucht, solche Schlagwörter 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, gegen die eigentlich niemand etwas haben kann.
Also ich kann das so aus meinem Blickwinkel sagen: Was wir machen, ist, wir entwickeln Software und Custom-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 es sich 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, dass es in Deutschland mittlerweile auch so weit ist, dass ich sage, die Krankheit ist erstmal ganz neutral. Viele in einer Führungshierarchie beim Kunden sagen, okay, Scrum ist cool, ich bleibe jetzt einfach beim – ich weiß, Scrum ist am weitesten verbreitet, weil – und jetzt kommen 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 haben jetzt eine Schulung besucht, sie haben einen Stempel bekommen von der Ebene über ihnen: „Du bist jetzt PO, Glückwunsch, und wir machen jetzt Scrum, weil das ist cool. Jetzt sieh mal zu.“ Aber sie bringen überhaupt nicht das Mindset mit, und 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? Agilität verkommt dann zum Wasserfall, nur mit einem neuen Anstrich.
Ja, da dreht sich der Kreis, und jetzt auch nicht falsch verstehen: Ich bin jetzt, glaube ich, auch seit zehn Jahren in der Scrum Alliance, im deutschen Dachverein und so weiter und so fort. Ich sehe mich da auch als Teil davon, aber ich glaube, dieses Marketing von der Scrum Alliance an alle heißt ja auch, dass es für jeden was ist. Also, wenn es vielleicht nicht die Alliance ist, dann sind es vielleicht einzelne Beratungsfirmen, die das genauso in ihren Slides als Verkaufsargument drin haben. Insofern, ja, nervt es, wenn mit falschen Voraussetzungen gestartet wird, nervt komplett. Aber die Frage ist halt, müssen wir uns dann nicht auch ein bisschen an die eigene Nase fassen? Also, wir Agilisten. Müssen wir 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 aus dem Schmerz geboren, dass jetzt Leute irgendeine Art von Produktarbeit machen, zumindest auf Delivery-Seite oder vielleicht die komplette Bandbreite machen wollen oder den Anspruch haben oder den Auftrag haben, aber halt nur so eine Scrum-Basis-Schulung haben – und das reicht halt nicht. Das ist auch gar nicht schlimm, wir fangen ja alle irgendwo an.
Aber im Prinzip: Ich habe auch einige Schulungen schon gehalten, habe auch verschiedene Leute schon gecoacht, und ein Basis-Tenor, der da immer wieder raushörbar ist, ist, dass diese Erwartungen, die an mich oder die ich selbst an mich als PO dann stelle, irgendwie im Konflikt mit der Realität stehen. Leute wollen ihren Job gut machen, 19 von 20 Leuten sagen, sie wollen ihren Job gut machen, die sind motiviert, die wollen, dass das irgendwie rundläuft. Und ihnen sozusagen auch diesen Schmerz rauszunehmen und zu sagen: „Ja okay, du hast jetzt vielleicht mit Scrum ein sehr Delivery-lastiges Werkzeug an der Hand.“ Und du bist jetzt aber in einem Bereich, der vielleicht sinnvollerweise auf deinem Schreibtisch liegt, aber den kannst du nicht mit dem Stand-up und der Retro lösen, sondern du musst dir halt einen strukturierten Research-Prozess überlegen, sowas.
Ja, genau. Und ich glaube, da muss sozusagen die Ausbildung – und Ausbildung klingt immer viel – aber es sind auch diese kleinen Schulungen, diese Zwei-Tages-Schulungen, die machen ja die Tür auf. Die geben auch ein bisschen Struktur vor, wo deine Reise hingehen kann, auch deine Lernreise. Da muss es besser werden. Sorry, also da bin ich offen für alles, aber an dem Punkt habe ich eine relativ starke Meinung. Diese Schulungen, die sind oft gut gemeint, aber in der Regel relativ schlecht.
Ja, genau. Ich habe halt auch noch das Problem, dieser Markt ist irgendwann überschwemmt worden, keiner kann heute das Wort „Agiler Coach“ mehr hören. Ja, und ich verstehe es auch. Es gibt so viele Modelle, so viele Unternehmen, die in diesem Bereich sich versuchen, was aufzubauen oder was aufgebaut haben, und viele Produkte 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 ist. Man kann ja nur Fehler machen, wenn man in Richtung Agilität gehen will, man muss ein klares Playbook haben. Und dann entsteht sowas wie Safe, das für mich einfach nur Papierkram-Wahnsinn ist. Nicht, dass ich da Erfahrung hätte, aber das ist mir alles viel zu kompliziert. Und darum geht es ja eigentlich im Fundament der Agilität überhaupt nicht.
Ich habe meine Folge gemacht über SpaceX, weiß nicht, ob du so Raumfahrt, Raumschiff, solche Sachen verfolgst. Das ist sehr faszinierend. Ich mag Elon Musk halt gar nicht mehr, der verdirbt mir auch wirklich jeden Spaß daran, obwohl ich da eigentlich immer sehr viel Spaß dran hatte. 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 sich das im Unternehmen sonst leisten könnte, 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, wie würde ich den Kern von Agilität beschreiben – auch mal unabhängig vom Team-Level oder einem einzelnen Team. Das ist es halt für mich: Das Unternehmen muss – also das Ziel eines Unternehmens 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 Product Owner sage, eine radikale Kundenorientierung hat und eine Transparenz für Daten, sodass ich auch mitkriege, wenn sich am Markt was ändert. Weil oft ist es so, ja, da kommen Elektroautos und die Chinesen bauen ganz viele Elektroautos, aber ne, betrifft uns nicht. Da funktioniert die interne Sensorik da nicht richtig, obwohl die Erkenntnis im Raum ist. Das sieht man sehr häufig in Unternehmen, großen wie kleinen.
„Fail Fast“ würde ich halt eher übersetzen, weil „Fail Fast“ sage ich mal, okay, das ist eine sehr frühe Phase von der Produktentwicklung. Das würde ich im Medizinbereich jetzt nicht machen.
Korrekt.
Würde ich übersetzen mit minimiertes Risiko, so gut wie es geht: Wie minimiere ich das Risiko? Indem ich kleine, schnelle Arbeitspakete mache, die ich schnell validiere. Das ist im Prinzip „Fail Fast“. Würde ich jetzt halt nicht mit Devices im OP-Saal machen, da würde ich eine andere Art von schnellem Feedback suchen.
Da bin ich dankbar.
Genau, das ist im Prinzip der Kern. Klar, die Frameworks haben einen Sinn, und die geben dir ein Handwerkszeug. Sie sagen: „Okay, wie kannst du planen, wie kannst du brainstormen, wie kannst du retrospektiv auf Dinge gucken, wie kannst du sicherstellen, dass du dich als Team verbesserst – im Prozess wie im Produkt.“ Okay, hier hast du ein Set an Werkzeugen, die haben in der Vergangenheit recht gut funktioniert, probier die mal aus, und abgefahren. 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. Gib dir einen Zeitraum, in dem du das wieder messen willst: Hat sich was verbessert? Guck drauf, mach es anders. Das ist für mich Agilität auf Prozessebene. Und deswegen meine ich, eigentlich ist mir egal – aus CPO-Blick – wie rum wir die Tickets am Board hängen und ob die montags oder mittwochs was auch immer der T-Shirt Size ist draufklebt oder was auch immer, I don't care. Was mich aber schon interessiert, ist, wie sie mit Fehlern umgehen. Gucken sie auch auf Ausweiser? Arbeiten sie damit? Das ist das, was mich interessiert.
Also es geht immer wieder mal was schief: Wie gehen die damit um? Wird darüber gesprochen? Wird es verschwiegen? Gibt es Reports? Wird mit mir gesprochen in der CPO-Rolle? Das ist eigentlich das, was mich interessiert, und das ist auch das, was das Produkt und die Firma voranbringt.
Ja, genau. Also ich kann das nur bestätigen. Ich bleibe mal ruhig bei Scrum. Ich finde den Scrum Guide halt gut, vor allem 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 Kanban, wir haben 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, 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 zu lösen, das passiert mir halt an manchen Stellen zu wenig. No size fits all. Was bringt uns diesem fundamentalen Ziel näher, nämlich zum Beispiel schnell am Markt zu sein oder effektiv am Markt zu sein? Was führt uns davon weg? 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 der 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 das immer noch Prägende ist, auch für alles, was ich mache und gemacht habe, sind ja eigentlich schon auch diese Scrum-Werte. Die sind sehr zentral: Focus, Commitment, Courage, Respekt, Openness. Da steckt so viel drin. Und aus diesen Prinzipien – und du kannst 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 das anders machst, obwohl ich jetzt den Daily Stand-up fast für das wichtigste Ritual halte.
Aber wie auch immer, was anderes, auch aus den Säulen, aus den Scrum-Säulen: Diese Empirie, das empirische Framework, das ist mir auch sehr wichtig. Es ist mir immer noch egal, 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, werden zu der Hypothese Annahmen formuliert oder umgekehrt Annahmen und Hypothese? 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 das und das Verhalten haben. Okay, gut. Dann haben wir diese Annahme, die müssen wir vielleicht auch nochmal separat validieren. Aber mit den Annahmen machen wir eine Hypothese, bauen was und messen das anschließend und definieren vielleicht auch die wichtigen Metriken dazu: Auf was schauen wir? Wann ist es ein Erfolg, wann ist es kein Erfolg? Erfolg ist, wenn 30 Prozent draufklicken. Okay, jetzt haben 29 Prozent draufgeklickt. Was machen wir jetzt? Okay, nochmal eine Iteration oder zwei fahren, vielleicht kriegen wir es noch gedreht.
Also das ist so das, was für mich, sage ich mal, aus Produktsicht interessant ist. Wird das gemacht? Ein Team sollte empirisch bis zu einem gewissen Punkt arbeiten, aber in dem Team, mit Daten, haben sie auch ein Verständnis, wo es Lücken gibt. Manchmal hat man Daten, aber Daten kann auch heißen, drei Leute haben im Kundenservice angerufen und waren sauer, weil etwas nicht funktioniert hat. Es sind auch Daten, aber es ist 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 agile, aber das sind für mich diese Dinge, die sehr wichtig sind und 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 das jetzt gemacht?"
Da steckt so viel drin, und da brauche ich vielleicht dann gar nicht so sehr über einzelne Rituale und Events streiten und sagen: "Ja, Scrum hier oder da." Sondern ich kann fragen: "Gehen wir einen Weg, wo wir einfach Dinge an Kunden bringen, wo wir sicherstellen, dass, was wir machen, das Richtige ist?" Das findet in agile oft auch gar nicht statt. Das Agile hat oft diesen krassen How-Prozessfokus, und fair, das ist auch wichtig, aber es ist nur ein Drittel. Das andere ist: Was machen wir und warum? Also sozusagen diese strategische Einordnung als Produkt oder auch als Unternehmen. Ja, wenn das Unternehmen sagt: "So, Leute, wir müssen unsere Customer Retention verbessern, wir haben zu viele Leute, die abspringen, wir müssen die, die wir haben, halten" – das ist das strategische Ziel, dann muss ich mich dann halt auch daran messen lassen. Dann ist es auch egal, ob mein Stand-up 10 oder 20 Minuten geht.
Aber im Prinzip, das, was mir halt wichtig ist, ist diese Diskussion. Und das ist für mich Agilität, weil sozusagen um die agilen Prinzipien oder um diese Prinzipien auch gebaut und gedacht ist.
So, was hab ich geredet? Nee, vollkommen richtig. Und ich find das so rum auch total sinnvoll. Also zum Beispiel das Agile Manifest, die 12 agilen Prinzipien, als Unterbau zu verstehen zu: Was ist mein Geschäftsziel? Und man kann sogar noch so eine Nebendimension aufmachen: Wie wollen wir miteinander umgehen? Und das findet man auch wieder im Agilen 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 schlechtreden. 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, lauft los, nehmt vielleicht noch ein paar Kanban-Metriken mit, weil die ich sehr sinnvoll halte und macht mal und guckt mal, wo ihr in drei Monaten landet oder in vier oder sechs oder was auch immer. Also die Dinge sind gut und sinnvoll. Aber wie 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 Agilisten – ich habe jetzt die Seiten gewechselt. Keiner hat’s gemerkt. Was dann halt auch vielen Agilisten vorgeworfen wird, 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 erstmal so. Es gibt jetzt keinen Grund, jeden Tag irgendwas zu ändern. Nichtsdestotrotz, wenn etwas da ist und funktioniert, dann ist es gut. So, das ist meine einfache Regel: Was funktioniert, ist gut, erstmal.
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, einen 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 Agile", 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 die Ohren hauen oder so? Ja, ich glaube, wir haben viel besprochen. Ich würde gleich auf eins nochmal kurz reinspringen, auch ausgehend von der Diskussion auf Mastodon, die ich auch in ähnlicher Form woanders 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 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 jetzt nicht über oder benutzt keine Wörter wie Agilität oder andere, die alles und nichts bedeuten. Das ist gefährlich und führt in der Regel dazu, dass man aneinander vorbeiredet.
Und es ist auch eure Aufgabe, und da spreche ich Agile Coaches an, Product Owner, auch Leute aus dem Team: Wenn im Management sozusagen eure internen Team-Metriken, wie jetzt meinetwegen Story Points – nehmt lieber Lead Time und Cycle Time, aber anyway – egal, wenn das falsch verstanden wird, wer soll es ihnen erklären, wenn nicht ihr? Und erklärt das, 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 die nächste 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 die restlichen 20 Prozent, die Ausreißer, 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 Städten Deutschlands geplant, Volumen 100.000 Euro. Die wollen nichts von deinen Story Points wissen. Die wollen wissen, ob sozusagen das da ist, wenn wir die in Städten plakatieren. Und versteht es, versteht die Sorgen und redet miteinander über echte Dinge und nicht über "Aber weil wir haben das so geschätzt" und "weil das sprinten" oder irgendwie sowas. Das ist kein Gespräch – redet über echte Dinge.
Genau, wer mal plätojägt. Ja, und das kann ich tatsächlich unterstützen. 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 Gästin, noch eine Frage: Was ist dein schönstes agiles Erlebnis?
Ja, da gibt's ja viele. Ich bin eigentlich – 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, das irgendwie ein besonderes Produkt ist, ein besonderes Feature, irgendwas Neues, etwas, das schwierig war, wo man dann merkt, okay, Leute benutzen das, Leute ziehen einen Mehrwert daraus. Das ist für mich jedes Mal etwas, worüber ich mich sehr freue. Und ich sag mal, jetzt im Gesundheitsbereich: Viele Releases waren echt eine schwere Geburt. Da reden wir schon gar nicht mehr über Sprints, sondern über Mondphasen. Wie auch immer, wenn dann die Sachen draußen sind und man sieht, hey, die machen Sinn, die fühlen sich richtig an. Ich mach mein Dashboard auf und sehe, 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, dem Team sozusagen den Raum und auch die strategischen Leitplanken mitzugeben, sodass halt das passieren kann, dass gute Sachen an Kunden kommen, die Kundinnen und Kunden benutzen können oder benutzen wollen.
Ja, super. Ja, toll. Also finde ich richtig gut. Finde 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 und sprechen uns bestimmt noch in 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 und 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 nobsagile@gmail.com. Ich bin sehr aktiv auf Mastodon. Mein Mastodon-Profil verlinke ich in den Shownotes, und begleitend zu dem Podcast gibt es ja auch ein Forum und zu jeder Folge lege ich dort einen eigenen Thread an. Auch da gerne, lass uns diskutieren. Du kannst mir auch eine Sprachnachricht hinterlassen. Auch dazu findest du einen Link in den Shownotes.
Zum Abschluss habe ich noch eine Bitte: Wenn dir diese Folge gefallen hat, wenn sie dir vielleicht sogar geholfen hat, dann teile die Folge gerne mit anderen. Besprich das mit Kolleginnen und Kollegen, mit Vorgesetzten, mit anderen Teams. Teile 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.
