Re: [SystemSafety] Agile methods

From: René Senden < >
Date: Mon, 2 Sep 2013 17:32:51 +0200


You are right about my initial question being somewhat polarizing, perhaps because I tacitly assumed that anyone who’d answer this question with “Yes”, would also include some

of the corresponding experiences … Regarding experience with reconciliation of agile environments with typical/common/… (software) safety standards, I am very interested in the

development processes and corresponding results/evidence/outputs, all this should be auditable. Is it (at all) possible to harmonize these very different worlds, or would any such

attempt result in compromising either? Transparency, auditability, documentation, and safety specific processes such as analyses are examples that, to me, seem to be particularly

difficult to address in an agile environment, let’s take “scrum” as an example of a popular agile approach.  


From: systemsafety-bounces_at_xxxxxx [mailto:systemsafety-bounces_at_xxxxxx Mencke
Sent: maandag 2 september 2013 14:39
To: Jon Davies
Cc: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Agile methods  


I have come across a situation in the railway field where an organization was required by the customer to comply with a safety standard which has specific requirements on the software development process, in this case, EN 50128, where this was previously not required.

It seems to me that this type of situation typically arises in industries/products where the SIL concept has traditionally not been applied, or is being introduced. The customer creates a “SIL requirement” as a type of marketing argument, where the SIL is understood by the customer as applying to equipment rather than to a function (in order to be able to state “This equipment is SIL X” in commercial scenarios).

Regarding your question, “Have you encountered a situation, in industrial practice, in which an organization developing software following an agile methodology has to comply with a safety standard which has specific requirements on the software development process?”

This is a polar question, which can only be answered with a yes/no.

If you are interested in practical experience, it might be useful to add to this question which aspect(s) of such a situation you are interested in. For example, if the answer is “yes”, was the project actually a success? Which measures/procedures were implemented in the company to approach this problem and reconcile the development process with such requirements?, etc.

Depending on the type of information you are seeking, it may not be possible to provide particular details regarding such a state of affairs, as this information may be company-specific.



2013/9/2 Jon Davies <jdavies_at_xxxxxx

On 30 August 2013 18:02, René Senden <rene.senden_at_xxxxxx
> Dear all,

> Do any of you have practical experience with reconciling established agile
> software development with software safety requirements (e.g. IEC-61508 or
> DO-178..) ?

Yes, and we usually end up throwing away the software developed using "agile" methods, and starting again properly.

I'm taking "agile software development" as meaning the development of software using processes consistent with the agile manifesto: - to quote the relevant part: "...we value... working software over comprehensive documentation"

this is fundamentally in conflict with many of the things we know about building high integrity software, and so "agile" methods are fundamentally in conflict with developing software for safety critical systems.

There's plenty to learn from agile development methods that might be useful in high integrity software development, but that's a whole different discussion. Every time we discuss agile development here, we end up back at the need to use a development process that builds in correctness - we can't test exhaustively, so we need a process that builds integrity in. Agile methods don't do this.


The System Safety Mailing List

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Tue Sep 03 2013 - 09:34:31 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST