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.

Written by

Christoph Schmiedinger Christoph Schmiedinger Complex topics and challenging technologies? That's where Christoph Schmiedinger feels particularly at home. He supports automotive manufacturers and their suppliers in preparing their organizations for the challenges of the mobility revolution. As an experienced executive consultant and industrial engineer, he also provides hands-on support for the transformation from a traditional to an agile company. The native Austrian has been working with agile methods for over ten years. In particular, he has built up expertise in agile transformations and large scaled projects as well as in the agile further development of physical products and safety-critical systems. He has also developed digitization strategies for major banks in Germany and Austria. He shares his knowledge in trainings, as a speaker at conferences and in regular publications. Christoph Schmiedinger is the best proof that determination, openness and humor can be perfectly combined. He particularly enjoys working with people from different cultures. "Commitment" is one of the most important agile values for him, because he values the trust that is placed in him.

Team member profile


Leave a Reply

Your email address will not be published.