NBA72: A Simple Guide To Scrum

00:00:00: Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Jede Woche spreche

00:00:08: ich hier kurz und knapp über Themen rund um agiles Arbeiten. In der letzten Folge ging es

00:00:12: um das Scrum Guide Expansion Pack und meine Meinung dazu. Wenn dich das interessiert,

00:00:17: hör da gerne rein. Den Link zu der Folge und alle weiteren Links, die ich hier erwähne,

00:00:22: die findest du, wie sich das gehört, in den Shownotes. Heute in Folge 72 geht es um den

00:00:28: kompletten Gegenentwurf dazu, nämlich A Simple Guide to Scrum. Das ist von Tobias

00:00:35: Meier und Bob Hartmann. Ich bin unsicher, ob das irgendwie durch Zufall mehr oder weniger zur

00:00:42: gleichen Zeit veröffentlicht wurde, wie das Expansion Pack oder ob das kein Zufall ist.

00:00:48: Vielen Dank tatsächlich an Stefan Rook an dieser Stelle. Grüße gehen raus. Mit dem habe ich mich

00:00:55: in dem Mastodon Thread zu dem Expansion Pack beziehungsweise zu meiner Folge zum Expansion

00:01:00: Pack unterhalten. War wirklich eine sehr nette Unterhaltung, spannende Punkte und Stefan machte

00:01:07: mich eben genau auf diesen Simple Guide aufmerksam. Und da habe ich mir gleich schon

00:01:13: gedacht, oh ja, das könnte ein Thema für die nächste Folge sein. Okay, ich würde sagen,

00:01:18: wir steigen mal ein. Worum geht es? Damit wollen wir mal anfangen. Wir haben den, ich nenne ihn

00:01:23: jetzt mal klassischen Scrum Guide. Aktuellste Version von 2020. Der hat so gefühlte zwölf

00:01:30: Seiten. Und dann ist eben das Scrum Guide Expansion Pack letzte Woche erschienen. Wie gesagt,

00:01:40: hatte ich schon eine Folge drüber gemacht. Das hat so gefühlte 40, 42 Seiten. Und ziemlich zur

00:01:48: gleichen Zeit wurde A Simple Guide to Scrum veröffentlicht. Das ist gefühlt eine Seite. Und

00:01:56: ja, das ist schon erstaunlich. Ich kann ja mal kurz erzählen, wie sieht diese Seite aus? Was

00:02:03: steht da drauf? Ihr findet den Link natürlich in den Shownotes. Ja, da wird einmal erklärt,

00:02:08: das hier ist das Scrum Team. Das sind die drei Accountabilities, also Developer, Product Owner,

00:02:15: Scrum Master. Dann ist das nächste. Das sind die Commitments, die ihr eingeht. Product Goals,

00:02:21: Sprint Goal und Definition of Done. Dann ist der nächste Abschnitt. Das sind die Artifacts,

00:02:27: die ihr betrachtet. Product Backlog, Sprint Backlog und Increment. Und dann kommt der

00:02:32: Abschnitt Events. Das sind die Events, die ihr habt. Sprint, Sprint Planning, Daily Scrum,

00:02:37: Sprint Review und Sprint Retrospective. Und dann gibt es noch einen kleinen Abschlusssatz. Und

00:02:42: das war es schon. Also könnte es als eine Kurzzusammenfassung des Scrum Guides verstehen.

00:02:49: Und von Stefan kam dann tatsächlich in diesem erwähnten Mastodon Thread eine sehr gute Frage

00:02:57: auf. Und die die Frage oder die These von Stefan war, kann jemand ohne Scrum Praxiserfahrung mit

00:03:04: den zusätzlichen Infos im Scrum Guide wirklich was Nützliches anstellen? Zusätzliche Infos meint er

00:03:11: an dieser Stelle all das, was jetzt im Scrum Guide steht, was in dem Simple Guide eben nicht

00:03:18: drin steht. Also elf Seiten Unterschied. Und ja, wie schon gesagt, da startete ein spannendes

00:03:25: Gespräch darüber. Meine Meinung ist, die Antwort auf diese These oder hypothetische Frage ist Nein,

00:03:33: kann ein Team nicht. Ich glaube, je mehr Infos man zu diesem Framework ergänzt und je mehr man

00:03:41: erklärt, desto mehr schränkt man es auch gleichzeitig ein. Viele Teams führen eine agile

00:03:47: Methode wie dann zum Beispiel Scrum ein und erwarten halt irgendwie auch sofort Wunder.

00:03:53: Und was ich hier immer wieder sage und was ich in der Praxis wirklich selber erlebt habe, ist nur

