Home Blog Die Scrum Master Verteilung: Ein Entwickler, der auch Scrum Master ist

Die Scrum Master Verteilung: Ein Entwickler, der auch Scrum Master ist

Die Aufgaben eines Scrum Masters sind vielfältig: Moderator in den Meetings, Coach für das Team, Berater und „Sparringspartner“ für den Product Owner und Vertreter der agilen Idee im Unternehmen.

Gleichzeitig tun sich Unternehmen, die nur ein einziges womöglich kleines Scrum Team haben schwer damit, eine Vollzeitstelle für den Scrum Master anzusetzen.

Wer dennoch einsieht, dass ein Scrum Master großen Mehrwert für das Unternehmen darstellt, indem er die Qualität von Team und Produkt verbessert, neigt dann dazu, einen Mitarbeiter im Scrum Prozess mit zwei Rollen zu betrauen: Product Owner, Tester, Teamleiter oder Entwickler werden dann „auch noch“ Scrum Master.

Das ist nicht ideal, aber oft genug gelebte Praxis. Alle diese Kombinationen haben ihre spezifische Fallstricke und Eigenheiten, manche weniger, andere mehr. Wir haben sie im einzelnen beleuchtet. Heute:

Kombination 4: Entwickler und Scrum Master

Diese Variante entsteht oft, wenn bestehende Teams auf Scrum umsteigen. Dann wird der Produktmanager zum Product Owner und alles Weitere macht das Team unter sich aus und einer der Entwickler übernimmt eben „nebenher“ die Rolle des Scrum Masters.

Auch in dieser Kombination besteht die Gefahr, dass der Scrum Master nicht so neutral im Rollengefüge ist wie er es sein sollte, dass er im schlechteren Falle eher als Sprecher des Teams fungiert denn als Vermittler zwischen Team und Management oder PO. Doch mit etwas Sensibilität und Bewusstsein für Neutralität muss das nicht sein.

Überhaupt sollte diese Rolle nicht zufällig ausgelost werden. Das Interesse, als Coach und Moderator zu arbeiten und sich nicht mehr nur um technische, sondern auch zwischenmenschliche Probleme zu kümmern, ist für einen Scrum Master unerlässlich. Die Bereitschaft, womöglich zunehmend weniger „coden“ zu können und wegen des Switchens zwischen den beiden Rollen vielleicht nicht mehr so tiefgehend an den großen technischen Herausforderungen beteiligt zu sein, ohnehin vorausgesetzt.

Und auch wenn dies alles akzeptiert und gegeben ist, bringt diese Konstellation einen zusätzlichen Faktor für die Team-Velocity hinzu: Wie viel ein Scrum Master in einem einzelnen Sprint gebraucht wird, schwankt stark von Sprint zu Sprint und ist oft nicht vorhersehbar. Gerade bei kleinen Teams, bei denen diese Rollendopplung erst recht nötig wird, macht es dann schon einen Unterschied für das Sprintergebnis, ob einer der z.B. vier Entwickler 80 oder nur 10 Prozent seiner Zeit mit der Umsetzung von Stories verbringen kann.

Somit ist auch diese Rollendopplung keineswegs ideal. Wenn möglich, sollte ein Scrum Master ein Scrum Master sein, und nichts anderes. Denn nur dann kann er sich voll und ganz um die Weiterentwicklung des Teams kümmern und es dabei unterstützen, ihre Potentiale voll und ganz zu entfalten.

Ist dies jedoch nicht möglich, weil es sich z.B. kleine Unternehmen schlicht nicht leisten können, für drei oder vier Entwickler eine ganze zusätzliche Stelle für „Overhead“ zu finanzieren, ist die Dopplung der Rolle von Scum Master und Entwickler – im Vergleich zu PO und Scrum Master, Projektleiter/Teamleiter und Scrum Master sowie Tester und Scrum Master –  mit Sicherheit das geringste Übel. Und besser als gar keiner allemal.


Newsletter_abo

Sie wollen regelmäßige Updates über neue Blog-Artikel?
Jetzt unseren Newsletter abonnieren!

Ein Antwort

  1. Wichtig ist dabei, dass dieser Scrum Master aus der Entwicklung aber auch „von oben“ ermächtigt ist, Dinge die das Team braucht, um gut(also auch effizient im Sinne des Zieles, nicht nur um sich selbst gut zu fühlen) arbeiten zu können, durchzusetzen und zu unterstützen über Abteilungen und Hierarchien hinweg.
    Wenn der Entwickler-Scrummaster entmächtigt wird, sobald seine Maßnahmen den Luftschlössern höherer Ebenen im Wege stehen(weil realistischer geschätzt wird zum Beispiel), dann hilft es nichts.
    Genauso darf der Entwickler-Scrum-Master natürlich nicht zu sehr Interessen von Entwicklern vertreten.

    Der Scrum Master muss also immer eine neutrale und ermächtigte Person sein, die vor allem das Einhalten des Prozesses, nicht Interessen einzelner Personen oder Gruppen, aus welcher Motivation auch immer, durchsetzt und unterstützt. Und es muss sich immer auch die ganze Organisation/Abteilung diesem Prozess unterordnen und mitmachen, auch wenn es dabei zeitweise unbequem wird. Der Lohn ist dann idealerweise eine offenes, faires Kooperationsverhältnis aller Beteiligten und das bestmögliche Ergebnis, das mit realistischer Planung und ohne übermäßigen Stress auf irgendeiner Seite erreicht werden kann. Nachhaltig, Effektiv und Effizient.
    So haben alle langfristig Spaß an der Sache und liefern Sprint für Sprint tolle Software.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

© by leanovate GmbH - Impressum