In the first part of the blog, we have considered the principles of agile development and the functional safety development. Based on these principles, I want to debate possible areas of conflict in this blog, if you want develop agile in functional safety projects. As well, I want to give an idea about the opportunities that may arise from this innovative approach.

Essential conflicts of functional safety development goals and agile development goals:

The picture illustrates the fact, that about 80% of the required work in a functional safety projects was not in the focus of the people which defined the agile manifesto.
The consequence is that the following contradicting goals (principles):

The conflicts arise from the fact that functional safety development projects must fulfill aspects, where the people which defined the agile manifesto are classified as less important.
For reasons of accountability, in the case of the cases to the public prosecutor’s office, documentation and planning are to be met extensively. Verbal communication and coordination are insufficient in such a case. This means that the dynamic interaction and the extensive exchange between individuals can’t be, done as intended by the agile manifesto.
The same applies to the second point of the agile manifesto (working software is more important that comprehensive documentation). In functional safety projects, non-working software is not an option at all. But the documentation must still be done – for the above reasons.
In functional safety projects which do have a high safety integrity level it will also be a challenge, to proof and ensure in any case the independence between test and development, if cross-functional teams are used according to the agile philosophy.

Opportunities that may arise from a reasonable combination of agile development and functional safety:

Of course, there are also positive opportunities for the development of software, by using agile methods. This is especially true if pragmatic approaches are used, when the functional safety and the agile world are connected.
The main advantage is that an incredibly powerful and comprehensive transparency in the project is placed through the correct application of agile practices. If Scrum is used, daily status meetings and short planning cycles of 2 to 3 weeks (sprints) are done. In effective agile teams, also the communication in-between the team and between the team and the product owner is very intense. These points together result in:

• Technical problems will be detected almost immediately after their occurrence and communicated in the team.
• Additional efforts and the effects on the future project planning are detected very early, because of the short planning cycles (sprints)
• The product owner ensures, that the management will be continuously informed about all relevant issues

Additionally to the positive effects in the project management, the following benefits in the technical project work are achieved:

• Ambiguous Requirements are identified early; Open questions are answered in a shorter period of time
• General improvement of the technical content in the documentation
• Test engineers and development engineers are working together to achieve the joint goals.
• The quality of tests can be improved

Conclusion:

It is undeniably a challenge for companies and project managers to apply agile practices in functional safety projects. As with all things which are somewhat unusual or new, and do not necessarily correspond to the mainstream, there can be many opponents and sceptics. Therefore a decision to follow such a way is brave.
On the other hand, there are many very good reasons for the application of agile principles and methods in safety-critical projects. I called some of the main reasons in the previous section. If a project do have problems in these areas, the introduction of agile methods should be considered as an serious option.
Finally I want to say a word about the “V-model versus agile methods” discussion. Many functional safety standards more or less assumes the V model as a (the) process model. Agile methods are not mentioned so far in these standards. However, the agile methods are not in contradiction to the V-model. If agile methods are applied in an pragmatic way, they are supporting the V-Model development perfectly. The requirements of most functional safety standards can be adhered in this area fully, even if the project is carried out using agile methods. The key of success is the pro-active dealing with possible conflicts, as they were described, as well as the pragmatic usage of agility.

Are you ready for a functional safety workshop, to analyse improvement potentials in your development process, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.