Scrum Master und ihre Aufgaben

Viele fragen sich, was genau es mit der Rolle Scrum Master so auf sich hat. Ihr beide seid Scrum Master. Was genau sind denn Eure Aufgaben in dieser Rolle? Was treibt ihr den ganzen Tag?

Jenny: Unser Aufgabenfeld ist sehr breit. Das macht den Job sehr anspruchsvoll, aber auch abwechslungsreich. Das macht genau den Reiz an der Rolle aus. Man weiß morgens nicht genau was im Laufe des Tages auf einem zukommt. Klar ist nur: die Aufgaben kommen aus ganz unterschiedlichen Bereichen.

Alle Aufgaben des Scrum Masters sind im Scrum Guide beschrieben. Grob zusammengefasst geht es um Aufgaben aus den folgenden Bereichen:

• Wissensvermittlung
• Moderation
• Coaching
• Teamführung

Das heißt der Scrum Master muss Trainer, Coach, Moderator und Führungskraft in einer Person sein?

Mike: Naja, man muss nicht gleich zertifizierter Business Coach und Trainer sein, um den Job gut machen zu können. Aber interessieren sollte man sich allemal für diese Themenfelder. Zwei Tage Zertifizierung zum Scrum Master reichen jedenfalls nicht. Sie sind aber wichtig, um das Scrum Framework zu verstehen und erklären zu können. Nicht aber um die Rolle des Scrum Masters in Gänze ausfüllen zu können. Da muss man sich schon mit den genannten Themenbereichen befassen. Eine sehr gute Quelle ist zum Beispiel managerSeminare.de, für die Themen rings um Training und Coaching. Hier findet man viele Impulse.

Jenny: Es ist schon nicht ganz einfach alle erforderlichen Kompetenzen in einer Person zu vereinen. Deshalb bin ich froh, dass wir zu zweit sind. Wir ergänzen uns gut, weil wir ganz verschiedene Lebensläufe haben. Mike war früher selbst Entwickler, kann deshalb technische Themen gut nachvollziehen. Ich war früher Teamleiterin, hab also Führungserfahrung. Jeder hat andere Erfahrungen, Stärken und Weiterbildungen. Wir helfen uns über Kreuz bei verschieden Themen in den Teams aus. Ganz nebenbei bringt das auch immer mal neue Impulse in die Teams, wenn der jeweils andere Scrum Master mal übernimmt.

Wie genau seid ihr denn organisiert?

Jenny: Wir sind beide Vollzeit als Scrum Master tätig. Jeder von uns begleitet jeweils zwei Scrum Teams. Das heißt wir sind ca. zur Hälfte unserer Wochenarbeitszeit in einem der Scrum Team.

Und das reicht aus?

Mike: Es ist aus unserer Sicht jedenfalls besser als zu 50% Softwareentwickler und zu 50% Scrum Master im gleichen Team zu sein. Und ja: 50% Scrum Master reichen aus für ein Team. Wir haben in jedem Team Büro einen Arbeitsplatz. So rotieren wir in der Woche durch beide Teams. Wir haben die Serientermine der Scrum Ereignisse zeitlich so versetzt geplant, dass das funktioniert.

Ok, dann mal zurück zu euren Aufgaben. Ihr macht also viel Know How Transfer.

Mike: Richtig. Allem voran ist es Aufgabe eines Scrum Masters allen Beteiligten Scrum in der Theorie zu vermitteln. Was gehört alles zum Scrum Framework? Und wie spielen die Elemente zusammen? Wir haben gute Erfahrungen damit gemacht Scrum mit einer Lego-Simulation zu erklären. So wird das Scrum Framework mit einfachen Mitteln erlebbar gemacht. Die Methode heißt Lego4Scrum und kann gratis als PDF heruntergeladen werden.

