Aug
23
Die Rolle Safety Manager in Scrum
Scrum besitzt ein festes Set an Rollen, um den Prozess zu gewährleisten. Es gibt den Product Owner, den Scrum Master und das Team. Ich habe mir die Frage gestellt, was passieren würde, wenn ich Scrum im Rahmen der ISO 26262 nutzen wollen würde. Es gibt viele Bereiche im Scrum Prozess die dafür zu betrachten wären. Ich habe meinen Startpunkt bei den Rollen gesetzt. In diesem Beitrag beleuchte ich Probleme und Gemeinsamkeiten der Rollen.
Die Rolle des Safety Managers habe ich bereits beschrieben. Da Scrum ein recht kleines Set an Rollen für den Prozess hat, gehe ich die wenigen, verschiedenen Rollen durch und beleuchte die Möglichkeiten den Safety Manager einzubinden. Der Zusammenhang zwischen Safety und Scrum kann im Rahmen von Agile Automotive wichig werden.
Der Product Owner als Safety Manager?
Der Product Owner ist die Person, die für das Produkt zuständig und verantwortlich ist. Da liegt es nahe zu überlegen, ob dort nicht auch die Rolle des Safety Managers sinnvoll ist. Safety relevante Arbeitsprodukte könnten im Product Backlog abgelegt werden. Durch die entsprechende Priorisierung des Product Owners wäre hier sichergestellt, dass diese Themen Beachtung finden. Da der Safety Manager immer die zentrale Stelle ist, um Kundenanfragen und -wünsche bezüglich Safety entgegen zunehmen, bietet sich ebenfalls der Product Owner an.
Die folgenden Tätigkeiten des Safety Managers passen zu denen des Product Owner:
- Der Product Owner ist für das Produkt verantwortlich und ist in der Lage Entscheidungen für das Produkt zu treffen.
- Er ist das zentrale Glied zwischen Kunde und interner Entwicklung und kann für Safety (wie auch für alle anderen) Anfragen zur Verfügung stehen.
- Der Product Owner ist der Besitzer des Product Backlogs, er priorisiert die Themen. Dabei orientiert er sich an dem Kundennutzen. Safety Themen können somit auch im Backlog priorisiert Platz finden.
Der Scrum Master als Safety Manager?
Der Scrum Master als Safety Manager bietet sich gerade für die moderierenden Dinge an, wie die Erstellung einer FMEA oder FTA an. Weiterhin kann der Scrum Master gut auf die Einhaltung der Prozesse achten, was er im Rahmen von Scrum sowie tut. Dem Scrum Master unterliegen in dem Sinne keine Arbeitsprodukte, was aber die Rolle des Safety Manager auch ausfüllt. Allerdings arbeitet der Scrum Master in dem Sinne nicht produktiv im Team mit (es sei denn, er ist auch ein Teammitglied). Das macht es wiederum etwas schwierig für Safety Anforderungen, die unbedingt umgesetzt werden müssen.
- Der Scrum Master ist gut geeignet für das Moderieren von FTA und FMEA Workshops.
- Er ist der “Hüter” der Prozesse und kann darauf achten, dass Safety Prozesse eingehalten werden.
Das Team als Safety Manager?
Das Team als Safety Manager ist auch eine Möglichkeit. Es finden sich einige Dinge in der Rolle des Safety Managers, die durch das Team erbracht werden können. Allerdings hat das Team bspw. nur eine begrenzte Möglichkeit der Entscheidung für die umzusetzenden Themen im Sprint, weniger im Product Backlog. Wenn das Team aber gute ISO 26262 Kenntnisse hat, ist es in der Lage zu bestimmen, in welcher Reihenfolge es mit welchen Auswirkungen implementiert werden kann und muss.
Ein Stakeholder als Safety Manager?
Stakeholder eignen sich nicht (siehe Pigs&Chicken). Sie haben keine wirklichen Entscheidungsbefugnisse und sind nicht direkt in das Team.
Eine neue Rolle für den Safety Manager?
Natürlich kann man schnell an eine neue Rolle denken. Warum nicht einfach einen Safety Manager in den Prozess einbauen? Die Frage ist zwar berechtet, allerdings genauso schwierig. Die Rolle des Safety Manager hat (wie wir oben gesehen haben) Berührungspunkte mit allen anderen Rollen. Ich vergleiche das gerne mit dem Bild eines Projektmanagers. Diese Rolle geht in Scrum praktisch auf Product Owner, Scrum Master und Team über. Und so ähnlich würde ich den Safety Manager auch sehen.
Was generell bei Scrum und Safety beachtet werden muss!
Bei aller Euphorie muss bedacht werden, dass Safety keine optionalen Arbeitsprodukte darstellen. Es ist nicht möglich, Safety wegfallen zu lassen. Ein Produkt muss sicherheitsrelevant entwickelt werden. Wie wir oben gesehen haben, lassen sich einige Dinge aber sehr wohl vereinbaren. Und diese Vorteile können bei einer möglichen Integration von Scrum und Safety ausgekostet werden. Es kann mit Sicherheit diskutiert werden, zu welchem Release die Funktionale Sicherheit nachgewiesen werden muss. Allerdings handelt es sich hier nie um optionale Anforderungen, ein Team kann nicht entscheiden, dass diese Anforderungen nicht umgesetzt werden.
Safety sich selbst organisieren lassen?
Die Frage habe ich mir selber gestellt und fand sie spannend. Betrachten Sie einmal das Team in einem nicht Safety-Umfeld. Dort ist das Team für viele Dinge verantwortlich, die sonst ein Manager vorgibt. Diese Eigenverantwortung ist ein Schlüsselkriterium bei agilen Methoden wie Scrum. Es ist also legitim sich zu überlegen, ob das Team den Safety Gedanken nicht selber umsetzen kann.
Sie sind dran!
Haben Sie auch schon Erfahrungen mit Scrum und der ISO26262 gemacht? Ist es für Sie ein Widerspruch? Diskutieren Sie mit, auf Facebook oder hier auf der Webseite!
Weitere Informationen zu ISO 26262 und Agile
