Der agile Scrum-Master – klar! Oder?

Der Scrum-Master entwickelt Teams, Stakeholder und die Organisation um das Team herum. Tagtäglich bieten sich Chancen, dass der Scrum-Master selbst zum Impediment wird und seiner eigenen Mission im Wege steht. Oftmals aus guter Absicht. Zeit, dass er selbst agil wird!

Grenzenlose Freiheit und ihre Grenzen

Vornweg: Agil zu sein bedeutet nicht flexibel und spontan. Die Einstellung mancher Scrum-Master folgt diesem Leitbild: Ich komme morgens rein, schaue was passiert, projiziere das auf meine Skills und reagiere darauf.

Ich leiste also bin ich

Leerlaufzeit ist des Scrum-Masters größter Feind. Nicht nur des Scrum-Masters, jeder begleitender Coach muss für sich selbst eine komfortable Haltung zum Thema Leerlaufzeit entwickelt. Denn sie wird kommen, immer wieder. Warum ist Leerlaufzeit so unbequem? In der Konstellation Team -Scrum-Master – Linienvorgesetzter können schnell folgende Meinungen entstehen, wenn jemand Leerlaufzeit hat:

  • der Scrum-Master hat nichts zu tun
  • das Team leistet die Arbeit und der Scrum-Master malt bunte Bilder
  • er kostet Geld, also muss er auch optimal ausgelastet sein
  • immer sagt er, es sei die Verantwortung des selbstorganisierten Teams; der drückt sich nur vor Arbeit und Verantwortung

Dabei ist es ganz gleich, ob diese Meinungen tatsächlich existieren und ausgesprochen werden. Schlimmer sind die Annahmen darüber, die sich der Scrum-Master selbst macht, und die Glaubenssätze, die daraus resultieren:

  • ich habe nichts zu tun
  • das Team leistet hervorragende Arbeit und ich beschäftige mich mit inhaltsfremden Themen
  • ich werde hier bezahlt, also muss ich auch leisten und ständig was zu tun haben
  • mein Team muss doch langsam denken, ich möchte mich vor Verantwortung und Arbeit drücken

Angereichert mit diesen Informationen lässt sich die Attitude wie folgt ergänzen: ich komme morgens rein, schaue was passiert, projiziere das auf meine Skills und reagiere darauf; in der Zwischenzeit helfe ich mit, wo ich kann.

Der Scrum-Master – ein Multi-Talent?

teileundherrscheDie Rolle der Scrum-Master wird oft verkannt und wäre mit Bezeichnungen wie Team-Sekretär oder Team-Office, aber auch Projektleiter zu betiteln.

Diese Bezeichnungen sollen keinesfalls die entsprechenden Rollen abwerten, je nach Projekt-Setting sind diese sinnvoll bis notwendig. Viel mehr geht es mir darum, ein Bewusstsein zu schaffen, dass „Scrum-Master“ keine moderne, coole und trendige Bezeichnungen für die oben genannten Stellen ist und – was noch viel wichtiger ist – nicht die Aufgaben eines Scrum-Masters bestimmen dürfen:

  • Übernahme von Alltagsaufgaben, z.B. Karten vom Online-Board ausdrucken und auf das physische Board hängen
  • Annahme und Durchführung von Story-relevanten Aufgaben, z.B. Einrichtung einer neuen VM, oder Beschaffung einer neuen Lizenz für die IDE
  • hartnäckiger Impulsgeber für organisatorische Aufgaben, z.B. 2x die Woche bei der Personalabteilung nachhaken, ob Stellenanzeige für Frontend-Developer schon online ist
  • Durchführung von Spezialaufträgen des Vorgesetzten, weil es ja irgendeiner tun muss, z.B. eine Analyse über die Marktentwicklung in der Abteilung, …

Der Scrum-Master, als ein Jemand, von dem man nicht so richtig weiß, was er machen soll und deshalb alles irgendwie machen kann. Meine Meinung ist, der Scrum-Master muss sich seinen Job selbst kreieren, sich Ziele für das Team setzen, diese in seiner Verantwortung sehen und verfolgen.

