Wie technikfern darf ein Scrum Master sein?
Bild: Public Domain Files/US Department of Energy - Public Domain |
Selbst wenn ein Quereinstieg möglich ist würde ich sagen, dass ein komplett technikferner Scrum Master auf Dauer in Probleme hineinlaufen wird. Das beginnt schon bei einer der Kernaufgaben, dem Beseitigen von Impediments: wenn die Entwicklerrechner zu wenig RAM haben, wenn es zu wenige Testumgebungen gibt oder wenn die Teams mit Feature Branches in eine Merge-Hölle geraten, dann muss man das nicht selbst beheben können, man sollte aber verstehen können worum es geht, damit klar ist wie eine Lösung angestoßen werden kann. Auch bei Microservices, festen und dynamischen IDs, Code Covarage, TDD und vielem mehr ist ein gewisses Verständnis mehr als hilfreich. Allerdings:
Die Bereitschaft sich in diese Bereiche einzudenken und einzulernen ist leider nicht bei jedem gleichermassen vorhanden. "Ich glaube, ich brauche das nicht. Ich coache ja nur deren soziale und methodische Skills" durfte ich mir in einem Fall gerade erst anhören. Und das ist gefährlich. Der schönste Prozess und das beste Arbeitsklima bringen nichts, wenn die Anwendung so verschachtelt gebaut und so schlecht durch Tests abgesichert ist, dass jede User Story durch eine mehrwöchige Analyse- und Bugfixing-Phase muss bevor sie auf Produktion kann. Deshalb:
Kein Scrum Master muss Entwickler sein (und ganz nebenbei - selbst wenn man als einer angefangen hat kann man erstaunlich schnell aus der Übung kommen). Wenn man aber nicht in unkalkulierbare Risiken hineinlaufen will sollte man Technikferne als relativen und nicht als absoluten Begriff begreifen.