Wollen Sie ein großartiger Scrum Master sein?

Das hoffe ich jedenfalls. (Naja, außer Sie sind Product Owner oder haben eine andere Rolle!) Über 20 Jahre habe ich als Scrum Master gearbeitet. Während dieser Zeit habe ich ziemlich viele Ratschläge gegeben und gesammelt. Für Sie habe ich die zehn wichtigsten Punkte herausgearbeitet:

 

1) Geben Sie nicht einfach ein Commitment für das Team ab!

In der Rolle als Scrum Master dürfen Sie keine Änderungswünsche im Namen des Teams annehmen (egal wie klein sie sein mögen). Selbst wenn Sie felsenfest davon überzeugt sind, dass das Team diesen Wünschen nachkommen kann, sollten Sie sagen: „Das muss ich erst mit dem Team besprechen”.

Und auf keinen Fall sollten Sie die Teammitglieder zu irgendwelchen Deadlines, Arbeitsergebnissen o.ä. verpflichten, ohne vorher mit ihnen darüber gesprochen zu haben. Sie müssen solche Dinge nicht immer zwingend mit dem gesamten Team absprechen – viele Teams haben kein Problem damit, wenn einzelne Teammitglieder sagen „Ja, das können wir machen”, ohne dass es dafür ein offizielles Teammeeting geben muss. Allerdings ist es immer noch deren Entscheidung und nicht Ihre.

 Sie wollen mehr über Scrum Master erfahren? Besuchen Sie unsere Trainings  Zu den Trainings
2) Sie sind dafür da, das Team gut aussehen zu lassen!

Bei der Rolle des Scrum Masters geht es nicht darum, sich selbst gut aussehen zu lassen. Sie stehen gut da, wenn das Team gut dasteht. Und das Team steht gut da, wenn es gute Arbeit leistet.

Sie wissen, dass Sie Ihren Job als Scrum Master gut machen, wenn Leute außerhalb des Teams anfangen, sich zu fragen, ob Sie überhaupt gebraucht werden. Natürlich kann es beängstigend sein, wenn sich Ihr Chef fragt, ob Sie überhaupt noch benötigt werden. Ein guter Chef wird jedoch wissen, dass Sie unentbehrlich sind, auch wenn Ihre Fähigkeiten und Know-How Sie überflüssig erscheinen lassen.

Vertrauen Sie darauf, dass Ihr Vorgesetzter den Unterschied zwischen überflüssig wirken und überflüssig sein verstanden hat.

3) Hauen Sie dem Team kein agiles Regelwerk um die Ohren!

Weder bei Scrum noch bei Agile im Allgemeinen gibt es einen Regelkatalog, den man befolgen muss (auch wenn einige versucht haben, einen zu erstellen).

Wenn Sie Nutzer für Ihr Produkt haben, versuchen Sie, mit User Stories zu arbeiten. User Stories sind aber keine Voraussetzung dafür, agil zu sein. Wenn jemand wissen muss, wann Sie liefern werden: schätzen Sie. Wenn es nicht nötig ist, tun Sie das vielleicht nicht. Wenn Sie glauben, dass ein Review am Ende des Sprints zu spät ist für Feedback, machen Sie nach jedem fertiggestellten Feature ein Review.

Agil zu sein bedeutet, die Werte und Prinzipien anzuerkennen, die Agilität erschaffen. Wenn Sie diesen agilen Werten und Prinzipien treu bleiben, können Sie gar nicht so weit vom rechten Weg abkommen, wie es Ihnen vielleicht manche weismachen möchten.

4) Nichts ist von Dauer also experimentieren Sie

Den agilen Prinzipien treu zu bleiben, bedeutet auch, mit den Prozessen zu experimentieren. Ermutigen Sie Ihr Team, neue Dinge auszuprobieren.

Ihr Team liebt zweiwöchige Sprints und alles läuft scheinbar perfekt? Großartig. Dann bitten Sie Ihr Team jetzt, einmal einen ein- oder dreiwöchigen Sprint auszuprobieren und sich die Ergebnisse anzuschauen. Experimente stoßen nicht immer auf große Begeisterung, aber sie sind die beste Möglichkeit, immer wieder neue und bessere Arbeitsweisen zu entdecken.

5) Sorgen Sie dafür, dass sich die Teammitglieder und die Stakeholder als Kollegen sehen!

Teammitglieder und Stakeholder im Unternehmen bringen beide einen wichtigen Blickwinkel in eine Produktentwicklungsinitiative ein. Aus diesem Grund sollten auch beide gleichermaßen geschätzt werden.

Wenn sich beide Seiten lediglich tolerieren, leidet das gesamte Unternehmen. Entwicklungsteams müssen die besondere Perspektive der Stakeholder verstehen und die Stakeholder müssen das Entwicklungsteam respektieren, was auch bedeutet, den Entwicklern zuzuhören, wenn sie sagen, dass das Einhalten der Deadline unmöglich ist.

6) Beschützen Sie das Team – auf unterschiedliche Weise!

Der vielleicht am häufigsten gegebene agile Rat ist, dass Scrum Master ihre Teams vor zu fordernden Product Ownern bzw. Stakeholdern beschützen müssen. Und das ist ein guter Rat. Manchmal fordern Product Owner einfach zu viel zu oft auf zu aggressive Art und Weise. Das zwingt Teams dazu, Abstriche zu machen – meist bei der Qualität – die sich dann im Endeffekt rächen.

Daher schützt ein guter Scrum Master das Team dagegen.