00:04:01: dadurch passieren halt keine Wunder. Es nützt halt nichts, einfach nur so einen Leitfaden zu

00:04:07: folgen. Also um das vielleicht noch mal zu erzählen für die, die es noch nicht so mitgekriegt haben.

00:04:11: Vor vielen Jahren haben wir bei uns mal Scrum eingeführt. Ich habe damals gesagt, weil das

00:04:17: mein Wissen war, also wir halten uns wirklich komplett und ganz strikt an den Scrum Guide.

00:04:23: Wir wollen nichts verwässern, sondern wir wollen die Methode genau so machen, wie sie gedacht ist.

00:04:28: Und ja, dann war meine Schlussfolgerung und dann sind wir agil. Heute weiß ich, nein, so ist das

00:04:35: natürlich nicht. Dem Vergangenheitsthomas würde ich dazu auch gerne was erzählen, kann ich natürlich

00:04:41: nicht. Der Vergangenheitsthomas konnte das aber auch alles noch gar nicht wissen. Und ich vermute,

00:04:46: dass viele Teams einfach auch an so einer Stelle sind und sich dann nicht weiterentwickeln,

00:04:51: sondern sagen, ja Scrum funktioniert bei uns nicht. Ich weiß eben und ich vermute, ihr wisst es tief

00:04:58: in mir dann auch, nur das Befolgen einer Methode, das hat gar nicht mal so viel mit Agilität zu tun,

00:05:04: komme ich gleich auch noch drauf, ist kein Garant, ein bestimmtes Ziel dieser Methode zu erreichen.

00:05:10: Also in unserem Fall kein Garant für agiles Arbeiten. Es gibt noch eine ganz große Gefahr,

00:05:15: die schwebt immer über allen, nämlich Cargo-Kult. Auch dazu habe ich mal eine Folge gemacht. MBA 65

00:05:23: ist das Cargo-Kult-Agilität, wenn man Agilität nur spielt. So, das ist also so die Situation und

00:05:33: das Problem. Und natürlich habe ich mich gefragt, okay, was ist denn die Lösung? Und da möchte ich

00:05:40: tatsächlich auf eine weitere Folge hinweisen, nämlich MBA 31 Shuuhari. Da hatte mich der Thomas

00:05:49: Michel mal draufgebracht. Schöne Grüße an dieser Stelle. Shuuhari beschreibt drei Lernphasen, kommt

00:05:56: aus dem japanischen, ich spreche es wahrscheinlich komplett falsch aus, verzeiht es mir bitte. Genau,

00:06:02: und beschreibt drei Phasen. Es gibt die erste Phase Shuuhari, da lernt man die Grundlagen und

00:06:08: folgt den Regeln. In der zweiten Phase, dem H, beginnt man diese Regeln zu hinterfragen und auch

00:06:14: anzupassen. Und in der letzten Phase, in der Re-Phase, erreicht man dann so eine Meisterschaft

00:06:21: und entwickelt eigene innovative Praktiken. Und dieses Bild passt ja wundervoll auf alles, was man

00:06:29: lernt und damit auch auf, wie lerne ich agiles Arbeiten. Der Scrum Guide, egal in welcher

00:06:36: Ausprägung, sei es der Simple Guide, sei es der normale Scrum Guide oder auch die Ergänzung, das

00:06:43: Expansion Pack, dienen meiner Meinung nach nur für diese erste Phase, die Shuuhari-Phase, in

00:06:50: deren ich die Grundlagen lerne. Keiner sagt dann aber, dass man da drin bleiben soll, sondern ganz

00:06:58: im Gegenteil. Shuuhari sagt dann, okay, es gibt eine zweite Phase, die H-Phase, in der ich dann

00:07:04: die Methode gelernt habe und anfange, das Regelwerk zu hinterfragen und für mich auch anzupassen. Das

00:07:14: ist auch ganz natürlich in allem, was ihr lernt. Wir nehmen mal ein ganz anderes Beispiel. Ich

00:07:18: spiele ein bisschen Gitarre und wenn man mit Gitarre spielen anfängt und, ja, sag ich mal,

00:07:24: das normal anfängt, also vielleicht mit einem Lehrer oder so, dann wird man anfangen, ganz

00:07:29: grundsätzlich zu lernen, wie halte ich meine Hände, wie halte ich die Gitarre, wo sind die

00:07:35: einzelnen Noten auf den Seiten und in den Bünden, wie spiele ich einen offenen Akkord. Irgendwann

00:07:41: kommt man dann aber an eine Stelle, wo man feststellt, diesen Akkord und die Fingerhaltung

00:07:48: dazu, den spiele ich viel leichter, wenn ich meine Finger anders halte. Der Lehrer hat einem

