Scrum Master Aufgaben: Kimberly Gepkens von der DEVK im Interview

Hallo Kimberly. Du hast deine berufliche Karriere als Redakteurin begonnen und viele Jahre die Online-Kommunikation der DEVK mitgestaltet. Wie bist du dann auf die Idee gekommen, Scrum Master zu werden?

Startschuss war die Gründung unserer neuen Digitalabteilung, in der wir uns ganzheitlich um die Themen rund um unsere Online-Kanäle kümmern. Erstmals haben wir hier die Bereiche Kommunikation, Marketing, Vertrieb und auch Entwicklung unter einem Dach vereint.

Von Anfang an haben wir in der neuen Abteilung agil gearbeitet. Ein Agile Coach hat uns dabei unterstützt, agile Arbeitsweisen in den Teams zu etablieren und die Zusammenarbeit zwischen den Teams zu gestalten. Außerdem begleitet ein Scrum Master die tägliche Arbeit in den Teams.

Ich hatte vorher kaum Berührungspunkte mit agiler Arbeit. Wir haben bei der DEVK zwar schon mit einzelnen Aspekten gearbeitet, zum Beispiel haben wir Boards genutzt oder Stand-up-Meetings durchgeführt. Aber in diesem Umfang war es für mich neu – und von Anfang an faszinierend. Ich war begeistert, wie wir durch die neue Arbeitsweise besser zusammenarbeiten konnten und können.

Damals arbeitete ich noch als Online-Redakteurin im Content-Team. Zum Team gehörte auch eine Scrum Masterin. Diese Rolle fand ich von Anfang an spannend. Und da die Rolle auch viel mit Kommunikation zu tun hat, konnte ich direkt einen Bezug herstellen. Wobei ich am Anfang nicht so ganz verstanden habe, was ein Scrum Master eigentlich macht (lacht). Aber das haben wir dann gemeinsam mit unserer Scrum Masterin herausgefunden. Toll fand ich, dass wir nicht von Anfang an gesagt haben „Das ist deine Rolle und das sind deine Aufgaben“. Wir haben die einzelnen Rollen und Verantwortlichkeiten der Mitglieder im Team definiert. Und obwohl ich meinen Job als Redakteurin sehr gerne gemacht habe, habe ich schnell gemerkt: Scrum Master – das wäre auch was für mich.

Und wie hast Du dann die Rolle gewechselt?

Parallel zu meiner Arbeit als Redakteurin habe ich mich in die Tätigkeit eingearbeitet und mir theoretisches Wissen angeeignet. Gleichzeitig suchte ich in Absprache mit meinem Abteilungsleiter und meinem Teamkolleg*innen ein Team, in dem ich meine theoretischen Erfahrungen mit der Praxis verbinden konnte. Der Product Owner des Self Service Teams bot mir dann an, in seinem Team in die Rolle hineinzuwachsen.

Natürlich habe ich nicht alles stehen und liegen gelassen. Ich war Teil des Content-Teams. Gleichzeitig wollte ich aber auch die Chance nutzen. Wir haben uns dann zunächst für einen Mittelweg entschieden: Ich bin in Teilzeit als Co-Scrum-Masterin ins Self-Service-Team eingestiegen, neben meinem Job als Online-Redakteurin. Die eigentliche Scrum-Masterin des Teams hat mich dabei sehr unterstützt und war sozusagen meine Mentorin. Wir haben fast zwei Jahre gemeinsam als Scrum-Master im Team gearbeitet. Seit gut einem halben Jahr bin ich nun Vollzeit als Scrum Master tätig. In diesen zwei Jahren habe ich sehr viel gelernt.

Du bist als Scrum Master ja quasi Quereinsteigerin. Wie hast du die Rolle erlernt?

Für mich waren zunächst die Teammitglieder eine große Hilfe. Von der Scrum Masterin im Team habe ich sehr viel gelernt.  Es war super, eine erfahrene Kollegin an meiner Seite zu haben, die mir vertraut hat, mich aber auch mal ins kalte Wasser geworfen hat. Auch der Product Owner des Teams hat mich sehr unterstützt und gefördert.

