Interview mit Mark Hay, Scrum Master bei der x-root
Unser Team wächst weiter: Mit Mark begrüßen wir einen neuen Scrum Master, der unsere Entwicklungsteams künftig bei der Umsetzung agiler Projekte unterstützt. In dieser Rolle sorgt er dafür, dass Scrum als Framework effektiv eingesetzt wird und Teams strukturiert, transparent und zielgerichtet zusammenarbeiten können.
Im Interview spricht Mark darüber, was ihn an agiler Zusammenarbeit begeistert, welche Rolle ein Scrum Master im Projektalltag spielt und wie Teams von klaren Prozessen und kontinuierlicher Verbesserung profitieren.
Hi Mark, du bist frisch bei der x-root gestartet! Hast du Lust, dich kurz vorzustellen?
Hi, ich bin Mark. Scrum Master, Agile Coach und seit Kurzem Teil des x-root-Teams. Ich komme aus dem agilen Umfeld und bringe über zehn Jahre Erfahrung mit, unter anderem aus der Automobilindustrie bei BMW und MAN, wo ich sowohl einzelne Teams als auch größere Verbünde von bis zu 20 Teams begleitet habe.
Was mich an x-root gereizt hat: Hier wird maßgeschneiderte Software mit einem klaren Fokus auf Qualität entwickelt und genau dort, direkt im Team und am Produkt, möchte ich wirklich etwas bewegen.
Ich bin zweisprachig aufgewachsen Deutsch und Englisch und freue mich darauf, mit euch gemeinsam herauszufinden, wie wir die agile Arbeitsweise bei x-root weiter voranbringen können.
Was macht eigentlich ein Scrum Master und was ist deine Aufgabe bei der x-root?
Ein Scrum Master sorgt dafür, dass das Team effektiv zusammenarbeiten kann nicht durch Kontrolle, sondern durch Unterstützung.
Konkret bedeutet das: Ich moderiere Scrum-Events wie Sprint Planning, Daily, Review und Retrospektive, mache Hindernisse sichtbar und beseitige sie, und helfe dem Team, sich kontinuierlich zu verbessern. Ich bin auch Schnittstelle zwischen Team, Product Owner und Stakeholdern nicht als Kommunikationsfilter, sondern als Brücke, die für gemeinsames Verständnis sorgt. Bei x-root sehe ich meine Aufgabe darin, das Team fokussiert zu halten, damit Tempo und Qualität nicht gegeneinander ausgespielt werden müssen.
Welche Erfahrungen hast du als Scrum Master bereits gesammelt?
Meine Erfahrung reicht von der Einführung agiler Arbeitsweisen in klassisch organisierten Unternehmen bis hin zur Koordination großer Agile Release Trains mit 20 Teams bei BMW. Bei Aisin Europe habe ich drei Produkte von der Idee bis zur Markteinführung begleitet, bei MAN agile Methoden in Engineering-Funktionen eingeführt, die traditionell sehr wasserfallartig gearbeitet haben. Ich bin zertifiziert als CSM, PSPO, ICAgile Coach und Team Facilitator sowie als SAFe Release Train Engineer aber Zertifikate sind für mich Mittel zum Zweck, kein Selbstzweck.
Wie würdest du die Rolle des Scrum Masters in der Individualsoftwareentwicklung beschreiben und welchen konkreten Einfluss hat sie auf den Projekterfolg?
In der Individualsoftwareentwicklung ist jedes Projekt einzigartig die Anforderungen, die Kunden, die technische Ausgangslage. Das bedeutet, der Scrum Master muss sehr schnell verstehen, was das Team und der Kunde wirklich brauchen, und sicherstellen, dass das im Sprint-Rhythmus sichtbar wird. Der konkrete Einfluss zeigt sich meiner Erfahrung nach vor allem in drei Bereichen:
- schnelleres Erkennen von Fehlentwicklungen durch kurze Feedbackzyklen,
- weniger Nacharbeit weil Anforderungen früh geklärt werden, und
- ein Team das mit der Zeit weniger Führung braucht und mehr selbst entscheidet.
Ich würde aber vorsichtig sein zu behaupten, dass ein Scrum Master allein den Projekterfolg garantiert er ist ein wichtiger Hebel, aber kein Allheilmittel.
Warum ist ein Scrum Master aus deiner Sicht ein entscheidender Erfolgsfaktor in Softwareprojekten?
Weil die größten Probleme in Softwareprojekten selten technischer Natur sind sie entstehen durch unklare Prioritäten, schlechte Kommunikation, Überlastung oder das Ignorieren von Frühwarnsignalen.
Ein guter Scrum Master hält diese systemischen Probleme im Blick, bevor sie eskalieren. Er schafft einen Rahmen, in dem das Team offen über Schwierigkeiten sprechen kann und das ist die Voraussetzung dafür, dass Probleme gelöst werden, bevor sie Deadlines gefährden. Ich sage das mit einer gewissen Überzeugung aus Erfahrung, würde aber fairerweise ergänzen: Ein Scrum Master entfaltet diese Wirkung nur, wenn er auch die Unterstützung des Managements hat.
Wie stellst du in der Praxis sicher, dass fachliche Anforderungen wirklich verstanden und korrekt umgesetzt werden?
Mein wichtigstes Werkzeug dafür sind gut strukturierte Backlog Refinements und klare Definition-of-Done-Kriterien. Im Refinement stelle ich sicher, dass User Stories nicht nur geschätzt, sondern auch hinterfragt werden, was ist der eigentliche Nutzen, was sind die Akzeptanzkriterien, was könnte missverstanden werden?
Ich arbeite eng mit dem Product Owner zusammen, damit Stories nicht unklar ins Sprint Planning gehen. Zusätzlich helfen Sprint Reviews, bei denen wir funktionsfähige Software zeigen keine Status-Updates. Das zwingt zur echten Überprüfung, ob das Gebaute dem entspricht, was gemeint war.
Welche typischen Risiken und Konflikte begegnest du in Softwareprojekten, und wie greifst du als Scrum Master ein?
Die häufigsten Risiken, die ich beobachte, sind: zu viel Arbeit für zu wenige Sprints (Scope Creep), technische Schulden die ignoriert werden, und unklare Priorisierung seitens des Product Owners.
Bei Konflikten zwischen Team und PO etwa wenn Kapazität und Erwartungen auseinanderklaffen greife ich früh ein, indem ich das Gespräch strukturiere und Fakten auf den Tisch lege: Velocity, Kapazität, offene Impediments.
Mein Ansatz ist, Transparenz herzustellen bevor jemand überrascht wird. Konflikte innerhalb des Teams adressiere ich bevorzugt in der Retrospektive in einem geschützten Rahmen, nicht ad hoc im Daily.
Wie sorgst du für Transparenz gegenüber den Projektbeteiligten, insbesondere Product Ownern?
Transparenz entsteht für mich durch sichtbare Boards, klare Sprint Goals und regelmäßige, ehrliche Kommunikation nicht durch umfangreiche Reports.
Mit dem Product Owner arbeite ich auf Augenhöhe: wöchentliche Sync-Termine, gemeinsame Backlog-Arbeit und klare Signale, wenn ich Risiken für das Sprint Goal sehe. Bei BMW habe ich Jira-basierte Team-Health-Metriken aufgebaut, die Flow und Blockaden sichtbar gemacht haben so etwas würde ich auch bei x-root schrittweise einführen, angepasst an den Reifegrad des Teams.
Woran misst du den Erfolg deiner Arbeit als Scrum Master?
Mein wichtigster Indikator ist: Braucht das Team mich weniger als zu Beginn? Wenn Teams nach einigen Monaten selbständig Probleme ansprechen, Impediments selbst lösen und Retrospektiven eigenständig gestalten, dann hat mein Coaching gewirkt.
Darüber hinaus schaue ich auf Liefervorhersagbarkeit (Velocity-Stabilität), die Qualität der Retrospektiven-Outputs und ganz pragmatisch ob Sprints mit einem klaren Done abgeschlossen werden. Ich bin vorsichtig mit rein quantitativen Metriken, weil sie leicht zu Gaming-Verhalten führen.
Was macht aus deiner Sicht einen guten Scrum Master aus?
Drei Dinge:
- Erstens echtes Interesse am Menschen im Team nicht nur am Prozess.
- Zweitens die Fähigkeit, Dinge anzusprechen, die unangenehm sind, ohne dabei Vertrauen zu zerstören.
- Drittens pragmatisches Framework-Verständnis: Scrum ist ein Werkzeugkasten, kein Dogma.
Ein guter Scrum Master weiß, wann er das Framework anpassen muss und wann er es verteidigen sollte.
Was mich persönlich antreibt: Ich messe meine Arbeit daran, ob Teams nach einer gewissen Zeit weniger Methodenerklärung brauchen und mehr Initiative zeigen das ist in meinem Anschreiben gut zusammengefasst und entspricht wirklich dem, was ich glaube.
Wie sieht dein Arbeitsalltag während eines laufenden Projektes konkret aus?
Ein typischer Tag beginnt mit dem Daily ich moderiere es, aber es gehört dem Team. Danach schaue ich, welche Impediments offen sind und wo ich aktiv werden muss.
Ich führe regelmäßige kurze Gespräche mit dem Product Owner, um den Backlog-Status im Blick zu behalten.
Zwischen den Events arbeite ich an der Vorbereitung kommender Ceremonies, kläre offene Fragen mit Stakeholdern oder coache Einzelpersonen.
Gegen Ende des Sprints intensiviere ich die Kommunikation rund um Review und Retrospektive.
Was sollten Projektverantwortliche bei der Auswahl eines Software-Dienstleisters in Bezug auf Scrum besonders beachten?
Drei Dinge würde ich empfehlen zu prüfen: Erstens, ob Scrum wirklich gelebt wird oder nur als Labeling existiert also: Gibt es echte Sprint Reviews mit funktionierender Software, oder werden Präsentationen gezeigt?
Zweitens, wie der Dienstleister mit Scope- und Anforderungsänderungen umgeht. Ein agil arbeitendes Team sollte das als normal behandeln, nicht als Sonderfall.
Drittens, ob es einen klaren Ansprechpartner auf Product-Owner-Seite beim Kunden gibt, ohne aktive Kundenbeteiligung funktioniert Scrum nicht, egal wie gut das Team ist.
Das ist etwas, das ich aus eigener Erfahrung gelernt habe: Die besten Teams scheitern an schlechter Kundeneinbindung.
Vielen Dank für die interessanten Einblicke in deine Erfahrungen mit agiler Zusammenarbeit uns Scrum!
Sind noch Fragen offen? Schreibt es uns in die Kommentare!
