Aktuell experimentiere ich ja ein wenig mit Youtube-Videos ergänzend zum Podcast. Die Idee ist es euch in kurzen stringenten Episoden einen Impuls mitzugeben. Schau dir das gerne mal an und teile da gerne auch direkt in den Kommentaren, was du von diesen Videos hältst.
Am Freitag hatte ich die Folge „𝐇ö𝐫 𝐚𝐮𝐟, 𝐬𝐭ä𝐧𝐝𝐢𝐠 𝐝𝐚𝐬 𝐑𝐞𝐭𝐫𝐨𝐬𝐩𝐞𝐤𝐭𝐢𝐯𝐞𝐧-𝐅𝐨𝐫𝐦𝐚𝐭 𝐳𝐮 𝐰𝐞𝐜𝐡𝐬𝐞𝐥𝐧!“ auf LinkedIn gepostet. Was zu einem sehr spannenden Austausch in den Kommentaren führte und letztlich den Anstoß für die heutige Folge gesetzt hat.
Deswegen nochmal einen Dank an Armin Schubert, Anne-Dorotheh Feuß, Lukas Böhler und alle anderen, die mich mit ihren wunderbaren Kommentaren ins grübeln versetzt haben. Genau für solche Diskurse liebe ich LinkedIn.
Zum Thema, ob wir als Scrum Master und Agile Coach nicht oft unbeabsichtigt übergriffig agieren, möchte ich über folgende drei Themen sprechen:
Vereinnahmen wir aus unserer Rolle als Scrum Master oder Agile Coach nicht oft auch Inhaltlich die Retrospektive?
Agieren wir im agilen Umfeld nicht viel zu oft aus einem Idealbild und ist nicht genau das auch in gewisser Weise übergriffig?
Sehen wir uns nicht viel zu oft dazu genötigt, den Fortschritt im Sprint zu überwachen, sowie relevante Entscheidungen des Scrum Teams so zu beeinflussen, dass es fast schwer wird unser handeln von dem eines Vorarbeiters zu unterscheiden?
Klicken Sie auf den unteren Button, um den Inhalt von play.libsyn.com zu laden.
Wir als Scrum Master vereinnahmen inhaltlich die Retrospektive
Als Warm up zu diesem Abschnitt, möchte ich mal den Scrum Guide zitieren, weil er so wunderbar den eigentlichen Fokus der Retrospektive und der Aufgabe eines Scrum Masters zusammenfasst:
„Die Sprint Retrospektive bietet dem Scrum Team die Gelegenheit, sich selbst zu überprüfen und einen Verbesserungsplan für den kommenden Sprint zu erstellen. […] Der Scrum Master sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer seinen Zweck verstehen. Er sorgt dafür, dass die Time Box eingehalten wird. Aufgrund seiner Verantwortung für den Scrum Prozess nimmt der Scrum Master als gleichberechtigtes Mitglied an der Sprint Retrospektive teil.“
Ich dachte früher ja, dass die Retrospektive doch eigentlich der Termin des Scrum Masters ist. Hier wird aber herausgestellt, dass der Scrum Master als gleichberechtigtes Mitglied teilnimmt. Einen Vorschlags- oder Gestaltungsanspruch kann ich daraus beim besten Willen nicht herauslesen. Für mich besteht ein riesiger Unterschied zwischen Gestaltungshoheit eines Termins und dafür zu sorgen, dass dieser Termin stattfindet und alle Teilnehmer seinen Zweck verstanden haben.
In dem oben angesprochenen Youtube-Video „𝐇ö𝐫 𝐚𝐮𝐟, 𝐬𝐭ä𝐧𝐝𝐢𝐠 𝐝𝐚𝐬 𝐑𝐞𝐭𝐫𝐨𝐬𝐩𝐞𝐤𝐭𝐢𝐯𝐞𝐧-𝐅𝐨𝐫𝐦𝐚𝐭 𝐳𝐮 𝐰𝐞𝐜𝐡𝐬𝐞𝐥𝐧!“ hatte ich nochmal hervorgehoben, dass ich es für zielführender halte wesentliche Teile der Retrospektive stabil zu halten.
Vor allem weil die ständig wechselnden Formate eben vielen Teilnehmern den Halt nehmen sich Gedanken zu machen ihre Themen einzubringen. Wenn dich interessiert, welches Format ich in der Retro in Scrum Team favorisiere, dann höre gerne auch nochmal in die Podcast-Folge Sind abwechslungsreiche Retrospektiven ein Irrweg? aufgearbeitet.
Im wesentlichen gibt es zwei Hauptargumente die gegen eine beständige Retrospektive mit einem wiederkehrenden Rahmen sprechen:
Das wird doch so schnell langweilig!
Es braucht ein Format, was die Teilnehmer aus der Reserve lockt, sonst werden die wirklichen Probleme nicht in die Retro eingebracht und aufgearbeitet
Beide Argumente hängen für mich letztlich zusammen.
Wenn die wirklich drängenden Probleme von den Scrum Team Mitgliedern in die Retrospektive eingebracht werden, dann braucht es keine Show und Entertainment. Wenn die großen drängenden Probleme in der Retro aufgearbeitet werden, dann hat dies für mich an sich Spannung genug 😉 Da braucht es eher einen Rahmen der einem dabei hilft, diese strukturiert aufzuarbeiten, anzugehen und über Retrospektiven hinweg nach zusetzen. Genau darauf optimiere ich normalerweise meine Retrospektiven. Mehr dazu in der eben erwähnten Podcast-Folge.
Bleibt also nur noch die Frage offen, wenn nicht die stimulierenden Formate in der Retrospektive primär diese Inhalte in der Retrospektive setzen, wie kommen diese dann in die Retrospektive.
Außerhalb von einem Rahmen zur Selbstorganisation, wie ihn Scrum bietet, sehe ich es sogar als zwingend an hier über passende Übungen die Leute zu stimulieren und auch dem Facilitator kommt in solchen Retrospektiven eine deutlich aktivere Rolle zu. Das wurde mir in dem Austausch mit Irina klar, wo wir über den losgelösten Einsatz von einzelnen Elementen aus Agile in der HR-Abteilung gesprochen hatten.
Wenn du mit Scrum arbeitest und von den Teilnehmern nicht die wirklichen Probleme selbst in die Retrospektive eingebracht werden, dann liegt mein erster Fokus nicht auf stimulierenden Übungen in der Retrospektive, sondern darauf den Scrum Rahmen zu stärken. So sehen die Teilnehmer selbst in der Arbeit im Scrum Rahmen die konkrete Notwendigkeit für Verbesserungen und das stimuliert sie selbst die Probleme angehen zu wollen und die Retrospektive richtig zu nutzen.
Beispielsweise hatten wir ein Team in einer Organisation, was keine Retros gemacht hat und selbst sahen sie auch keinen Anlass sich weiter zu optimieren. Obwohl sie hinter ihrem Rücken vom Rest der Organisation als “Team Bottleneck” bezeichnet wurden. Den Anstoß, das zu ändern, hatten wir in diesem Fall dadurch gesetzt, dass die Ops Teams jetzt auch im Company Review mit den Entwicklungsteams ihre Leistungen vorstellen durften und aus dem Eindruck, wie sie ankamen, hatten sie sich direkt nach dem Review einen Moderator für eine Retro gesucht. In einem Monat wollten sie einfach gemeinsam besser dastehen.
Einen etwas genaueren Eindruck, wie einer meiner Teilnehmer von unserem Mentorprogramm für Scrum Master und Agile Coaches solche Akzente gesetzt hat findest du in dem Youtube-Video Retro, keiner spricht wirkliche Probleme an, DAS hat geholfen.
Das klingt dann auch weniger so, wie eine Beurteilung der Arbeit im Team durch einen Vorarbeiter, sondern eher danach, wo ihr Probleme seht dem Team zu helfen die Probleme anzugehen. Oder euch vielleicht sogar von ihnen alleine gelassen fühlt. Und wer das mal ehrlich in die Retro eingebracht hat, der weiß was für einen positiven Anstoß das setzt und eben ganz ohne übergriffig die Retrospektive thematisch zu hijacken.
Habe ich da was vergessen? Ist diese Sicht unfair vielen Scrum Mastern und Agile Coaches gegenüber, die sich in der Gestaltung der Retrospektiven mit tollen Formaten und vielen Gedanken einbringen? Oder ist es vielleicht auch ein spannender Denkanstoß, über den man mal eine Nacht schlafen sollte?
Haben wir als Agilisten nicht zu oft schon ein Idealbild im Kopf und ist das nicht schon in gewisser Weise übergriffig?
Was mich zu dem zweiten spannenden Punkt bringt. Als Agilisten unterhalten wir uns gerne über Idealzustände. Wie sieht denn eine gute agile Organisation aus? Wie spielt man richtig Planning Poker? Ich frage mich, ob wir zu häufig zu ideale Vorstellungen im Kopf haben und diese zu schnell zu unserer Agenda machen. Am Ende ist es doch völlig irrelevant, was wir uns als Idealbild vorstellen.
Agilität heißt ja nicht aus kruden Gedanken Luftschlösser zu erträumen und anderen aufoktroyieren, sondern es heißt ja gemeinsam aus Erfahrungen Sachen auszuprobieren. Es heißt Ergebnisse zu liefern, um aus diesen zu lernen und um Produkt und Arbeitsweise passend zu den Ambitionen der beteiligten Personen und zum Kontext auszugestalten.
In einer der Diskussionen zu Shu-Ha-Ri aufbauend auf der Podcast-Folge Scrum by the Books, hatten einige durchblicken lassen, dass sie es als wichtig ansehen den Arbeitsrahmen am Anfang zu bestimmen, damit die anderen diesen aus eigener Erfahrung kennenlernen können. Mich schreit aus dieser Aussage nach wie vor ein riesiger Widerspruch an. Nämlich das Scrum auf dem Fundament von selbst-gemanagten Teams und Empirie, also dem systematischen lernen aus Erfahrung beruht. Diese am Anfang außer Kraft zu setzen ist quasi, wie ein Putsch des Militärs, das die Kontrolle übernimmt, bis die Untertanen “gelernt” haben, was gut für sie ist. Es hilft dabei Mechaniken nachzuahmen und die beteiligten Personen auf diese zu dressieren, wobei dabei der Kern nicht nur ignoriert wird, sondern letztlich das tayloristische Gegenteil gelebt wird. Mein Eindruck ist, dass Teams die so gestartet werden zwar oberflächlich gut nach der Arbeit mit Scrum aussehen, sich aber nur sehr mühsam von diesem dysfunktionalen Start erholen und sich nicht weiterentwickeln.
Wenn du mehr Wissen möchtest, worauf es aus meiner Sicht beim Start ankommt: Schau mal das Youtube-Video Mit Scrum effektiv starten. Ich hoffe dieses Video zeigt, dass es sinnvollere Wege gibt mit Scrum zu starten, die von Anfang an den Kern von Scrum leben und so die Basis für wirklich effektive Scrum Teams setzen.
Letztlich sollten wir uns soweit es geht von Ideal Bildern verabschieden und mehr darauf gucken, dass wir mit den Personen herausarbeiten, was sie erreichen wollen, wir ihnen aufzeigen, wie man diese Ziele mit einer agilen Arbeitsweise erreichen kann und wie ein Pfad aussehen kann diese Aufstellung zu erreichen, um dies dann in der gemeinsamen exploration auf die Beine zu stellen.
Wenn wir so auf Vertrauen setzen, warum haben wir oft die Arbeit, Herangehensweise und Entscheidungen der beteiligten Personen so eng im Blick?
Als letzten Punkt bewegt mich der Widerspruch, dass wir viel über Vertrauen, über psychologische Sicherheit und ach so schöne Menschenbilder sprechen. Damit es nicht, wie bei den Retrospektiven zu dem Missverständnis kommt, dass ich Retrospektiven nicht mag wo ich sie in richtigem Einsatz doch für ein wichtiges Werkzeug halte was nur leider viel zu oft verunstaltet wird. Ich halte die Punkte Vertrauen, psychologische Sicherheit und auch die Haltung hinter Ansätzen, wie New Work für positiv und wichtig. Was mich stört ist, dass wir viel über diese Begriffe reden und wenn man dann genauer auf unser Wirken als Scrum Master und Agile Coach schaut, dann passt auch hier vieles mit diesen Ansprüchen nicht zusammen.
Ich meine stell dir mal selbst die Frage:
- Wie eng schaust du auf die Entscheidungen, die dein Team und dein Bereich trifft?
- Wie eng hast du das Vorankommen im Sprint im Blick und bist darauf gefasst bei Bedarf Anstöße zu setzen, dass sie auch nicht vergessen das Ziel zu erreichen?
- Wie oft schaffst du nicht einfach nur eine Lernumgebung aus der die beteiligten Personen so schnell aus ihren Fehlern lernen, dass ein kompensieren von Dysfunktionen und Fehlern von deiner Seite nicht nötig ist?
Mein Eindruck ist, wir alle sind hier manchmal zu viel Vorarbeiter. Oft haben wir hier noch nicht die Ansätze gefunden, um den beteiligten Personen dabei zu helfen, die konkrete Notwendigkeit zu sehen selbst früher zu handeln. Dazu habe ich übrigens in dem Youtube-Video Wie du als Scrum Master echte Veränderung bewirkst zusammengefasst, was sich für mich gut bewährt hat hier passende Anstöße zu setzen.
Ich würde mich freuen von euch zu hören. Bin doch immer sehr neugierig, wie ihr auf dieses Thema schaut und welche Herausforderungen ihr seht, um effektiv eure Umgebungen zu unterstützen.
Bis bald 😉
