In Kürze: Agile regulierte Industrien
Gibt es agile regulierte Industrien, oder ist das ein Widerspruch in sich?
Kürzlich erhielt ich eine Projektmeldung von einer Organisation, die einen Scrum Master mit mindestens zwei Jahren Erfahrung mit Informationssystemen für Reisende im Bahnverkehr und im öffentlichen Nahverkehr haben sollte.
Wenn man sich die Stellenbeschreibung ansieht, scheint diese jedoch nicht nach einem Scrum Master zu verlangen, sondern nach einem Projektmanager und glorifiziertem Jira-Sachbearbeiter. Wenn das der Fall ist, warum weißt der potentielle Auftraggeber bzw. Arbeitgeber nicht darauf hin, sondern tun so, als gäbe es so etwas wie agile regulierte Industrien?
Agile regulierte Industrien: Die Scrum Master Stellenanzeige
Setzen wir einmal voraus, dass Sie eine Scrum Master-Stelle und nicht nur eine Anstellung suchen. (Natürlich habe ich volles Verständnis dafür, dass jeder in der aktuellen Situation ggf. andere Prioritäten setzt.)
1. Beschreibung der Tätigkeit:
Die Stellenanzeige — ich habe den Originaltext aus lizenzrechtlichen Gründen umformuliert — sah etwa wie folgt aus. Tätigkeiten:
- Erbringung von Dienstleistungen nach den vereinbarten Standards und Spezifikationen des Kunden (Rahmenvertrag, Prozessmodell, Architektur- und Sicherheitsrichtlinien, Programmierstandards).
- Beratung bei der Umsetzung der Scrum-Regeln und der Einhaltung des Scrum-Prozesses.
- Beratung bei der Sicherstellung, dass die Teams die Software in der erforderlichen Qualität und unter Einhaltung aller Standards liefern.
- Der externe Spezialist übernimmt im Rahmen seines Auftrags Aufgaben aus dem regelmäßigen technischen Austausch mit dem Implementierungsteam. Dies geschieht in Übereinstimmung mit den agilen Methoden durch das Abrufen von Aufgaben, die sich aus den User Stories ergeben.
- Beratung bei der Umsetzung von Scrum-Regeln im Projektteam.
- Beratung zur Einhaltung der vereinbarten agilen Prozesse und Definitionen.
- Beratung zur notwendigen Disziplin des Teams bei der Durchführung von agilen Projekten.
- Erfassung aller Hindernisse während des Projekts im Impediment Backlog (z. B. Probleme mit der Kommunikation, persönliche Konflikte, externe Störungen während der Sprints).
- Beseitigung von Hindernissen
- Moderieren von Meetings in agilen Projekten (z.B. Sprintplanung, Retrospektive).
- Auftreten als Vermittler (Facilitator).
- Beratung zum Informationsfluss zwischen Product Owner und Projektteam.
- Aktualisierung von Scrum-Artefakten (Product Backlog, Sprint Backlog, Burndown-Charts).
- Verfolgt die „Definition of Done“ für alle Arbeitsergebnisse des Entwicklungsteams.
- Berichten des Status aller Sprint-relevanten Metriken.
- Bestimmen und Verfolgen der Teamkapazität und -geschwindigkeit für die Sprint-Planung.
- Teilnahme an allen technischen Projektmeetings, Scrum-Veranstaltungen und Workshops.
- Teilnahme an notwendigen technischen Terminen am Erfüllungsort.
- Technische Unterstützung bei der Projektsteuerung und Kapazitätsplanung.
2. Anforderungen an Bewerber:
a) Unbedingt erforderlich:
- Methodische Kompetenz, Modellierung, Prozessmodelle. Mehr als 4 Jahre Erfahrung in der Kenntnis agiler Projektansätze (Kanban und „Scrum of Scrums“).
- 3 Projektreferenzen als Scrum Master in Projekten mit mehreren parallel arbeitenden Scrum Teams (mindestens 3 Projektreferenzen innerhalb der letzten 7 Jahre).
- Mindestens 2 Jahre Erfahrung mit Informationssystemen für Bahnreisende und öffentliche Verkehrsmittel.
- 4 Jahre Erfahrung in der Arbeit mit Atlassian Confluence und Jira.
- Zertifizierung als Scrum Master.
b) Wünschenswert:
- 4 Jahre Erfahrung mit Kenntnissen in Problemlösung/Arbeitsorganisation in den letzten 4 Jahren.
- 4 Jahre Berufserfahrung in der Entwicklung von Software und Systemen.
- 4,5 Jahre Erfahrung in der Moderation von Team-Meetings (Daily [Scrum], Replenishment, Planning, Refinement) und Workshops sowie Retrospektiven (mindestens drei Projektreferenzen in den letzten 4,5 Jahren).
Agile regulierte Industrien: Analyse der Stellenanzeige aus der Sicht eines Scrum Masters
Aus meiner Sicht sind dies die problematischsten Abweichungen von der idealen Rolle eines Scrum Masters, basierend auf der vorliegenden Stellenanzeige:
1. Bereitstellung von technischen und Prozessstandards:
- Anforderung: „Erbringung von Dienstleistungen nach den vereinbarten Standards und Spezifikationen des Kunden (Rahmenvertrag, Prozessmodell, Architektur- und Sicherheitsrichtlinien, Programmierstandards).
- Abweichung: Die Rolle des Scrum Masters besteht darin, sicherzustellen, dass das Scrum-Rahmenwerk verstanden und umgesetzt wird, und nicht darin, technische und architektonische Standards durchzusetzen. Diese Verantwortung liegt normalerweise bei den Entwicklern oder den technischen Leitern, nicht beim Scrum Master.
2. Übernahme von technischen Aufgaben:
- Anforderung: „Der externe Spezialist übernimmt im Rahmen seines Auftrags Aufgaben aus dem regelmäßigen technischen Austausch mit dem Implementierungsteam. Dies geschieht in Übereinstimmung mit den agilen Methoden durch das Abrufen von Aufgaben, die sich aus den User Stories ergeben.“
- Abweichung: Der Scrum Master sollte nicht direkt an der technischen Arbeit oder der Aufgabenerledigung beteiligt sein. Seine Rolle besteht darin, den Prozess zu erleichtern und Hindernisse zu beseitigen, nicht darin, Entwicklungsaufgaben auszuführen.
3. Einhaltung der Softwarequalität sicherstellen:
- Anforderung: „Sicherstellung, dass die Teams die Software in der erforderlichen Qualität und unter Einhaltung aller Standards liefern.“
- Abweichung: Ein Scrum Master hilft dem Team zwar bei der Einhaltung der Scrum-Praktiken, zu denen naturgemäß auch Qualitätspraktiken gehören, ist aber nicht für die Gewährleistung der Softwarequalität oder die Einhaltung technischer Standards verantwortlich. Diese Verantwortung liegt bei den Entwicklern.
4. Direktes Aktualisieren von Artefakten:
- Anforderung: „Aktualisierung von Scrum-Artefakten (Product Backlog, Sprint Backlog, Burndown-Charts).“
- Abweichung: Die Verantwortung für die Aktualisierung von Artefakten wie dem Product Backlog und dem Sprint Backlog liegt beim Product Owner bzw. den Entwicklern. Der Scrum Master unterstützt diese Praktiken und stellt sicher, dass sie eingehalten werden, aktualisiert diese Artefakte aber nicht direkt.
5. Verfolgung und Berichterstattung:
- Anforderung: „Berichten des Status aller Sprint-relevanten Metriken.“
- Abweichung: Der Scrum Master hilft dem Team, die Metriken zu verstehen und zu nutzen, um sich zu verbessern, aber er berichtet in der Regel keine Statusmetriken an externe Stakeholder. Diese Rolle ist eher mit dem Projektmanagement und nicht mit den Aufgaben eines Scrum Masters verbunden.
6. Kapazität und Geschwindigkeit des Teams bestimmen:
- Anforderung: „Bestimmen und Verfolgen der Teamkapazität und -geschwindigkeit für die Sprint-Planung.“
- Abweichung: Während der Scrum Master den Prozess der Kapazitäts- und Geschwindigkeitsverfolgung erleichtern kann, liegt es in der Verantwortung des Teams, seine Kapazität und Geschwindigkeit zu verwalten und zu verstehen.
7. Teilnahme an technischen Meetings:
- Anforderung: „Teilnahme an allen technischen Projektmeetings, Scrum-Veranstaltungen und Workshops.“
- Abweichung: Der Scrum Master sollte Scrum-Veranstaltungen moderieren und sicherstellen, dass sie produktiv sind. Er sollte jedoch nicht verpflichtet sein, an allen technischen Projektmeetings teilzunehmen, es sei denn, seine Anwesenheit bringt einen Mehrwert, indem er Prozessprobleme anspricht.
8. Projektcontrolling und Kapazitätsplanung:
- Anforderung: „Technische Unterstützung bei der Projektsteuerung und Kapazitätsplanung.“
- Abweichung: Projektcontrolling und Kapazitätsplanung sind keine typischen Aufgaben eines Scrum Masters. Sie sollten sich darauf konzentrieren, das Team zu coachen, Hindernisse zu beseitigen und das Scrum-Framework ordnungsgemäß umzusetzen.
Diese Abweichungen deuten auf ein falsches Verständnis der Rolle des Scrum Masters hin, welches diese mit Projektmanagement und technischen Führungsaufgaben verwechselt, was die Prinzipien der Selbstverwaltung und Selbstorganisation von Scrum-Teams untergraben kann.
Agile regulierten Industrien: Mögliche Gründe für eine derartige Stellenanzeige
Was könnte der Grund dafür sein, ein als Scrum Master getarntes Stellenangebot für einen Projektmanager zu veröffentlichen? Was ist der Vorteil davon?
„Echte“ Scrum Master verstehen sofort den Zusammenhang und halten sich wahrscheinlich mit einer Bewerbung zurück. Diejenigen, die sich dennoch bewerben, brauchen vielleicht dringend einen Job und werden wahrscheinlich wieder gehen, sobald sie ein Stellenangebot finden, bei dem Scrum wirklich geschätzt wird. Der Arbeitgeber muss dann mit der Stellensuche von vorne beginnen – ein kostspieliger Misserfolg.
Diejenigen, die sich nicht an der offensichtlichen Fehletikettierung stören und sich auf die Stelle bewerben, sind ohnehin keine „echten“ Scrum Master, interessieren sich nicht dafür oder haben vielleicht auch keinen professionellen Hintergrund im Projektmanagement.
Missverständnis der Rollen:
- Mangel an Wissen: Dem einstellenden Unternehmen fehlt möglicherweise noch immer ein klares Verständnis der unterschiedlichen Rollen und Verantwortlichkeiten eines Scrum Masters im Vergleich zu denen eines Projektmanagers, insbesondere in einem regulierten Umfeld, in dem traditionelle Projektmanagementpraktiken tief verwurzelt sind.
- Umstellung auf Agile: Unternehmen in regulierten Branchen sind möglicherweise vorsichtiger, was die vollständige Übernahme agiler Methoden angeht, und suchen daher eventuell nach einer hybriden Rolle, die sowohl die Aufsicht über das traditionelle Projektmanagement als auch einige Elemente von Scrum übernehmen kann.
Strategische Intentionen:
- Einhaltung gesetzlicher Vorschriften: Regulierte Branchen haben oft strenge Compliance- und Dokumentationsanforderungen. Der Arbeitgeber könnte der Meinung sein, dass die Fähigkeiten eines Projektmanagers im Bereich der Dokumentation und des Compliance-Managements neben den agilen Praktiken unerlässlich sind.
- Risikomanagement: Das Unternehmen könnte jemanden mit soliden Risikomanagement-Fähigkeiten suchen, die typischerweise mit Projektmanagern in Verbindung gebracht werden, weil es glaubt, dass dies dabei hilft, die Komplexität der Einhaltung von Vorschriften zu bewältigen.
- Kosteneffizienz: Die Kombination der Rollen könnte als kostensparende Maßnahme angesehen werden, die es dem Unternehmen ermöglicht, eine Person einzustellen, die sich um die Einhaltung gesetzlicher Vorschriften und agile Praktiken kümmert.
Vorteile aus der Sicht des Arbeitgebers:
- Breiteres Skill Set: Kandidaten, die sowohl über Scrum- als auch über Projektmanagement-Kenntnisse verfügen, bringen möglicherweise ein breiteres Skill Set mit, das dabei hilft, die doppelten Anforderungen der agilen Entwicklung und der Einhaltung von Vorschriften zu bewältigen.
- Ausgewogene Herangehensweise: Für Unternehmen in regulierten Branchen könnte jemand, der sich mit beiden Praktiken auskennt, eine ausgewogene Herangehensweise bieten, die die Einhaltung der Vorschriften sicherstellt und gleichzeitig die agilen Praktiken fördert.
- Regulierungsexpertise: Das Unternehmen könnte der regulatorischen Expertise Vorrang einräumen und die gemischte Rolle als eine Möglichkeit sehen, die Compliance aufrechtzuerhalten, ohne auf die Vorteile agiler Praktiken zu verzichten.
Nachteile:
- Unausgewogene Erwartungen: „Echte“ Scrum Master werden die Unausgewogenheit erkennen und sich möglicherweise nicht bewerben, wodurch sich der Pool qualifizierter Kandidaten verringert. In regulierten Branchen könnte diese Fehlanpassung aufgrund der erhöhten Bedeutung der Compliance noch ausgeprägter sein.
- Bindungsprobleme: Diejenigen, die den Job aus der Not heraus annehmen, werden ihn wahrscheinlich verlassen, sobald sie eine Aufgabe finden, die besser zu ihren Fähigkeiten und Überzeugungen passt, was zu einer höheren Fluktuation und damit verbundenen Kosten führt. Dieses Verhalten kann in regulierten Branchen, in denen Fachwissen und Compliance-Kenntnisse entscheidend sind, besonders problematisch sein.
- Qualität der Kandidaten: Kandidaten, denen die falsche Bezeichnung nichts ausmacht, verfügen möglicherweise nicht über das nötige Verständnis oder Engagement für die agilen Prinzipien, was zu ineffektiven Scrum-Implementierungen und schlechter Teamleistung führen kann. In regulierten Branchen könnte dies auch zu Compliance-Risiken und Misserfolgen führen.
Fazit:
Die Strategie des Arbeitgebers, diese Rollen in einer regulierten Branche zu vermischen, spiegelt m. E. den Wunsch wider, agile Praktiken mit strengen regulatorischen Anforderungen in Einklang zu bringen. Dieser Ansatz kann jedoch zu falsch ausgerichteten Erwartungen, ineffektiven Praktiken und letztlich zu höheren Kosten aufgrund von Fluktuation und Rekrutierungsaufwand führen.
Es ist für Unternehmen in regulierten Branchen von entscheidender Bedeutung, die Rollen, für die sie Einstellungen vornehmen, klar zu definieren und zu verstehen, um sicherzustellen, dass sie die richtigen Talente anziehen und gleichzeitig die Compliance einhalten und ihre agile Transformation effektiv unterstützen. Eine falsche Kennzeichnung von Rollen kann besonders in Branchen problematisch sein, in denen Compliance und agile Praktiken sorgfältig ausbalanciert werden müssen.
Am Ende werden wir nicht dafür bezahlt, Scrum zu praktizieren, sondern die Probleme unserer Kunden im Rahmen der gegebenen Einschränkungen zu lösen und gleichzeitig zur Nachhaltigkeit der Organisation beizutragen. Scrum mag in dieser Hinsicht sinnvoll sein, andere Praktiken sind es aber auch. Man sollte dies nur entsprechend kommunizieren.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 42.000 Abonnenten anschließen.