Agile Software Development for Medical Devices
Many medical device manufacturers are in favor of agile software development. However, they confuse SCRUM with a process model and are not fully aware or the implications even when working compliant with regulatory requirements.
Agile software development in general
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:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- 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
Most important things first!
It is possible to develop software agile and to comply with the requirements of IEC 62304.
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
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.
Define the first two levels of your architecture upfront. Keep the architecture and documentation concise and consistent at any sprint!
Agile Software Development for Medical Devices: The pitfalls
We have already mentioned two pitfalls in agile software development for medical products:
- The document approvals are not done in a IEC 62304 compliant way or increase rather than decrease the overhead.
- 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 :
- 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.
- If you use the agility to adapt to the real "customer needs" "zoom-to-iterate", you waive an efficient development.
- 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.
- 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!)
Recommendations for Agile Software Development for Medical Devices
We recommend you develop the (agile) software development as follows in order to develop your medical software quickly, professionally and IEC 62304 compliantly:
- Iteration Cycle 1: Do not iterate over the entire software development process in order to derive the real customer requirements (Type A). Instead, requirements engineering methods systematically and verify the identified stakeholder directly (Type B). By the way: This reflects the formative usability evaluation.
- Upfront architecture: Once you know these requirements, model the software architecture upfront, at least for the first two levels of building blocks. Do not describe any method of any class, because otherwise the effort to keep the model and software in sync is too high. The IEC 62304 does not require that, either.
- Iteration Cycle 2: If you are unsure whether the chosen architecture is suitable (e.g. with respect to performance), use vertical prototypes to get an answer. There is no need to involve the customers again. You must therefore iterate only over path C and not on the complete development process.
- Iteration Cycle 3: Take iteration type D to iteratively transform the (course) architecture into executable code and in order to reduce the complexity of software development (e.g. by time boxing).
- Test automation: Use the agile software development best practices: Write and automate the unit, integration and system testing as completely as possible an to build the entire build process (nightly).
- Documents release: Update, review and approve the documents (requirements, architecture) for every sprint as for any release. Lightweight document approvals are a prerequisite, to avoid any form of bureaucracy.
Agility for agility’s sake is nonsense. The values of the agile manifesto are not: Trusting cooperation, customer focus, mutual understanding, mental flexibility and effective communication. Live these values!
If you want to learn even more about how you can make your software development agile and compliant with the IEC 62304, then use our help:
- Seminar "Medical Software": Here we will discuss the developing processes and the agile procedures - also available as on-site seminar.
- Seminar "Requirements, Usability and IEC 62366": Here you learn how to systematically derive user requirements and to avoid unnecessary iterations.
- Personal advice: We like to support your team
- with a view from the outside to identify potential for improvement,
- to examine your process and be compliant with standards
- with practical tips to make development more effective and efficient.
Get in contact with us!