In meiner ersten Zeit mit Agilität und Scrum habe ich mich immer sehr schwer getan, wenn mich jemand gefragt hat, was ich eigentlich so mache. Hat mich jemand aus dem Entwicklerumfeld gefragt, war die Antwort einfach: ich bin Scrum Master. Hat mich jedoch jemand gefragt, der noch nie etwas von Scrum gehört hat, wurde die Sache schwierig. Wie erklärt man jemandem in wenigen Worten, was ein Scrum Master den ganzen Tag lang macht?
Viel Zeit verbringt man damit, Meetings zu moderieren, aber ich bin kein Moderator. Das würde ich nicht als Beschreibung meiner Aufgaben stehen lassen wollen. Es ist sicherlich ein Teil meiner Jobbeschreibung, aber es ist nicht die Essenz.
Man könnte auch kurz aufzählen, was man in der Literatur als Aufgabenbeschreibung des Scrum Masters findet: Meetings moderieren, auf die Timebox achten, Hindernisse beseitigen usw., aber irgendwie klingt das für mich nicht wirklich griffig. Ganz davon abgesehen denke ich auch nicht, dass es den Kern unserer Aufgabe trifft.
Ein anderer Ansatz ist es, Begriffe zu nutzen, die unser Gegenüber kennt und zu sagen, dass ein Scrum Master sowas wie ein Teamleiter wäre, wir würden es nur anders nennen. Fühlt sich nicht nur komisch an, wenn ich das sage, es stimmt auch nicht. Ein Scrum Master ist kein Teamleiter, oder vielleicht doch?
Wir weisen mit größter Vehemenz den Vergleich zum Teamleiter von uns und verweisen darauf, dass wir in Scrum keine Hierarchien kennen und dass es keine Befehlsstrukturen gäbe, aber ganz abwegig finde ich den Vergleich dennoch nicht.
In meinem Verständnis sorgt ein Teamleiter dafür, dass ein Team gut zusammenarbeitet und so seine Ziele erreicht. Wenn ich das so formuliere, klingt der Vergleich mit einem Scrum Master nicht mehr so abwegig, oder? Für die Beschreibung dessen, was die Aufgabe eines Scrum Masters ist, ist es vollkommen unerheblich, ob wir Hierarchien nutzen. Da geht es doch eher darum, was das Ziel unserer Aufgabe ist, und dafür klingen die Begriffe Zusammenarbeit im Team und Erreichung der Teamziele schon ziemlich sympathisch. Bei der Beschreibung einer Aufgabe interessiere ich mich nicht für unseren Werkzeugkoffer. Fragt mich also jemand, was ich so mache, könnte ich antworten:
Ich arbeite in der Softwareentwicklung als Scrum Master. Ich sorge dafür, dass ein Team gut zusammenarbeitet und seine Ziele erreichen kann.
Klingt für mich nicht vollkommen abwegig.
Trifft es aber auch nicht vollkommen.
Der Haken bei dieser Formulierung ist in meinem Verständnis, dass wir keine Teamziele im klassischen Sinne kennen. In meiner grenzenlosen Naivität kenne ich nur das Bestreben, das Projekt bzw. Produkt voranzubringen. Für mich gibt es keine Teamziele, ebensowenig wie es eine Projektzielsetzung gibt. Selbstverständlich ist mir klar, dass es solche Dinge in der realen Welt da draußen durchaus gibt, und dass wir ständig damit arbeiten müssen, aber ich versuche einmal, mich auf das Wesentliche zu reduzieren. Und da gibt es für mich nur die kontinuierliche Weiterentwicklung des Produkts.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Versuche ich die Weiterentwicklung des Produkts in die Kurzbeschreibung der Aufgabe eines Scrum Masters einzubeziehen, dann lande ich sehr schnell bei der Jobbeschreibung eines Projektmanagers und damit noch weiter weg von meiner nebulösen Vorstellung davon, was ich eigentlich den ganzen Tag lang so tue. Der Grund dafür ist, dass mich die Weiterentwicklung des Produkts nicht direkt betrifft. Das ist nicht meine Baustelle. Ich sorge lediglich dafür, dass andere (nämlich Product Owner und Entwickler) das tun können. Der Begriff des »Enablers« wird so verständlich, aber für einen Außenstehenden ist das auch nicht besonders griffig.
Ich höre und lese immer wieder als eine der Kernaufgaben des Scrum Masters, dass dieser für den Prozess Scrum verantwortlich ist und diesen im Unternehmen weiterentwickeln soll. Mit dieser Aussage tue ich mich sehr schwer. Das klingt für mich wie Scrum als Selbstzweck. Ich bin dabei der Gärtner, der das Pflänzchen beschützt und ständig wässert, damit es wächst und gedeiht, aber was die Aufgabe der Pflanze ist, bleibt dabei vollkommen außen vor. Die Pflege von Scrum als reine Beschreibung der Aufgabe eines Scrum Masters müsste ich ebenfalls von mir weisen. In meinem Verständnis ist auch das nur ein Teil meiner Aufgabe, ebenso wie die Pflege der Werkzeuge für einen Mechaniker ein Teil seiner Aufgabe ist. Dieser würde aber niemals sagen, dass es sein Beruf ist, Werkzeug zu putzen oder Werkzeuge zu kaufen.
Die Weiterentwicklung unserer eigenen Prozesse ist für mich eine Verbesserung unserer Werkzeuge und damit ein natürlicher Bestandteil meiner Aufgabe aber niemals die Aufgabe selbst. Was das betrifft, fühle ich mich im Umfeld des »Enablers« schon wesentlich wohler. Aber nur zu sagen, ich wäre ein Ermöglicher von irgendwelchen Dingen, ist auch irgendwie vage.
Ich versuche einmal, es etwas anders auszudrücken:
Ich sorge dafür, dass die richtigen Personen zur richtigen Zeit in er richtigen Art und Weise über die richtigen Dinge miteinander sprechen, aber ich entscheide sie nicht.
Wie ich das tue, und welche Werkzeuge ich dafür nutze, ist doch vollkommen unerheblich, wenn es darum geht, was meine Aufgabe ist. Es ist nicht meine Aufgabe, zu entscheiden, wer wann mit wem über welche Dinge spricht, und welche Entscheidungen dabei getroffen werden. Ich sorge lediglich dafür, dass alle Beteiligten selbst entscheiden – vor dem Hintergrund der Weiterentwicklung des Produkts – was wann Thema sein wird, und wer dazu etwas beitragen kann. Mit den Inhalten habe ich nichts zu tun, aber ich helfe allen Beteiligten dabei, mit den Inhalten umzugehen, damit sie selbst eine bewusste Entscheidung treffen können.
Das wiederum klingt für mich schon wie eine passende Umschreibung der Rolle eines »Enablers«.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
