Lass mich dir ein Geheimnis verraten:
Ich habe einen sechsten Sinn.
Ich erkenne einen guten Scrum Master, wenn ich ihm bei der Arbeit über die Schulter schaue.
Vielleicht bilde ich mir das aber auch nur ein. Was ich allerdings weiß: Durch meine eigene Arbeit in Scrum Teams, den jahrelangen Austausch mit anderen Scrum Mastern in CoPs, Meet-ups und Weiterbildungen, meine eigenen fortgeschrittenen Scrum-Master-Schulungen und nicht zuletzt das viele Coaching anderer Scrum Master in den vergangenen zehn Jahren habe ich ein besseres Gespür dafür bekommen, was erfolgreiche Scrum Master auszeichnet.
Gleichzeitig erkenne ich mittlerweile, wenn jemand vielleicht den falschen Karrierepfad eingeschlagen hat. Und ich bin sehr treffsicher darin geworden, zu sehen, dass jemand noch eine sehr lange Reise vor sich hat, bis er ein erfolgreicher Scrum Master ist.
Hier sind 5 der Anzeichen dafür, dass jemand kein geborener Scrum Master ist.
(Warnung: Jedes der Anzeichen für sich genommen ist bestimmt kein Problem. Kritisch wird es dann, wenn eine Person ausschließlich so agiert.)
Der Prozessverfechter
Die Art und Weise, wie Scrum Master andere Menschen unterbrechen, sagt viel über sie aus.
Hier zwei Beispiele:
- „Laut dem Scrum Guide muss das Daily Scrum genau 15 Minuten dauern. Tim, du redest bereits seit 5 Minuten. Das reicht für heute. Lass auch mal die anderen zu Wort kommen.“
- „Wir hatten uns darauf verständigt, dass es eine meiner Aufgaben im Team ist, zu helfen, dass unsere Meetings kurzweilig und produktiv sind. Ich beobachte, dass im Moment nicht alle den gleichen Redeanteil haben. Ich bin mir unsicher, ob das Meeting so für alle produktiv ist. Seht ihr das ähnlich? Falls ja, was könnten wir verbessern?“
Was unterscheidet die beiden Aussagen? In der ersten Aussage nutzt der Scrum Master den Prozess, um seine Arbeit zu erledigen. Wir könnten fast sagen, er versteckt sich hinter dem Prozess. In der zweiten Aussage macht der Scrum Master die Interaktion zwischen den Menschen transparent. Er stellt die Menschen und ihre Wünsche in den Mittelpunkt.
Zusammenfassend könnten wir sagen:
Ihm sind Menschen und Interaktionen wichtiger als Prozesse und Werkzeuge.
Wenn ein Scrum Master hingegen den Scrum Prozess über alles stellt, ist dies ein Anzeichen dafür, dass er den falschen Beruf ergriffen hat.
Der Perfektionist
Perfektion ist der Feind des Fortschritts.
Wenn Scrum Master alles daransetzen, jeden Moment perfekt zu planen, beunruhigt mich das. Sie versuchen, jede Eventualität vorherzusehen. Sie machen sich jetzt schon über Schritt 14 den Kopf, obwohl wir noch nicht einmal Schritt eins gegangen sind. Für mich ist das der Inbegriff eines wasserfallartigen Entwicklungsprozesses. Er fußt auf der Annahme, dass wir das Problem nur ausreichend analysieren müssen. Dann können wir eine Reihe von Lösungsschritten ableiten. Jeder dieser Schritte muss perfekt umgesetzt werden. Da wir zu Beginn genug analysiert haben, müssen wir keinen der Schritte wiederholen. Es treten keine unvorhergesehenen Komplikationen auf. Versteh mich jetzt bitte nicht falsch. An dieser Einstellung ist absolut nichts auszusetzen. Es gibt Situationen, in denen dieser Ansatz zu guten Ergebnissen führt.
Nur halt nicht in der Softwareentwicklung, was eines der Einsatzgebiete von Scrum ist.
Im Kern ist die Aufgabe des Scrum Masters doch, Scrum zu verkörpern. Er sollte es bereits gemeistert haben. Das steckt doch schon im Namen. Scrum zu meistern bedeutet, Probleme auf eine andere Art zu lösen.
Diese Art lautet:
Wir glauben, dass wir nicht alles vorhersehen können.
Deshalb:
- Wenn wir uns auf den Weg machen,
- werden wir besser
- und irgendwann auch schlauer.
Wie du sehen kannst, geht es um Fortschritt. Es geht darum, anzufangen und daraus zu lernen. Und nicht erst zu lernen, bevor angefangen wird.
Erfolgreiche Scrum Master zeichnet der Drang aus, anzufangen, ohne alles erst perfekt planen zu wollen.
Der Experte
Rückblickend hatte ich viel Glück.
Ich habe Wirtschaftsinformatik und Mathematik studiert und auch viel programmiert. Dadurch habe ich bereits, bevor ich Scrum Master war, zwei von drei Wissensbereichen, die für Scrum Master wichtig sind, abgedeckt. Die drei Bereiche, in denen Scrum Master Wissen mitbringen sollten, lauten:
- Technik (etwa Softwareentwicklung)
- Wirtschaft (etwa Business-Cases, Kosten-Einnahmen-Rechnung)
- Teamdynamik (etwa Psychologie, Motivationslehre)
Scrum Masterei liegt für mich in der Mitte dieser Bereiche.
Gleichzeitig habe ich sehr schnell und sehr unangenehm lernen müssen, dass Probleme in Teams sich nicht mit Lösungen aus der Informatik oder Mathematik erklären lassen.
Es vergingen einige Jahre, bis ich akzeptierte, dass …
- … das Verhalten eines Teams nicht allein durch seine Bestandteile vollständig bestimmt werden kann.
- … zukünftige Ereignisse nicht zwingend aus vergangenen Ereignissen, gegenwärtigen Beobachtungen und unter Verwendung von Naturgesetzen vorhergesagt werden können.
Was mir fehlte, war Wissen über Dynamik in sozialen Systemen, Bedürfnisse von Menschen und psychologische Phänomene.
Damit beschäftige ich mich jetzt schon einige Jahre. Und um ehrlich zu sein: Je mehr ich mich damit beschäftige, desto mehr fühle ich mich wie ein Anfänger. Die vielen Fehlschläge damit haben mich sehr demütig gemacht. Und diese Demut kann ich auch bei meinen großen Scrum-Master-Vorbildern erkennen. Wir alle bezeichnen uns nicht als Experten, eher als ewige Auszubildende, die immer hungrig nach neuem Wissen sind.
Damit sind wir häufig allein.
Leider sehe ich auch viele Scrum Master, die ihr Team aus der Haltung eines Experten unterstützen. Etwa indem sie ihren Teams vermitteln, dass Story-Points die einzige wahre Schätzung sind und genutzt werden müssen.
Dies ist für mich ein Anzeichen dafür, dass die Person vielleicht den falschen Karriereweg eingeschlagen hat.
Der Unfehlbare
Wie häufig bitten Scrum Master ihr Team nach einem Meeting um Feedback?
Ist die Antwort „nie“ und wird auch sonst kein Feedback zur Arbeit eingeholt? Dann ist dies für mich ein Anzeichen, dass der Scrum Master noch nicht verstanden hat, worum es bei Scrum geht.
Ich wiederhole mich nur ungern. Aber es ist wichtig. Als Scrum Master dienen wir als Vorbild für empirisches Arbeiten. Empirisches Arbeiten im Gegensatz zum kausalen Determinismus. Kausaler Determinismus bedeutet: Wenn jemand einen Ball in deine Richtung wirft, dann kannst du ihn fangen. Denn du kannst vorhersagen, in welche Richtung er sich bewegt und wie schnell er etwa da sein wird. Kausaler Determinismus bedeutet also, dass zukünftige Ereignisse aus vergangenen Ereignissen, gegenwärtigen Beobachtungen und unter Verwendung von Naturgesetzen vorhergesagt werden können.
Wenn kausaler Determinismus allerdings versagt, wie etwa bei der Vorhersage davon, wie und ob die Nutzer die Software auch verwenden werden, dann brauchen wir einen anderen Ansatz, um zu verstehen, ob wir Fortschritt bei der Erreichung unserer Ziele machen. Dieser andere Ansatz lautet:
Feedback.
So früh wie möglich und dann regelmäßig.
Das Problem mit Feedback ist, dass es viel Mut braucht, es einzuholen. Deshalb ist auch der Wert Mut in Scrum von Bedeutung. Als Scrum Master können wir nicht von unserem Team verlangen, den Mut aufzubringen, Feedback vom Kunden einzuholen, wenn wir nicht selbst den Mut haben, Feedback für unsere Arbeit einzuholen.
Scrum Master, die kein Feedback einholen, sehen sich entweder selbst als unfehlbar. Oder sie sind nicht mutig genug für diesen Beruf.
Was ein Anzeichen dafür ist, dass sie den falschen Karriereweg eingeschlagen haben.
Der Feelgood-Manager
Zum Schluss möchte ich noch eines klarstellen:
Scrum Master sind keine Feelgood-Manager.
Wenn ich höre, dass Scrum Master häufig als Feelgood-Manager betitelt werden, stellen sich mir jedes Mal die Nackenhaare auf. Scrum Master unterstützen das Team dabei, Probleme zu lösen. Und zwar Probleme, die das Team bei der Arbeit behindern und nicht sofort von den Entwicklern gelöst werden können.
Ein Beispiel von mir: Ein Team hatte vor einigen Jahren mit einem langwierigen Freigabeprozess zu kämpfen. Einige Schritte im Prozess konnten die Entwickler im Team selbst automatisieren. Zum Beispiel mussten wir für jedes Release einen Bericht über die Testabdeckung anfertigen. Das war manuell sehr zeitraubend und stumpfsinnig. Deshalb haben wir ein Skript geschrieben, das diesen Prozess vereinfachte. Der Bericht musste dann vom Testmanager abgezeichnet werden. Dies ließ sich nicht automatisieren und wir mussten häufig mehrere Tage auf die Unterschrift warten. Auf die E-Mails oder Anrufe reagierte der Testmanager aus Zeitgründen häufig nicht.
Diese Behinderung unseres Teams war eine Aufgabe für mich – den Scrum Master.
Und das hat nichts damit zu tun, dass sich das Team dann besser fühlt. Es geht darum, dass das Unternehmen nicht Zeit und Geld mit Warten verbrennt.
Erfolgreiche Scrum Master sind weder Feelgood-Manager noch besonders harmoniebedürftig. Verlässt ein Scrum Master sein Büro nicht, um mit dem Testmanager zu arbeiten, auch wenn es sehr unangenehm werden kann, dann ist das ein Anzeichen dafür, dass er die falsche Karriere eingeschlagen hat.
Scrum Master fühlen sich im Team wohl, können aber allein voranschreiten, wenn es nötig ist.