Die ersten sechs Monate als Scrum Master bei CodeCamp:N

Die Entwicklung vom blutigen Anfänger zum Junior Scrum Master


Hey, mein Name ist Brendan und ich arbeite seit über sechs Monaten als Scrum Master im CodeCamp:N. Ich möchte euch erzählen, wie es für mich war als Scrum Master anzufangen, was mir geholfen hat, mich als Scrum Master zu etablieren und warum ich hier gerne arbeite.

Kurz zu mir: Ich bin 26 Jahre alt und habe 2017 als Praktikant im CodeCamp:N angefangen. Nach Aufgaben im Eventmanagement, in der Produktentwicklung und der Baukoordination habe ich mich im September 2019 als Scrum Master zertifizieren lassen. Neben meiner Arbeit studiere ich den Master Management an der Handelshochschule Leipzig. In meiner Freizeit fahre ich gerne mal längere Strecken mit dem Fahrrad nach Würzburg, Bamberg oder Bayreuth und spiele einmal die Woche mit meinen Kollegen Fußball. So jetzt aber genug zu mir, beginnen wir mit meiner Geschichte.

Meine Geschichte Teil I (September – Dezember 2019):

Vom Krabbeln zum Stolpern (Transparent)

Nachdem unser zweiter Standort in der Solgerstraße fertig saniert war, begann mein Weg zum Scrum Master. Zum Einstieg habe ich unseren Scrum Master Georg begleitet, dessen Team bankz family ich nach einiger Zeit übernommen habe. Ziel der ersten Wochen war es, meine Scrum Master Zertifizierung abzuschließen und erste praktische Erfahrungen zu sammeln. Das Erste war einfacher, das Zweite lehrreicher.

Meine ersten Wochen in bankz family waren für das Team und mich von Veränderung geprägt. Ich übernahm Georgs Aufgaben als Scrum Master. Gleichzeitig wechselten Kollegen vom und ins Scrum Team bankz family. Daher mussten das Team und ich uns neu organisieren. Hier war ich als Scrum Master gefragt, dem Team zu helfen das Scrum Framework für sich zu nutzen.

Meine Reflektion aus den ersten Monaten als Scrum Master (Inspection):

  • Wenn das Team eine Veränderung nicht versteht oder nicht als sinnvoll erachtet, wird es diese Veränderungen auch nicht konsequent umsetzen. Und das ist richtig so!
  • Ich muss begründen können, warum die Termine, Rollen und Artefakte im Arbeitsablauf wichtig sind.
  • Eine Zertifizierung heißt nicht, dass du Scrum komplett verstanden hast oder umsetzen kannst.


Meine Maßnahmen daraus (Adaption):

  • Für eine erfolgreiche Umsetzung brauchte ich tieferes Wissen über Scrum. Deswegen habe ich ein Scrum Theoriebuch aus dem Bücherregal im CodeCamp:N genommen und es gelesen!


Meine Learnings:

(1) Scrum wurde für mich ein schlüssigeres Framework, nicht nur eine Wolke von Buzzwords.

(2) Es gibt Wasserfall, was so etwas wie das Gegenteil von Scrum ist. Die klassische Vorgehensweise funktioniert nicht mehr, weil sie einem vordefinierten Plan folgt und sich nicht an den Markt anpasst. Das passt nicht mehr in unsere komplexe Umwelt.

(3) Ich fand die Erklärungen zwar schlüssig im Buch, konnte aber im Arbeitsalltag die Ansätze nicht auf einfache Erklärungen herunterbrechen.

Bevor ich weitermache: Mein Dank in dieser Anfangsphase geht an das Team bankz family. Sie haben sich klar zum Produkt bekannt und konsequent nur die Dinge umgesetzt, die sie auch tatsächlich als sinnvoll erachtet haben. Das hat mich motiviert, unsere Arbeitsweise an das Produkt und unserer Umwelt anzupassen, statt blind einem Framework zu folgen.

Zusätzlich zu diesem tollen Team hat mich unsere kleine, aber feine interne Bibliothek, der regelmäßige Austausch mit dem Enabler Marko sowie die Community of Practice der Scrum Master schnell auf die richtige Bahn gebracht.


Meine Geschichte Teil II (Januar – März 2020):

