10 Dos und Don'ts einer Scrum Master-Stellenausschreibung
Über die Jahre bin ich bei mehreren Kunden daran beteiligt gewesen Stellenausschreibungen für Scrum Master zu erstellen, die ich dann auch auf lokalen Community-Meetups vorgestellt habe. Basierend auf dem Feedback (und eigener Expertise) sind hier einige Ratschläge:
1. Scrum nicht komplett in Grossbuchstaben schreiben (und schon gar nicht mit Punkten dazwischen)
Es ist einer der grossen Klassiker:
"Gesucht wird ein SCRUM Master für ein SCRUM-Team". Das Problem - dem Bewerber wird dadurch sofort klar, dass man sich hier nur sehr oberflächlich mit der Methodik beschäftigt hat.
Scrum ist ein Eigenname und keine Abkürzung, weshalb auch erst recht die Variante S.C.R.U.M. nicht benutzt werden sollte.
2. Seriöse Sprache benutzen
Für die meisten Firmen ist Scrum etwas Neues und damit auch gefühlt mit Jugendlichkeit verbunden. Wird versucht das auf die Sprache zu übertragen wirkt das schnell anbiedernd und peinlich. (Pseudo-)Jugendsprache, schlimmstenfalls gemischt mit deutsch-englischem Kauderwelsch zieht niemanden an. Also
bitte kein "Booste die Performance Deiner Crew" und kein
"Du hast Bock auf Agile?"
3. Methodische "Anpassungen" kommunizieren
Wer die Scrum Master-Rolle so verändert oder mit Zusatzaufgaben versehen hat, dass sie sich vom Standard stark unterscheidet, sollte das schon in der Ausschreibung klar machen. Wenn das nicht passiert setzt schnell das grosse Staunen ein warum denn alle Neueinstellungen schon in der Probezeit kündigen. Wir reden schliesslich von gesuchten Fachkräften, die schnell etwas anderes finden.
4. Keine Selbstverständlichkeiten aufzählen
"Zu Deinen Aufgaben gehören das Vermitteln von Scrum und die Beseitigung von Impediments". Das ist richtig, es braucht aber nicht erwähnt zu werden. Der Scrum Guide
liefert eine klare Stellenbeschreibung, die jeder der in diesem Job arbeitet kennen muss. Dass nochmal zu wiederholen kostet entweder knappen Platz oder bläht den Text unnötig auf. Zur Not reicht:
"Deine Tätigkeiten sind die aus dem Scrum Guide".
5. Klar sagen welche agilen Praktiken schon eingesetzt werden und welche noch nicht
"Du stehst auf DevOps, CI/CD und TDD? Dann bist Du hier richtig." Wer so eine Ansage macht muss dann auch liefern, sonst setzt schnell das grosse Staunen ein (siehe oben). Wenn es aber tatsächlich so ist, dass das schon gelebt wird, dann ist das ein Differenzierungsmerkmal das auf jeden Fall genannt werden sollte. Damit zieht man die richtigen Leute an.
6. Keine technischen Skills verlangen (auch nicht für Jobs in IT-Teams)
"Erforderlich ist Expertise in Java, C# und Oracle PL/ SQL". Kann man so schreiben, allerdings trifft dann das Gleiche zu wie bei der Schreibweise SCRUM: dem Bewerber wird dadurch sofort klar, dass man sich hier nur sehr oberflächlich mit der Methodik beschäftigt hat. Der Scrum Master entwickelt selbst keine Software, er braucht diese Skills nicht.
7. Herausforderungen ehrlich benennen
Veränderungsprozesse können anstrengend sein, und wenn das der Fall ist, dann ist auch der Job des Scrum Masters anstrengend. Das muss nicht abschreckend sein, manche suchen nach einer derartigen Herausforderung. Manche aber auch nicht, die entwickeln dann auch keine Wirkung. Um den Richtigen zu bekommen hilft es,
klar zu sagen womit man zu rechnen hat wenn man unterschreibt.
8. Kommunizieren ob es verteilte Teams und Heimarbeit gibt
Scrum läuft vor allem dann gut wenn das gesamte Team fünf Tage die Woche in einem Raum zusammensitzt. Sonst
wird die Kommunikation ineffektiv und
Information Radiators funktionieren nicht mehr. Wenn das nicht gegeben ist (warum auch immer) sollte das vorher klar sein, für viele Scrum Master wäre das ein Kündigungsgrund.
9. Klar machen ob es ein Scaled Agile-Kontext ist
Egal ob LeSS, Nexus, SAFe oder Flight Level-Kanban - sobald ein Scrum Team Teil von einem Projekt oder einer Abteilung ist in der Skalierungsframeworks eingesetzt werden verändern sich die Aufgaben eines Scrum Masters. Das ist nicht gut oder schlecht, es ist aber etwas das manche machen wollen und andere nicht. Darum sollte das von Anfang an transparent sein.
10. Keine Zertifizierungen verlangen
Ein Zertifikat kann den Eindruck erwecken, dass man einen Fachmann vor sich hat.
Diese Annahme ist falsch. Obwohl es gute Zertifizierungskurse gibt hat die damit verbundene Industrie
einen zwielichtigen Ruf und wird von vielen Scrum Mastern abgelehnt. Wer auf Zertifizierungen beharrt schneidet sich von vielen guten Kandidaten ab.
---
Ich habe diese Punkte schon oft auf der Tonspur weitergegeben und dabei manchmal irritierte Rückmeldungen bekommen: diese Dos und Don'ts wären zu spezifisch. Ob z.B. das Vorgehen angepasst wurde, welche Praktiken eingesetzt werden und welche Herausforderungen bestehen liesse sich doch aus HR-Sicht gar nicht beurteilen. In solchen Fällen gebe ich einen elften Ratschlag - bei derartigen Ausschreibungen kann man sich auch helfen lassen.