Jenny: In dem Lego-Workshop lassen wir die Teilnehmer einige Sprints lang Lego bauen und führen fast alle Scrum Ereignisse durch. Wir gucken also in einer Sprint Retrospektive was die Teilnehmer beim nächsten Sprint besser machen können. Im Sprint Review sehen wir uns gemeinsam die Ergebnisse an und im Sprint Planning bereiten wir den nächsten Sprint vor. Lediglich das Daily Scrum lassen wir bei dieser Simulation außenvor. So können wir beim Durchspielen von Scrum die Praktiken, die es im Scrum Framework gibt, erläutern und erklären welche Regeln zu beachten sind. Um den Scrum Prozess und die Abfolge der Ereignisse noch einmal zu erläutern greifen wir am Ende des Workshops auf Erklärvideos auf Youtube zurück. Ich bin ein großer Fan der Erklärvideos von dem Munich Institute for IT Service Management (mITSM).

Welche Rolle spielt das Schlagwort Agilität dabei?

Mike: Eine besondere Rolle. Agilität ist das Fundament des Scrum Frameworks. Wir erläutern immer wieder was sich hinter dem Schlagwort Agilität verbirgt. Also ja: Gerade zu Agilität versuchen wir möglichst viel Wissen an unsere Kollegen zu vermitteln. Wir vermitteln das korrekte Verständnis von Agilität und erläutern ihre Anwendung. Wichtig ist dabei: Es reicht nicht nur graue Theorie zu vermitteln. Wir suchen immer nach neuen Formaten, um das Verständnis von Agilität für unsere Kollegen erlebbar zu machen, damit sich das Wissen fest in den Hirnen verankert. Wer erlebt hat wie sich Agilität anfühlt vergisst das nie wieder und weiß die Vorteile sehr zu schätzen.

Das heißt mit bloßem Wissen um Agilität und das Scrum Framework ist es getan?

Jenny: Nein, natürlich nicht. Neben der Theorie zum Scrum Framework spielt das Werte-System, das hinter dem Scrum Framework steht, eine wichtige Rolle. Auch das gilt es zu vermitteln, genau so wie die Werte und Prinzipien des Agilen Manifests. Während es beim Scrum Framework selbst aber im Wesentlichen um die Vermittlung von Wissen geht, ist bei den Werten und Prinzipien die Herausforderung ein Mindset, eine Haltung, zu vermitteln. Dafür braucht es andere Methoden. Das geht nur mit Anwenden lassen, Erfahrung sammeln und Reflektion auf das Erlebte. So bauen wir unsere Mikro-Trainings auf. Das sind zwei- bis dreistündige, kompakte Trainings. Wir denken uns Übungen aus, die zum Thema Agilität hinführen und diskutieren dann in Reflektionsphasen über das gerade Erlebte.

Mike: Außerdem höhlt steter Tropfen den Stein. Im Gegensatz zu den Scrum Ereignissen wiederholen sich die Inhalte des Wertesystems nicht automatisch in jedem Sprint. Die Ereignisse und Artefakte kommen ohne großes Zutun immer wieder automatisch in den Fokus und werden zum Thema. Die Werte muss man regelmäßig mit passenden Maßnahmen in Erinnerung rufen. Zum Beispiel geht das mit Methoden wie dem „Begriff der Woche“. Wir wählen immer einen Begriff aus den Werten und Prinzipien aus und stellen ihn eine Woche lange in den Mittelpunkt. So wird man erinnert an die zentralen Begriffe und ihre Bedeutung.

Was ist denn aus Eurer Sicht die wichtigste Fähigkeit, die ihr Euren Teams näher bringt?

Jenny: Das ist einfach zu beantworten, oder Mike? Auch wenn es platt klingt: Die wichtigste Fähigkeit von Scrum Teams ist: Zeit-Management. Das Scrum Framework basiert auf sog. Time-Boxen. Der Sprint ist auf eine bestimmte Sprintlänge festgelegt, alle Ereignisse haben eine vorgegeben Dauer. Ein zentraler Erfolgsfaktor von Scrum ist deshalb die Einhaltung dieser Timeboxen. Das ist deutlich schwieriger als man denkt. Deshalb unterstützen wir unsere Teams gerade bei dieser Kompetenz mit allen Mitteln. Sowohl mit Kenntnissen zum Thema Timeboxen einhalten, als auch mit Tipps zu technischen Helferlein. Wir schwören beispielsweise auf unsere TIME TIMER Tischuhren*.

