NBA25: Im Gespräch: Marco von SCRUMschau über Scrum

Hallo und herzlich willkommen bei NoBullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier jede Woche Themen aus der agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Man fokus liegt auf der Praxis, daher eben auch der Name NoBullshit Agile. In der letzten Folge habe ich über das Schwungrad gesprochen. Wenn dich das interessiert, hör da gerne rein, den Link dazu findest du in den Shownotes. Das hier ist die Folge 25 und heute freue ich mich ganz besonders, denn ich habe einen Gast, den Marco von Scrumschau und mit dem unterhalte ich mich, wer hätte das gedacht, über Scrum. Ja, wie schon angesprochen, hallo Marco, vielen Dank für deine Zeit und schön, dass das mit uns endlich geklappt hat. Ja, hallo Thomas, danke für die Einladung. Hi, wir kennen uns ja tatsächlich vom Mastodon. Ich kenne ein bisschen deine Website Scrumschau, kannst du ja auch gerne ein bisschen was zu erzählen und ja, wir tippsen uns ja immer mal ein bisschen an bei ein paar Themen. So, dein Hauptthema ist ja Scrum. Bevor wir da einsteigen, willst du vielleicht ein paar Sätze über dich erzählen? Ja, sehr gerne. Ja, ich heiße Marco und bin seit über zehn Jahren im Bereich der agilen Softwareentwicklung unterwegs. Dort eigentlich immer als Scrum Master, Scrum Master Agile Coach, wie man das auch mal bezeichnen möchte und habe dort ja eigentlich großen Gefallen mit Scrum gefunden und in deiner Folge Nummer vier hast du es ja gesagt, dass Scrum ist so die Einstiegsdroge in der Agilität. Ja, ist so mein Eindruck. Genau, ich habe das exakt auch so erlebt. Wir haben die ersten Jahre Agile gearbeitet, ohne dass wir wussten, dass wir Agile arbeiten. Ich hätte gesagt, so ein Atorq, mein damals Produktowner Projektleiter, hat es jede zweite Woche irgendwie reingekommen mit neuen Ideen. War alles irgendwie komisch und dann sind wir auf Scrum gekommen, haben Scrum im Team eingeführt und haben da viel Spaß und viel Freude gehabt und konnten damit echt auch so Probleme lösen, die prozessseitig vorher bestanden. Ja, und als ich dann, du weißt nicht, zwei, drei Jahre mit Scrum gearbeitet habe, habe ich mich dann gefragt, ja und jetzt, wie geht es weiter, wie kann ich denn was Neues lernen und war so ein bisschen auf der Suche und habe dann angefangen so paar Links zu finden im Internet, da ein bisschen zu lesen und dann dachte ich mir, oh, jetzt gibt es ja ein paar Sachen und vor ein paar Jahren war ja noch so Blogs schreiben, so ein auslaufender Hype, sage ich mal und habe gedacht, okay, komm, mach ich auch mal, probier es aus und dieser Blog sollt einfach meine Lernreise irgendwie nochmal so ein bisschen unterstützen und mich motivieren. Ja, finde ich super. Und daraus ist dann Twitter Account entstanden und bei Twitter hat mich dann die volle Breitseite an noch mehr Links, noch mehr Infos getroffen und Twitter ist jetzt raus, jetzt bei Mastadon ein bisschen ruhiger das Ganze, ja also eigentlich ist Scrum Show meine Lernreise und mein Versuch, alles was ich gelernt habe, zusammenzufassen. Ja, super cool. Den Link gibt es natürlich in den Schoenuts, kann ich auch wirklich nur jedem empfehlen, mal reinzugucken und gerade dieser Blick, meine Reise finde ich für Blogs halt immer total angenehm, weil es halt den persönlichen Touch eben auch hat und ich finde diese Perspektive auf so ein Thema, die man selber mitbringt, die ist, finde ich immer total interessant und ich glaube, die ist wirklich auch für viele andere interessant. Ja, und das ist jetzt leider ein bisschen ruhiger geworden, weil halt meine Lernreise so weit gekommen ist und inzwischen auch in anderen Firmen arbeite, wo Agilität nochmal viel mehr gelebt wird und dann ist so die Lernreise, die öffentliche Lernreise im Blog so ein bisschen weniger sichtbar, aber das Blog lebt noch. Ja, genau und das ist ja, finde ich auch immer gut, wenn man sowas auch leben lässt, weil ich glaube einfach, dass viele Sachen immer noch stimmen. Es hängt ja auch immer ein bisschen davon ab, genau wie du es grad sagst, in welcher Phase bin ich gerade, wo es in welcher Phase ist das Unternehmen oder meine Kunden, deswegen, ich finde es immer super, dass man ja, ich sage mal, auch diese Art von Dokumenten noch im Zugriff hat. Ja, genau. Magst du denn mal sagen, heute, wie groß ihr so seid? Also muss natürlich keine Details nennen, aber damit vielleicht die Leute, die zuhören, so ein bisschen Orientierung haben. Wir entwickeln Individuals-Software für große Industriekunden und sind bei uns in der direkten Firma so 150 Leute, so in Richtung 200 Leute, mehreren Standorten deutschlandweit als auch international und sind aber in einem Großkonzern aufgehangen mit mehreren tausend Leuten und wo jede Tochterfirma so eine Spezialisierung hat und wo jetzt auch nicht jeder Agil arbeitet. Also unsere Firma macht Agile Software Entwicklung. Okay, cool. Und das machen dann alle also wirklich im Prinzip die 100 oder die ungefähr 100? Genau, die 150 Entwickler machen ganz klassisch Agile Software Entwicklung und Wasserfall ist dort verpönt. Ja, super. Ja, ich glaube, wir kommen da immer mal wieder drauf. Jetzt war es ja so, unser Anlass auch im Vorgespräch eben gerade, dass wir gesagt haben, okay, ich hatte ja mal so eine Folge 4, auch die verlinke ich natürlich in den Show-Notes. Da habe ich mal, ich sage mal, meine Erfahrungen ein bisschen zusammengefasst, auch ein bisschen den Scrum Guide ja genommen und darüber ein bisschen erzählt, ist Scrum noch das Richtige? Also ich habe es natürlich ein bisschen reißerisch genannt, wie man das im Internet so macht. Warum es Zeit ist ein anderes Agiles-Vorgehen zu erwegen, habe ich zumindest noch genannt. Und da hattest du ja auch gesagt, ja, da gibt es schon ein paar Punkte, die würde ich gar nicht Scrum anlasten, sondern vielleicht einfach welche Möglichkeiten man hat, das im Unternehmen umzusetzen oder vielleicht sogar Thomas, also ich habe ja selber auch von mir erzählt, dass wir mal fünf Jahre Scrum gemacht haben. Vielleicht hast du es auch nicht so ganz richtig angewandt. Vielleicht willst du da mal so einsteigen, ein, zwei Punkte nennen, wo du siehst, so ja, das kann man auch schon anders sehen. Ja, genau, vielleicht erste Worte dazu. Ich glaube, es gibt wenig richtig und falsch, sondern ich glaube, es bringt sehr viel, wenn man nochmal im Austausch geht, und das machen wir bei dir jetzt auch gerade hier, nochmal so paar Sichtweisen einfach nochmal neu zu beleuchten. Und eine Sichtweise, die du hier in der Folge 4 ganz viel genannt hattest, spielt um das Thema Velocity. Velocity, Storypoint, Storypoint-Schätzung und so weiter. Und das ist für mich immer der erste Punkt, wo ich hellhörig werde. Wenn ich lese, wenn ich höre, Scrum funktioniert bei uns nicht, weil Velocity ist blöd, Storypoint sind blöd. Daher ist meine erste Antwort, warum macht ihr denn das Ganze? Warum macht ihr den Storypoint? Warum macht ihr denn Velocity? Und wenn die Antwort ist, na weiß Scrum, lass uns vorschreibt, frage ich immer ganz gerne, ja, aber seit einigen Jahren eigentlich überhaupt nicht mehr. Also das Scrum Guide ändert sich immer wieder mal. Und in der neuesten aktuellen Version spielt das Thema Schätzung gar keine Rolle mehr. Es gibt sogar eine Strömung, die nennt sich No Estimation. Die sagen von vornherein, wir schätzen gar nicht, weil es gibt gute Studien, die nachweisen, dass Schätzen nicht unbedingt erfolgreicher macht. Ich habe das jetzt auch in einigen Teams schon probiert und gesagt, warum schätzen wir eigentlich, was passiert, wenn wir es weglassen? Wir können es weglassen und das ändert nichts. Also ein Storypoint Wert führt nicht dazu, dass eine Entwicklungsaufgabe schneller wird, schneller umgesetzt wird. Das ist völlig egal, ob da 100 Storypoint oder ein Storypoint dran steht, die braucht so lange wie sie braucht. Und die Entwickler haben mich darum gebeten, es trotzdem zu machen, weil sie wollten einen Wert an eine Story dran haben, wenn sie sich im Sprint dieser Aufgabe aussuchen, um sie umzusetzen, um ein Gefühl dafür zu bekommen, ob es eine große oder kleine Story ist. Und in dem einen Projekt, in dem ich aktuell noch tätig, haben wir uns dann auf T-Shirt Größen geeinigt. Weil wir gar keine Zahlenwerte brauchten, ist das Spiel überhaupt gar keine Rolle. Ich wünschte mir, dass ich mal ein Projekt habe, wo ich ganz radikal unterwegs bin. Und jetzt kommen wir mal zu dem Punkt, wo können wir denn mal mit der Velocity den echten Mehrwert oder warum machen wir das Thema Velocity? Was wäre, wenn wir Storypoints ran schreiben, die Aufwandschätzung und das nutzen wir in der Sprint Planning, weil dafür ist eine Aufwandschätzung da. Das, was wir im Sprint Planning besprechen, schaffen wir das im Sprint, so um groben und ganz darum geht es. Und was passiert, wenn ich am Ende des Plannings sage und jetzt löschen wir alle Storypoints von den Stories runter, weil der Zweck ist erfüllt. Unser Planning haben wir gemacht. Das macht halt keiner, weil man und jetzt kommen wir in das Management hier machen. Was du halt so ein bisschen angesprochen hast. Wir lassen die Storypoints dran, damit wir irgendwann mal zurückblicken können und irgendwelche Velocities ausrechnen können, wo wir glauben, das ist ungefähr so ein Mittelwert. Die Erfahrung zeigt, funktioniert im Großteil nicht. Also ich erlebe selten Sprints, wo die Velocity gleich bleibt. Und sie bleibt nicht gleich, weil im Sommer, wir haben Urlaub, es sind weniger Leute da, da geht die Velocity runter. Dann sind Feiertage, um die Osterfeiertage drum herum. Das ist weniger. Dann sind mal alle da, dann haben wir Höhen drin. Und wenn ich auf ein halbes Jahr zurückblicke und auf die einzelnen Sprints schaue, kann ich mich nicht mehr erinnern, warum haben wir da mehr und mal da weniger Velocities gehabt. Also deswegen, das ist eigentlich so ein spannendes Thema. Die Velocity hilft uns im Planning und danach können wir sie eigentlich wegschmeißen, weil alles andere, um sie zu behalten und um Reporting draus zu machen, was ich, was man alles machen kann, nimmt uns den Spaß eigentlich weg. Ja, kann ich voll mitgehen. Also wie gesagt, wir haben ja auch mal so fünf Jahre und auch wirklich Hardcore Scrum gemacht. Da war der Scrum Guide noch ein bisschen älter. Da war es zumindest so für Sprint Planning, das Commitment, was das Team für den Sprint abgibt, ist so Weather Forecast Level. Also keiner wird erschossen, wenn man jetzt da nicht die Punkte schafft in Sprint. Es dient so als eine Vorhersage. Auch da war es halt schon so, dass die Velocity jetzt nicht dazu diente, das Team darauf festzunageln. Was ich immer für sehr positiv erfunden habe beim Sprint Planning, wenn wir tatsächlich mit Story Points gearbeitet haben, die Diskussion, die daraus entstanden, wenn die Schere in den Story Points im Team zu weit auseinander war. Ja, kann das sein, dass du vielleicht die Komplexität unterschätzt hast? Du darfst ja nicht vergessen, wir müssen das und das und das noch machen. Fand ich total wertvoll? Ja, bin ich bei dir. Du spielst hier auf die Methodik des Poker Plannings an. Ja, genau. Und beim Poker Planning ist diese Diskussion super spannend. Ich kann den Poker Planning ja auch machen ohne Story Points am Ende. Genau. Also es ist super nützlich festzustellen, einer sieht es groß, der andere sieht es klein. Dann kann ich die Diskussion nochmal fortführen und vertiefen. Und danach könnte ich sagen, okay, jetzt haben wir ein gleiches Verständnis von, keine Ahnung, ist ein mittelgroßer Aufgabe, fertig. Also ich muss noch nicht mein Story Point jetzt ermitteln. Richtig. Sondern eigentlich reicht ja die Erkenntnis, wir haben ungefähr ein gleiches Level. Genau, wir haben ein gleiches Verständnis. Genau, gleiches Verständnis. Und wenn ich jetzt nochmal in die Agilität reingehe und auch hier wieder ein bisschen radikal denke und für mich und ich sage, wir brauchen kein Refinement ins Scrum oder kein Refinement oder ganz wenig Refinement Forms Print Planning. Weil wenn wir ganz viel Refinement Form machen, ganz viele Dinge vor dem Planning besprechen, kommen wir in einem kleinen Wasserfall rein. Genau. Eigentlich wollen wir mit Scrum sehr agil sein. Eigentlich würde uns im Sprint Planning ausreichen, wenn wir die Aufgaben oder die Ideen, die wir im Sprint umsetzen wollen, soweit verstanden haben, was soll das Ziel sein und soweit auch verstanden haben, dass uns da jetzt keine größeren Blocker drin sind. Und das Refinement können wir auch innerhalb des Sprints machen. Ablaus von meiner Seite, ja. Ja, nein, sehe ich wirklich auch so. Und das ist aus meiner Sicht so dieser Vorteil von Scrum und dann so wie ich das auch verstehe, Scrum als Framework. So, und du hattest in deiner Folge 4, ich fand es ein bisschen ketzerisch angesprochen, Scrum als Management Reporting Tool. Ja. Und das ist ein Teil des Erfolges von Scrum, da Scrum aus der Management Sicht so gesehen wird. Und Scrum wollte das aber eigentlich nie. Oder zumindest nicht, glaube ich das nicht. Aber diese Elemente, die das Management braucht, können dort wunderbar implementiert werden oder drin sein und eigentlich kann ich sie rauslassen. Ja, genau. Mit diesem Management Tool, oder das ist zumindest bei Management beliebt, sagen wir mal so, habe ich deswegen ein bisschen Schwierigkeiten auch, weil ich auch das Gefühl habe, dass das Management das mittlerweile auch in Deutschland alles gut erkannt hat, was man aus dieser Methodik rausholen kann. Und ich immer das Gefühl habe, dass die Dev Teams ein bisschen Schwierigkeiten haben, ihr Scrum, wie sie es benötigen, zu verteidigen. Also Leute von außen werden manchmal so eingriffig, erlebt das teilweise bei Kunden, die deren Verständnis davon, von der Methodik Scrum wird ja auch besser, weil ich stelle zumindest fest, dass die immer wieder auch Hausinterne Fortbildung machen und da zum Beispiel Scrum auch immer wieder ein Thema ist. Und du hast das gerade so schön formuliert, du hast nämlich gesagt, wir als Team brauchen ja zum Beispiel dann die Storypoints gar nicht mehr, die haben uns jetzt am Anfang mal geholfen für eine Orientierung und dafür sind die gut, kommt lasst die jetzt wegschmeißen. Und ich finde dann ist Scrum auch wieder total wertvoll. Was ich mit diesem Management-Tool meinte, ist, dass ich das Gefühl habe, dass es von außen einfach auch, ja ich sag mal, Dev Teams gezogen werden auf einmal Dinge mit Scrum zu tun, die sie gar nicht wollten. Ja, ja, habe ich auch so häufiger so erlebt und hier gibt es häufig das Problem, dass wir auch, wenn wir das als Scrum Team nicht sein wollen, aber wir sind sehr häufig abhängig von gewissen Stakeholder und Finanziers oder Nutzern. Und wenn die nicht zufrieden sind mit, also wenn wir nicht deren Spiel mitspielen, dann sagen sie, okay, dann macht es halt ein anderes Team. Also ich selber arbeite im IT-Consulting, wir arbeiten nur für den Kunden und wenn der Kunde das so braucht, wenn er das so wünscht, wird das dann halt auch leider häufig so gemacht. Weil ich kann nicht einem Manager oder einem Management-Team sagen, ne, Velocity machen wir nicht. Das ist aber für die häufig eine der ganz wenigen Punkte, die in deren Welt messbar ist und wo sie halt ein Chart dazu haben, wo sie das halt sehen können. Es wird sehr selten und jetzt kommen wir noch auf einen weiteren Punkt, den du angesprochen hattest. Das Thema Commitment. Das Team, so, die erste Frage ist, was ist denn das Team? Und das Team verstehe ich und das aktuelle Scrum Guide versteht ja unter dem Team auch den Product Owner und den Scrum Master und die Entwickler. Da ist schon der erste Punkt, der Product Owner wird meistens vom Kunden gestellt. Hast du ja auch noch eine andere Folge dazu gemacht? Der Product Owner wird häufig vom Kunden gestellt. Also der ist eigentlich mitgefangen in all dieser Diskussion, er nimmt sich aber trotzdem häufig raus. Also hier haben wir mit dem neuen Scrum Guide sowieso diesen Wechsel von das Entwicklungsteam. Gabs ja vorher im Scrum Team ist er bereit und heute gibt es nur noch das Team und das ist das gesamte Scrum Team. Und das Scrum Team committed sich nicht auf einen Sprint Backlog oder committed sich nicht auf einzelne Aufgaben, die im Planning dort reingepackt werden, sondern das Scrum Team committed sich auf ein Sprintziel. Und das ist für mich der Knackpunkt, wo es sich zeigt, ob Scrum gut oder nicht gut funktioniert in einem Team. Und ich nehme mich und meine Teams, die ich betreue, häufig auch nicht aus. Es ist furchtbar schwierig, einen Sprintziel zu definieren. Interessant. Es wird häufig trotzdem dann in Jira wieder eine Liste an Aufgaben zusammen gepackt und dann entsteht die Erwartungshaltung vom Management oder vom Product Owner. All das, was da drin steht, wird geliefert. Aber das ist gar nicht die Idee von Scrum, sondern Scrum sagt, wir committed uns auf das Sprintziel, alles dafür zu tun, dieses Sprintziel zu erreichen und es kann auch mal daneben gehen. Und wir wollen ja agil sein. Und agil bedeutet auch, dass ein Sprintziel durchaus fix ist und wir neue Aufgaben hinzufügen, den Sprintzieh oder den Sprintplan, die dem Sprintziel zuträglich sind und wir auch eventuell Aufgaben rausnehmen, die dem Sprintziel nicht zuträglich sind oder mit den neuen Erkenntnissen nicht mehr gebraucht werden. Und das ist ja auch richtig so, genau in dem agilen Sinne, so wie du es gerade gesagt hast. Genau. Aber das erlebe ich in keinem Team oder so gut wie in keinem Team. Und ich glaube, hier haben wir einen ganz, ganz großen Knackpunkt, warum dann am Ende gesagt wird, Scrum funktioniert bei uns nicht. Scrum ist ein Management-Tool, weil dort der Fokus auf das Abarbeiten von Features gelegt wird, also eher eine Feature Factory statt outcomebasiertes Sprintzielmanagement. Und ich weiß für alle Hörer da draußen, das klingt wunderbar in der Theorie und es ist super schwierig in der Praxis. Aber ich als Scrum-Master höre dann immer gerne rein und verstehe, okay, wenn wir es nicht schaffen, Sprintziel zu definieren, wird es schwierig mit Scrum. Und deine Folge vier ging ja so ein bisschen auch da drum, was wäre dann so eine Alternativen, zum Beispiel Kanban oder so. Und hier schaue ich ganz gerne auf den Reifegrad oder den Entwicklungsgrad des Produkts. Scrum ist aus meiner Sicht nicht geeignet für den vollständigen Produktlebenszyklus, sondern Scrum versucht in einem komplexen Umfeld, im Komplex heißt das viele Dinge noch unbekannt, bedeutet, dort in dem Produktlebenszyklus, der am Anfang ist, wir versuchen neue Features zu entwickeln, neuen Mehrwert zu entwickeln, am Anfang, wo das Produkt versucht, die Nutzungswelt, die Nutzer da draußen zu verstehen. Was ist jetzt aber, wenn ich ein Software habe, die seit zehn Jahren entwickelt wird, dann habe ich 30, 40, 50 Prozent Maintenance Aufgaben. Da geht es darum, Libraries auszutauschen, geht es darum, das Ding am Leben zu halten, juristische Anforderungen zu erhalten und so. Das ist planbar durchaus, das hat wenig was mit komplexer Welt zu tun und dann gibt es nur noch so ein paar neue Sachen, paar neue Features, die irgendwie im Detail sind. Aber ich muss nicht mehr ständig in Kontakt sein mit den Nutzern da draußen und gucken, funktioniert das, funktioniert das nicht. Und an der Stelle versuche ich, oder würde ich gerne auch dann in Richtung Kanan gehen, weil das dann dieser Sprintzyklus einfach nicht mehr so notwendig ist. Und hier erlebe ich dann wieder Kunden, die sagen, bitte lasst uns bei Scrum bleiben, weil wir die Timebox, diese Sprints brauchen. Und warum brauchen sie diese Sprints? Erstens sind sie gewohnt, alle zwei Wochen sich regelmäßig zusammenzusetzen und zu planen. Die sind es gewohnt, dass man nach zwei Wochen im Review die Ergebnisse vorträgt und sie sind es gewohnt auf Sprintbasis Rechnungen zu stellen. Da wird man beauftragt für, weiß ich nicht, die Entwicklung von zehn Sprints. So, und wenn ich jetzt in die Ecke komme und sage, lasst uns doch die Sprints wegmachen, die arbeitet in Kanan, dann verliert der Kunde diesen Aufhänger von, wie kann ich jetzt da eine Rechnung stellen? Ja, aber da hat man Gründe und all das auch ohne Scrum machen. Also ein Rechnungsrhythmus, den kann man ja, wie die ich definiere, und regelmäßige Meetings halte ich eh immer für sinnvoll. Die kann man ja auch zwei wöchentlich über vier wöchentlich ansetzen. Ja, genau. Aber das muss halt auch von der beauftragende Organisation, muss das halt gelernt werden. Vom, ich sag mal, Product Owner, vom Kunden, vom Finanzier bis hin zum Einkauf. Die haben ja jetzt viele Jahre verstanden und gelernt, Agilität können wir doch abrechnen. Ja. Also es gab viele Jahre, da wurde Agil gearbeitet in den Teams, aber in der Rechnungsstellung hat man das nicht abbilden können, da gab es andere Konstrukte. Ja, kenne ich auch. Und jetzt sind wir so weit und verstehen, wir können im schlimmsten Fall nach Storypoints abrechnen. Ja, also dieses Konstrukt gibt es ja auch noch. Und wenn man jetzt um die Ecke kommt und sagt Storypoints sind weg, Sprints sind weg, wir machen es jetzt anders, dann haben die wieder keine Lösungen dafür. Und ich glaube, das sind so Themen, die uns stören. Und sie liegen nicht ans Scrum. Nein, ich gebe dir vollkommen recht, die liegen nicht ans Scrum, sondern wie im Zweifelsfall Scrum genutzt oder vielleicht manchmal sogar missbraucht wird. Ja. Ich frage mich dann in diesen Lebenszüklien, ich finde du hast das super beschrieben, wann in einer Produktphase ist Scrum wohl gut geeignet, wenn man nicht mehr in so einer Phase ist. Hab ich zumindest immer die Erfahrung gemacht, dass sich das Team eigentlich dann auch schlecht fühlt, weil sie selber wissen, eigentlich brauchen wir jetzt auch keinen Scrum oder eigentlich machen wir keinen Scrum, denn so etwas wie ein Sprintziel formulieren wird in so einer Betriebsphase ja auch immer schwieriger. Die ungeplanten Tätigkeiten steigen auf einmal, weil du in so einen Support-Modus vielleicht kommst und dann zu was hast du dich committed oder auch nicht committed. Ich glaube nach innen ist es dann wirklich viel ehrlicher zu sagen, wir wechseln den Modus, damit da bloß keine Frustration innen aufkommt und nicht innen auf einmal so eine Stimmung aufkommt, wie Scrum ist nix. Was natürlich auch geht und diese Diskussion habe ich witzigerweise letzte Woche bei uns in der Firma auch geführt. Genau in unserer Frage, ja Scrum sind wir nicht mehr happy, wir wollen jetzt auf Kanban wechseln und dann frage ich immer wieso, welche Problemen habt ihr denn mit Scrum? Ja, da kommen natürlich diese Klassiker wie Sprints passen nicht mehr und so weiter und dann sag ich ok, dann geht doch, dann macht doch Kanban. Und für mich, dass ich liebe Kanban, weil dort ganz viele tolle Sachen dabei sind, aber in den meisten Fällen haben wir keine erfahrenen Personen in den Projekten, die wissen was Kanban ist. Also so ein klassisch Kanban Master oder so. Sondern Kanban lässt sehr viel offen, also ist noch mehr Framework als Scrum und dann fange ich dann mal, was würden wir denn jetzt in Kanban machen? Wir bräuchten ja doch einen Planning-Metting und wir bräuchten doch einen Daily und die alten, die Kunden noch sprechen, ist ein Review und nur Feynman brauchen wir auch noch. Dann zieht man das von Scrum rüber. Super cool, jetzt haben wir das von Scrum rüber kopiert, jetzt müssen wir über unsere Rollen sprechen. Wir brauchen jemand, der irgendwie sagt worum es geht, Product owner, richtig, nennen wir Product owner. Dann brauchen wir jemand, der irgendwie ein bisschen Auge darauf hat auf den Prozessen, ok, das heißt nicht mehr Scrum Master, sondern Kanban Master und den Rest sind Entwickler. Ach, warte mal, jetzt haben wir das auch wieder von Scrum rüber kopiert. Und jetzt machen wir noch Aufwandschätzung. Ja, haben wir auch aus, ich sag jetzt mal aus einem ganz klassischen Scrum rüber kopiert, ja und was machen wir denn jetzt anders? Eigentlich lassen wir nur den Sprint weg, also den Sprintrahmen, damit wir oder den Sprintziel mit seinem Sprintrahmen lassen wir weg. Und dann denke ich mir so, ja ok, aber dann lass es uns doch einfach Scrum Light nennen und sagen ok, wir folgen weiterhin Scrum, aber es gibt so zwei, drei Punkte, die einfach, die wir einfach ganz bewusst weglassen aus dem und den Gründen und dann bin ich auch damit fein. Ich habe mal eine Hybrides Projektmanagement Fortbildung gemacht, die war total interessant, weil nämlich das Ergebnis war, dass wir alles, was in Scrum existiert und super beschrieben ist, ziehen wir in das Hybride Projektmanagement rüber und nennen es ein kleines bisschen anders. Und das ist der Erfolg von Scrum. Scrum ist super beschrieben, Scrum ist kurz beschrieben und man kann es einfach auch übernehmen, auch wenn es immer nicht sofort passt, aber es gibt kein zweites Framework, wo man sagt, ok, wenn es nicht in Scrum steht, nehmen wir es von woanders her. Ist nicht extrem programmierend, ist ein Sonderfall, weil es eine Softwareentwicklung ist. Ja, also genau, ich habe ja auch gesagt, oder sage ich auch immer ganz gerne, Scrum ist eine ganz gute Einstiegsdroge in die Agilität, weil ich sehe das genau wie du. Der Scrum Guide hat an vielen Stellen einfach Riesenvorteile, da sind auch unter anderem Rollen beschrieben, da sind Rituale beschrieben. Im Prinzip ist es ein super Playbook, mit dem man starten kann und deswegen, ich würde nie sagen, Scrum ist schlecht, so meine Ausdage steckt ja vor allen Dingen, wenn andere das beeinflussen oder nur Teile rausziehen, dann kann das Bösen-Einfluss auf das Team haben und auch auf das Ergebnis und auch auf die Agilität, kann ich gleich auch noch eine nette Story zu erzählen. Aber ja, ich glaube, Kanwarn ist dann erstmal deutlich schwieriger, weil schlussendlich hast du ein ganz grundsätzliches Fundament. Ja, es gibt von der Kanwarn-User-Universität ja mittlerweile auch ein Guide, aber sie versuchen nur zu verbildlichen. Unser, schlussendlich steht im Mittelpunkt Manager den Flow, starte, wo du bist, Manager den Flow und das Change Management, das ist das, was Kanwarn ist und das macht es natürlich einfach, am Anfang total schwer, weil man sich natürlich vortrefflich lange darüber unterhalten kann, welche Dinge man jetzt ja wie angeht und da hilft einem Scrum einfach. Zu dieser Geschichte, was ich erlebt habe, das habe ich letztens gelesen tatsächlich in einem größeren Slack, hat sich dann jemand schlussendlich beschwert, der ist in der QA in einem Scrum Team, aber also guckt gerne über den Tellerrand und der hatte jetzt tatsächlich vom PO vorliegen, dass der PO aufgrund der Velocity, die existiert jetzt, den Rest des Jahres geplant hat. Die haben jetzt einfach alle ihre Sprints bis Ende des Jahres vom PO durchgeplant bekommen. Das ist traurig. Habe ich aber auch Projekte schon betreut, die so ähnlich gearbeitet haben, die glaubten, dass man am Anfang des Jahres das Backlog durchschätzen kann und dann kann man damit Excel durchrechnen, wie viele Story Points pro Sprint gearbeitet werden müssen und die halt die Realität leider gar nicht beachten, dass durchaus Dinge einfach noch nicht beschrieben sind. Ja und dass wir auf Veränderungen reagieren wollen. Auf Scrum will das ja. Wir wollen ja den Feedbackzyklus haben und zu gucken, wie beeinflusst der das. Ja und das ist vor allen Dingen so immer die Beispiele, wo ich jetzt auch in dieser Podcastfolge oder in der vierten Folge einmal so drauf einsteigen wollte. Ich würde gerne noch einen Punkt ansprechen, der mir häufig auch vorkommt, wenn es um die Diskussion geht, Scrum funktioniert bei uns nicht. Da gehe ich gerne als Scrum Master in die Dailies rein und guck mal die Dailies an, weil dort wunderbar zu sehen ist, haben wir dort ein Team, ein echtes Team oder haben wir dort eine Gruppe von Menschen, die ähnliche Aufgaben machen. Häufig erlebe ich, das heißt nicht häufig, aber dort in den Gruppen, wo dann infrage steht, machen wir Scrum oder machen wir nicht Scrum, haben wir häufig eine Gruppe von Menschen, die ähnliche Aufgaben machen, die irgendwie zusammengefasst worden sind aus organisatorischen Gründen, aber so Wissensinseln vorhanden sind. So einer kümmert sich um das Thema, der eine und der zweite um das, dann gibt zwei Leute, die irgendwie noch ein anderes Legacy Tool noch mitbetreuen und wurde so ein Mischmarsch aus mehreren Menschen, aus mehreren Erfahrungen, aus mehreren Tools hast, die aber in einem Team zusammengehalten werden, weil allein gesehen würden sie kein Team ergeben. Das ist eine Gruppe von Menschen, das ist kein Team und Team bedeutet, dass das Ergebnis von der einen Person auf das Ergebnis einer anderen Person durchaus einzahlt und man untereinander abhängig ist. Wenn man eine Gruppe von Leuten hat, die in Daily einfach nur kurz berichten, was sie tun und der Rest, dem ist das egal, wenn sie von diesem Ergebnis nicht abhängig sind, ja, dann funktioniert Scrum nicht so richtig, funktioniert auch das Daily nicht richtig, weil dann wird es einfach nur so ein kurzes Berichtswesen. Wenn ich aber ein Team habe, wo der eine sagt, hier, ich habe das fertig gemacht, der andere sagt, super, jetzt kann ich endlich mit dem anfangen. Und der dritte sagt, nee, mach das, ich arbeite da dran und der vierte sagt, nee, mach mal bitte nicht, das würde ich gerne machen, du kannst mit dich, mit dem Thema weiter beschäftigen. Also sehr lebhafte Dailies stattfinden, dann verstehe ich, das ist ein Team und hier funktioniert Scrum viel besser. Also, das ist auch so ein Punkt, wo man gerne mal reingehen kann und sich überlegt, sind wir ein echtes Team oder sagen wir als moderne Menschen, okay, es ist ein Team, weil wir uns irgendwie zusammengehörig führen, aber die Ergebnisse sind entscheidend. Ja, und also das kann ich nur nochmal bestärken, vielleicht mache ich darüber auch nochmal eine Folge, ich glaube, das wäre nochmal ein ganz guter Punkt, um den rauszupicken auch, dass man, wenn solche Voraussetzungen nicht da sind, dass es schon Möglichkeiten gibt, daran auch zu arbeiten, also man kann sich mit den Leuten ja auch unterhalten, warum vermissen sie das nicht, dass jemand auch mal eine Frage stellt im Date und sagt, wie hast du das gemeint? So, da merkt man ja schon an so Kleinigkeiten, jeder erzählt was und dann gehen sie wieder auseinander und wenn man an dem Punkt nicht ist beziehungsweise nicht sieht, dass das so langsam fruchtet, ich glaube, dann ist jegliche Agilität einfach schwieriger, ob es jetzt Scrum ist oder nicht. Ja, sehr guter Punkt. Eine Sarah hat ich vorhin noch, das fand ich auch gut und das treibt mich auch immer wieder um. Ich stelle von bei mir selber manchmal fest, dass ich gar nicht so reflektiert bin und nachdenke, dieses Thema, was wir jetzt gerade bearbeiten, ist es eigentlich super repetitiv oder ist es jetzt wirklich irgendwie in dem Bereich, wo wir die Erfahrungen nicht haben und wo wir, ich sage mal, in so einer Forschung sind, denn jedes mal, wenn wir doch eher repetitive Sachen machen, kann man sich sogar grundsätzlich überlegen, muss es jetzt gerade überhaupt auf irgendeiner Art Agile sein. Für mich ist mal das Beispiel, wenn man mal definiert hat, wie so ein Golf aussieht, dann wiederholt man den Golf. Und klar, es werden schon irgendwie dann von VW auch Umfragen wahrscheinlich gemacht, was kann man beim nächsten Golf verbessern, aber diese Stückzahl, die wird so produziert und das ist ja auch fair und okay, das so zu tun. Und du hattest das so im Produktzyklus auch gesagt, wenn das Produkt so vielleicht bestimmte Phase erreicht hat, kommt sie vielleicht auch eher in so ein Modus, wo man gar nicht mehr so viel von der fundamentalen Agilität braucht. Ja, ja, sehe ich auch so. Zum Beispiel mit dem Golf, ich halte mich da mal ganz bewusst raus, weil ich da Industrieerfahrungen durchaus habe und da Dinge und Naturgemäß jetzt anders sehe, aber ich will da jetzt erstmal nicht weiter hingehen, weil wahrscheinlich das Bild für dich, genau. Aber für mich ist es immer so ein schönes Bild, weil man sich es gut anfassen und vorstellen kann, okay, ja stimmt, der Golf ist einmal definiert und dann wird er produziert so. Aber ja, wahrscheinlich ist es gar nicht so. Ja, genau. Vor allem nicht jetzt mehr, wo die Fahrzeuge sehr softwarelastig werden. Ja, okay, ja, ja, stimmt, soweit habe ich gar nicht gedacht. Ich denke tatsächlich so an meinen alten Golf Einzel, Schaltwagen. Ja, super. Hast du denn sonst noch Themen? Hast du sonst noch Dinge rund um die Folge oder was dich so bei Scrum berührt, was du mir schon immer sagen wolltest? Nein, ich glaube, die wichtigsten Themen haben wir so besprochen. Ja, gibt es wahrscheinlich noch im Detail noch ein weiteres Thema, aber ich glaube so ein großes, ganz rundes Gesprächspaket hier gemacht. Super, dann habe ich noch eine Abschlussfrage. Was ist dein coolstes Agiles-Erlebnis? Mein coolstes Agiles-Erlebnis, ich denke gerade so irgendwie so an Retrospectiven, also ich liebe so Retrospectiven vorzubereiten, durchzuführen und das ist jedes mal irgendwie so ein Überraschungspaket funktioniert, funktioniert es nicht. Und da sind immer ganz viele Retros, die immer wieder in Erinnerung bleiben, die irgendwie kult geworden sind. Wenn ich da jetzt irgendwie an eine Retro denke, die hat leider nur in diesem einen Team wirklich mal funktioniert und das, ich weiß nicht, man kennt bestimmt diese drei Schweinchen, das ist so diese Geschichte mit drei Schweinchen und dem Wolf und das ist, glaube ich, eine der ersten animierten Disneyfilme gewesen oder Kurzfilme. Und das habe ich als Aufhänger genommen für ein Retro, wo es darum geht, wie weit sind wir denn eigentlich mit unserer Software, wir waren vom Wechsel von einem normalen Server in die Cloud gewesen und da wollte ich einfach mal so Themen sammeln. Was ist unsere Strohhütte? Also was ist total wackelig? Was sind unsere Holzhütte? Was steht schon solide? Und was ist unsere Steinhütte? Was steht total auf Stein? Da haben wir das mal so gesammelt und das ist dann in den Monaten, Jahren danach immer wieder so als Aufhänger gekommen, weil ich auch dieses Video, das läuft irgendwie drei Minuten nur, so eingespielt habe. Das ist irgendwie immer in Erinnerung geblieben. Das ist so ein cooles, agiles Erlebnis, wo man sagt, wenn der Retro einfach zur Erinnerung bleibt. Ja, super. Ja, das ist doch ein perfekter Abschluss. Mako, nochmal ganz ganz vielen Dank für deine Zeit. Ich bin mir ziemlich sicher, das wird nicht das einzige Mal sein. Wenn du noch Lust hast, dass wir uns in so einer Folge mal wiedersehen. Ja, sehr gerne. Und ja, wir lesen uns ja auch vielleicht ab und zu mal wieder im Forum. Ja, bestimmt. Leiner Aufruf an alle Hörer da draußen kommt uns Forum. Ja, genau. Da sage ich danach auch nochmal was dazu und auch den gibt es natürlich in den Show Notes. Ja. Dann Mako, vielen vielen Dank und ja, wir hören sehen und lesen uns. Mach's gut. Ja, dir auch vielen Dank. Ciao. Ciao. Ja, Mako, nochmal an dieser Stelle ganz ganz vielen Dank für deine Zeit. Grüße gehen raus. Das hat sehr viel Spaß gemacht. Und Mako und ich, wir sind sehr gespannt auf euer Feedback. Wenn du Feedback hast, dann erreichst du mich auf verschiedenen Kanälen. Unter anderem kannst du mir eine Mail schreiben an nobs@gmail.com. Du findest mich sonst auch noch auf Mastodon und es gibt das von Mako ja auch nochmal angeteaserte Forum. Allerdings findest den Show Notes. Im Forum ist es so, dass ich zu jeder Folge da ein Thread anlege. Aber ich freue mich auch, wenn ihr selber da Themen einstellt. Die Idee hinter dem Forum ist halt tatsächlich zu sagen, ich möchte ganz gerne so eine offene Treffpunkt haben. Versuche das mit so einem Forum. Das ist eine moderne Forum Software, die meiner Meinung nach super gut funktioniert. Und das soll so ein bisschen der Gegenpol sein zu den ganzen Slacks und Discords, die es so gibt. Die sind ja immer hinter so einem Login versteckt. Das Forum ist öffentlich erreichbar. Das ist von Google indizierbar. Ich finde es eigentlich immer ein bisschen besser, das so offen und transparent zu machen, damit auch mehr Leute was davon haben. Wenn du auch Lust hast mit mir über agile Themen hier im Podcast zu sprechen, dann melde ich auch sehr gerne. Tatsächlich suche ich weiter Gesprächspartner. Und ja, deswegen wenn du Lust hast, hier der Aufruf, melde ich gerne auf den ja eben gerade erzählten Kanälen bei mir. Habt noch eine ganz tolle Woche und bis zum nächsten Mal. Bye. [Musik]