00:07:53: beigebracht, das ist mal erst mal die grundsätzliche Fingerhaltung. Ich stelle aus der

00:07:58: Praxis heraus fest, okay, wenn ich von dem Akkord in den wechseln will, macht es mehr Sinn, die

00:08:03: Finger so zu halten, weil es dann schneller geht. Ein ganz normaler Prozess, wenn man Gitarre lernt,

00:08:07: ich vermute bei anderen Instrumenten zum Beispiel auch. Und das vergessen wir, glaube ich, dieses

00:08:13: ganze Grundprinzip, wie lernen und wie entwickeln wir uns, wenn wir über die Anwendung von agilen

00:08:19: Arbeiten mithilfe einer Methode reden. Denn, wie gesagt, mein Beispiel vor ein paar Jahren,

00:08:24: ich selber, wir kommen nicht so gut und nicht so oft in diesen Modus von, okay, ich habe die

00:08:30: Grundlagen wirklich verstanden und jetzt passe ich es bei mir an. Und diese letzte Phase, die Re-Phase,

00:08:36: wie erreicht man so eine Meisterschaft, die ist für viele noch schwerer. Das bedeutet nämlich

00:08:44: unter anderem, dass man auch Dinge oder den ganzen Scrum Guide bleiben lässt und sagt,

00:08:49: okay, aber so funktioniert es für unser Umfeld, für unsere Stakeholder, für unser Produkt,

00:08:55: für unser Outcome viel besser. Wenn der Scrum Guide behauptet, das muss so sein,

00:09:02: wir sind aber schlechter, warum den dann nicht verlassen oder zumindest in den Punkt verlassen?

00:09:07: Wichtig ist diese Reflexion. Und wenn ich mir so Diskussionen auf LinkedIn oder so angucke,

00:09:13: habe ich das Gefühl, viele sind nicht bereit zu diskutieren. Das heißt, ich finde es eben wichtig,

00:09:21: eine gewisse Haltung zu haben. Und eine Haltung ist größer als eine Methode. Es ist zuerst wichtig

00:09:28: zu verstehen, wir haben eine agile Haltung und eine Methode implementiert das im Zweifel oder

00:09:34: auch nicht oder Teile der Methode. Es schadet ja nichts, wenn ihr feststellt, so ein Daily macht

00:09:41: total Sinn, das Daily auf jeden Fall zu machen. Es ist ja nicht 0 und 1 oder schwarz und weiß,

00:09:48: Scrum machen oder nicht, sondern man kann doch auch Teile davon nehmen. Mir war es nochmal wichtig

00:09:54: und deswegen sind wir auch schon beim Fazit. Es passte halt inhaltlich auch ganz gut, nochmal

00:09:58: diesen Gegenentwurf zum Expansion Pack oder Guide plus Expansion Pack zu zeigen, nämlich diesen

00:10:05: Simple Guide. Lest euch den mal durch, macht euch mal selber Gedanken dazu. Tut es der Simple Guide

00:10:11: nicht auch? Eine Methode ist ein Start, um etwas zu lernen. Die Methode, wie ich einen Akkord greife

00:10:18: oder die Methode Scrum. Aber nicht das Ziel. Es geht darum, agil zu sein statt agil zu tun. Und

00:10:27: wie immer gilt kontinuierliche Verbesserung. Agilität, agiles Arbeiten ist eine dauerhafte

00:10:36: Reise. Ihr seid nicht irgendwann agil, sondern ihr passt das permanent an, aufgrund von Veränderungen

00:10:44: von eurem Umfeld zum Beispiel. Und damit sind wir für heute auch dann auch schon durch. Habt ihr

00:10:50: euch damit tiefer beschäftigt? Das wäre für mich interessant, wenn ihr da Feedback habt,

00:10:54: immer gerne her damit. Ansonsten habe ich wie immer eine ganz große Bitte, wenn dir die Folge

00:10:59: hier gefallen hat, vielleicht hast du schon mehr Folgen gehört und dir gefällt der Podcast ganz

00:11:04: gut, dann teile das gerne mit deinen Kolleginnen und Kollegen und natürlich auch auf deinen

00:11:09: Social Media Kanälen. Je mehr Leute von dem Podcast erfahren, desto größer wird die Diskussion. Das

00:11:15: kann ich alles wieder aufnehmen und verarbeiten und daraus neue Folgen machen. Und ja, das kommt

00:11:21: schlussendlich, wenn es gut läuft, dir ja auch zugute. Ich sage da auf jeden Fall ganz vielen

00:11:25: Dank. Ansonsten sage ich, habt noch eine ganz tolle Woche und bis zur nächsten Folge bei No Bullshit,

00:11:31: Edrey!