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

Shownotes

Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/41-nba25-im-gespraech-marco-von-scrumschau-ueber-scrum 

—

Marco

• Mastodon: https://mastodon.social/@scrumschau/
• SCRUMschau: https://scrumschau.wordpress.com/

Letzte Folge NBA24: Das Schwungrad

• https://no-bullshit-agile.de/nba24-das-schwungrad.html

NBA04: Scrum: Warum es Zeit ist, ein anderes agiles Vorgehen zu erwägen

• https://no-bullshit-agile.de/nba04-scrum-warum-es-zeit-ist-ein-anderes-agiles-vorgehen-zu-erwaegen.html

Zusammenfassung

In der aktuellen Folge von No Bullshit Agile, Episode 25, spricht Thomas mit Marco von Scrumschau über seine langjährige Erfahrung mit Scrum und agile Softwareentwicklung. Marco, der über zehn Jahre als Scrum Master und Agile Coach tätig ist, erklärt, wie er seine Leidenschaft für Scrum entdeckt hat und wie sein Blog Scrumschau als persönliche Lernreise begann.

Das Gespräch beleuchtet, wie Scrum als "Einstiegsdroge" in die Agilität fungieren kann, insbesondere wenn Teams erstmals agil arbeiten und Herausforderungen meistern wollen. Marco und Thomas diskutieren die Vor- und Nachteile von Scrum, einschließlich der Frage, ob Story Points und Velocity wirklich notwendige Metriken sind oder ob sie den agilen Prozess eher behindern. Marco teilt seine Erfahrungen und Überlegungen zur Schätzung von Aufgaben und wie es manchmal besser sein kann, ganz auf solche Metriken zu verzichten.

Zusätzlich wird erörtert, wie Scrum in unterschiedlichen Phasen des Produktlebenszyklus unterschiedlich nützlich sein kann. Marco hebt hervor, dass Scrum in komplexen, dynamischen Umfeldern besonders effektiv ist, während für langfristige Wartungsaufgaben Kanban oder andere Methoden geeigneter sein könnten.

Das Gespräch schließt mit der Diskussion, wie Scrum oft missbraucht oder falsch verstanden wird, insbesondere wenn es um das Management von Projekten geht. Marco betont, dass die Herausforderung nicht im Framework selbst liegt, sondern in der Art und Weise, wie es umgesetzt wird.

Transkript

Hallo und herzlich willkommen bei No Bullshit 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. Mein Fokus liegt auf der Praxis, daher eben auch der Name No Bullshit 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. Dies ist die Folge 25 und heute freue ich mich ganz besonders, denn ich habe einen Gast: den Marco von Scrumschau. Mit ihm 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 dazu erzählen. Wir tippsen uns ja immer mal wieder ein bisschen an bei ein paar Themen. Dein Hauptthema ist ja Scrum. Bevor wir da einsteigen, willst du vielleicht ein paar Sätze über dich erzählen?

Ja, sehr gerne. Ich heiße Marco und bin seit über zehn Jahren im Bereich der agilen Softwareentwicklung unterwegs. Dort eigentlich immer als Scrum Master oder Agile Coach, wie man das auch nennen möchte, und habe großen Gefallen an Scrum gefunden. In deiner Folge Nummer 4 hast du gesagt, dass Scrum so die Einstiegsdroge in der Agilität ist. Ja, das ist auch mein Eindruck.

Genau, ich habe das exakt auch so erlebt. Wir haben die ersten Jahre agil gearbeitet, ohne dass wir wussten, dass wir agil arbeiten. Ich hätte gesagt, so ein Atorq, mein damaliger Produktowner und Projektleiter, hat jede zweite Woche irgendwie neue Ideen eingebracht. Es war alles irgendwie komisch, und dann sind wir auf Scrum gekommen, haben Scrum im Team eingeführt und hatten viel Spaß und Freude dabei. Wir konnten damit auch Probleme lösen, die prozessseitig vorher bestanden.

Als ich dann, nach zwei, drei Jahren mit Scrum gearbeitet hatte, fragte ich mich: Wie geht es weiter? Wie kann ich etwas Neues lernen? Ich begann, ein paar Links im Internet zu finden und zu lesen. Vor ein paar Jahren war das Bloggen noch ein auslaufender Hype, und ich dachte mir: „Okay, probier es aus.“ Dieser Blog sollte einfach meine Lernreise unterstützen und mich motivieren.

