28. Mai 2014

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

Share

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.

 

Share

3 comments on “Die Scrum Master Verteilung: Ein Entwickler, der auch Scrum Master ist”

  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.

  2. Unternehmen, welche für die Rolle eine Stelleausschreibung erstellen, suchen eher selten:
    Scrum Master Informatik MA (m/w) gute Kenntnisse in Java Script, SQL Server, HTML5, Python, Ruby, Swift, C# und Konfliktbewältigung - und zu Recht. Ich habe inzwischen (Scrum Master) Stellen explizit mit Anforderung eines Abschlusses in Psychologie gesehen.
    Bei der rein technischen Besetzung tippe ich (zu 90% - Überraschungen gibt es immer), dass die agilen Prinzipien auf der Strecke bleiben. Die Scrum Meetings werden erfüllt, Retrospektiven werden irgendwann gestrichen oder sind reine Codediskussionen, das Board (dann natürlich nur digital) und eine Reihe von Tools existiert aber der Dev. Scrum Master betreibt schlicht Mikromanagement und "selbstorganisiert" heißt, er streitet mit dem Product Owner. Das im besten Fall - im schlechtesten nimmt er eine quasi Team Lead Funktion gegen das Entwicklerteam ein.
    Wenn man schon Rollen splitten muss, schlage ich einen Mitarbeiter von HR vor.

  3. So dramatisch sehe ich das nicht. Ich habe über die Jahre schon excellente Scrummaster gesehen, die zuvor Entwickler waren und auch welche, die das so in Teilzeit gemacht haben. Zugegebenermassen aber auch solche, die lediglich ein sehr seichtes und rein mechanisches Verständnis von Agilität hatten. Die grosse Gefahr bei der Teilzeitscrummasterei ist die Schizophrenie, die das mit sich bringt: Früher oder später gibt es Zielkonflikte und eine der beiden Rollen muss - mindestens temporär - zurückstecken. Meist der Scrummaster und das hat dann Folgen. Ein Grundproblem ist auch, dass oft die Weiterentwicklung auf der Strecke bleibt: Wo Teilzeitscrummaster unterwegs sind sind sie oft allein - es fehlt ein Team von Agilisten, das sich gegenseitig Feedback gibt und voran bringt - der Teilzeitscrummaster ist einsamer Streiter auf einer Mission, die ihm oft selbst nicht so klar ist und Kämpfer gegen Windmühlen, die mächtig Gegenwind produzieren. Zeit zur intensiven Auseinandersetzung mit agilen Prinzipien hat er ebenso wenig wie sein Tun über das Team hinaus wirken zu lassen und sich selbst Weiterzubilden - jegliche Slacktime wird ja von seiner Zweitrolle mit Beschlag belegt. So wird viel Potential verschenkt und oft genug sind kaputte agile Implementierungen die Folge. So oder so ist Teilzeitscrummasterei eine Notlösung - aber besser als keine und eine, die zumindest eingeschränkt funktionieren kann. Und im übrigen auch eine, die in den Anfängen von Scrum der Normalfall war, speziell in der Doppelrolle als Entwickler und Scrummaster.
    Einen Mitarbeiter aus der HR habe ich als Scrummaster übrigens bewusst noch nicht nicht erlebt. Ist eine interessante Idee - könnte aber je nach Setup auch zu Zielkonflikten und Vertrauensproblemen gegenüber dem Scrummaster führen.

Schreibe einen Kommentar

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

Hiermit akzeptiere ich die Datenschutzbedingungen.

Rufen Sie uns an: 030 – 555 74 70 0

Made with 
in Berlin. 
© leanovate 2024