Agil in stark regulierten Bereichen - Wie soll das gehen?
Vor gut zehn Jahren wurde ich erstmals Product Owner im sicherheitskritischen Bereich - seither beschäftige ich mich mit der Anwendung agiler Arbeitsweisen. Mittlerweile habe ich viele Teams bei der sicherheitskritischen Entwicklung begleitet und bin ich selbst erstaunt darüber, mit welcher Unbeschwertheit – um nicht zu sagen Naivität – ich damals mit meinen ersten Entwicklungsteams auf Scrum umstellte.
Ein Trend und ein Schmerz
In den Jahren 2011 bis 2014 entwickelte ich für ein österreichisches High-Tech Unternehmen Aufzeichnungssysteme (bestehend aus Software- und Hardwarekomponenten) für eine wichtige Kommunikation in sicherheitskritischen Bereichen. Unsere Kunden waren hauptsächlich aus der Flugsicherung und aus Einsatzleitzentralen, wo die Aufzeichnung von Kommunikation für einen späteren Zeitraum ein sicherheitskritisches Feature ist.
Erstmals wandten wir uns in diesem konservativen Bereich den doch eher neuartigen agilen Methoden zu, weil der Anteil von Software in unserem Produkt zunehmend größer wurde. Dazu kam ein Schmerz: Die Jahresplanungen waren meist bereits im Januar obsolet, weil wir überraschend große Kundenprojekte gewonnen hatten oder ein Kunde erst nachträglich den ein oder anderen Wunsch feststellte.
Die ersten euphorischen Schritte mit Scrum
So fingen wir der Reihe nach an, Elemente des agilen Arbeitens einzuführen. Zuerst Daily Stand-ups, dann User Storys, anschließend gingen wir dazu über, in Iterationen zu planen und zu liefern. Nach einigen Monaten des Experimentierens kamen wir an den Punkt, an dem wir uns fragten, ob wir nicht komplett nach Scrum arbeiten wollten. Gesagt getan, fortan war ich Product Owner von zwei Entwicklungsteams. Heute wäre der Aufschrei bei einem sicherheitskritischen Team wahrscheinlich größer. Wenn ich ehrlich bin, war damals den wenigsten in diesem Umfeld bewusst, was agile Entwicklung wirklich ist. Also ließ uns das Management mehr oder weniger allein entscheiden, wie wir die Entwicklungsmethodik gestalten wollten.
So stellten wir Sicherheits- und Qualitätsstandards sicher:
Selbstverständlich wussten wir, dass wir auf Grund von Normen (hauptsächlich aus der Functional Safety) verschiedenste Analysen und Dokumentationsarbeit leisten mussten. Gemeinsam mit unserem Safety- und Quality-Manager:innen erarbeiteten wir so über die Monate einen eigenen Entwicklungsprozess, der es uns ermöglichte, agil zu arbeiten und trotzdem ein normenkonformes Produkt zu entwickeln. Im Wesentlichen einigten wir uns auf diese zwei Punkte:
- Eine umfangreiche Definition of Done, mit der wir sicherstellten, dass wir sämtliche Analysen (hauptsächlich Risk- und Hazard-Analysen) und Dokumentationen (Safety Case, Requirements Specification, Design Documents etc.) stetig – User Story für User Story – aktuell hielten.
- Ein versetztes agiles Arbeitsmodell, in dem einerseits die jeweils kommende Iteration etwas genauer vorbereitet wurde. Zum Beispiel, in dem bereits erste Analysen stattfanden, in denen evaluiert wurde, ob eine User Story eine Auswirkung auf den Safety Case hatte. Und andererseits, in dem nach Abschluss der Entwicklungsarbeit in einer Iteration die Lieferung in der Iteration danach von Safety- und Quality-Seite noch mal genauer unter die Lupe genommen wurde (wir haben sehr wohl das Inkrement im Team durch einen Tester getestet, lediglich die Independent Validation fand nach der Iteration statt).
Was ich heute besser weiß als damals:
Unseren damaligen Entwicklungsprozess und den Nachweis der Normen-Compliance habe ich 2013 im Rahmen meiner Masterarbeit verarbeitet. Diese findet ihr zum kostenfreien Download hier unten verlinkt. Heute, nach mehr als acht Jahren Beratungserfahrung, würde ich die ein oder andere Änderung vornehmen. Ich würde beispielsweise die Arbeiten vor und nach der Iteration, in der entwickelt wird, noch schlanker halten.
Heute bin ich vor allem in der Entwicklung im Automotive-Bereich unterwegs und stelle fest: Die Herausforderungen sind ähnlich wie damals für uns. Auch hier geht es im Kern um die Frage, wie wir Produkte nach Normen der funktionalen Sicherheit (ISO26262) oder Prozessreife (A-SPICE) agil entwickeln können. Die gute Nachricht: Es geht!
Es ist natürlich komplizierter als eine simple – und nicht sicherheitskritische – App zu entwickeln. Dennoch sind es oft nur Schauergeschichten, die einen von der Anwendung neuartiger Arbeitsweisen abschrecken. Normen sind in der Regel gar nicht so „böse“ wie ihr Ruf.
Auch haben viele Unternehmen einen PEP (Produktentstehungsprozess) im Einsatz, der oft viel strenger als die zu Grunde liegenden Normen ist. Das liegt daran, dass über die Jahre immer wieder ergänzt wurde, um einmal geschehene Fehler zukünftig zu verhindern. So wird der PEP ein überbordendes Monster, welches die Innovationsfähigkeit und Schnelligkeit in der Entwicklung hemmt oder sogar gänzlich verhindert.
Mein Tipp: Traut euch!
Daher mein Aufruf: Traut euch, anders zu arbeiten, auch wenn ihr ein Normenkorsett erfüllen müsst. Es lohnt sich auch in diesen Setups. Schnappt euch Expert:innen für Normen, Qualität und Sicherheit, Agilität und diskutiert offen, wie ihr über eine agile Arbeitsweise Normenkonformität sicherstellen könnt. Wenn ihr Unterstützung dazu braucht, sprecht mich gerne an.
Bildquelle: Photo by Paul Hanaoka unsplash.com
.svg)