Ich finde es super. Daraus entstand dann der Twitter-Account, und bei Twitter traf mich die volle Breitseite an noch mehr Links und Infos. Twitter ist jetzt raus, jetzt ist es bei Mastodon etwas ruhiger. Also, eigentlich ist Scrumschau meine Lernreise und mein Versuch, alles, was ich gelernt habe, zusammenzufassen.

Den Link gibt es natürlich in den Shownotes. Ich kann es wirklich nur jedem empfehlen, mal reinzugucken. Gerade dieser Blick auf die eigene Reise finde ich für Blogs immer total angenehm, weil er den persönlichen Touch hat. Diese Perspektive auf ein Thema, die man selbst mitbringt, ist immer total interessant und sicherlich auch für viele andere interessant.

Ja, und das ist jetzt leider ein bisschen ruhiger geworden, weil meine Lernreise so weit gekommen ist und ich inzwischen in anderen Firmen arbeite, wo Agilität noch viel mehr gelebt wird. Daher ist die öffentliche Lernreise im Blog weniger sichtbar, aber das Blog lebt noch.

Genau, und das ist ja auch gut, wenn man sowas weiterleben lässt. Viele Sachen stimmen immer noch, und es hängt auch davon ab, in welcher Phase man sich gerade befindet – ob es das Unternehmen oder die Kunden sind. Daher finde ich es super, solche Dokumente noch im Zugriff zu haben.

Magst du denn mal sagen, wie groß ihr heute seid? Natürlich musst du keine Details nennen, aber vielleicht haben die Zuhörer so ein bisschen Orientierung.

Wir entwickeln Individualsoftware für große Industriekunden und sind bei uns in der direkten Firma so 150 Leute, in Richtung 200 Leute, an mehreren Standorten deutschlandweit und international. Wir sind in einem Großkonzern mit mehreren tausend Leuten eingegliedert, und jede Tochterfirma hat ihre Spezialisierung. Nicht jede Tochterfirma arbeitet agil. Unsere Firma macht agile Softwareentwicklung.

Okay, cool. Und das machen dann alle, also wirklich im Prinzip die 150?

Genau, die 150 Entwickler machen ganz klassisch agile Softwareentwicklung, und Wasserfall ist dort verpönt.

Ja, super. Ich glaube, wir werden immer wieder darauf zurückkommen. Unser Anlass für das Gespräch war auch, dass ich in Folge 4, die ich natürlich auch verlinke, meine Erfahrungen zusammengefasst und den Scrum Guide ein bisschen analysiert habe. Der Titel war: „Ist Scrum noch das Richtige?“ – ich habe es ein bisschen reißerisch genannt, wie man das im Internet so macht. Warum es Zeit ist, ein anderes agiles Vorgehen zu erwägen, habe ich zumindest genannt. Da hattest du ja auch gesagt, dass es Punkte gibt, die man Scrum nicht unbedingt anlasten sollte, sondern die eher die Möglichkeiten darstellen, wie man es im Unternehmen umsetzen kann. Vielleicht möchtest du ein paar Punkte nennen, wo du siehst, dass man das auch anders betrachten könnte?

Ja, genau, vielleicht erste Worte dazu: Ich glaube, es gibt wenig richtig und falsch. Es bringt sehr viel, wenn man sich im Austausch darüber Gedanken macht, und das machen wir hier gerade. Eine Sichtweise, die du in Folge 4 viel genannt hast, betrifft das Thema Velocity. Velocity, Storypoints, Storypoint-Schätzung und so weiter. Das ist für mich immer der erste Punkt, wo ich hellhörig werde. Wenn ich lese oder höre, dass Scrum bei uns nicht funktioniert, weil Velocity oder Storypoints blöd sind, frage ich mich immer: Warum macht ihr das Ganze? Warum macht ihr die Storypoints? Warum macht ihr die Velocity? Wenn die Antwort ist: „Na, weil Scrum das vorschreibt“, frage ich immer ganz gerne: „Aber seit einigen Jahren spielt das Thema Schätzung eigentlich keine Rolle mehr.“ Das Scrum Guide ändert sich immer wieder mal, und in der neuesten Version wird Schätzen nicht mehr thematisiert. Es gibt sogar eine Strömung, die sich „No Estimation“ nennt. Diese sagen von vornherein, dass Schätzen nicht unbedingt erfolgreicher macht. Ich habe das in einigen Teams ausprobiert und festgestellt: Wenn wir das Schätzen weglassen, ändert sich nichts.