Mike: Am liebsten arbeiten wir sogar mit zwei von den Dingern in unseren Scrum 
Ereignissen: Einer um die Gesamtdauer der Sprint Retrospektive oder des Sprint Plannings im Auge zu behalten, der zweite um kleinere Timeboxen anzuzeigen, die wir uns für ein Thema setzen. Etwa in der Sprint Retrospektive 10 Minuten für das Thema „pünktlich starten der Meetings“ oder 15 Minuten für die „User Story „Login Daten speichern“ im Sprint Planning“.

Habt ihr einen Tipp zum Thema Timeboxing?

Jenny: Wir reiten beim Thema Timeboxen einhalten immer auf zwei Grundsätzen herum: Zum einen dauert es immer so lange wie man Zeit hat. Und zum anderen ist die beste Strategie einfach nicht zuzulassen, dass die Timebox überschritten wird. Wenn man eine Stunde Retro angesetzt hat, dann endet die Retro auch genau nach einer Stunde, bestenfalls früher. Dann ist es sehr ärgerlich, wenn nicht alle Themen besprochen werden konnten. Durch diesen Ärger setzt sich das Team aber selbst unter Druck beim nächsten Mal effizienter mit der Timebox zu haushalten. Im Team muss man sich also die Frage stellen, wo Zeit im Meeting vergeudet wurde und es beim nächsten Mal besser machen. Das dauert meist einige Sprints bis es funktioniert, deshalb ist so wichtig, dass man nicht zulässt, dass an der Timebox gerüttelt wird. Die ist in Stein gemeißelt.

Aber was ist denn, wenn man es wegen der Timebox nicht geschafft hat über ein ganz wichtiges und dringendes Thema zu sprechen?

Mike: Dann stimmte schlicht die Reihenfolge nicht. Das Thema hätte weiter vorne in der Themenliste stehen müssen. Besser gesagt weiter oben im Meeting-Backlog. Auch für das Managen der Themen in einem Scrum Meeting gilt der Backlog Gedanke. Die Themenliste ist nach Mehrwert sortiert und die Themen mit größtem Mehrwert stehen weiter oben. Die Themenliste wird dann im Meeting wie ein Backlog von oben abgearbeitet. So kann es nicht passieren, dass man zwar über unwichtigere Themen gesprochen hat, wichtige und dringende Themen aber liegen geblieben sind.

Und die Reihenfolge der Themen legt ihr als Scrum Master fest?

Mike: Auf gar keinen Fall! Hier ist das Scrum Team gefragt, das Team legt die Reihenfolge fest. Als Scrum Master ist man hier aber als Moderator gefragt. Aufgabe ist den Team Mitgliedern zu helfen die Themen aufzulisten und in eine Reihenfolge zu bringen. Das sind ganz klassische Moderationsfähigkeiten, die man auch in Scrum Meetings anwenden kann. Einen guten Überblick über die verschiedenen Moderationsschritte bekommt man z.B. durch den Moderationszyklus von W. Seifert. Einige Schritte sind zwar für wiederkehrende Meetings wie die Scrum Ereignisse nicht so relevant, aber dennoch ist dieses Modell ein guter Leitfaden.

Jenny: Der Bedarf an moderativen Eingriffen durch den Scrum Master unterscheidet sich allerdings auch von Ereignis zu Ereignis und variiert über die Zeit.
Während beim Refinement von Product Backlog Einträgen und beim Sprint Planning die Themenliste und -reihenfolge schon durch das sortierte Product Backlog vorgegeben ist geht es in der Sprint Retrospektive immer darum, die aktuellen Themen zu sammeln und nach Mehrwert zu sortieren. Dabei helfen wir den Teams. Hier ist Moderationskompetenz gefragt.

Der Scrum Master ist aber gerade bei der Retro nicht nur als Moderator dabei. Er oder sie sorgt dafür, dass das Sprint Retrospektive Meeting konstruktiv und produktiv ist. Aber aufgrund seiner Verantwortung für den Scrum Prozess nimmt der Scrum Master als Moderator und zeitgleich als gleichberechtigtes Scrum Team Mitglied an der Sprint Retrospektive teil. Mit dieser Doppelrolle muss man umgehen lernen. Auch das gehört in den Bereich Moderationskompetenz.

