Der unerfahrene Scrum Master wird zur Sekretärin
Scrum Master mit Erfahrung gibt es nicht viele. Daher werden oft Mitarbeiter zu Scrum Mastern umgeschult, wenn Scrum eingeführt wird. Meist durch einen Coach, der das gesamte Unternehmen bei der Einführung berät. Dies kann gelingen, wenn der Coach dafür genug Zeit hat und es nicht nebenbei macht, aber leider ist dies nach meiner Erfahrung nicht der Fall.
Die noch schlechtere Alternative sind die Scrum Master Trainings: sie gehen oft nur ein oder zwei Tage und vermitteln zwar die prozeduralen Grundlagen, aber dies reicht einfach nicht aus, um ohne weitere Anleitung erfolgreich zu sein. Nach meiner Einschätzung liegt dies daran, dass man sich unter der Rolle des Scrum Masters nur sehr wenig vorstellen kann und Vergleiche zu bekannten traditionellen Rollen, die es in der klassischen Softwareentwicklung gibt, nicht möglich sind. Eine Stilblüte davon ist es, einen Scrum Master als Projektmanager oder Teamleiter anzusehen.
Typischerweise erhält ein neuer Scrum Master einen Appell, die Scrum Werte zu verinnerlichen und eine ausgedruckte Kopie des offiziellen Scrum Guide. Dies ist ein guter Anfang aber reicht natürlich bei Weitem nicht aus. Was genau ist denn bitte "Servant Leadership"? Was bedeutet dies im Arbeitsalltag? Wie soll man dem Product Owner helfen, sein Product Backlog effizient zu managen? Wie hilft man dem Entwicklungsteam, hochwertige Produkte zu erstellen?
Letztlich bleibt der Scrum Guide und viele Quellen im Internet nur im Ungefähren. Auf das Einhalten der Scrum Events zu achten und diese zu organisieren (das noch nicht so selbständige Team wird dies gerade zu Beginn der Umstellung auf Scrum noch nicht machen) und Impediments, also Hindernisse für das Team, beseitigen, sind die einzigen etwas klareren Aufgaben. Und deshalb stürzt sich ein unerfahrener Scrum Master natürlich darauf. Da weiß er oder sie wenigstens ziemlich genau, was es zu machen gilt. Und so hält sich der neue Scrum Master ganz schnell an trivialen organisatorischen Aufgaben fest. Dieser Effekt verstärkt sich tendenziell sogar noch selbst: Bei der Einführung von Scrum in einem Unternehmen, sind die typischen Impediments Unterbrechungen durch Personen anderer Abteilungen, die in den Team Space kommen und Fragen haben. Der Scrum Master bittet dann höflich, aber bestimmt dies zu unterlassen. Entsprechend sind diese Mitarbeiter verunsichert und wissen nicht, wie und wann sie mit dem Team kommunizieren dürfen. Klärt hier der Scrum Master nicht auf, wird es darauf hinauslaufen, dass er dann die Anfragen stattdessen per E-Mail bekommt, und zwar mit der Bitte diese an das Team zum geeigneten Zeitpunkt weiterzuleiten. So wird der Scrum Master zum E-Mail Router. Das Entwicklungsteam denkt mit der Zeit dann deshalb auch noch irrigerweise, dass der Scrum Master der "Universal Organisator" für das Team ist und es so laufen muss.
Mein Tipp für "frische" Scrum Master: lernt so schnell wie möglich erfahrene Scrum Master kennen und tauscht euch mit ihnen aus! Begreift sehr genau, wie die Aufgabenteilung zwischen Product Owner und Entwicklungsteam aussehen soll und coacht sie genau in diesem Punkt. Je schneller die Refinement Meetings kollaborativ verlaufen, desto schneller fühlt sich das gesamte Team wohl und wird selbstsicherer in der Anwendung von Scrum. Dies verschafft Ruhe und damit Zeit, Zeit dich als Scrum Master weiterzuentwickeln, denn diese Rolle ist fast alles, nur keine eines Organisators und Sekretärs!