Also, ein Storypoint-Wert führt nicht dazu, dass eine Entwicklungsaufgabe schneller umgesetzt wird. Es ist völlig egal, ob da 100 Storypoints oder nur ein Storypoint dransteht – die Aufgabe dauert eben so lange, wie sie dauert. Die Entwickler haben mich darum gebeten, trotzdem Storypoints zu verwenden, weil sie einen Wert an eine Story haben wollten, um im Sprint eine bessere Vorstellung davon zu bekommen, ob es sich um eine große oder kleine Aufgabe handelt.

In dem Projekt, in dem ich aktuell noch tätig bin, haben wir uns dann auf T-Shirt-Größen geeinigt. Weil wir keine Zahlenwerte brauchten, spielt die genaue Anzahl der Storypoints überhaupt keine Rolle. Ich wünschte mir, dass ich mal ein Projekt habe, in dem ich ganz radikal vorgehen kann.

Jetzt kommen wir zu der Frage, wie wir mit der Velocity echten Mehrwert schaffen können und warum wir das Thema Velocity überhaupt behandeln. Was wäre, wenn wir Storypoints zur Aufwandschätzung verwenden und das in der Sprint-Planung nutzen? Die Aufwandschätzung soll dazu dienen, grob abzuschätzen, ob wir das im Sprint schaffen können oder nicht. Was passiert, wenn ich am Ende des Plannings sage, dass wir alle Storypoints von den Stories löschen, weil der Zweck erfüllt ist? Unser Planning haben wir abgeschlossen. Das macht halt niemand, weil wir jetzt ins Management-Thema einsteigen. Was du ein bisschen angesprochen hast, ist, dass wir die Storypoints dranlassen, um später irgendwelche Velocities auszurechnen, was man dann als Mittelwert betrachten könnte. Die Erfahrung zeigt jedoch, dass das meistens nicht funktioniert. Ich erlebe selten Sprints, in denen die Velocity konstant bleibt. Sie variiert aufgrund von Urlaub, Feiertagen und anderen Faktoren.

Wenn ich auf ein halbes Jahr zurückblicke und die einzelnen Sprints betrachte, kann ich mich nicht mehr genau erinnern, warum die Velocity mal höher und mal niedriger war. Daher ist die Velocity für uns im Planning hilfreich, aber danach könnten wir sie eigentlich wegwerfen. Alles andere, was wir tun, um sie zu behalten und für Reporting-Zwecke zu nutzen, nimmt uns den Spaß daran.

Ich kann dir da nur zustimmen. Auch wir haben fünf Jahre lang Hardcore-Scrum gemacht, als der Scrum Guide noch etwas älter war. Das Commitment, das das Team für den Sprint abgibt, war damals eher auf Wettervorhersage-Niveau. Niemand wurde bestraft, wenn die Punkte nicht erreicht wurden. Es diente nur als Vorhersage. Was ich beim Sprint Planning immer sehr positiv fand, war die Diskussion, die entstanden ist, wenn die Schere in den Storypoints im Team zu weit auseinander ging. Diese Diskussion war sehr wertvoll, um zu verstehen, ob jemand die Komplexität unterschätzt hat.

Das ist die Methodik des Poker Plannings, bei dem solche Diskussionen super spannend sind. Ich kann Poker Planning auch ohne Story Points durchführen. Es ist hilfreich, wenn wir feststellen, dass einer die Aufgabe groß und der andere klein sieht. Dann kann ich die Diskussion vertiefen und sicherstellen, dass wir ein gemeinsames Verständnis haben, ohne dass wir unbedingt Story Points ermitteln müssen.

Wenn ich jetzt nochmal radikal denke und in die Agilität eintauche, würde ich sagen, dass wir kein oder nur sehr wenig Refinement im Scrum benötigen. Wenn wir zu viel Refinement vor dem Planning machen, geraten wir in einen kleinen Wasserfall. Eigentlich wollen wir mit Scrum agil sein. Im Sprint Planning sollte es ausreichen, wenn wir die Aufgaben oder Ideen, die wir umsetzen wollen, soweit verstanden haben, dass wir das Ziel kennen und keine größeren Blocker erwarten. Das Refinement kann auch innerhalb des Sprints erfolgen.