Wo liegen denn typische Fehler beim Moderieren von Sprint Retrospektiven?

Mike: Der größte Fehler, der bei Retros passieren kann, ist fehlende Abwechslung. Unsere Teams arbeiten mit einer Sprintlänge von einer bzw. zwei Wochen. Das heißt es finden zwei bis vier Sprint Retrospektiven statt in einem Monat. Der kontinuierliche Verbesserungsprozess hat nur dann eine Chance zu funktionieren, wenn es bei aller Professionalität auch Spaß macht. Der Spaß ist schnell dahin, wenn es langweilig wird weil immer der gleiche Stiefel durchgezogen. Deshalb haben wir uns ein sehr breites Repertoire an Methoden angeeignet, um Retros und andere Ereignisse abwechslungsreich zu gestalten. Eine Hilfe auf neue Ideen für Retros zu kommen ist beispielsweise der Retromat. Mit Hilfe des Retromats bekommt man einen Leitfaden für den Ablauf von Sprint Retrospektiven und kann verschiedenste Elemente in einer Retro kombinieren. Auch eine Zufallsauswahl ist möglich.

Heißt das, dass ihr grundsätzlich bei den Scrum Ereignissen als Moderator dabei seid ?

Jenny: Nein, das heißt es nicht. Viele denken der Scrum Master moderiert grundsätzlich alle Scrum Ereignisse. Das stimmt aber nicht. Wir machen das bei Bedarf und auf Anfrage. So steht es auch im Scrum Guide.
Beim Planning meiner Teams bin ich beispielsweise nie dabei. Da wurde ich noch nie angefragt. Bei den Daily Scrums war ich in den ersten Monaten jeden Tag dabei, bis sich alles so eingeschwungen hatte, dass die Teams das Daily in den vorgegebenen 15 Minuten geschafft haben. Ohne zu überziehen und trotzdem wussten alle am Ende woran die anderen gerade arbeiten und wie der Stand ist. Ab da brauchte es mich nicht mehr. Abgemacht ist, dass mich die Teams einfach wieder zum Daily Scrum dazu holen wenn sich das Meeting wieder verschlechtert oder eintönig wird.
Anders sieht es beim Sprint Review und bei der Sprint Retrospektive aus. Da sind wir grundsätzlich von den Teams als Moderatoren angefragt.

Ihr habt eben gesagt, in einigen Ereignissen gibt das Product Backlog schon die Reihenfolge der Themen vor. Wer sortiert die Einträge denn? Macht ihr das in Eurer Rolle?

Mike: Auch hier: Nein, auf keinen Fall! Hierfür sind die Product Owner verantwortlich. Wir unterstützen sie aber mit Wissen und Techniken, um das Product Backlog möglichst optimal und effektiv zu gestalten. Zum Beispiel: Wie erkennt man den Mehrwert eines Backlog Eintrags und kann dann danach sortieren? Dabei können verschiedene Modelle helfen, etwa das KANO-Modell oder die MoSCoW-Priorisierung. Wir halten uns da immer auf dem Laufenden und geben unsere Erkenntnisse an die Product Owner weiter. Noch mehr ist es aber Training on the Job und Einzelcoaching. Wir setzen uns mit den Product Ownern zusammen vor das Product Backlog und sehen uns die Einträge an. An den echten Beispielen diskutieren wir dann verschiedene Modelle und Techniken. Das bringt mehr als frontaler Theorie-Input.

Jenny: Eigentlich beginnt unser Job bezüglich des Product Backlogs sogar schon früher im Prozess: Wie formuliert man überhaupt Backlog Einträge so, dass eine Umsetzung durch die Entwicklungsteams zu einem möglichst optimalen Ergebnis führt? Antworten darauf vermitteln wir den Product Ownern bzw. wir erarbeiten die Antworten mit den Product Ownern und den Entwicklern zusammen. Dabei schaffen wir an erster Stelle ein Verständnis für die Notwendigkeit klarer, prägnanter Product Backlog Einträge im gesamten Scrum-Team. Unser Grundsatz für das Verfassen von Backlogeinträgen ist: So viel Information wie nötig, so wenig Text wie möglich!