Das theoretische Wissen habe ich mir in Schulungen und Seminaren angeeignet. Wir haben bei der DEVK zum Beispiel einen „Scrum-Master-Lernpfad“, der über 1,5 Jahre geht und die Fähigkeiten und Fertigkeiten eines Scrum Masters vermittelt. Schließlich habe ich auch die Zertifizierung zum Professional Scrum Master bei Scrum.org gemacht.

Du hast gesagt, deine Kollegin hat dich „ins kalte Wasser geworfen“. Was heißt das genau?

Sie hat mir nicht nur alles erklärt und mich überall hin mitgenommen, sondern mich auch machen lassen. Nach etwa einem Monat habe ich zum Beispiel schon meine erste Retrospektive konzipiert und moderiert. Da war ich vorher schon ein bisschen nervös. Ist dann auch eher mittelmäßig gelaufen (lacht). Aber die Erfahrung war super lehrreich für mich. Ich kannte die Teammitglieder damals noch nicht so gut wie heute. Was mir aber schnell klar wurde: Eine der wichtigsten Aufgaben eines Scrum Masters ist es, dem Team und den Teammitgliedern zuzuhören. Man muss sein Team kennen. Was beschäftigt sie? Wo liegen die Probleme? Aber auch: Wie sind die einzelnen Mitglieder gestrickt? Sprechen sie Schwierigkeiten und Probleme offen an oder verstecken sie Kritik hinter ironischen Bemerkungen? Dafür muss man als Scrum Master ein Gespür entwickeln, um einen Zugang zum Team und geeignete Lösungsansätze zu finden.

Bei meiner ersten Retro hatte ich ein Thema vorbereitet. Zu Beginn kam dann direkt die Frage aus dem Team: „Warum wollen wir das denn besprechen? Läuft doch alles super.“  Da steht man erst einmal da und fragt sich: „Und jetzt?“ Ich habe dann durch gezieltes Nachfragen den Dreh rausbekommen und aus dem Team herauskitzeln können, dass es doch ein paar Dinge gibt, über die man reden kann. Die richtigen Fragen stellen zu können, ist meiner Meinung nach eine zweite wichtige Fähigkeit eines guten Scrum Masters.

Du arbeitest im Self-Service-Team der DEVK. Was genau macht ihr?

Wir entwickeln meineDEVK, das Online-Portal für DEVK-Kund*innen. Hier können sie ihre Verträge und Dokumente verwalten, Schäden melden und mit ihrem Berater in Kontakt treten. Wir bieten auch die Möglichkeit, den kompletten Schriftverkehr zwischen unseren Kund*innen und der DEVK zu digitalisieren. Das Portal verfügt zudem über eine Update-Funktion für Versicherungsverträge. Mit einer Art Ampelsystem weist das Portal die Kund*innen darauf hin, auf welchem Stand sich ihr Versicherungsschutz befindet und ob es hier Optimierungspotenzial gibt.

Wir entwickeln das Portal komplett in unserem Team. Natürlich benötigen wir verschiedene Schnittstellen innerhalb der DEVK und stehen in engem Austausch mit anderen Abteilungen wie dem Vertrieb oder der IT. Aber die reine Entwicklung liegt komplett bei uns

Wie groß ist das Team?

Neben mir als Scrum Master und einem Product Owner (PO) arbeiten acht weitere Teammitglieder am Online-Portal. Im Team sind zwei Backend-Entwickler, zwei Frontend-Entwickler, zwei Tester, ein UX/UI-Designer und ein Business-Analyst. Außerdem haben wir einen Tech Lead im Team. Während mein Fokus auf den Prozessen und der Teamentwicklung liegt und unser PO Thomas die fachliche Führung und Priorisierung übernimmt, trifft der Tech Lead die Entscheidungen bezüglich Technik und Entwicklung.

Was sind deine Aufgaben als Scrum Masterin des Teams?

Ich sehe mich im Team nicht nur als Scrum-Coach und Moderator. Das sind zwei der zentralen Aufgaben, aber nicht die einzigen. Natürlich liegt mein Fokus darauf, dass wir die Werte und Regeln von Scrum im Team leben, um so effizient wie möglich zu arbeiten. Ich coache in agilen Arbeitsmethoden und unterstütze das Team dabei, eigenverantwortlich zu handeln.

