Endlich startet dein erstes Scrum-Projekt, und du freust dich, dein ganzes Wissen in die Praxis umzusetzen. Du hast viel gelesen und gelernt, weißt auch, wie Scrum funktioniert und wer welche Verantwortung zu tragen hat. Deine Rolle als ScrumMaster verstehst du gut:
Du willst das Team produktiver machen, indem es sich kontinuierlich verbessert. Daneben sollst du Strukturen so verändern, dass die Teammitglieder erfolgreich sind und zuverlässig ihre Arbeit liefern können. Und die Kommunikation sollst du so steuern, dass der Fokus gewährleistet ist und Ergebnisse erzielt werden können.
Du stehst das erste Mal vor deinem Team, viele Augenpaare schauen dich an. Du merkst schnell: So einfach wie du dachtest wird das nicht. Denn du bist nun für den Prozess und die Produktivität verantwortlich, aber darüber hinaus auch dafür, Teamdynamiken zu erkennen, und im Rahmen von Scrum und Agilität weiterzuentwickeln und zu verändern. Das klingt in der Theorie super. Aber wie gelingt es dir in der Praxis?
Ich möchte hier eine Reihe meiner Erfahrungen schildern, die ich bei meinen Scrum-Projekten gemacht habe. Vielleicht findest du dich in diesen wieder.
Um mich herum saßen lauter erfahrene Softwareentwickler:innen, die sollten doch wissen, wie das mit Scrum läuft, oder? Das war mein erstes Missverständnis. Ich dachte, ich müsste nicht mehr viel erklären und wir könnten direkt loslegen. Während einer Retrospektive wurde mir aber bewusst, dass ich damit falsch lag. Plötzlich und (für mich) überraschend kam die Frage auf, warum wir in Sprints von nur zwei Wochen arbeiten sollten. Die Teammitglieder fragten nach Verlängerungen, weil sie dachten, in zwei Wochen doch gar nicht so viel schaffen zu können. Und auch an den Retrospektiven zweifelten sie: Reine Zeitverschwendung, lautete der vernichtende Kommentar. Ihr seht, wir mussten an einem ganz anderen Punkt ansetzen.
Das habe ich daraus gelernt: Bei der Übernahme der Rolle in einem Team würde ich zunächst eine Umfrage zu Scrum und agilem Wissen machen, um festzustellen, welchen Wissensstand das Team hat. Dann würde ich herausfiltern, wie ich als Scrum Master meine Erfahrung und mein Wissen bestmöglich einsetzen kann, um das Team in eine gemeinsame Richtung bringen zu können.
Du kennst als Scrum Master die Theorie gut und willst diese in die Praxis umsetzen, aber das ist unheimlich fordernd. Einerseits braucht dein eigener Weg vom Wissen zum Verstehen und schließlich Anwenden Zeit und Erfahrung. Du wirst außerdem feststellen, dass es nicht so einfach ist, Strukturen in Teams und in Organisationen in der Regel zu verändern kann, wie es die Bücher suggerieren.
Deine Aufgabe wird zu Beginn vor allem sein, das Team vor äußeren Störungen zu schützen und für Fokus zu sorgen. Das mag dich zunächst überwältigen, aber nach dem dritten Sprint ist vieles sehr routiniert und dann kannst du dich verstärkt darauf konzentrieren, was dein Team braucht. Dabei hilft dir dein theoretisches Wissen.
Das habe ich daraus gelernt:
Bleib entspannt und mach dir nicht zu viel Druck. Du wirst nicht alles auf einmal und sofort erreichen, dafür aber ganz sicher nachhaltig. So war ich unheimlich zufrieden, als mein Team schließlich von sich aus Dinge vorschlug, die ich mit Interventionen versucht hatte, in den Fokus zu rücken.
So wollte ich beispielsweise die unmittelbare Zusammenarbeit an einem Task fördern, um das Risiko von Wissenssilos zu verringern. Ich hatte ständig von Pair oder Mob Programming und vom Busfaktor gesprochen, doch häufig wurde mir berichtet, dass Pairing nicht funktioniere bzw. doch alles verlangsamere, wenn gemeinsam an Aufgaben gearbeitet wird.
Dennoch konnten wir als Teams aufgrund von Abwesenheiten oder Krankheiten Dinge nicht zeitnah fertigstellen. Als ein Entwickler während des Refinement Meetings dann meinte: „Wir sollten uns im zukünftigen Sprint nur auf eine Sache alle gemeinsam fokussieren“ und er dafür Zuspruch erhielt, war das für mich ein großer Erfolg. Der Busfaktor wurde ernster genommen und verselbstständigte sich sogar als Running Gag.
Tipp: Ein gutes Instrument, um die eigenen Gedanken zu sortieren, ist ein Impediment Board oder ein eigenes ScrumMaster-Taskboard. Hier kannst du alle deine Ideen, aufkommende Gedanken, Hypothesen notieren, diese reflektieren und gegebenenfalls in Handlungen und Aufgaben überführen.
Ich habe jeden Morgen nach dem Daily meine Beobachtungen notiert und versucht, dabei wertfrei zu sein. Das ist gar nicht so einfach, denn in fast jedem Satz war ein „viel“, „wenig“, „laut“, „schnell“. Dann habe ich mir angewöhnt, die Wertungen einfach zu streichen und die Beobachtungen nochmal durchzulesen. Das war schon besser.
Das habe ich daraus gelernt: Anhand deiner wertfreien Beobachtungen kannst du Hypothesen darüber bilden, was die Produktivität deines Teams behindert. Wenn du für dich Hypothesen aufgestellt hast, kannst du damit experimentieren und gezielter Interventionen vorbereiten. Dabei lernst du wahrscheinlich, dass du durch wertfreies Beobachten deine Interpretationen, deine Bewertungsgrundsätze und auch deine Emotionen reflektieren kannst, damit diese die Teamarbeit weniger beeinflussen.
In meinem Team habe ich beispielsweise beobachten können, dass selbst fünf Tage nach unserem Sprint Planning kein Fortschritt unserer geplanten Aufgaben erzielt wurde. Ich habe mich gefragt, woran kann das liegen und habe die Hypothesen aufgestellt, dass entweder die Stories zu groß sind, dass es Unklarheiten und Unwissenheit bei der Bearbeitung der Story gab und dass die Teammitglieder möglicherweise viel nebenbei machten wie z.B. Recruitinggespräche oder andere interne Termine, die nicht auf unsere Arbeit einzahlten.
Ich habe mir anfangs immer die Frage gestellt: Warum sind die Dinge so, wie sie sind, warum funktionieren Teams, Strukturen und Organisationen so und nicht anders? Irgendwann habe ich mir diese Frage nach dem Warum abgewöhnt.
Natürlich kann es sinnvoll sein, nach Ursachen zu forschen und Gründe für bestimmte Aktionen oder Reaktionen zu verstehen, aber oftmals hilft es nicht. Im Gegenteil, man dreht sich immer im Kreis, bis einem schwindelig wird und das ist nicht effektiv.
Das habe ich daraus gelernt: Ich stelle nicht mehr die Frage nach dem Warum, sondern frage mich: Was kann ich tun, damit es anders wird? Ich drehe mich nicht mehr im Kreis, sondern werde wirksam und produktiv. Und ich frage das Team in der Retrospektive: Was können wir tun, damit sich die Problemfelder und Themen verändern?
In meinen ersten Sprint Plannings war ich sehr verkrampft. Ich hatte viele Pläne gemacht, um das Meeting perfekt durchführen zu können. Entgegen meiner Erwartung blieb das Team im Meeting dann aber passiv, kaum jemand sagte unaufgefordert etwas. Es war für alle mühsam.
Dann las ich das Buch von Gerald Hüther „Wie Träume wahr werden“, in dem stand, ich solle einfach Spaß haben: „Alles, was wir mit Freude tun und was uns bisweilen sogar begeistert, gelingt uns nach einiger Zeit immer schneller und nachhaltig besser.“
Das habe ich daraus gelernt: Hab Spaß und du wirst Erfolg haben. Es stimmt wirklich. Als ich mich dazu entschlossen hatte, Spaß zu haben, waren die Meetings und auch meine Arbeit in der Rolle des ScrumMasters leichter und damit einfach erfüllender.
Weitere Blogbeiträge für ScrumMaster findest du hier: ScrumMaster-Praxistipps
Bildquelle: Dayne Topkin on Unsplash