Was genau ist also Eure Verantwortung bezüglich des Product Backlogs?

Jenny: Unsere Aufgabe ist also sicherzustellen, dass der Product Owner weiß, wie er das Product Backlog so anordnet und die Einträge so formuliert, dass das Backlog den größten Wert für den Kunden erzeugt. Die Verantwortung für das Backlog selbst behält aber immer der Product Owner. Da mischen wir uns letztlich auch nicht ein.

Mike: Wobei: Neben aller Theorie über das Scrum Framework und zu Agilen Arbeitsweisen sind wir als Scrum Master auch recht nah an der Fachlichkeit dran. Obwohl es in der Verantwortung des Product Owners liegt die Fachlichkeit zu vermitteln, stellen wir doch sicher, dass die Teams die Ziele, den Umfang unseres Vorhabens und generell die Produktdomäne verstanden haben. Das ist sicher ein Grund, warum es Sinn macht als Scrum Master am Refinement der Product Backlog Einträge teilzunehmen. Da bekommt man aus erster Hand mit, ob das Verständnis für die Ziele und die Produkt Domäne im Entwicklungsteam entstanden ist.

Was ist die Produkt Domäne?

Mike: Die Produkt Domäne ist das Fachliche Umfeld, in dem Wir uns bewegen. Unsere Fachdomäne ist beispielsweise das Umfeld eLearning und Akademiebetrieb. Wir schaffen Lösungen für alle möglichen Probleme und Herausforderungen in diesem Bereich. Eine Produkt Domäne hat eine klare Grenze – etwa Geschäfts-Prozess-Grenzen – und es wird ein Domänen-eigenen Vokabular verwendet. Daran lassen sich oft die Grenzen der Produkt Domäne erkennen.

Mit welchem Schlagwort müssten Product Owner denn suchen, um selbst Informationsquellen zum Product Backlog anzuzapfen?

Jenny: Das müsste eigentlich der Suchbegriff Agile Produktplanung in einem empirischen Arbeitsumfeld sein. Leider spuckt die Suche – beispielsweise per Google – dazu nicht wirklich etwas aus. Was man tun kann ist: Experten aus dem Bereich Produktmanagement in Sozialen Netzwerken folgen. Eine wirkliche Koryphäe auf dem Gebiet Produktmanagement ist definitiv Ellen Gottesdiener. Sie veröffentlicht Beiträge auf LinkedIn und Twitter.
Ein Literatur-Tipp zum Thema Agiles Projektmanagement ist außerdem das Buch Agiles Produktmanagement mit Scrum* von Roman Pichler.

Es ist aber nicht weniger wichtig auch bei den Entwicklungsteams ein gutes Verständnis von Produktplanung im Agilen Umfeld zu schaffen. Bei aller Flexibilität, die im Agilen Umfeld erforderlich ist, geht es ohne eine grobe Produktplanung nicht über die Ziellinie. Dieses Verständnis mussten wir in unseren Entwicklungsteams erst einmal herstellen. Einige empfanden jede Art von Vorausplanung als unagil.

Mike: Das stimmt. Agile Produktplanung bedeutet ja auch nicht auf die Kalenderwoche genau vorauszuplanen wann welche Funktionalität ausgeliefert wird. Aber es geht schon um eine Road Map, die Aussage darüber gibt welche Funktionsbereiche in welcher Reihenfolge angegangen werden. Außerdem muss man in der Lage sein jederzeit eine Prognose für die Fertigstellung des aktuellen Product Backlogs zu geben. Dieses Verständnis vermitteln wir unseren Product Ownern und unseren Entwicklungsteams.

Zusammengefasst kann man also sagen, dass ihr als eine Eurer Kernaufgaben Wissen zu verschiedensten Themen an Eure Kollegen in den Scrum Teams weiter gebt, richtig?

