Agile methods in safety-critical projects

Before I joined borisgloger consulting, I worked for a software vendor that delivers solutions for safety-critical environments. While we initially tried to manage the development with traditional project management methods, we switched to more agile methods over time. During this time I also was constantly in contact with the Vienna Institute of Systems and Safety Engineering, in particular with Hans Tschürtz. Together we developed a procedure model that allows the usage of agile methods while ensuring compliance to safety standards.
Agile in safety-critical projects has become a more important topic today than five years ago, when we started developing our ideas. Agile is everywhere, especially in the automotive industry. Customers and users value innovative solutions while taking safety for granted. They even punish companies if there are only minor indications that safety is not assured – refer for example to the discussion about the driving assistance system of Tesla. Thus we need a development approach, that allows being innovative and flexible while ensuring upmost safety for potential users. In the following paragraphs I will discuss the key success factors of such an approach.

The Team

Cross-functional teams are most important in agile development. We need to have all the skills that are necessary for developing the product represented in the team. In safety-critical projects this requirement calls for the integration of a safety engineer in the development team. Further we should treat safety like quality – a value everyone in the team has to care about.

The Start

When starting a safety-critical project, we recommend an initial workshop phase, in which the whole development team plus experts analyzes the requirements, elaborates a first rough technical concept and performs a first safety analysis. Depending on the context and size of the project, this workshop may last from 2 to 10 days. We don’t believe that it is necessary to do months of analyzing and designing. To keep the workshop attendees focused we recommend to carry out the following workshop off-site.
The workshop itself is split in four parts:

  • Story Map (1st iteration)
    In the very first step we identify the major functionalities of the system/product. A helpful method for structuring this approach is story mapping. 
  • Technical Concept
    Based on the functionalities a rough technical concept can be derived. This includes for example architecture decisions, principles and/or programming languages.
  • Preliminary Hazard Identification
    The next step consists in identifying top level hazards. Functional Failure Analysis (FFA) based on the functionalities in the story map is a simple approach, but there are other valuable methods. In addition, this stage could be the right one for determining the safety integrity level.
  • Story Map (2nd iteration)
    In order to minimize the risks of the system/product safety, measures have to be identified based on the hazards identified one step earlier. These measures are integrated in the story map and thus complete the initial functional picture.

After elaborating those parts, the results lay the foundation for the development project, that can now start with its iterations.

Impact Assessment

During the iterations, every new user story has to be assessed if the new functionality has an impact on the current safety concept. Are the new hazards introduced? Do we need new safety measures? A first analysis can be already done during the backlog refinement meeting. The more cross-functional a team is, the easier the identification should be. If the user story has an impact, the team knows that at least some parts of the safety concept have to be updated in the iteration.

Definition of Done

To maintain an overview of what is necessary if the user story has an impact, you can make use of your Definition of Done. Just add all required tasks, for example an update of the Functional Failure Analysis or an update of the safety case. Of course, this checklist can be quite long for safety-critical projects, but that’s the constraint that such projects have to face.
I hope you got a little insight in how safety-critical projects can be tackled with agile methods. If you have any further questions, don’t hesitate to contact me.

Geschrieben von

Christoph Schmiedinger Christoph Schmiedinger Komplexe Themen und herausfordernde Technologien? Darin fühlt sich Christoph Schmiedinger besonders wohl. So entwickelt er u. a. Digitalisierungsstrategien für Großbanken in Deutschland und Österreich und begleitet hands-on den Wandel vom traditionellen zum agilen Unternehmen. Mit agilen Methoden arbeitet der gebürtige Österreicher seit beinahe zehn Jahren und hat dabei besondere Expertise in agilen Transitionen und skalierten Projekten sowie in der agilen Weiterentwicklung von ERP-Systemen und sicherheitskritischen Systemen aufgebaut. Sein Wissen dazu gibt er in Trainings und als Sprecher auf Konferenzen weiter. Christoph Schmiedinger ist der beste Beweis, dass sich Zielstrebigkeit, Offenheit und Humor bestens vereinen lassen. Besonders gerne arbeitet er mit Menschen aus verschiedenen Kulturen zusammen. „Commitment“ ist für ihn dabei einer der wichtigsten agilen Werte, weil er das Vertrauen schätzt, das in ihn gesetzt wird.



Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on pinterest
Share on print
Share on email