Das ist ein Punkt, dem ich voll zustimme. Scrum sollte als Framework verstanden werden, und es gibt oft Diskussionen darüber, ob Scrum als Management Reporting Tool verwendet wird. Es wird oft von außen als solches gesehen, obwohl das nicht die ursprüngliche Intention von Scrum war. Die Elemente, die das Management benötigt, können implementiert werden, aber sie können auch weggelassen werden.

Das Management verwendet diese Tools, weil es messbare Punkte wie die Velocity benötigt, um Fortschritte zu visualisieren. Allerdings gibt es oft Konflikte, weil Dev-Teams Schwierigkeiten haben, ihr Scrum zu verteidigen. Kunden und Management erkennen zunehmend den Wert von Scrum, und manchmal greifen sie so stark ein, dass das ursprüngliche Scrum-Konzept in den Hintergrund tritt.

Der Product Owner, der oft vom Kunden gestellt wird, ist ein weiteres Problem. Er ist Teil des Scrum Teams, aber nimmt sich manchmal heraus. Mit dem neuen Scrum Guide ist das Team das gesamte Scrum Team, einschließlich des Product Owners und des Scrum Masters. Das Scrum Team sollte sich auf ein Sprintziel committen und nicht auf eine Liste von Aufgaben. Das ist der Punkt, an dem Scrum gut oder weniger gut funktioniert.

Es ist schwierig, ein Sprintziel zu definieren, aber es ist wichtig, dass das Team sich darauf committen kann. Wenn das Sprintziel nicht klar ist, kann Scrum Schwierigkeiten haben. In vielen Teams wird die Liste an Aufgaben zusammengestellt und es entsteht die Erwartung, dass alles geliefert wird. Aber Scrum soll auf das Sprintziel abzielen, und es ist akzeptabel, wenn neue Aufgaben hinzugefügt oder entfernt werden, um das Ziel zu erreichen.

Scrum ist nicht immer für den gesamten Produktlebenszyklus geeignet. Es funktioniert gut in einem komplexen Umfeld, in dem viele Dinge noch unbekannt sind, und beim Entwickeln neuer Features. Für langfristige Wartungsaufgaben, bei denen es weniger um komplexe Neuerungen geht, könnte Kanban sinnvoller sein. Manchmal wollen Kunden jedoch bei Scrum bleiben, weil sie an den Zeitboxen und regelmäßigen Reviews gewöhnt sind und diese Struktur für Rechnungsstellungen nutzen.

Ja, aber da hat man Gründe und all das auch ohne Scrum machen. Also einen Rechnungsrhythmus, den kann man ja, wie ich ihn definiere, und regelmäßige Meetings halte ich eh immer für sinnvoll. Die kann man ja auch zweiwöchentlich oder vierwöchentlich ansetzen. Ja, genau. Aber das muss halt auch von der beauftragenden Organisation 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, dass Agilität auch abgerechnet werden kann. 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 Story Points abrechnen. Ja, also dieses Konstrukt gibt es ja auch noch. Und wenn man jetzt um die Ecke kommt und sagt, Story Points 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 am Scrum. Nein, ich gebe dir vollkommen recht, die liegen nicht am Scrum, sondern daran, wie im Zweifelsfall Scrum genutzt oder vielleicht manchmal sogar missbraucht wird.

