Wenn Sie ein Buch aufschlagen und nach der Rollendefinition des Scrum Masters suchen, dann werden Sie dort in aller Regel finden, dass es Ihre Aufgabe ist, die Zeremonien zu moderieren, darauf zu achten, dass die Timeboxen eingehalten werden, und Impediments aus dem Weg zu räumen. Das klingt alles ziemlich einfach, und wenn man die Rolle des Scrum Masters auf diese Dinge reduziert, dann ist es das meistens auch, aber lassen Sie sich bitte nicht täuschen. Es gehört sehr viel mehr dazu.
Ich werde sehr oft nach einer Rollendefinition des Scrum Masters gefragt, und ich muss gestehen, dass mir die Antwort immer schwerer fällt. Anfänglich hätte ich noch aus einem Buch zitieren können, inzwischen bin ich aber der Meinung, dass all die Umschreibungen, die ich bisher gelesen oder gehört habe, irgendwie nicht ausreichend sind.
Sie werden auch oft lesen oder hören, dass es nach der Einführung von Scrum, wenn sich die Dinge eingespielt haben, kein Problem ist, wenn einer der Entwickler die Rolle in Teilzeit übernimmt, ich bin jedoch kein großer Fan dieser Lösung. Selbstverständlich ist es nicht besonders schwer, in einem Meeting auf die Uhr zu sehen und nach einer Stunde zu sagen, dass die Zeit abgelaufen ist. Das kann eigentlich jeder. Aber schon bei der Moderation wird es manchmal etwas komplizierter.
Jeder Entwickler kann sicherlich ein Auge darauf haben, ob beim Daily das Team abschweift und plötzlich über das Fußballspiel vom Wochenende spricht oder nur noch Witze macht. Echte Moderation ist jedoch nicht ganz so einfach. Wie organisiert man z.B. ein einfaches Brainstorming? Das ist zwar in der Theorie nicht besonders schwierig, die Grundsätze (keine Wertungen während der Sammelphase etc.) kennt auch jeder, die Durchführung ist jedoch nicht ganz so einfach. Wie fördert und fordert man stillere Teammitglieder? Wie bremst man die Lautsprecher? Es gehört einige Erfahrung dazu, derartige Meetings effektiv zu gestalten.
Diese Dinge sind erlernbar. Es gehört ein wenig Zeit und Arbeit dazu, aber im Prinzip kann jeder ein Moderator werden, sofern er nicht durch ein grundlegendes charakterliches Problem daran gehindert wird (Selbstdarsteller sind nicht besonders gut geeignet, schließlich geht es um das Team und das zu erzielende Ergebnis, nicht um die Person des Moderators). Etwas anders verhält es sich mit den Impediments. Nicht jeder ist in der Lage, Hindernisse aus dem Weg zu räumen.
Woran liegt das? Zuerst einmal muss man sich die Frage stellen, was überhaupt ein Impediment ist. Was ist ein Hindernis, das einen Entwickler einschränkt, und dass ein Scrum Master aus dem Weg räumen kann? Einfache Impediments sind z.B. technischer Natur, wenn möglicherweise ein Laptop defekt ist. In dem Fall könnte der Scrum Master das defekte Laptop zur IT bringen und ein Ersatzgerät abholen. Seien wir ehrlich: das kann der betroffene Entwickler auch selbst tun.
Andere technische Probleme, die das gesamte Team betreffen (z.B. Netzwerkkonfigurationen, die Bereitstellung von Servern usw.) kann durchaus der Scrum Master in die Hand nehmen. Das bedeutet nicht, dass er selbst den Server aufstellt, sondern dass er mit den Leuten aus der IT spricht, die diese Aufgabe letztlich übernehmen werden. Ist der SM selbst kein Techniker oder Entwickler, wird er auch dabei die Hilfe seiner Kollegen benötigen, die ihn mit den wichtigen Informationen versorgen müssen. Am einfachsten wird es sein, ein Treffen zwischen IT und Entwicklung zu vereinbaren, damit sich die betroffenen Personen direkt austauschen. Niemand spielt gern Stille Post.
Auch das sind Aufgaben, die nicht zwingend einen Scrum Master erfordern. Diese Dinge kann ein Entwickler oftmals tatsächlich besser tun. Impediments dieser Art werden vom Scrum Master nicht direkt beseitigt, er leitet lediglich die notwendigen Schritte ein. Wofür brauchen wir also einen »echten« Scrum Master, und was sind Impediments, die ein Entwickler nicht selbst aus dem Weg räumen kann?
Schwieriger wird es, wenn es um organisatorische Dinge geht, wenn die vereinbarten Abläufe gefährdet sind, wenn sich einzelne Personen aus anderen Abteilungen nicht an die vereinbarten Spielregeln halten wollen. In unserem Beispiel könnte ein Kollege au dem Marketing die Angewohnheit entwickelt haben, immer wieder direkt einen Entwickler anzusprechen, um ihn um einen kleinen Gefallen zu bitten. Wir kennen das alle: »Kannst du das nicht mal eben einschieben? Dauert doch bestimmt nur ein paar Minuten.«
In diesem Fall könnte der Entwickler einfach ablehnen. Problem dabei ist nur, dass man dann eine Aufgabe hat, die nicht erledigt wird, einen Kollegen aus dem Marketing, der nicht versteht, was gerade passiert, und im schlimmsten Fall abteilungsübergreifenden Ärger. Der Scrum Master würde mit dem Kollegen aus dem Marketing sprechen, ihm die Regeln erklären und so dafür sorgen, dass diese Dinge über den Product Owner priorisiert werden. Hier kommen wir an den ersten Punkt, an dem ein Scrum Master wichtig wird: er ist eben nicht einer der Entwickler.
Selbstverständlich könnte ein Entwickler, der die Rolle des Scrum Masters übernimmt, das auch tun, aber diese Dinge kosten zum einen Zeit (manchmal sogar sehr viel), und zum anderen benötigt der Scrum Master, um die Abläufe und die Zusammenarbeit ordnen zu können, auch ein bestimmtes Standing. Wir alle sprechen gern von flachen Hierarchien, aber allzu oft sind die Strukturen in Unternehmen (auch in jungen Startups) unterschwellig vom Positionsdenken geprägt. Ein Entwickler ist in den Augen der anderen Abteilungen eben ein Entwickler, auch wenn er die Zusatzrolle Scrum Master trägt. Der Scrum Master ist in den Augen der anderen immer eine Führungsperson, mit dem man anders spricht. Niemand wird das zugeben, aber leider lehrt die Erfahrung, dass es genau so ist.
Das Standing innerhalb des Unternehmens ist ein sehr wichtiger Punkt. Das muss man sich verdienen und erarbeiten. Ein Scrum Master sollte präsent sein, ohne sich aufzudrängen. Das ist schwer, wenn man auch andere Aufgaben zu erledigen hat.
Was manchmal verschwiegen wird, was aber der wichtigste Punkt in der Rollenbeschreibung des Scrum Masters ist, er arbeitet ständig an der Verbesserung der Prozesse, was uns durchaus komisch erscheinen mag, sagt uns das Agile Manifest doch, dass Interaktionen wichtiger als Prozesse sind. Was ist also unter den Prozessen zu verstehen?
Ich verstehe darunter die Art und Weise, wie wir Agilität und Scrum leben. Im Kern ist Scrum eine sehr einfache Sammlung von Spielregeln. Die gesamten Scrum Regeln passen auf eine Postkarte. Wie füllt man dieses sehr grobe Framework mit Leben, und was sind die feineren Spielregeln, auf die wir uns einigen müssen, damit das Ganze funktioniert?
Der Scrum Master macht Vorschläge, leitet an, gibt Hinweise und erarbeitet gemeinsam mit allen beteiligten eben diese feineren Spielregeln. Dabei übernimmt er immer eine Position des Vordenkers, ohne zu bestimmen. Er hilft z.B. dem Product Owner dabei, das Backlog zu priorisieren, wobei er durchaus auch inhaltlich eine Meinung haben kann, in keinem Fall aber für den PO priorisieren darf. Viel wichtiger ist aber, dass er dem PO Werkzeuge und Methoden an die Hand gibt. Er stellt dem Product Owner die unbequemen Fragen, die Aufschluss darüber geben, ob die Priorisierung auch sinnvoll ist.
Er kann und sollte sich auch in die Abläufe der Entwicklung einbringen. Ist die Qualitätssicherung reibungslos eingebunden? Gibt es dort Potential für Verbesserungen? Dabei muss der Scrum Master kein Entwickler sein. In den meisten Fällen genügt der fundierte Überblick über die Abläufe, es hilft jedoch ungemein, wenn man zumindest grundlegende Dinge der Softwareentwicklung versteht.
Wirklich kompliziert und zeitraubend wird die Rolle des SM, wenn es um die Zusammenarbeit zwischen Entwicklung und anderen Teilen des Unternehmens geht. Hierbei genügt es bei weitem nicht, einmalig die Regel aufzustellen, dass alle Anforderungen zukünftig nur noch über die Product Owner eingebracht werden dürfen. Der Scrum Master sorgt auch für den Austausch zwischen den Abteilungen. Er koordiniert die Zusammenarbeit. Wann muss wer mit wem worüber sprechen, um das Produkt voranzubringen? Sind regelmäßige Treffen zwischen bestimmten Personen sinnvoll? Um es ganz kurz zu machen: der Scrum Master sorgt dafür, dass Scrum läuft. Das umfasst weit mehr als nur den Blick auf die Uhr beim Meeting oder den Abbruch der Diskussion, die aus dem Ruder läuft. Das umfasst vor allen Dingen die Arbeit der Menschen miteinander, über Abteilungsgrenzen hinweg.
Aber reicht das? Vielleicht sollte ich versuchen, die ganze Sache einmal von der anderen Seite aufzurollen. Die wichtigste Aufgabe, und damit die Grundlage für alles, ist die Verankerung und Stärkung des Agilen Denkens im Unternehmen. Damit ist nicht nur die Einführung von Scrum gemeint. Es ist ein fortlaufender Prozess, der selbstverständlich noch vor der Einführung beginnt.
Scrum hat keinen Sinn, wenn das Unternehmen, die Geschäftsleitung, die übrigen Abteilungen, nicht agil denken. Dann ist es lediglich ein Set von Regeln, deren Sinn angezweifelt werden kann. Der Scrum Master sorgt also in allererster Linie für Verstehen. Dabei muss er erkennen, wenn Agilität von Prozessdenken überlagert wird. Auch das ist ein schleichender leiser Prozess, den man meistens erst bemerkt, wenn es zu spät ist. Wann wird also eine der Spielregeln, die wir innerhalb von Scrum aufgestellt haben, zum Selbstzweck? Und wie kann man das verhindern?
Agilität bezieht sich damit nicht nur auf das Vorgehen in der Softwareentwicklung, sondern auch auf unsere Art zu arbeiten. Regeln und Vorgänge werden immer wieder hinterfragt und angepasst.
Und was bedeutet jetzt, agil zu denken? Auch hier kann man sich leicht wieder auf das Agile Manifest beziehen. Interaktionen zwischen Personen sind wichtiger als Prozesse. Eine Regel hat also nur Bestand, so lange sie die Interaktion der Personen unterstützt. Sie kann modifiziert oder abgeschafft werden. Zum Agilen Denken zählt also die Bereitschaft, das eigene Vorgehen immer wieder kritisch zu hinterfragen und ggf. auch Heilige Kühe zu schlachten.
