Regulatory background
Firstly let's explore the train of thought of creators of medical software regulations. They recognized that a bug in medical software could lead to a patient's severe injury or even death - fact! Therefore they are determined to prevent this by any means. To achieve this, they regulated the development of medical devices, implemented processes to prevent defects, thoroughly documented everything, and conducted extensive reviews.
This has led to a very strict and cautious environment that is reluctant to change. However, this approach was established long before the concept of agile development and when medical devices had very little to do with software. Today some medical products consist entirely of software (known as SaMD) and run on remote generic platforms without in-house hardware. Changes on those platforms can happen even a hundred times a day to maintain robustness and cybersecurity.
The fact that the International Electrotechnical Commission (and not some Software Commission) has standardized the #1 process standard for medical software development IEC62304 suggests that approaches were firstly written for firmware and embedded software where agile is less present.
Agile background
On the contrary, the train of thought of creators of Agile started with experiencing most software projects' late delivery as most of the functionality testing and integration work was done only at the end. Therefore every release was very stressful and every small change after the release required a lot of overhead work. Customers were making change requests late into the project too. These were facts that they wanted to change by all means.
Therefore different frameworks and practices* emerged out of the Agile movement that gave a fresh approach - SCRUM, Kanban, eXtreme Programming (XP), DevOps, and Test-Driven Development to name a few. They decided to limit work in process and make all work visible, automate testing, integration, and deployment to reduce lead time, make code potentially shippable every few weeks, and release to production as frequently as possible. This resulted in a dynamic environment, prepared for regular changes, which are inevitable in modern complex or innovative software projects.
A quick conclusion would be regulatory and agile parties would be at each other’s throats and in fact early publications stated that "Agile is clearly not appropriate for safety-critical applications". Does this mean medical and health software development must keep being stressful, tardy, and late in delivery?
Misinterpretation of the Agile Manifesto
To answer this we need to find if the regulatory world made a misconception in interpreting Agile manifesto value statements. In my opinion, they did and it originates in the brain's tendency to categorize everything, see things in black and white, and fear change. Our brain consumes more energy to make conclusions in the spectrum and there is a big spectrum of what people call Agile.
“The Agile Manifesto does value things on the right side of value statements but values the things on the left side more.”
Since the term "over" in value statements does not imply "instead of" as a mentioned tendency of our brain would wrongly conclude. However, practices like "cowboy coding" tend to disregard things on the right side, which has caused significant harm by associating them with Agile. As a result, the adoption of Disciplined Agile in regulated industries such as medicine has been slowed down. Additionally, one of the key values of Agile is to adapt to the environment in which it is used, so it won't simply overlook regulatory demands.
However, Agile tends to optimize, streamline, and automate (regOps movement) its approach to compliance to deliver more value to the product elsewhere with the same amount of resources.
Getting to alignment
“Let’s start with a bold statement that agile and regulatory perspectives align well on a higher level and see if we can prove it.”
To start with low-hanging fruit, both worlds value the developed software's quality, even though they may have different approaches to achieving it. Medical regulatory highest values are safety and performance.
But aren’t those the priority of the medical software customers? Therefore Agile’s highest focus on meeting the customer needs is covering that. On the other hand, agile places great emphasis on productivity and predictability. Medical software companies’ management certainly values those as they cannot afford to be only compliant, but have low productivity and be constantly late with delivery.
Therefore I believe the key is to find deficiencies and blind spots in the processes to improve productivity and predictability without compromising on quality and its evidence.
What's next
To address the posed question it is unlikely that the regulatory industry will incorporate Agile practices into its regulations and standards by itself. However, companies refusing the adoption of Agile methodologies will likely lose their competitiveness to more adaptable competitors.
When a critical mass of Agile medical software companies provides at least the same level of quality in a shorter period, standards as “industry best practice” will probably need an update to be more directly applicable to Agile. The good news is that while I am writing this article a group of regulatory professionals is meeting and intensely collaborating to make the second edition of the IEC62304 standard.
“While I am writing this article a group of regulatory professionals is meeting and intensely collaborating to make the second edition of the IEC62304 standard.”
From what I have heard from auditors for this tipping point to happen most of the Agile world will have to improve in providing clearer outputs, objective evidence, and traceability that would more objectively prove that their product is safe and effective. But I argue that providing this is certainly possible.
Suppose you agree with these arguments and want to improve your company's agility within a regulated environment or company’s compliance if you come from an agile world. In that case, we will share more in-depth information in the next blog post by analyzing each Agile value statement separately to pinpoint areas that either side can improve.
*If you are new to the Agile world and want to learn more about the reasoning behind the Agile culture, I recommend reading the book: The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. Through a very exciting plot, a first-person character who is the IT department lead tells a story of how painful it is to work on big and old-fashioned waterfall software projects. And how he discovered agile principles through mentorship.
This article is inspired by AAMI TIR45:2023 and author’s knowledge about medical software development.