Was man nicht so häufig hört, ist, dass ein guter Scrum Master sein Team auch vor Bequemlichkeit schützen sollte. Gute agile Teams wollen sich permanent verbessern. Andere Teams werden – vielleicht unbewusst – bequem und glauben, dass sie sich bereits genug verbessert haben. Und mit großer Wahrscheinlichkeit sind sie auch wesentlich schneller und besser als in ihren Zeiten vor Agile. Allerdings können sich auch großartige Teams häufig noch sehr verbessern.

Großartige Scrum Master schützen ihr Team davor, zu glauben, es gäbe nichts mehr dazuzulernen.

7) Streichen Sie „Scheitern” aus Ihrem Wortschatz!

Ab und zu höre ich ein Team von einem „gescheiterten Sprint” sprechen. Meistens bedeutet das, dass das Team es nicht geschafft hat, alles zu liefern, was sie geplant hatten. Das sehe ich nicht als Scheitern an, besonders wenn das Team die meisten Items fertigstellen konnte oder wenn sie geschickt einen Notfall gelöst haben.

Wenn ein Basketball-Spieler den Ball Richtung Korb wirft und trifft, nennt man das Field Goal, also Feldtor. Wenn er nicht trifft, nennt man das Attempt, also Versuch.

Gute Scrum Master helfen Ihren Teams dabei, ihre Denkweise zu ändern und Sprints und Features, die nicht ganz ihren Erwartungen entsprechen, nicht als gescheitert sondern als Versuch zu sehen.

8) Loben Sie oft aber immer ehrlich!

Vor einigen Tagen sagte ich meiner Tochter, dass ich stolz auf sie bin. Sie strahlte über das ganze Gesicht. Das sollte mich eigentlich nicht wundern. Wer würde nicht gerne hören, dass jemand stolz auf ihn ist?

Aber ihre Reaktion zeigte mir, dass ich ihr das nicht oft genug sagen kann. Ich dachte immer, es sei genau das Gleiche, wie ihr etwas so offensichtliches zu sagen wie: „Du bist groß”. Aber ich habe gelernt, dass es eben nicht das Gleiche ist.

Falsches Lob sollten Sie jedoch niemals aussprechen. Das will niemand hören. Wenn Ihre Teammitglieder aber gute Arbeit machen, sagen Sie es ihnen. Es kann gut sein, dass sie das nicht oft genug gesagt bekommen.

9) Ermutigen Sie das Team, Ihren Job zu übernehmen!

Ein Team, das sich noch nicht gut mit Agile auskennt, ist stark auf seinen Scrum Master oder Coach angewiesen. Das Team weiß vielleicht nicht, wie es die 15 Minuten für Daily Scrum Meetings einhalten kann. Oder die Teammitglieder haben noch nicht die Wichtigkeit von überlappenden Arbeiten oder von interdisziplinären Teams verstanden.

Das Gleiche gilt für Sportmannschaften. Ein Trainer, der kleinen Kindern Fußball beibringt, muss ihnen alles erklären. Als meine Töchter sechs Jahre alt waren, rannte der Trainer während des gesamten Spiels neben ihnen her und rief: „Kicken und rennen!” Wenn er das nicht tat, vergaßen die Kinder das. Sogar trotz seiner Rufe setzte sich ab und zu ein Kind einfach auf den Platz und starrte in die Luft.

Vergleichen wir den Trainer der Kindermannschaft mit dem Trainer einer Nationalmannschaft. Die Spieler einer Nationalmannschaft haben gelernt, was sie tun müssen. Wenn der Trainer zu spät zum Training erscheint, wissen die Spieler, mit welchen Übungen sie schon einmal anfangen können. Der Coach der Nationalmannschaft muss die Spieler nicht daran erinnern, den Ball zu treten und zu laufen. Allerdings würde keine Nationalmannschaft der Welt sagen, dass sie keinen Trainer mehr benötigen.

Egal, wie gut ein agiles Team ist, ich glaube, dass sie trotzdem von einem Scrum Master oder Coach profitieren. Gute agile Teams übernehmen jedoch auch selbst einige der offensichtlichen Aufgaben eines Scrum Masters als Teil der Weiterentwicklung der Fähigkeiten, die sie für die Produktentwicklung benötigen.

10) Mund halten und zuhören!

Das beste Coaching bzw. Mentoring ist, nichts zu sagen und das Team selbst die Antwort finden zu lassen.

Das kann ganz schön hart sein. Wenn Sie sehen, dass Ihr Team Probleme hat, eine Lösung zu finden, ist es ganz natürlich, einzuspringen und Hilfe anzubieten. Wenn Sie jedoch allzu bereitwillig Probleme lösen oder Vorschläge machen, lernen die Teammitglieder, nur darauf zu warten, bis Sie jedes Problem für sie lösen.

Ich will damit nicht sagen, dass Sie keine Tipps geben dürfen. Sie sind klug; und wenn nicht, sollten Sie nicht in der Rolle sein, in der Sie sind. Allerdings gehört es auch zur Rolle des Scrum Masters, den Teams beizubringen, ihre Probleme selbst zu lösen. Wenn Sie immer jedes Problem des Teams direkt lösen, nehmen Sie den Teammitglieder die Chance, zu lernen, wie sie diese Probleme selbst lösen können.

Dieser Beitrag stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.

Das könnte dich auch interessieren

Meine Lieblingsstruktur für User Stories User Story Vorlage Ungefähre Lesedauer: 4 Minuten Wenn es um das Schreiben von User Stories geht, empfehle ich folgende Struktur: “Als &...
Ist Agile effizienter als Wasserfall? Einer der Scrum Master, den wir häufig coachen, ruft uns regelmäßig wegen Problemen an, mit denen er  zu kämpfen hat. Er scherzte, wir sollt...
Fünf Fallen bei der Skalierung von Agilität Große Unternehmen suchen besonders nach schnellen und einfachen Wegen, um die Transition von der klassischen zur agilen Entwicklung zu vollz...