Anders gesagt wirkt er damit dem oben beschriebenen Verhalten des Team-Sekretärs entgegen, wie es mit einem Zitat von Mark Twain nicht treffender formuliert werden kann: Und als wir das Ziel aus den Augen verloren, verdoppelten wir unsere Anstrengungen.

Freiheit muss gestaltet werden

GestaltungAgil vorzugehen bedeutet diszipliniert und professionell vorzugehen, so meine Auffassung. Das beginnt bereits beim Setting des Vorhabens, der Planung. Als Scrum-Master installiere ich beim Produktmanagement folgende einfache Dinge:

  • eine klare Vision entwickeln, anhand der sich Involvierte und Stakeholder orientieren und organisieren
  • ein Ende-Datum festlegen, bis dahin die Vision Realität geworden ist
  • Epics identifizieren, die der Vision Gestalt geben
  • Epics auf Stories runterbrechen und gemäß Businessvalue priorisieren

Diese Rahmenbedingungen wirken wie Treibstoff für die Entwicklung und Motivation. Vor allem verhindern sie eine Drauf-Los-Entwicklung und das tägliche Ändern des Fokus.

Mit gutem Beispiel voran: das Improvement-Backlog

Was wir Scrum-Master den Stakeholdern beibringen kann auch nicht so schlecht für uns selbst sein. Meiner Auffassung nach soll der Scrum-Master ebenfalls

  • eine Vision verfolgen,
  • sich einen Zeithorizont dafür stecken,
  • festlegen, was mit dem Team erreicht werden soll und
  • Beispiele für ganz konkrete Erkennungsmerkmale dafür identifizieren.

Alles zusammen bildet ein Improvement-Backlog. Und wie der Name ahnen lässt, geht es dabei um Verbesserungen für das Team. Der Job des Scrum-Masters!

Der Nährboden für Gestaltungsfreiheit

ampelIst der Scrum-Master im Besitz eines Improvement-Backlogs, kann dies mit dem Auftraggeber, dem Vorgesetzten, dem Teamleiter, der Geschäftsführung, etc. abgestimmt und als Auftrag erklärt werden. In diesem Moment ist transparent, was der Scrum-Master macht und er ist frei in seinem Handeln. Die oben genannten Annahmen lösen sich wie folgt auf:

  • der Scrum-Master hat was zu tun, siehe Improvement-Backlog
  • das Team leistet die Arbeit und der Scrum-Master macht sie dabei noch besser, siehe Erfolge aus dem Improvement-Backlog
  • er kostet Geld und ist auch entsprechend ausgelastet, siehe Improvement-Backlog
  • er sagt, es sei die Verantwortung des selbstorganisierten Teams – so ist auch der Auftrag an ihn

Kommt es zu Situationen, in denen der Scrum-Master einen kleinen Gefallen erledigen soll, kann er stets auf die vereinbarten Ziele verweisen.

Customer collaboration… Responding to change…

ankommenWas sich in der Produktentwicklung durchsetzt und vom Agilen Manifest gefordert wird, darf auch nicht am Scrum-Master vorbeigehen: schnell auf Änderungen reagieren, anstatt stur einen Plan zu verfolgen und die inhaltliche Zusammenarbeit mit dem Kunden forcieren, anstatt sich an Vertragsverhandlungen zu klammern.

Auch das Leben eines Teams ist nicht vorhersehbar. Es ändert sich, Leute wechseln, neue kommen hinzu. Die Ziele werden sich verändern, manche werden obsolet und neue Herausforderungen kommen hinzu.

Und jeden kleinen Gefallen mit der „Vertragskeule“ in Form der Zielvereinbarung abzuschmettern schadet der Zusammenarbeit mit dem Vorgesetzten. Hier muss der Scrum-Master kreativ werden, um aus dem kleinen Gefallen, den er ausführen soll, ein Learning für das Team zu machen.

Für seine Zielerreichung muss der Scrum-Master es also doch immer wieder sein: flexibel und spontan!

Quellenangaben
mydegage/shutterstock.com
ChiccoDodiFC/shutterstock.com
ponsulak/shutterstock.com
maradonna 8888/shutterstock.com
Don Pablo/shutterstock.com
LoloStock/shutterstock.com