At first glance they are like oil (Agile lubricates development by reducing resistance) and water (FDA drowns you in processes and paperwork); they just don’t mix well at all!
Agile de-emphasizes documentation, controls and tools in favor of close interaction between individuals working on small pieces of functionality without the overhead of detailed processes and documentation.
The FDA requires companies, under their jurisdiction, to comply with a mountain of published regulations and guidelines that cover the processes and documentation needed to qualify a product for release.
The FDA regulations have a waterfall methodology feel to them that does not lend itself to today’s need to rapidly get new products to market. But, this is not necessarily the case. FDA regulations only specify that a process needs to be in place and that it is followed (Click here). Agile development processes using SCRUM, Sprints, or other approaches can be used provided:
- The process itself is documented
- The required documents can be produced
- Auditors can determine that the process was followed
The FDA regulations do not specify the process; it can be whatever works best in your own company. It can be very detailed or lightweight; as long as it produces what is needed to be compliant.
The challenge becomes creating a lightweight process with a semi-transparent framework that supports agile development. The process & framework needs to provide added value to the sprint teams. It shall not require them to engage in activities that impact their ability to complete their commitments for the sprint.
A semi-transparent framework can “hide” most of the FDA documentation and control requirements overhead from the sprint teams.
To enable the development organization to focus on producing product, the documents, audit records, etc required for submission to the FDA can be generated from the framework by a regulatory affairs/quality systems group that is not part of the software development organization.
Development and maintenance of the framework needs to be a partnership between the internal regulatory and development teams with primary ownership by regulatory.