Die Stellenbeschreibung des Scrum Masters sieht in jeder Organisation irgendwie anders aus. Das führt dazu, dass immer wieder Anforderungen an uns gestellt werden, die wir nicht erfüllen können, oder die wir nicht erfüllen sollten. Lasst uns Mal den Anfang machen, diese Unklarheiten aus der Welt zu schaffen.
Ganz einfach ausgedrückt ist es die Aufgabe des Scrum Masters, dafür zu sorgen, dass Scrum in der betreffenden Organisationseinheit funktioniert – was auch immer wir darunter verstehen mögen. Ihr seht bereits, dass es in diesem Bereich viele Unklarheiten gibt. Dieser große Interpretationsspielraum ist Quelle einiger unserer Probleme, weil sich weder wir noch alle anderen ganz sicher sein können, was alles darunter zu verstehen ist.
Noch schwieriger sieht es bei Kollegen im Kanban Umfeld aus. Für die gibt es noch nicht einmal eine allgemeine Bezeichnung. Dennoch können wir die Parallele ziehen, dass für alle Agilen gilt, dass es deren Aufgabe ist, dafür zu sorgen, dass Agilität in der betreffenden Organisationseinheit gelebt wird.
Wenn man eine Stellenausschreibung für einen Scrum Master oder einen anderen Agilen liest, findet man darin alle möglichen Formulierungen. Im Allgemeinen steht da was von der Moderation der Meetings – damit hat keiner ein Problem.
Dann finden wir dort aber auch gern irgendeine Formulierung in der Richtung »Konfliktlösung«. Das ist der erste Punkt, bei dem wir äußerst vorsichtig sein sollten. Wenn es unsere Aufgabe ist, dafür zu sorgen, dass Scrum in unserer Organisationseinheit gelebt wird und Ergebnisse zeigt (welche das auch immer sein sollten – das müssen wir zwingend vereinbaren, weil wir sonst immer mit unterschiedlichen Erwartungen leben müssen, was niemals Spaß macht), dann fällt darunter alles, was dazu beiträgt, diesen Prozess zum Laufen zu bringen, am Leben zu halten und zu erweitern / verbessern.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Das ist erst einmal Methode und Coaching unserer Kollegen, das sich jedoch ausschließlich auf die Schulungsaspekte eines Coachings beschränkt. Ein persönliches Coaching im Sinne einer Persönlichkeitsentwicklung können wir keinesfalls leisten. Dafür sind wir (zumindest die meisten von uns) nicht ausgebildet, und ich rate Euch dringend davon ab, Euch dazu breitschlagen zu lassen.
Ihr solltet hier eine klare Linie ziehen. Die Argumentation ist sehr einfach: »Ich bin dafür nicht ausgebildet. Wenn ich es versuche, könnte ich mehr Schaden als Nutzen anrichten.«
Die meisten professionellen Coaches in diesem Bereich sind nicht ohne Grund Psychologen. Wenn Ihr in die Situation kommt, Euch hier umsehen zu wollen, weil Ihr für Euer Team oder einen Kollegen Unterstützung sucht, dann rate ich auch dringend dazu, eher konservativ zu bleiben. In diesem Bereich gibt es eine ganze Menge New-Age-Quatsch und Scharlatane, die ebenso wenig Ahnung von den hochkomplexen psychologischen Vorgängen haben wie Ihr.
Die Konfliktbewältigung, die immer wieder erwähnt wird, geht in eine ganz ähnliche Richtung. Wir sind keine Mediatoren, aber wenn ein Konflikt im Team oder in einer der Schnittstellen unserem reibungslosen Scrum im Wege steht, dann fällt es unseren Aufgabenbereich. Das führt uns in ein Dilemma, weil wir etwas tun müssen, wozu wir nicht ausgebildet sind.
In unserem direkten Teamumfeld kann es selbstverständlich immer zu persönlichen Konflikten kommen. Die alltäglichen Dinge können wir vielleicht selbst auflösen, weil wir hoffentlich über eine gut ausgeprägte Sozialkompetenz verfügen. Wir können mit den Beteiligten sprechen, zwischen den Zeilen lesen und dafür sorgen, dass man sich zumindest soweit respektiert, dass man wenigstens vernünftig miteinander arbeiten kann.
Allerdings kann kein Mensch erwarten, dass wir jeden persönlichen Konflikt auflösen können. Das schafft auch er beste Mediator nicht. Was tun wir also, wenn wir an unsere Grenzen stoßen, wenn wir mit einem Gespräch nichts mehr erreichen?
Wir können einen professionellen Mediator hinzuziehen, was aber natürlich nur möglich ist, wenn die Kollegen damit einverstanden sind. Im schlimmsten Fall müssen wir am Teamschnitt arbeiten. Einer wird das Team verlassen müssen, was natürlich nur der letzte Ausweg ist.
Als Scrum Master können wir Konfliktlösung nicht pauschal von uns weisen, wir sind hier jedoch stark eingeschränkt, und es ist wichtig, dass alle verstehen, dass wir keine Superkräfte besitzen. Wir können nicht dafür sorgen, dass Menschen, die sich nicht mögen, plötzlich wie durch Zauberhand gut zusammenarbeiten. Es bleibt jedoch unsere Aufgabe, dafür zu sorgen, dass Scrum funktioniert. Wir können uns also nicht komplett heraushalten, werden uns aber womöglich Unterstützung suchen müssen.
In jedem Fall ablehnen sollten wir Konfliktbewältigung in irgendeiner anderen Organisationseinheit. Wenn jemand auf Euch zukommt und Euch bittet, Euch eines Konflikts irgendwo im Unternehmen anzunehmen, weil es ja Euer Job sei, sich um solche Dinge zu kümmern, dann lehnt höflich ab. Egal wer fragt.
Doppelt unterstrichen, fett gedruckt, kursiv und rot: Egal wer fragt. Auch wenn es der Oberhoncho ist.
Wir sind keine Mediatoren. Wir können Konflikte sowieso nur sehr begrenzt lösen, und auch nur in unserem direkten Umfeld. In einem Bereich, in dem wir uns nicht auskennen, mit Menschen, die uns fremd sind, werden wir sehr wahrscheinlich wenig erreichen oder sogar Schaden anrichten.
Eine andere Sache, die häufig von Scrum Mastern oder den Agilen im Unternehmen verlangt wird, ist die Moderation irgendwelcher Meetings oder die Durchführung von Workshops oder sonstige Trainings oder Schulungsmaßnahmen.
Ich habe kein Problem damit, irgendwo irgendetwas zu moderieren. Meine Priorität liegt aber in meiner eigenen Organisationseinheit. Wenn ich es einbauen kann, ohne mein Team zu beeinträchtigen, dann mache ich es. Wenn ich jedoch Termine mit meinem eigenen Team verschieben oder ausfallen lassen müsste, lehne ich ab.
Etwas anders ist es, wenn wir über ein Thema der Organisationsentwicklung oder die skalierte Ebene sprechen. Diese Dinge betreffen die Arbeit in unseren Teams zumindest indirekt. In dem Fall würde ich den Dialog mit meinem Team suchen und im Zweifel auch ein Teamevent (in Absprache) verschieben.
Werden wir darum gebeten, Schulungen oder Workshops durchzuführen, gilt neben dieser ersten Bedingung noch eine zweite: wir müssen uns mit dem Thema auskennen. Ich würde niemals eine Schulung durchführen, die ein anderer ausarbeitet, und die ich nur vortrage, weil ich so ein guter Redner bin (oder so). Betrifft es meine Themen, bin ich gern zur Unterstützung bereit, betrifft es sie nicht, bin ich sowieso der falsche Ansprechpartner.
Ihr solltet solche Dinge ebenfalls ablehnen. Es hilft niemandem, wenn ihr einen Workshop durchführt, dessen Inhalt Euch völlig fremd ist. Methodische Unterstützung wäre noch in Ordnung, aber ihr solltet nur in zweiter Reihe agieren.
Eine dritte Sache, die Stellenausschreibungen immer wieder erwähnt wird, ist »Verantwortung für den übertragenen Bereich«. Eine solche Formulierung benötigt Klarheit. Wenn damit gemeint sein sollte, dass wir über Zahlen sprechen – im Sinne von Umsätzen – dann ist das mit absoluter Sicherheit nicht Eure Aufgabe. Das ist Fachlichkeit. Diese Verantwortung liegt beim Product Owner. Punkt. Keine Diskussion.
Es mag in unserer Verantwortung liegen, den Product Owner methodisch zu schulen, aber wir treffen keine fachlichen Entscheidungen.
Der Begriff »Verantwortung« kann auf unterschiedlichste Arten interpretiert werden. Lassen wir ihn einfach so stehen, werden wir immer mit unterschiedlichen Erwartungen konfrontiert werden, was immer ein Problem sein wird. Wir sollten also dringend dafür sorgen, dass Klarheit herrscht, wie eine solche Formulierung zu verstehen ist.
Sollte damit die methodische und prozessuale Weiterentwicklung unserer Organisationseinheit gemeint sein, sind wir natürlich dabei. Sprechen wir darüber, dass organisationsweite Prozesse und Regelungen eingehalten werden, sind wir ebenfalls an Bord. Das ist noch immer Methodik und damit unsere Aufgabe. Sobald wir in den Bereich fachlicher Entscheidungen kommen, sind wir als Scrum Master raus. Hier beginnt die Domäne des Product Owners. Wir sollten sehr darauf achten, dies nicht miteinander zu vermischen.
Kernaussagen: Die Grenzen des Scrum Masters liegen sowohl in der persönlichen Entwicklung einzelner Personen als auch in der Mediation von Konflikten. Ihr solltet bei der Moderation von Meetings oder der Durchführung von Schulungen oder Workshops individuell entscheiden, ob es einen Konflikt mit Eurer eigenen Organisationseinheit gibt, und ob Ihr fachlich überhaupt geeignet seid. Achtet bei der Frage nach der Verantwortung auf die Grenze zwischen Fachlichkeit und Methode.