Darüber hinaus lege ich ein besonderes Augenmerk auf das Thema Kommunikation – im und mit dem Team und mit den Stakeholder*innen. Die Art und Weise, wie wir miteinander kommunizieren, spielt eine große Rolle für den Erfolg unserer Arbeit. Davon bin ich überzeugt. Deshalb ist uns eine klare, offene und transparente Kommunikation sehr wichtig. Außerdem haben wir im Team eine echte Feedback-Kultur etabliert und geben uns regelmäßig Rückmeldung zu den Arbeitsergebnissen und der Zusammenarbeit im Team.

Eine weitere wichtige Aufgabe ist die Arbeit an Prozessen. Hier suche ich immer nach Möglichkeiten, wie wir die Zusammenarbeit im Team und mit den Stakeholder*innen verbessern können. Sei es durch die Einführung neuer Methoden oder Tools für die Zusammenarbeit oder Austausch- und Feedbackformate.

Außerdem bin ich im Team für das Onboarding neuer Teammitglieder zuständig. Das geht so weit, dass ich mich um die Technik, die benötigten Arbeitsmittel und Berechtigungen kümmere. Ich stelle Kennenlerntermine mit den Teammitgliedern und Kolleg*innen aus anderen Teams oder Abteilungen ein. Mein Ziel ist es, dass neue Teammitglieder alles bekommen, was sie brauchen, um gut im Team anzukommen und mitzumachen.

Wie ist deine Rolle in den Scrum-Events?

Ich plane, organisiere und führe die Scrum-Events als Moderatorin durch. Im Daily Stand-up leite ich die Diskussion, frage nach, ob die Absprachen eingehalten wurden und überprüfe mit dem Team den Status der aktuellen Tickets. Ich bereite das Sprint Planning vor, indem ich die Verfügbarkeiten des Teams für den kommenden Sprint überprüfe. Außerdem behalte ich einen Überblick über die durchschnittlich erreichten Story Points und weise das Team im Planning auf diese hin. So kann das Team besser einschätzen, wie viel Arbeit es für den Sprint planen kann. Sonst fällt uns das im Sprint und in der Retrospektive auf die Füße.

Unser Planning gliedert sich in zwei Teile: Der PO leitet Planning 1, in dem wir die Backlog Items besprechen, die das Team im Sprint abarbeiten wird. Im Planning 2 unterstütze ich das Team bei der Planung der konkreten Aufgaben aus den Items. Hier begleite ich eher durch Fragen und versuche sicherzustellen, dass alle verstehen, was mit den einzelnen Tickets gemeint ist.

In der Sprint Review fungiere ich zusammen mit dem Product Owner als Moderator. Hier haben die Teammitglieder die Möglichkeit, die Ergebnisse ihrer Arbeit zu zeigen. Wir machen immer eine Live-Demo, zeigen also echte Ergebnisse, keine Power-Point-Präsentation oder ähnliches.

Die Retrospektive ist für mich die wichtigste Veranstaltung, um die Zusammenarbeit im Team zu verbessern. Deshalb zähle ich sie auch zu meinen Hauptaufgaben: Ich bereite sie komplett vor und führe sie als Moderatorin durch. Außerdem verfolge ich, dass wir die beschlossenen Maßnahmen, wir nennen sie „Action Items“, auch umsetzen.

Wie gestaltest Du die Retrospektiven? Nutzt Du unterschiedliche Varianten?

Wir haben eine Art Vorlage entwickelt, die wir für jede Retro anpassen. Am Anfang machen wir immer einen Security-Check, der aus zwei Ebenen besteht: einem Safety-Check und einem Emotion-Check. Ich frage die Teilnehmer auf einer Skala von 1 bis 5, wie sicher sie sich fühlen, über alles reden zu können. Die Teammitglieder geben ihre Antwort nur an mich weiter. 5 bedeutet sehr sicher, 1 sehr unsicher. Wenn ein oder mehrere Teammitglieder mit einer Zahl unter 3 antworten, findet die Retrospektive nicht statt. Ich spreche mit der betreffenden Person und versuche, das Problem zu erörtern. Es kommt aber mittlerweile nicht mehr vor.

