Wer committet sich in Scrum eigentlich?
1

 
Das Entwicklungsteam committet sich für den nächsten Sprint. Generationen von ScrumMastern sind mit dieser Vorstellung groß geworden. Immer und immer liest man das in Büchern. Stopp, Moment. Nur das Entwicklungsteam? Wenn man das so handhabt, bringt man Scrum um eines seiner wichtigsten Prinzipien, die das Framework letztlich so verlässlich machen: die Verantwortung. Ohne Verantwortung kann man Scrum auf dem Papier machen, doch es wird nicht geliefert.
Wenn das Team nicht die Verantwortung für professionelles Entwickeln übernimmt, gibt es keine erfolgreiche Lieferung. Wenn der Product Owner keine Zusage gibt, dem Team immer fachlich zur Seite zu stehen, wird das Produkt nicht annähernd einen so hohen Return on Investment (ROI) für das Unternehmen bringen, wie es könnte.
Genauso viel Einfluss hat das Commitment des ScrumMasters. Der Glaube “Ich unterstütze das Entwicklungsteam bei seinem Commitment” birgt einen Trugschluss in sich, der die Lieferung und ihre Qualität entscheidend beeinflussen kann. Als ScrumMaster ist meine Arbeit mit dem Commitment nicht getan. Alle haben sich geeinigt, sie wissen, worum es geht. Nein, im Gegenteil: Gerade jetzt schaue ich besonders darauf, dass ich meinen Job voll und ganz übernehme; ich werde alle Hindernisse aus dem Weg räumen, die Entwickler oder den Product Owner daran hindern, effektiv zu arbeiten. Ich werde alles dafür tun, dass UNSER Commitment eingehalten wird. Dass der Product Owner verfügbar ist. Dass er Fragen beantwortet. Dass er im Review anwesend ist und weiß, welche Features als nächste umgesetzt werden sollen. Dass das Entwicklungsteam ungestört arbeiten und alle Features umsetzen kann. Dass alle notwendigen Informationen zwischen den richtigen Teammitgliedern ungehindert fließen, Missverständnisse ausgeräumt werden und Disziplin in der Arbeitsweise eingehalten wird.
Als ScrumMaster schütze ich das Team – das gesamte Team. Ich bin so für das Team da, wie es mich gerade braucht. Als bester Freund, als Führungskraft, als guter Hirte im Tal der Tränen, als Provokateur, wenn etwas zu selbstverständlich aussieht. Eben das, was es braucht, damit wir das schaffen, wofür wir alle zuständig sind: die Lieferung. Die Produktivität ist die Aufgabe des ScrumMasters. Die Produktivität des ganzen Teams. Denn vom ihm hängt die Lieferung ab. Wenn wir nicht alle Hand in Hand arbeiten, ist unser Ziel gefährdet. Nicht die Entwickler sagen, dass sie das Sprintziel umsetzen können. Jeder im Team tut es.
Aber wie führe ich als ScrumMaster? Es ist meine Verantwortung, dem Team einen Weg zu zeigen. Ja, es ist mein Ziel als ScrumMaster, Teams auf dem Weg zur Selbstorganisation zu unterstützen, wenn sie noch nicht so weit sind. Es ist meine Aufgabe, ihnen das Wichtigste zuerst beizubringen: pünktlich sein, zielorientiert liefern, sich selbst und die Gruppe managen können, kurz: die agilen Werte zu verankern.
Die Verantwortung des ScrumMasters ist eine Führung im Spannungsfeld:
Ich schreibe keine Aufgaben vor, aber setze Regeln.
Ich werde keine Anweisungen geben, aber immer wieder unbequem sein.
Ich bin Teil des Teams und verantworte seine Produktivität – nicht durch Command und Control, sondern durch den Umgang auf Augenhöhe. Das heißt auch für mich: ein Commitment geben. Für jede Minute des Sprints.
 

Geschrieben von

Paul Haase Paul Haase

Genau zuhören zu können und sowohl das Gesagte als auch das Nichtgesagte wahrzunehmen, ist in der agilen Arbeitswelt eine Schlüsselkompetenz. In der Unternehmenskommunikation hat Paul Haase diese Kompetenz viele Jahre trainiert und setzt sie jetzt gezielt als ScrumMaster für seine Teams ein. Durch das Zuhören erkennt er schnell, wo die Potenziale von Menschen liegen und wann er mit seiner Moderations- und Mediationserfahrung in schwierigen Kommunikationssituationen klärend eingreifen sollte. Commitment sowie das Vertrauen in die eigenen Fähigkeiten und jene der anderen sind für Paul Haase die wichtigsten Voraussetzungen auf dem Weg nach vorne. Den Maßstab der Verlässlichkeit legt er daher stets an sich selbst an und  schafft so mit seinen Teams das Vertrauen in das agile Arbeiten und in die eigene Mission.    

Ähnliche Beiträge: