FDA Endorses Agile: What Does that Mean?

In January of 2013, the wishes of Agile fans writing software for medical devices finally came true—FDA added AAMI TIR45:2012, “Guidance on the use of Agile practices in the development of medical device software” to its list of approved standards. What does this FDA endorsement mean? Agile has been widely adopted by software development organizations to improve the quality of software, rapidly develop and deliver working software, and minimize risk by implementing sliced software requirements as they evolve.

Process-overburdened software professionals welcomed the Agile manifesto, which represented a radical change to development methodologies, but process purists were cautious in accepting it. The question of how much process is enough kept haunting professionals, especially since compliance to regulatory requirements is critical aspect of the medical device business. FDA requirements and other compliance standards (e.g. 21 CFR Part 820, ISO 13485, ISO 14971 and IEC 62304) have been stringent and these did not necessarily map directly to the Agile manifesto or the commonly adopted practices of Agile methodology. Unlike CMMI Development Ver. 1.3, existing standards didn’t provide any guidance on interpretation of Agile practices either. Moreover, although such mapping was attempted by professionals, it lacked recognition of relevant industry authorities. This definitely constrained organizations in the healthcare and medical device industry.

The Association for the Advancement of Medical Instrumentation (AAMI) has published Technical Information Report (TIR) 45 in mid-2012 for using Agile in the development of medical device software.

AAMI TIR45:2012 provides a holistic approach to address Agile’s role in the development of medical device software. It delves into finding synergies and provides guidance on aligning Agile with IEC 62304 at both the concept and practices level. The guidance covers several key topics such as documentation, evolutionary design and architecture, traceability, verification and validation, managing changes and “done” criteria. the document has become a must-have reference document for every professional implementing Agile to develop medical devices software. It focuses on providing the following:

  • Clarity and direction to map Agile practices to regulatory requirements.
  • Assurance that the Agile methodology can be aligned and used to develop software for medical devices according to compliance requirements.

FDA’s endorsement of Agile is the first step in accelerating institutionalization of rapid software development in the medical devices industry. Now that FDA has recognized Agile, writing software using the methodology should become easier.

What Next?

Suggestions for incorporating Agile in medical device software development include the following:

  1. Review AAMI: TIR45 report and develop a strategy to adapt Agile methodology. The strategy should help decision making during further implementation, if a ‘to be or not to be’ kind of situation arises.
  2. Map Agile practices to compliance and regulatory requirements and visa-versa (i.e. bidirectional traceability) as applicable to your industry.
  3. Address the gaps observed—if any, as a part of your mapping exercise.
  4. Ensure through an independent review that documentation and record control needs are fulfilled.
  5. Maintain this mapping under document control and keep it up-to-date. This mapping document will serve an important purpose: setting the right context and perspective during the audits by external agencies, which is undoubtedly an influential measure.
  6. Review suitability of Agile practices to existing or upcoming software development programs. Know reasons behind unsuccessful scrum implementation and address them suitably.
  7. Institutionalize the Agile methodology in a planned and systematic way.

Anand Paropkari is head of corporate quality, part of delivery excellence at Persistent Systems. He has more than 20 years of rich experience in process institutionalization. He is actively involved in coaching, training, adapting and improving Agile practices at Persistent Systems. He can be reached at 

500 characters remaining