Wir haben alle gelernt, dass es zu den Kernaufgaben eines Scrum Masters zählt, das Team zu schützen. Was genau damit gemeint ist, fällt dabei leider zu oft unter den Tisch, und genau definiert ist es auch nicht. Zu gern vergessen wir bei all dem, dass wir am Ende daran gemessen werden, was wir liefern – also daran, wie das Team performt.
Die Aufgaben eines Scrum Masters ergeben sich leider nur zum Teil aus den Regeln des Scrum Guides. Das ist etwas, was grundsätzlich gilt: der Scrum Guide ist außerordentlich grob gehalten. Das liegt in der Natur der Sache, er stellt nur ein Rahmenwerk dar. Zur Rolle des Scrum Masters äußert er sich nur in einigen wenigen Stichworten. Es liegt also auch hier an uns, die tatsächlichen Regeln aufzustellen.
Wer schon einmal an Rollendefinitionen gearbeitet hat, weiß, wie schwer das sein kann. Man ist entweder zu global und lässt damit zu viel Spielraum für Interpretationen, oder man verliert sich in endlosen Details. Bei den Rollen Product Owner und Scrum Master für das Scrum Team ist die Versuchung groß, es bei wenigen Stichpunkten bewenden zu lassen – ich halte das jedoch für einen großen Fehler.
Beim Product Owner ist es vielleicht noch zu verschmerzen. Wir könnten ganz einfach sagen, dass die Aufgabe dieser Rolle die fachliche Führung des Teams sei. Der Product Owner gibt Antworten auf die Frage, was das Team umsetzen wird. Das ist natürlich sehr grob und muss weiter beschrieben werden (insbesondere mit Kompetenzen ausgestattet: was darf ein PO und was darf er nicht?), aber letztlich ist es ein guter Startpunkt.
Beim Scrum Master ist der Startpunkt schon sehr viel schwerer zu setzen. Wofür ist der eigentlich verantwortlich?
Der Scrum Guide gibt hier zumindest eine klare Aussage: The Scrum Master is accountable for the Scrum Teams effectivenes. Wir sprechen hier wohlgemerkt von Effektivität – nicht von Effizienz. Auch ist nicht die Rede von Produktivität. Wenn wir diesen Satz aus dem Scrum Guide also wörtlich nehmen, landen wir lediglich dabei, dass der Scrum Master dafür verantwortlich ist, dass ein Team überhaupt arbeitet und etwas liefert. Wir alle kennen den Unterschied zwischen Effektivität und Effizienz.
Ich weiß nicht, wie es Euch dabei geht, aber mir ist das zu wenig.
Wenn mich jemand fragt, was die Aufgabe eines Scrum Masters ist, dann ist meine Antwort in aller Regel ganz kurz: dafür zu sorgen, dass der Laden läuft. Es genügt nicht, dafür zu sorgen, dass Scrum läuft. Um ehrlich zu sein: die paar Zeremonien durchzuführen, zu organisieren und im Zweifel zu moderieren, ist nicht abendfüllend. Wenn ich nur das als meine Aufgabe betrachte, kann ich als Scrum Master vollkommen problemlos mehrere Teams gleichzeitig betreuen, solange es mir gelingt, die Termine nicht zu stark miteinander kollidieren zu lassen.
Es genügt auch nicht, dafür zu sorgen, dass ein Team überhaupt irgendwie läuft. Dafür braucht es keinen Scrum Master. Es würde sich innerhalb kürzester Zeit selbst irgendwie organisieren, und es würde einen Output liefern.
Das Zauberwort lautet nicht »Effektivität« sondern »Effizienz«.
Am Ende wird ein Team immer daran gemessen, wie es performt. Wir gewinnen keinen Preis für die schönste Scrum Implementierung der Welt oder für die Agilste Organisation. Wir bewegen uns in einem wirtschaftlich denkenden Umfeld – in Organisationen, die Gewinne erwirtschaften müssen. Dass dies alles Grenzen haben muss, ist keine Frage und wird auch etwas später unser Thema sein, aber zuerst ist wichtig für uns, dass ein Team nur dann wirklich gut funktioniert, wenn es auch liefert. Wir können noch so gut kommunizieren und unsere Dashboards noch so schön pflegen und so transparent mit allem sein, wie wir wollen – wenn unser Output nicht stimmt, dann läuft das Team nicht, und dann haben wir ein Problem.
Vielleicht habt Ihr solche Diskussionen in Euren Unternehmen schon führen müssen: Ihr habt alles getan, was (scheinbar) von einem Scrum Master erwartet wird. Ihr habt alle Termine sauber gepflegt (damit sind wir übrigens nichts weiter als eine recht gut bezahlte Teamassistenz), Ihr habt das Backlog gut aufbereitet, alles ist sauber dokumentiert. Es scheint sogar so zu sein, dass Euer Team gut läuft – es gibt regelmäßige Refinements, eine gute Kommunikation zwischen PO und Entwicklern, das Planning läuft gut, und auch die Sprints laufen gut, ohne sich groß zu über- oder zu unterschätzen.
Und dennoch werdet Ihr irgendwann zu einem Gespräch gebeten und gefragt, warum Euer Team so schlecht performt.
Wie man zu dieser Schlussfolgerung kommt, steht auf einem ganz anderen Blatt. Ein Vergleich mehrerer Teams miteinander ist immer schwierig, und man kann auch darüber streiten, welche Kennzahlen sinnvoll sind, aber das soll jetzt nicht unser Thema sein.
Unser Thema ist vielmehr die Frage, ob es genügt, sich an Scrum zu halten und dieses Rahmenwerk umzusetzen, oder ob da noch viel mehr ist, was uns interessieren sollte.
Die Antwort ist recht eindeutig: Scrum allein reicht nicht.
Sich an die Scrum Regeln zu halten, wird uns nicht automatisch ein performantes Team bescheren. Natürlich wird jetzt jeder sofort sagen, dass wir dafür doch die Retrospektiven haben, und zum Teil gebe ich Euch dabei Recht – aber eben nur zum Teil. Stellt Euch einmal die Frage, wie gut ein Team in seiner Selbsteinschätzung ist. Wie gut sind eigentlich Menschen im allgemeinen in ihrer Selbsteinschätzung?
Ein weiterer Aspekt: kennt das Team alle Zusammenhänge, oder hat es nur den Blick auf sich selbst und einen kleinen Teil des direkten Umfelds? Ist es gefangen in einem bequemen Trott, der durch die Scrum Zeremonien gesteuert wird? Wie ist es eingebunden in die gesamte Kette der Leistungserbringung? Wie viel Wert generieren eigentlich die Ergebnisse unserer Sprints?
Scrum gibt darauf keine Antworten und nur sehr wenige Werkzeuge. Gerade die Beurteilung des geschaffenen Wertes liegt in unserer eigenen Hand. Wir sprechen zwar (hoffentlich) mit dem Kunden/Anwender, aber nach welchen objektiven Kriterien bewerten wir eigentlich den Wert unserer Arbeit?
Punkt 1: Scrum gibt uns keine Methode, den Wert unserer Arbeit zu beziffern – dazu müssen wir uns selbst etwas einfallen lassen, und wenn wir das nicht tun, können wir nicht sicher sein, dass wir tatsächlich wertvolle Software schaffen (oder ein wertvolles Produkt). Als Scrum Master werde ich mich also mit Metriken und der Frage auseinandersetzen müssen, wie was zu bewerten ist.
Das zweite große Problem ist, dass Scrum erst einmal ein theoretisches Modell ist. Wir haben ein Set an Regeln und Vorgaben, die wir auf ein einzelnes Team anwenden können, aber leider steht dieses Team nicht allein auf der Insel der Glückseligen. Es ist meistens Teil einer sehr viel komplexeren Organisation, in der Entscheidungen getroffen werden, die nicht immer zu unserem Vorgehen passen.
Punkt 2: Es ist Aufgabe des Scrum Masters, diese »weltlichen« Einschränkungen/Leitplanken, die nichts mit Agilität oder Scrum zu tun haben, mit unserem Vorgehen so zu verheiraten, dass keine Reibungsverluste entstehen. Der Scrum Master agiert damit weit jenseits der eigenen Teamgrenzen und damit auch weit jenseits des Scrum Kontexts. Dazu muss man sich mit Prozessen auskennen, vielleicht auch mit klassischem Projektmanagement, und eine gute Portion Business-Diplomatie und Verhandlungsgeschick kann auch nicht schaden.
Ich könnte noch weitere Punkte aufzählen und damit zeigen, dass der Scrum Guide nur ein Teil dessen ist, was wir für unsere Arbeit benötigen, aber diese beiden Beispiele sollten eigentlich genügen.
Wichtig ist erst einmal die Erkenntnis, dass schlussendlich auch unsere Arbeit an der Performance des Teams gemessen wird, und dass auf eben diese Performance des Teams mehr einzahlt als nur die Scrum Zeremonien. Die Dinge, die uns behindern und bremsen, finden sich oftmals weit jenseits der Teamgrenzen, aber es ist trotzdem unsere Aufgabe, uns darum zu kümmern und Wege zu finden, die Effizienz unserer Teams zu steigern.
Damit kommen wir zum Punkt aus der Überschrift dieses Beitrags: Gibt es damit einen Konflikt bei der Rolle des Scrum Masters?
Einfache Antwort: Ja.
Wir sind auf der einen Seite dafür verantwortlich, möglichst viel aus dem Team herauszuholen, auf der anderen Seite aber auch dafür verantwortlich, das Team gesund zu halten. Das einfachste Beispiel dafür ist, dass ich natürlich mehr Performance bekomme, wenn alle mehr arbeiten, aber ich möchte natürlich nicht, dass alle endlos viele Überstunden schieben.
Wenn wir einen Schritt zurück treten, haben wir folgende Situation: Die Geschäftsführung fordert möglichst viel Leistung, und auch wir werden daran gemessen, wie viel Leistung erbracht wird (vergesst das nie). Nach außen hin machen wir also einen guten Job, wenn möglichst viel Leistung erbracht wird. Auf der anderen Seite haben wir aber das Bestreben, unsere Teams vor zu viel Einfluss und auch vor zu hohen Erwartungen zu schützen. Das wäre recht einfach zu erreichen, wenn wir der Geschäftsführung sagten: erwartet nicht zu viel. Dann hat unser Team vielleicht Ruhe, aber in den Augen der Geschäftsführung (die letztlich auch unseren Gehaltscheck unterschreibt) machen wir dann keinen guten Job. Wir befinden uns also in einem Dilemma.
Das Zauberwort lautet Balance und damit auch ein geschicktes Erwartungsmanagement, an dessen Ende die Aussage steht, dass das Team tut, was in seiner Macht steht, und das auch bestmöglich optimiert ist, dies aber die Grenzen des Machbaren sind. Diese Grenzen zu überschreiten würde das Team über Gebühr strapazieren. Ohne das Klarziehen dieser Grenzen und Möglichkeiten werden Erwartungen und Forderungen immer höher werden. Dagegen können wir uns irgendwann nicht mehr wehren.
Mein Rat an Euch ist also folgender: Betrachtet Scrum nur als einen Teil Eurer Aufgaben, indem Ihr Euch als die Person versteht, die dafür zu sorgen hat, dass Euer Team so effizient wie möglich läuft. Euer Wirkungskreis liegt damit auch außerhalb Eures Teams. Und sorgt immer für absolute Klarheit, was möglich und was nicht möglich ist. Wenn Ihr das versäumt, kommt nicht nur das Team sondern auch Ihr persönlich in eine schwierige Situation.
Gerade als der Bremser der Erwartungen ist es eine gute Idee, nicht der Blockierer sondern der Partner zu sein. Der Blockierer, der einfach nur sagt, dass irgendetwas nicht geht, wird ganz schnell zum Widersacher, den es zu bekämpfen gilt, das wollen wir aber natürlich überhaupt nicht. Der Partner ist derjenige, der die Erwartung und auch die Motivation für die Erwartung versteht und Vorschläge und Lösungen anbietet.
Viele Kollegen sind schon in diese Falle getappt und haben sich das Leben unnötig schwer gemacht.
Kernaussagen: Als Verantwortlicher für die Leistung eines Teams stehen Scrum Master im Konflikt zwischen Steigerung der Performance und Schutz des Individuums im Team vor Überlastung. Zur Steigerung und Beurteilung der Performance genügen die Scrum Methoden allein nicht. Der beste Schutz des Teams vor zu hohen Anforderungen ist ein frühzeitiges und partnerschaftliches Erwartungsmanagement.
Wenn Ihr mehr erfahren wollt, oder Unterstützung braucht, sprecht mich einfach an.