Beim Emotion-Check frage ich, wie sich die Teammitglieder persönlich fühlen, da dies auch Einfluss auf die Retrospektive hat. Wieder auf einer Skala von 1 bis 5. Wenn hier jemand mit einer Zahl unter 3 antwortet, vereinbare ich auch einen Gesprächstermin mit dem oder der Kolleg*in, wenn er oder sie das möchte.

Die eigentliche Retrospektive beginnen wir dann standardmäßig mit drei Elementen:

• Frage: Wie hast Du den Sprint erlebt? Welche Emotionen hattest du?
• Analyse des vergangenen Sprints anhand einer Übersicht der erledigten Stories. Wir prüfen, ob wir alle Tickets abgearbeitet haben und bewerten den Sprint mit 1 bis 5 Sternen.
• Jedes Teammitglied nennt sein Highlight des Sprints. Das können ganz unterschiedliche Dinge sein, z.B. eine tolle Zusammenarbeit mit einem anderen Teammitglied oder eine kreative Lösung für ein Problem.

Der Hauptteil der Retrospektive ist dann immer etwas anders. Manchmal machen wir hier einen Lean Coffee, eine Keep-Start-Stop-Retrospektive oder etwas ganz anderes. Ich versuche hier immer wieder etwas Neues auszuprobieren und mache zum Beispiel auch saisonale Retros, z. B. eine Weihnachtsretro. Letztens haben wir eine Super-Mario-Retro gemacht. Mittlerweile habe ich schon viele Varianten ausprobiert. Manchmal hole ich mir Inspirationen für Retros bei Miroverse.

Habt ihr auch noch weitere Retro-Formate?

Am Anfang des Jahres machen wir immer eine sogenannte „Futurespective“, in der wir schauen, was wir im ersten Halbjahr erreichen wollen. Am Ende des Jahres blicken wir dann in einer Retro auf das Jahr zurück und prüfen, was davon wirklich geklappt hat.

Wichtig: In jeder Retro vereinbaren wir Action Items, die wir bis zum nächsten Mal umsetzen wollen. Das können Maßnahmen zur besseren Zusammenarbeit sein oder auch klare To Dos, z.B. „Wir müssen einen Termin mit der Abteilung XY vereinbaren“ oder „Wir müssen uns mit folgendem Thema genauer auseinandersetzen“. Wir klären in der Retrospektive, wer sich um das jeweilige Action Item kümmert und überprüfen in der nächsten Retrospektive, ob es umgesetzt wurde.

Hast du ein konkretes Beispiel?

Wir verwalten unser Board und unsere Tickets in Jira. Das Tool bietet die Möglichkeit, die geschätzte Arbeitszeit zur Bearbeitung eines Tickets einzutragen. So können wir messen, wie lange es dauert, bis eine Aufgabe erledigt ist. In einer der letzten Retros haben wir beschlossen, das einmal zu testen. In einer der nächsten Retros werden wir besprechen, was es gebracht hat und ob wir es weiterführen wollen.

Oder: Wir hatten am Anfang nur einen Kollegen im Team, der sich um die Releases gekümmert hat. Das wollten wir gerne ändern, um unser Team mehr in Richtung T-Shape zu entwickeln. Wir haben im Team den Mehrwert erkannt, wenn mehrere Kolleg*innen diese Aufgabe übernehmen können. Also haben wir die Rolle „Release-Manager“ geschaffen, die für jedes Release von zwei Teammitgliedern übernommen wird. Zuerst haben wir immer am Anfang des Sprints gefragt, wer diese Rolle übernehmen möchte. Nachdem wir dann mehrmals nachgefragt und ein Rotationsprinzip eingeführt haben, funktioniert es mittlerweile sehr gut und hat sich etabliert. So konnten wir zwei Fliegen mit einer Klappe schlagen: Durch den Wissenstransfer können nun mehrere Kolleg*innen diese Aufgabe übernehmen. Und der Kollege, der sich bisher alleine darum gekümmert hat, wird entlastet.

Habt ihr im Team neben den klassischen Scrum-Events noch weitere Regeltermine?