Mike: Ja – und noch mehr. Unser Job ist es nicht nur Mitgliedern der Scrum Teams Wissen zu vermitteln. Auch alle anderen außerhalb der Teams helfen wir mit unserem Wissen weiter. Zum Beispiel helfen wir zu verstehen welche Interaktionen mit den Scrum Teams sinnvoll sind. Wobei das schon fast einer Prozess-Optimierung gleichkommt. Optimierung des Kommunikationsprozesses zu den Scrum Teams. Dabei geht es unter anderem um die Frage ob man synchron oder besser asynchron mit den Scrum Teams kommuniziert. Dabei spielt es eine zentrale Rolle die Unterbrechungsfreie Arbeitszeit der Teams zu maximieren. Ich habe zum Beispiel kürzlich einen Vortrag dazu gehalten „wie teuer Unterbrechungen im Arbeitsfluss sind!“ Das ist vielen nicht bewusst. Jede Unterbrechung bedeutet, dass ich mich als Entwickler erst wieder an die Stelle reindenken muss, an der ich im Arbeitsfluss unterbrochen wurde. Das kostete einige Minuten und diese Minuten addieren sich im Laufe des Tages. Das kann man fast schon mit Rüstzeiten in der Produktion vergleichen. Vielen fehlt dafür das Verständnis, deshalb setzen wir den Hebel da an um mehr Effizienz in den Teams zu erreichen.

Ihr habt jetzt schon viel über Eure Aufgaben in der Wissensvermittlung und der Moderation gesprochen. Was habt ihr mit Coaching ganz zu Beginn des Interviews gemeint?

Jenny: Neben all der Wissensvermittlung und den Moderatoreneinsätzen sind wir auch als Coach gefragt. So ist es ganz klar unsere Verantwortung die Entwicklungsteam hin zur Selbstorganisation zu coachen und ihnen Wege zu einer funktionsübergreifenden Teamarbeit zu zeigen. Dabei geht es ganz stark darum die Zusammenarbeit im Team und zwischen den Teams zu optimieren. Da spielt die Sprint Retrospektive eine große Rolle, aber auch im Verlauf der Sprints spreche ich viele Themen an, die mit Selbstorganisation und Teamarbeit zu tun haben. Coaching heißt für mich in diesem Zusammenhang: Die Mitglieder unserer Teams sind in anderen Bereichen des Lebens bereits äußerst selbstorganisiert und arbeiten crossfunktional mit anderen zusammen. Da sind also Kompetenzen vorhanden. Mit Coaching-Methoden machen wir diese Kompetenzen für alle im Team explizit und dadurch nutzbar. Meist wissen die Kollegen also wie es geht oder wo die Hindernisse liegen, warum es nicht funktioniert. Wir helfen durch Coaching dieses Wissen an die Oberfläche zu holen.

Mike: Es gibt noch einen weiteren Aspekt, der für Coaching spricht: Wissen, dass ich mir als Individuum oder als Team selbst erarbeitet habe, wirkt viel nachhaltiger, als Wissen, dass mit jemand eingetrichtert hat. Deshalb versuchen wir durch Coaching Erkenntnisse in den Teams zu erzeugen. Daraus resultiert dann nachhaltigen Wissen.

Ihr seid Coachs und gleichzeitig Führungskraft. Ist das nicht ein Widerspruch?

Mike: Eine ganz wichtige Aufgabe ist es den Kontinuierlichen Verbesserungsprozess (KVP) anzuleiten. Unser Umfeld entwickelt sich so schnell, dass wir gar nicht anders können als und im gleichen Tempo mit zu entwickeln. Ein Scrum Master ist also auch Personalentwickler. Und Personalentwicklung ist nach unserer Auffassung ganz klar Führungsaufgabe. So ist es nicht verwunderlich, dass der Scrum Guide den Scrum Master als Führungskraft bezeichnen. Allerdings nicht als herrschende Führungskraft alter Schule, sondern als Serveant Leader. Jemand der laterale Führung beherrscht und situativ führen kann. Jemand, der natürliche Autorität besitzt. Coaching ist da eine sehr passende Methoden, besser gesagt ein Methoden-Koffer. Das ist also überhaupt kein Widerspruch, ganz im Gegenteil.

Diese natürliche Autorität wird auch benötigt, um einer weiteren Kernaufgabe des Scrum Masters nachzukommen: Die Beseitigung von Hindernisse, so genannte Impediments.

Impediments. Wie spricht man das eigentlich aus? Und worum geht es genau?

