Agile in Sicherheitstechnik

Hinweis

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

Skalierung agiler Prinzipien und Vorgehensweisen

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:

  • Die angestrebte Kundenlösung ist wahrscheinlich technisch sehr groß und/oder extrem verteilt.
  • Das gesamte zur Entstehung, Produktion und Lieferung beitragende Personal ist extrem spezialisiert und/oder organisatorisch verteilt Die geschäftliche Entscheidungsebene ist organisatorisch verteilt.
  • Alle oben genannten Punkte unterliegen auch einer weiten geographischen Verteilung.

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.

 

Agiles Vorgehen im normen-regulierten Produkt- und Systementwicklungsumfeld

 

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

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
    Die enge Zusammenarbeit mit Behörden - Zulassungsinstituten oder vergleichbaren Einrichtungen - sollte gesucht und kontinuierlich gepflegt werden, um gemeinsam Änderungen an den bisherigen Arbeits- und Kommunikationsweisen vornehmen zu können. Bestehen hier konkrete Vorgaben von zu verwendenden Prozessen, Vorgehensweisen und Methoden sind diese so schlank und konfliktfrei wie möglich in die neue agile Arbeitsweise zu integrieren. Diese Art von „Prozessanforderungen“ können meist gut in die Definition-of-Done (DoD) auf Komponenten-, Produkt- und Systemebene eingebaut werden. Das Gleiche gilt auch für evtl. verpflichtend zu nutzende Werkzeuge, die ein Teil der Vorgaben sein können.
  • Funktionierende Software mehr als umfassende Dokumentation
    Durch die konsequente Einbindung von Vertretern der Zulassungsinstitute in Demonstrationen einzelner Produkt- und integrierter Systeminkremente bekommt das Unternehmen schon frühzeitig Rückmeldung, ob, und wenn was, konkret noch nicht den normativen Erwartungen entspricht und noch weiterentwickelt werden muss. Gegebenenfalls werden hier auch bisher nicht transparente Erwartungen aufgedeckt, wie z.B. Test- und Prüfschnittstellen, usw. Dies sollte auch die geforderte Dokumentation in Inhalt, sowie Art und Weise abdecken. Hier ist die Zulassungsdokumentation als Produktinhalt zu verstehen und ist nicht vernachlässigbar. Wie auch schon für den obigen Punkt, lässt sich dies gut in die jeweilige DoD integrieren.
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
    Die Abgabe eines neuen Produkts (oder einer großen Änderung an einem Bestandsprodukt) zur Prüfung an ein Zulassungsinstitut (hier jetzt „Kunde“) ist immer durch ein vertraglich abgesichertes Umfeld bestimmt. Wie flexibel dies zu gestalten ist, wird durch die beteiligten Parteien abgestimmt. Während der Ausführung ist gemeinsam zu lernen, was angepasst werden muss. 
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans
    Die zum agilen Arbeiten notwendige Flexibilität (und deren möglichen Einschränkungen) muss bereits während der ersten Abstimmung mit den Zulassungsinstitutionen zur Sprache kommen und vertraglich festgehalten werden. Wichtig ist hier der stetige Austausch zwischen den beteiligten Partnern während der Entwicklungs- und Zulassungsphasen, um Überraschungen auf beiden Seiten zu vermeiden.

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.

 

Aspekte der Sicherheitstechnik in agilen Vorgehensweisen

 

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.

 

Fazit: Agile ist kein Allheilmittel und Anpassung ist immer notwendig!

 

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.

Zurück