Ja, ich frage mich dann in diesen Lebenszyklen, 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, habe ich zumindest immer die Erfahrung gemacht, dass sich das Team dann auch schlecht fühlt, weil sie selber wissen, dass sie jetzt keinen Scrum brauchen oder keinen Scrum machen, 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 nichts.

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 Probleme habt ihr denn mit Scrum? Ja, da kommen natürlich diese Klassiker wie Sprints passen nicht mehr und so weiter. Dann sage ich, okay, dann geht doch, dann macht doch Kanban. Und für mich, 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, ist noch mehr Framework als Scrum. Dann fange ich dann mal an, was würden wir denn jetzt in Kanban machen? Wir bräuchten ja doch ein Planning-Meeting und wir bräuchten doch ein 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überkopiert, 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 auf den Prozessen hat, okay, 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überkopiert. Und jetzt machen wir noch Aufwandschätzungen. Ja, haben wir auch aus, ich sage jetzt mal, aus einem ganz klassischen Scrum rüberkopiert, und was machen wir denn jetzt anders? Eigentlich lassen wir nur den Sprint weg, also den Sprintrahmen und das Sprintziel, den lassen wir weg. Und dann denke ich mir so, ja, okay, aber dann lass es uns doch einfach Scrum Light nennen und sagen, wir folgen weiterhin Scrum, aber es gibt so zwei, drei Punkte, die wir 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, in das hybride Projektmanagement rüberziehen und es ein kleines bisschen anders nennen. 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 manchmal nicht sofort passt. Aber es gibt kein zweites Framework, bei dem man sagt, okay, 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. Der Scrum Guide hat an vielen Stellen einfach Riesenvorteile. Da sind unter anderem Rollen beschrieben, da sind Rituale beschrieben. Im Prinzip ist es ein super Playbook, mit dem man starten kann. Und deswegen würde ich nie sagen, Scrum ist schlecht. Meine Aussage steckt ja vor allem darin, 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, Kanban ist dann erstmal deutlich schwieriger, weil schlussendlich hast du ein ganz grundsätzliches Fundament. Ja, es gibt von der Kanban-User-Universität ja mittlerweile auch einen Guide, aber sie versuchen nur zu verbildlichen. Unser, schlussendlich steht im Mittelpunkt: Manage den Flow, starte, wo du bist, manage den Flow und das Change Management. Das ist das, was Kanban ist, und das macht es natürlich am Anfang total schwer, weil man sich natürlich vortrefflich lange darüber unterhalten kann, welche Dinge man jetzt wie angeht. Da hilft einem Scrum einfach.

Zu dieser Geschichte, was ich erlebt habe, das habe ich letztens tatsächlich in einem größeren Slack gelesen. Da hat sich dann jemand schließlich beschwert, der ist in der QA in einem Scrum Team, aber also guckt gerne über den Tellerrand. Der hatte jetzt tatsächlich vom PO vorliegen, dass der PO aufgrund der Velocity, die existiert, 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. Die Realität wird leider gar nicht beachtet, dass durchaus Dinge einfach noch nicht beschrieben sind. Ja, und dass wir auf Veränderungen reagieren wollen. Scrum will das ja. Wir wollen ja den Feedbackzyklus haben und gucken, wie das beeinflusst.

Das ist vor allem so ein Punkt, den ich in dieser Podcastfolge oder in der vierten Folge einmal so drauf eingehen wollte. Ich würde gerne noch einen Punkt ansprechen, der mir häufig vorkommt, wenn es um die Diskussion geht, Scrum funktioniert bei uns nicht. Da gehe ich gerne als Scrum Master in die Dailies rein und schaue mir 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, dass in den Gruppen, wo dann infrage steht, machen wir Scrum oder machen wir nicht Scrum, wir häufig eine Gruppe von Menschen haben, die ähnliche Aufgaben machen, die irgendwie zusammengefasst worden sind aus organisatorischen Gründen, aber so Wissensinseln vorhanden sind. Einer kümmert sich um das Thema, der andere um das, dann gibt es zwei Leute, die irgendwie noch ein anderes Legacy-Tool mitbetreuen und das ist ein Mischmasch aus mehreren Menschen, aus mehreren Erfahrungen, aus mehreren Tools. Die werden in einem Team zusammengehalten, 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 einzahlt und man untereinander abhängig ist. Wenn man eine Gruppe von Leuten hat, die im Daily einfach nur kurz berichten, was sie tun, und der Rest ist das egal, weil sie von diesem Ergebnis nicht abhängig sind, dann funktioniert Scrum nicht so richtig, funktioniert auch das Daily nicht richtig, weil es dann einfach nur so ein kurzes Berichtswesen wird. 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 daran, und der vierte sagt, nee, mach mal bitte nicht, das würde ich gerne machen, du kannst dich mit dem Thema weiter beschäftigen. Also sehr lebhafte Dailies, dann verstehe ich, dass es ein Team ist und hier funktioniert Scrum viel besser. Das ist auch so ein Punkt, den man gerne mal überprüfen kann und sich überlegen sollte, sind wir ein echtes Team oder sagen wir als moderne Menschen, okay, es ist ein Team, weil wir uns irgendwie zusammengehörig fühlen, aber die Ergebnisse sind entscheidend. Ja, und 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. Wenn solche Voraussetzungen nicht da sind, gibt es Möglichkeiten, daran zu arbeiten. Man kann sich mit den Leuten ja auch unterhalten, warum vermissen sie das nicht, dass jemand auch mal eine Frage im Daily stellt und sagt, wie hast du das gemeint? Da merkt man ja schon an so Kleinigkeiten. Jeder erzählt etwas und dann gehen sie wieder auseinander. Wenn man an dem Punkt nicht ist beziehungsweise nicht sieht, dass das so langsam fruchtet, glaube ich, wird jegliche Agilität einfach schwieriger, ob es jetzt Scrum ist oder nicht.

