Einige grundlegende agile Methoden werden im weiteren Text als bekannt vorausgesetzt. Die Erwähnung einiger agiler Artefakte, Praktiken und Zeremonien (z.B. DoD, Sprint/Release Demo, usw.) im weiteren Text ist exemplarisch zu verstehen und muss im jeweiligen Geschäftskontext interpretiert und angepasst werden, ganz nach dem agilen Grundprinzip: „Inspect & Adapt“!
Der im weiteren Text beschriebene agile Kontext bezieht sich ausschließlich auf die Anwendung im Bereich der Entwicklung von Kundenlösungen. Ein „agiles Unternehmen“ (basierend auf einem agilen Geschäftsmodell) ist ein anderer Kontext und wird nicht betrachtet!
Herausforderung und Chance
Die meisten, die sich mit agiler Produktentwicklung beschäftigen wollen, kennen Scrum, XP oder andere, team-zentrische und aus der Softwareentwicklung entstandene Vorgehensmodelle. Die Herausforderung für Unternehmen im Industrieumfeld, und im Besonderen in der Sicherheitstechnik, besteht in der notwendigen Skalierung und Anpassung dieser bekannten und meist einfach beschriebenen Modelle.
Skalierung kann aus verschiedenen Aspekten heraus notwendig sein:
Bevor ein Unternehmen jetzt mit einer skalierten Anwendung agiler Praktiken und Prinzipien zur Entwicklung physikalischer Systeme beginnt, sollten die obigen Aspekte einzelnen analysiert und im Vorfeld vereinfacht bzw. zusammengeführt werden. Meist wird dies zu Beginn einer unternehmensweiten Transition stattfinden, die auch nach agilen Praktiken geführt wird. Das heißt aber auch, dass eventuell angestrebte Vorteile erst später spürbar sind und auch anfänglich mehr Probleme sichtbar werden, um die sich dann jeweils fokussiert gekümmert werden muss. Je nach Ansatz der Skalierung, der Unternehmensgröße und Problemlösungsgeschwindigkeit kann das mehrere Monate, ggfs. Jahre dauern. Aber das ist bereits ein Teil der neuen agilen Arbeitsweise des Unternehmens und sollte kontinuierlich weitergeführt werden.
In dem stark durch Normen, Standards und Richtlinien eingeschränkten Bereich der Sicherheitstechnik ist das Manifest für Agile Softwareentwicklung und die weiterführenden Prinzipien schwierig zu interpretieren bzw. zu bewerten. Siehe https://agilemanifesto.org/iso/de/manifesto.html
Was generell zu beachten bleibt, ist die Intentionen hinter den Prinzipien zu verfolgen und das passende agile Vorgehen mit Augenmaß daraus selber zu entwickeln, bzw. sich an am Markt befindlichen Skalierungsframeworks zu orientieren, welche die Problematik der normengerechten Entwicklung bereits beinhalten.
Die Verantwortung für jeweils notwendige Anpassungen bleibt natürlich ausschließlich bei dem agilentwickelnden Unternehmen. Diese kann weder auf Standard-Frameworks, noch auf externe Berater übertragen werden. Daher ist es wichtig, dass Vertreter jedes Unternehmensbereiches, hier im Besonderen der Zulassungsabteilung und jeder Führungsebene, im agilen Leitungsteam vorhanden sind.
Grundsätzlich gelten in agilen Vorgehensweisen die gleichen hohen Ansprüche an die Produkterstellung (wie z.B. hohe technische Kompetenz, robuste Verifikation und Integration, usw.), wie auch in traditionellen Vorgehensweisen im industriellen Bereich, wohl aber mit Unterschieden in der Planung und Ausführung, als auch in der Art der Einbindung von entsprechenden Fachkompetenzen, -abteilungen oder -partnern.
Die Product Owner in einem skalierten agilen Entwicklungsbereich müssen auch hinreichende Kenntnis über die relevanten Normen, Standards und Richtlinien haben, die für ihr jeweiliges Produkt (-portfolio) wichtig sind. Ihnen obliegt die Entscheidung mit welcher Zielsetzung gerade vom Backlog gearbeitet wird und somit welche sicherheitsrelevanten Produkt- und Systemaspekte, wie in die aktuelle Planung mit einfließen müssen. Meist werden sie dabei durch Sicherheits- und Normenexperten unterstützt bzw. holen sich deren Expertise ein, um das Backlog nach entsprechenden Prioritäten sortieren zu können.
Die im Gegenzug zu traditionellen Vorgehensmodellen höher frequente Lieferung von funktionalen Erweiterungen erlaubt in kleinerem und damit schnellerem Masse die Prüfung auch von sicherheitsrelevanten (Teil-)Aspekten. Hier mit dem Unterschied, dass auch meist andere spezielle Testexperten und -umgebungen gebraucht und kontinuierlich mit eingebunden sein müssen.
Die Aufstellung für das regelmäßige und vollständige systemweite Blackbox-Testen nach offiziellen Standards und Richtlinien stellt eine komplexe Aufgabe an das agile Leitungsteam, die es nur mit Hilfe aller am Entstehungs- und Lieferprozess Beteiligten lösen kann. Auch in diesem Bereich des Testens sollte versucht werden, so viel wie möglich über Testautomatisierung abzudecken. Um dies erreichen zu können, müssen Tester entsprechend geschult sein und sowohl Expertenwissen in der jeweiligen Industriedomäne haben, als auch die richtigen Automatisierungspraktiken und -werkzeuge beherrschen.
Die enge Zusammenarbeit mit externen Zulassungsbehörden und -instituten ist dringend empfohlen, um eine erfolgreiche agile Entwicklung von sicherheitstechnischen Anlagen problemfreier aufstellen zu können.
Auch im Bereich der industriellen Sicherheitstechnik können agile Vorgehensweisen ihre Stärken ausspielen, aber da Zykluszeiten, externe Einschränkungen und spezielle Zielmärkte anderen Gegebenheiten unterliegen als „Consumer“-Produkte ist hier besondere Sorgfalt geboten, wenn man als Unternehmen Agilität in die Entwicklung von Kundenlösungen bringen möchte.
Der zu kleine Fokus beim Start einer Transition, auf z.B. nur die reine Entwicklungsabteilung, schlägt meistens aus Unternehmenssicht fehl oder erzeugt bestenfalls nur marginale Verbesserungen. Schon nur eine Pilotierung von neuen Vorgehensweisen sollte immer alle Entscheidungsebenen mit einbeziehen und deren Eingaben berücksichtigen, um später keine großen Probleme mit Akzeptanz und Durchführbarkeit im ganzen Unternehmen zu bekommen.
Wichtig ist das Zusammenbringen aller notwendigen Funktionen und deren Einwilligung, dass die Umstellung zu agileren Vorgehensweisen nur ein gemeinsamer Weg sein kann. Systemdenken und der Stand der heutigen Prozesse im Unternehmen sollten den Startpunkt definieren, von dem aus gemeinsam das Vorgehen kontinuierlich entwickelt und weiter angepasst wird.