Meine ersten eigenen Schritte auf dem Weg zum Scrum Master (Transparent)

Neben meiner Tätigkeit in bankz family sammelte ich erste Erfahrungen in einem zweiten Team. Hier übernahm ich von Niklas ab Januar die Rolle des Scrum Masters. Ich war zwar schon ab Oktober im Projekt, teilte mir aber bis Dezember die Scrum Master Rolle mit ihm. Das Team bestand aus CodeCamp Mitarbeitern und Mitarbeitern eines anderen IT-Dienstleisters. In dem Projekt wurde bereits seit sechs Monaten erfolgreich mit Scrum gearbeitet.

Im Januar konnte ich mit dem Team kleine Maßnahmen ausprobieren, die unsere Arbeitsweise und den Prozess an äußere Faktoren anpassen sollten. Diese wurden dann entweder beibehalten oder wieder fallen gelassen, wenn diese das Team nicht unterstützte. Als problematisch stellte sich heraus, Konsequenzen aus Veränderungen im Voraus abzuschätzen und einfach zu erklären, warum wir nah am Scrum Prozess bleiben sollten. Es wurde aber immer wieder klar, dass ein Entfernen vom Framework zu einer Verschlechterung in unserem Workflow oder der Voraussagekraft führte. Warum das so war, konnte ich weder greifen noch erklären.

Meine Reflektion (Inspection):

  • Ich konnte schwer begründen, warum wir nach Scrum arbeiten müssen.
  • Ich konnte sehen, dass es oft kontraproduktiv ist, vom Framework abzuweichen, konnte mir aber nicht erklären warum.


Meine Maßnahmen (Adaption):

  • Handrecherche über die Herkunft und Basis von Scrum, wobei ich auf agiles Arbeiten stieß.
  • Analyse, was die Ziele und Grundprinzipien von agilem Arbeiten sind.


Meine Learnings:

Es ist viel wichtiger zu verstehen, warum man agil arbeiten sollte als warum nach Scrum. Meiner Meinung nach kommt man von automatisch zu Scrum, wenn man die agilen Grundwerte lebt.

Nach diesen zwei Reflektionszyklen fokussierte ich mich darauf, meinem Team die agilen Ziele und Grundwerte zu vermitteln. Diese Grundlage half uns, die gemeinsame Softwareentwicklung zu verbessern. Nachdem wir das “why“ verstanden hatten, konnten wir als Team auch vom Scrum Prozess abweichen, ohne negative Konsequenzen zu spüren. Vielmehr konnten wir unseren Arbeitsprozess an uns und unsere Umwelt anpassen, sowie Konsequenzen besser im Voraus abschätzen.

Mein Dank in der zweiten Phase geht an das unternehmensübergreifende Team, durch das ich lernen konnte, wie in anderen Unternehmungen mit Scrum umgegangen wird. Ebenfalls möchte ich dem Team KFZ Digital für das transparente Feedback danken, durch das ich mich verbessern konnte. Eine weitere wichtige Stütze waren die Enabler Marko und Dominik, die Selbstorganisation fördern und eine Fehlerkultur zulassen, bei der man ausprobieren kann und auch mal falsch liegen darf.


Was ich heute mache (April 2020):

Nach sechs Monaten bei bankz family und KFZ Digital verließ ich beide Teams, um zu AKAB zu wechseln. AKAB ist ein Projekt der NÜRNBERGER, um deren IT-Infrastruktur zu modernisieren. Ich bin auf der einen Seite traurig, die Teams zu verlassen, da sie mir auf ihre sehr unterschiedlichen Arten sehr viel beigebraucht haben und wir sichtbare Fortschritte gemacht haben. Auf der anderen Seite freue ich mich riesig auf AKAB, da dort ein super Team auf mich wartet und ich bei der Implementierung von SAFe von Anfang an dabei sein darf.

Falls du Interesse hast, agile Projekte als Scrum Master zu begleiten, gefördert und gefordert zu werden und jeden Tag dazu zu lernen, dann kannst du dich gerne bei uns bewerben. Wir suchen noch weitere Scrum Master.

Ich melde mich in sechs Monaten wieder, da dieser Bericht zwar eigentlich für euch ist, aber er mir beim Reflektieren geholfen hat.

Bis bald, Brendan Kolb