Ja, sehr guter Punkt. Eine Sache hatte ich vorhin noch, das fand ich auch gut und das treibt mich auch immer wieder um. Ich stelle 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 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 irgendeine Art agil sein? Für mich ist mal das Beispiel, wenn man mal definiert hat, wie so ein Golf aussieht, dann wird er wiederholt. Und klar, es werden schon irgendwie von VW auch Umfragen wahrscheinlich gemacht, was kann man beim nächsten Golf verbessern, aber diese Stückzahl 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 vielleicht eine bestimmte Phase erreicht hat, kommt es vielleicht auch eher in so einen Modus, wo man gar nicht mehr so viel von der fundamentalen Agilität braucht.

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 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 mehr, wo die Fahrzeuge sehr softwarelastig werden.

Ja, okay, 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, es gibt wahrscheinlich noch im Detail noch ein weiteres Thema, aber ich glaube, so ein großes, rundes Gesprächspaket haben wir hier gemacht.

Super, dann habe ich noch eine Abschlussfrage: Was ist dein coolstes Agiles-Erlebnis?

Mein coolstes Agiles-Erlebnis? Ich denke gerade so an Retrospektiven. Also ich liebe es, Retrospektiven vorzubereiten und durchzuführen. Das ist jedes Mal irgendwie so ein Überraschungspaket: funktioniert es, 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 Disney-Filme 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, bei dem 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, dass wir uns in so einer Folge wiedersehen. Ja, sehr gerne. Und ja, wir lesen uns ja auch vielleicht ab und zu mal wieder im Forum.

Ja, bestimmt. Kleiner Aufruf an alle Hörer da draußen: Kommt ins Forum. Ja, genau. Da sage ich danach auch nochmal was dazu und auch den gibt es natürlich in den Show Notes. Im Forum ist es so, dass ich zu jeder Folge einen Thread anlege. Aber ich freue mich auch, wenn ihr selbst Themen einstellt. Die Idee hinter dem Forum ist tatsächlich, einen offenen Treffpunkt zu schaffen. Ich versuche es 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 zu den ganzen Slacks und Discords sein, die es so gibt. Die sind ja immer hinter einem Login versteckt. Das Forum ist öffentlich erreichbar, von Google indizierbar. Ich finde es eigentlich immer ein bisschen besser, das so offen und transparent zu machen, damit auch mehr Leute etwas davon haben.

Wenn du auch Lust hast, mit mir über agile Themen hier im Podcast zu sprechen, dann melde dich auch sehr gerne. Tatsächlich suche ich weiter Gesprächspartner. Und ja, deswegen, wenn du Lust hast, hier der Aufruf: Melde dich gerne auf den eben gerade erzählten Kanälen bei mir. Habt noch eine ganz tolle Woche und bis zum nächsten Mal. Bye.

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 nobsagile@gmail.com. Du findest mich auch noch auf Mastodon und es gibt das von Mako ja auch nochmal angeteaserte Forum. Allerdings findest du den Link in den Show Notes. Im Forum ist es so, dass ich zu jeder Folge einen Thread anlege. Aber ich freue mich auch, wenn ihr selbst Themen einstellt. Die Idee hinter dem Forum ist, einen offenen Treffpunkt zu schaffen. Es ist eine moderne Forum-Software, die meiner Meinung nach super gut funktioniert. Und das soll so ein bisschen der Gegenpol zu den ganzen Slacks und Discords sein, die es so gibt. Diese sind ja immer hinter einem Login versteckt. Das Forum ist öffentlich erreichbar und von Google indizierbar. Ich finde es eigentlich besser, das so offen und transparent zu machen, damit auch mehr Leute etwas davon haben.

Wenn du auch Lust hast, mit mir über agile Themen hier im Podcast zu sprechen, dann melde dich auch sehr gerne. Tatsächlich suche ich weiterhin Gesprächspartner. Und ja, deswegen, wenn du Lust hast, hier der Aufruf: Melde dich gerne auf den eben gerade erzählten Kanälen bei mir. Habt noch eine ganz tolle Woche und bis zum nächsten Mal. Bye.