Agile Compliance - Agile Software Development explained for RAQA

As a QA/RA manager who knows IEC 62304 and related standards you expect software engineers to implement the software according to a V-MODEL. The standard clearly identifies the different phases of the software development process as well as the need for reviews and development phases which need to be established.

Regulatory view on software development

However modern software development is no longer based on a hierarchical model where you work top down according to a very detailed plan. The reason for this is that software became so complex that it is impossible to plan and specify everything upfront. As a matter of fact the only complete specification of a software is the code itself.

The idea of the agile software development is based on 4 principles states in the Agile Manifesto:

Individuals and interactions over processes and tools, meaning in agile we want people and teams to be accountable, responsible, innovative, creative, problem solving, original, learning and being rewarded for adding value. Process and Tools should aid not limit.

Working software over comprehensive documentation. Ok, that sounds scary, but is not a reason not to do documentation. To see how this potential conflict can be overcome, wait for the next article of this series, Part 3 - Bridging the Process Gap between Agile and Regulation in Medical Devices.

Customer collaboration over contract negotiation.This essentially says there should be lots of validation. 

Responding to change over following a plan. This means that the software development process needs to be reviewed and improved, which totally fits the idea of continuous improvement of the quality system.

Now you might be asking how can good working software be developed without upfront planning? 

First of all there is upfront planning, but the plan on what needs to be developed and how it needs to be done, is kept to a minimum to cover the foreseeable future. One of the reasons to switch to agile development is to improve the predictability if something can be done and how long it will take. Knowing how long it will take to develop a software upfront is basically impossible as the specifications are the final product. The agile process approaches this by starting with a coarse design and estimation of the duration. Afterwards the project managers will identify the most critical software requirements (critical means for example - the core algorithms, is it possible to make it work at all, can we get to the performance we need, how can the interaction with the user be done efficiently, etc.). Then these critical requirements are implemented, tested and validated. Once this is done the work which was done is reviewed, were the estimations correct, was the goal achieved, can the development process be improved. Once this is done the process starts again, the next most critical features are planned and executed. However this time the estimations and processes will be better, as the most difficult stuff is already done.

Example of an agile process

This agile process can be more or less strict, e.g. the length of one cycle can be limited to a certain time like 2 weeks or a month to be sure to catch problems early and to be able to react and fix those on a global level.

The one big risk with the agile process is that you don’t look back at previous iterations. So a new iteration could change anything you did before, which means that the related verification and validation you did before becomes irrelevant. To solve that problem on a technical level agile processes work a lot with automated testing. In each development cycle you need to ensure that there are automatic tests for new functionality and the ones for previously developed functionally still work or that there is a valid reason why they don’t, in which case the tests need to be fixed