Wir haben im Team ein sogenanntes Huddle etabliert, das einmal in der Woche stattfindet. Hier geht es um den Austausch und den Wissenstransfer. Wie gesagt, wir sind ein crossfunktionales Team. Wir arbeiten am gleichen Produkt und am gleichen Ziel, aber jeder macht etwas anderes. Im Huddle sprechen wir über unsere Arbeit. Wenn jemand zum Beispiel ein großes Problem gelöst hat, erzählt er, wie er es gelöst hat. Das Ziel ist, dass wir voneinander lernen.

Wir nutzen den Huddle aber auch, um Themen aus der Retrospektive ausführlicher zu besprechen. Wir planen auch mehrere Huddles zum Thema „Desaster Recovery“.  Hierbei überlegen wir uns, welche Katastrophenszenarien für unsere Arbeit möglich sind und wie wir darauf reagieren können. Was machen wir zum Beispiel, wenn das Rechenzentrum der DEVK ausfällt?

Weitere Regeltermine gibt es nicht. Mit den Scrum-Events und dem Huddle-Meeting ist der Terminkalender schon gut gefüllt. Oft haben einzelne Teammitglieder ja auch noch themenbezogene Termine im Team oder mit Stakeholder*innen.

Wir überdenken aber regelmäßig die Gestaltung und Häufigkeit unserer Termine. Mindestens halbjährlich überprüfen wir, wie wir das optimieren können.

Wie geht ihr mit Hindernissen in der täglichen Arbeit um?

Wir sind relativ autark in der Entwicklung des Portals. Trotzdem haben wir natürlich Schnittstellen und arbeiten mit verschiedenen Teams der DEVK zusammen. Da kann es auch mal dazu kommen, dass Teammitglieder auf Feedback warten oder auf die Unterstützung von Kolleg*innen aus anderen Abteilungen angewiesen sind. Und das kann dann zu Blockaden in der Arbeit führen.

Das besprechen wir dann meistens im Daily Stand-up. Ich biete meine Unterstützung an, oft kümmern sich die Kolleg*innen auch selbst um das Problem. Bei größeren Themen machen wir in der Regel einen Termin mit dem Teammitglied und den beteiligten Stakeholder*innen aus, um das Problem zu besprechen. Ich hole mir vorher so viele Informationen wie möglich und agiere während des Termins als Moderator. Dabei versuche ich immer, Verständnis für die „andere Seite“ zu zeigen. Wir arbeiten langfristig mit den Kolleg*innen zusammen, da hilft es nicht, Druck aufzubauen oder seinen Willen durchsetzen zu wollen. Oft wissen die Kolleg*innen auch gar nicht, dass ein Problem existiert. Wir versuchen immer, für alle eine gute Lösung zu finden.

Wenn es um Themen geht, die mehrere Teams betreffen, besprechen wir das entsprechend in einer größeren Runde. Wie in den meisten Fällen gilt: Kommunikation ist der Schlüssel. Und das heißt nicht nur reden, sondern auch zuhören. Ich glaube, das wird oft vergessen. Wir sollten alle weniger reden und mehr kommunizieren.

Was gefällt dir an der Rolle?

Ich finde es toll zu sehen, wie sich ein Team im Laufe der Zeit entwickelt und wie ich als Scrum Master dazu beitragen kann. Für mich ist es eine großartige Aufgabe, Menschen dabei zu helfen, besser zusammenzuarbeiten und auch besser miteinander auszukommen. Ich habe das große Glück, dass mir Themen anvertraut werden, die ich selbstständig und eigenverantwortlich bearbeiten kann. Und auch mal über etwas ganz Praktisches zu sprechen: Ich liebe es, Workshops vorzubereiten und durchzuführen.

Außerdem arbeite ich gerne übergreifend an der Organisation mit. Sei es an der Organisation des Teams, zum Beispiel bei der Gestaltung des Onboarding-Prozesses. Aber auch an der Gesamtorganisation: So durfte ich zum Beispiel einen Workshop zum Thema „Konfliktmanagement in der DEVK“ mitgestalten. Insgesamt macht es mir sehr viel Spaß, im gesamten Unternehmen zu vermitteln, wie agiles Arbeiten funktioniert und wie wir Prozesse effektiv und produktiv gestalten können.

Stichwort „agiles Arbeiten in der DEVK“: Habt ihr im Unternehmen regelmäßige Treffen, Workshops oder ähnliche Formate, um Agilität in der Organisation voranzutreiben?

Einmal im Monat treffen sich alle Scrum Master der DEVK. Jeder bringt Themen mit, über die wir diskutieren und voneinander lernen können. Meistens sind es Themen aus den eigenen Teams.

Außerdem veranstalten wir jährlich eine „Agile Praxiswerkstatt“. An diesem Format können alle interessierten Mitarbeitenden der DEVK teilnehmen. Also nicht nur Scrum Master oder Agile Coaches. Meist gibt es zu Beginn eine Keynote und anschließend ein Open Space Format. Hier kann jeder Teilnehmende Themen einbringen, die wir dann in verschiedenen Panels diskutieren.

Und dann gibt es noch das „Agility Coffee“: Hier laden wir externe Referenten ein, die Themen vorstellen und oft auch Übungen oder Trainings dazu durchführen. Zuletzt haben wir uns mit „Psychologischer Sicherheit“ beschäftigt.

Was konntest Du persönlich für Dich aus diesen Treffen mitnehmen?

Gerade in den regelmäßigen Scrum-Master-Meetings merkt man, dass die Probleme vieler Teams ähnlich sind und viele häufig auftreten. Die Lösungsansätze meiner Kolleg*innen, über die wir sprechen, sind oft auch für mich und meine Arbeit hilfreich.

Ich bin ja noch relativ frisch in der Rolle und da ist es auch interessant zu sehen, was noch alles auf mich zukommen kann (lacht). Man merkt auch: Wo sind meine Lücken? In welchen Bereichen muss ich mich noch weiterbilden? Zum Beispiel: Ich bin als Scrum Master in ein bestehendes Team gekommen. Mir fehlt die Erfahrung, ein neues Team mit aufzubauen. Das erfordert noch einmal andere Kompetenzen und Fähigkeiten.

Wo wir beim Thema sind: Was glaubst du sind die wichtigsten Fähigkeiten und Kompetenzen, die ein Scrum Master mitbringen muss?

Zunächst einmal muss ein Scrum Master natürlich mit agilen Arbeitsweisen vertraut und ein echter Scrum-Experte sein. Seine Hauptaufgabe ist es, das Team besser zu machen. Neben diesen fachlichen Kompetenzen muss er oder sie aber noch einige andere Dinge mitbringen, die gemeinhin eher als „Soft Skills“ bezeichnet werden. Meiner Meinung nach sind diese aber mindestens genauso wichtig wie die „Hard Skills“. Ohne sie kann der Scrum Master seinen Job nicht wirklich gut machen.

Und da bin ich wieder beim Thema Kommunikation: Ein guter Scrum Master muss offen und transparent kommunizieren. Er muss aber auch hinterfragen können und den Mut haben, auch kritische Fragen zu stellen. Ein Scrum Master muss sich Gehör verschaffen, nicht nur im Team, sondern auch gegenüber Stakeholder*innen.

Der Scrum Master dient dem Team mit dem Ziel, dass es bestmöglich arbeiten kann. Daher muss er als Vertrauensperson anerkannt sein. Ohne gegenseitiges Vertrauen funktioniert die Zusammenarbeit nicht. Ein Scrum Master sollte eine enge Bindung zum Team haben, das Teambuilding vorantreiben und unterstützen. Hier sind auch seine kommunikativen Fähigkeiten gefragt. Er ermutigt die Teammitglieder, sich offen zu äußern und unterstützt die Lösungsfindung durch gezieltes Nachfragen. Ein Scrum Master ist nicht dazu da, dem Team fertige Lösungen für ein Problem zu liefern. Er unterstützt seine Kolleg*innen darin, eigenständig Lösungen zu entwickeln. Dies ist ein zentraler Aspekt in der Selbstorganisation von Teams.

Ein Scrum Master muss das Rückgrat haben, sich nicht in die Rolle des „Moderators und Händchenhalters“ drängen zu lassen. Er muss auf allen Ebenen kommunikationsfähig sein und auch gegenüber Stakeholder*innen und dem Product Owner selbstbewusst auftreten können. Das bedeutet, dass er z.B.  dem Product Owner auch mal auf die Füße treten oder ihm beibringen muss, wie er das Team befähigen kann.