Jenny: Hehe! Das wird „Impäädiment“ ausgesprochen… 🙂

Im vermeintlich einfachen Fall geht es dabei um technische Hindernisse, die das Entwicklungsteam nicht alleine aus der Welt schaffen kann. Schwieriger wird es, wenn es sich bei den Impediments um Konflikte im Team handelt, die die Zusammenarbeit behindern. Oder wenn es um Störungen geht, die aus der Organisation kommen. Etwa Vorgesetzte, die vorbei an jeder Sprintplanung auf die Kapazitäten der Scrum Team Mitglieder zugreifen. Da hilft es sehr, wenn man über natürliche Authorität verfügt innerhalb der Teams. Aber auch ein gewisses Standing in der Organisation ist hilfreich beim Beseitigen von Hindernissen, die das Entwicklungsteam aufhalten.

Mike: Das Stichwortet lautet hier: Laterale Führung. Führung ohne Vorgesetztenfunktion, ohne „Macht“. Vielleicht ist Followership sogar der bessere Begriff als Leadership. Es darum, dass mir die Leute folgen, ohne dass ich Macht anwenden muss. Das meint laterale Führung. In Teilen hat das bei uns etwas mit fachlicher Führung zu tun, weil wir das Wissen und die Erfahrung zum Scrum Framework mitbringen. Das ist aber eben nicht alles, es geht auch um Persönlichkeit, die dann zu Followership führt.

Wow – das ist ja wirklich eine ganz schöne Bandbreite an Aufgaben. Haben wir denn über alles wichtige gesprochen?

Mike: Fast: Zu guter Letzt ist es ja auch unsere Aufgabe als Verantwortliche für den Scrum Prozess dafür zu sorgen, dass die Scrum Ereignisse überhaupt stattfinden. Das geht nicht immer von alleine. Zum Beispiel sah eines unserer Teams keinen Sinn in der Retro. Hier war es also wichtig immer wieder zu erklären, warum die Sprint Retrospektive so wichtig ist und man die Retro-Themen nicht einfach zwischen Tür und Angel am Rande des operativen Tagesgeschäfts besprechen sollte. Man mjss sich Zeit dafür nehmen den Kopf zu heben und freizubekommen. Mal schnell im Tagesgeschäft wenn alle unter Strom stehen geht das nicht gut. Damit konnten wir das Team überzeugen.

Jenny: Bei einem meiner Teams fand lange Zeit kein Sprint Review statt. Der Zweck des Meetings war einfach nicht klar. Es ist aber genau unser Job sicherzustellen, dass die Teilnehmer den Zweck der Ereignisse verstehen. Im Falle des Sprint Reviews war es so, dass die Teammitglieder der Meinung waren die vierwöchentliche Demo, in der alle Teams ihren aktuellen Fortschritt zeigen, reicht aus. Dem war nicht so. Der Effekt am Sprintende auf das Produktinkrement zu schauen ging verloren. Es fehlten die Glückshormone bei positivem Sprintabschluss. Ohne diese Glücksmomente hält man aber als Team kaum ein Monate oder sogar Jahre andauerndes Projekt durch. Außerdem erhöht das fehlende Sprint Review das Risiko länger in die falsche Richtung zu entwickeln. Genau das will Scrum ja verhindern durch kurze Sprintlängen mit regelmäßiger Überprüfung des Ergebnisses.

Wunderbar. Dann vielen Dank für das Interview und die vielen Informationen zu Eurer Rolle Scrum Master und Euren Aufgaben.

Jenny: Sehr gerne! Hat Spaß gemacht! 🙂

Hier noch einmal eine Zusammenfassung Eurer Aufgaben:

• Wissenvermittlung zu:
  • Scrum in der Theorie
  • Agilität
  • Zeit-Management
  • Priorisieren von Themen
  • Backlog Management
  • Agile Produktplanung
  • Kommunikation
• Moderation
  • von Scrum Ereignissen
  • Umgang mit der Doppelrolle Moderator – Teilnehmer
• Coaching
  • Einzel-Coaching
  • Team-Coaching
• Teamführung
  • Laterale Führung
  • Führung ohne Vorgesetztenfunktion
  • Followership