Agile Software Development for Medical Devices 

Agile software development in general 

History 

The agile software development emerged as a kind of counter-movement to the trend,

• to demand more and more documents in the software development, 
• to limit the developers' freedom and to reduce their responsibilities to just a role (e.g. architect, tester, programmer, project manager), 
• to increasingly demand additional reviews, bureaucracy, controls and thereby to make the development process more and more heavyweight,
• to emphasis internal regulations instead of keeping the customer in the focus.

The Agile Manifesto 

The agile manifesto tries to overcome this trend, to find back to the original values and to adjust the priorities accordingly: 

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Another section in this article discusses this set of values in the context of software development for medical devices.

Agility and regulatory requirements

That's what the standard even explicitly expresses. But it also gives specific requirements, which we highlight below. 

Requirement 1: Documentation and verification of all activities

The IEC 62304 is clear: You have to document and to verify all activities:

• Specifying software requirements
• Designing software architecture and specifying the software units in the detailed design
• Programming the software units

Verification in agile software development

You can meet these requirements, by going through the following activities several times and iteratively:

• Document/revise the software requirements, traceability and the review
• Document/revise the software architecture, the traceability and the review 
• Document/revise the detailed design, the traceability and the review
• etc.

In practice, you mostly encounter one of the two approaches in medical devices:

Approach 1: Verification in each sprint 

The first (and compliant) approach includes the verification activities in every sprint. I.e. any changed artifact (e.g. SRS, architecture, code) will be reviewed prior to the next activity.

However, if your processes in particular the verification and approval steps are not very slim and streamlined, you have not reduced the documentation efforts, but multiplied it.

With delta-reviews and continuous revising documents you can minimize this issue. But that's the art of process excellence. Agile methods require highly trained protagonists and efficient approvals. 

Approach 2: "Quality Sprint" 

The second option is that you only document the above activities, including the reviews, after the last iteration. This is the approach that is frequently observed in practice in agile developing companies. But these companies have combined disadvantages:

• They do not comply with legal requirements as IEC 62304
• They continue still have to document - retrospectively 
• They do not benefit from documenting and reviewing: namely early detect and eliminate errors and thereby save time and money 
• The development team does not cooperate with the quality assurance team. Quality assurance is considered to be an annoying activity that delays progress and adds overhead

Thereby companies pervert the purpose of regulations. 

Requirement 2: No ad-hoc design decisions (software architecture)

The IEC 62304 is also pretty clear when it comes to software architecture: The standard prohibits ad-hoc design decisions. Of course, capable software architects can develop and revise a software architecture iteratively and document it in compliance with standards.

However: Developing a software architecture "upfront" is already difficult enough, and most companies fail defining a concise, weakly coupled, and maintainable architecture. Even more difficult it is to iteratively and incrementally develop and refactor a software architecture in an agile approach when new requirements may be added in any sprint.

Frequently documentation and code get out of sync, architectural depths increase and cause problems with software quality and maintainability in the long run.

"Grown historically" is the usual explanation of software architectures, when an auditor questions the quality of the documentation or/and of the software itself.

We have already mentioned two pitfalls in agile software development for medical products:

1. The document approvals are not done in a IEC 62304 compliant way or increase rather than decrease the overhead.
2. The software architecture is retrospectively or poorly developed and / or documented.

But there are more pitfalls that partially result from misconceptions.

a) Assessment of the Agile Manifesto

The values of the agile manifesto sound as reasonable as they are attractive. Let us analyze this set of values:

1. "Individuals and interactions are more important than processes and tools"

Undeniably, trusting teamwork, good communication and highly qualified employees are the prerequisite for successful software development.

The requirements of the standards such as the IEC 62304 or ISO 13485 for well-defined processes and the targeted selection, validation and documentation of employed tools neither can be discussed nor do they have a negative impact on achieving the goals of an agile development.

2. "Working software is more important than detailed documentation"

Many developers prefer to hear the second principle. Of course, working programs are essential. The hope of being able to reduce the documentation effort by agile software development, is mostly not met. On the contrary: The attempt of many companies, to develop in an agile way and in accordance with IEC 62304, often ends in the worst case: a particularly high proportion of documentation which is not conducive to the quality of the product. More on that later.

3. "The continuous cooperation with the customer is more important than the original terms of reference in contracts" and
4. "The courage and openness to change are above the following of a specified plan"

The most insidious trap is set by the last two points of the manifesto. Why does it require constant coordination with the customer? Why are regular changes necessary?

Misunderstanding of this set of values

I know the statements of the development departments very well such as "the customer has decided otherwise," or "the requirements have changed." But behind this there hides a downright tragic misunderstanding: User requirements never change in a given context of use. Rather, there is a deficit of identifying these usage requirements in a systematic, complete and correct way. And companies try to compensate for this deficit by creating a development process that can deal with these changes.

If the manufacturer were to only focus a fraction of the energy that they apply for conversion to agile processes, invest in a systematic requirement engineering and training of those responsible, they would produce new products faster, more reliably and more cost-effectively. For products that the customers actually really need.

Standards such as ISO 9241-210 (2010) will give you valuable information about how to collect user requirements systematically. By the way, you can achieve substantial compliance with the IEC 62366

Conclusion: Do not abuse the agility to compensate for the incompetence in the systematic collection of software requirements and stakeholder demands.

b) Iteration cycles for medical devices

It is desirable to develop, in an approximately one month cycle potentially shippable software, for example to reduce the complexity of the software development. However, it often makes no sense to actually bring  the new version of the medical device on the market in this cycle, because functional changes or improvements to the product, mean a new approval or conformance testing.

A new conformity assessment procedures and / or submission of the technical documentation with notified bodies or the FDA's many companies is too expensive. In addition, an FDA clearance can last 90 days. Therefore, most companies do not iterate over the complete development process.

c) Summary: Potential hazards of agile software development

Let us also summarise the potential (!) dangers and disadvantages of agile development :

1. If you do not explicitly define the documentation to be developed as part of the artifacts ("definition of done") and even do without an explicit and continuously updated architecture, you are not IEC 62304 compliant, thus you are contravening the law.
2. If you use the agility to adapt to the real "customer needs" "zoom-to-iterate", you waive an efficient development.
3. If you have no lightweight approvals but (want to) work in compliance with standards , you will slow down your development with agile approach in comparison with a conventional process model, because you have to pass a lot more verification steps.
4. If you only address the documentation at the end of the project ("QM Sprint") you not only violate the spirit of the standard IEC 62304 ("no ad-hoc design decisions"), but also brew united disadvantages of all process models: No conformity to standards, even though there is documentation effort, and no benefits that you would get by finding errors early or avoiding them from the very beginning. (Value should not only be in implementing but especially when constructing i.e. in documents!)

Next Article: Software Requirements