AGILE practices in the development of medical device software

The TIR describes that agile principles and development have become an accepted method for developing complex systems and software products. Also, that there have been questions and discussions from both manufacturers and regulators as to whether (or which) agile practices are appropriate to develop medical device software. As enough medical device manufacturers have implemented agile practices in their software development to answer such questions; the answers have been documented in this TIR. It documents guidance of which practices have been found appropriate and useful; serving developers of medical device software. This TIR provides recommendations for complying with international standards and U.S. Food and Drug Administration (FDA) guidance documents when using agile practices to develop medical device software.

We were happily surprised to find people from the industry (authors of the TIR) sharing our understanding, that agile and regulated perspectives share the same goals of quality and the satisfaction of customers. As the TIR points out, agile and regulated perspectives have differences in emphasis on development productivity and predictability, but this does not make them incompatible.

This recommends TIR also discusses the values of the agile manifesto, e.g. ‘Individuals and interactions over process and tools’ and concludes with recommendations on how to fulfill such values in regulated environments. Another good example which we liked very much is the chapter about ‘Customer collaboration over contract negotiation’. As described, it is key in agile to recognize that collaboration with an engaged customer in the development process is more likely to deliver software that meets the customer’s needs then based on contracts. Consistent with an incremental/evolutionary lifecycle, the emphasis on customer collaboration means also that software’s definition will evolve over time. The paper describes that it is normal and good practice, that some high-level definition will exist to varying degrees before the development begins, but most of the detailed definition and even some high-level definition will emerge as the development work proceeds. As recognized in the TIR, this might be uncomfortable for manufacturers and regulators who are more familiar with “big upfront definitions” models in which definition work is more complete before software development begins. The TIR concludes, that it is important for the development teams to explain how the definition will emerge and how that definition emerges in a controlled way. Such considerations are also reflected in Applied SAFe and we recommend to work with ‘Skeleton Requirements’ and different processes of contracting with suppliers, depending on the working model of the supplier, e.g. agile or traditional contracting.

Another must read is section 5, ‘Aligning on concepts’. This section talks about alignment, customization, and adoption of lifecycles, it provides recommendations on how to align agile and regulatory perspectives in a supportive manner; something that we also have implemented in Applied SAFe.

PEDCO strongly recommends this paper if you are interested in an unbiased view on agile and to truly establish scaled agility in a medical device development environment.

• You can read a preview of the TIR45
  http://my.aami.org/aamiresources/previewfiles/TIR45_1208_PREVIEW.PDF
• FDA recognition statement:
  https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfstandards/detail.cfm?standard__identification_no=30575
• Purchase TIR45 (PEDCO has no connection or interest on selling this paper)

This TIR provides perspectives on the application of AGILE during medical device software development. It relates them to the following existing standards, regulations, and guidance:

• ISO 13485:2003, Quality management systems ─ Requirements for regulatory purposes
• IEC 62304, Medical device software – Software lifecycle processes
• ISO 14971:2007, Medical devices ─ Application of risk management to medical devices
• FDA Code of Federal Regulations (CFR), Title 21, Part 820.30, Quality System Regulation: Design Controls–
• FDA Guidance for the content of premarket submissions for software contained in medical devices
• FDA General principles of software validation; Final guidance for industry and FDA staff

Why read this TIR?

(excerpt from AAMI TIR45:2012)

AGILE was developed in response to quality and efficiency concerns posed by existing methods of software development. It can bring benefits that are valuable to the medical device software world, including the following:

• Continuous focus on safety, risk management, and delivering customer value through BACKLOG prioritization, planning practices, and customer feedback
• Continuous assessment of quality through continuous integration and testing
• Continuous improvement of the software development process through RETROSPECTIVEs and team accountability
• Continuous focus on “getting to DONE” and satisfying quality management stakeholders through the regular completion of activities and deliverables

AGILE can bring value to medical device software.

There are concerns about AGILE’s compatibility with the regulated world of medical device software development. For example, the AGILE Manifesto has value statements that seem contrary to the values of a quality management system; and because AGILE initially grew from the information-technology space where human safety and risk management were not of primary importance, there is concern that AGILE lacks the proper controls for producing safety-critical software.

Fortunately, AGILE‘s fundamental nature is to be adaptable to the context in which it is applied, allowing for AGILE principles and practices to be applied in ways that are compatible with the needs of the safety-critical, medical device software world.

AGILE can be adapted to the unique needs of medical device software.

This TIR will examine AGILE‘s goals, values, principles, and practices, and provide guidance on how to apply AGILE to medical device software development. It will

• provide motivation for the use of AGILE;
• clarify misconceptions about the suitability of AGILE; and
• provide direction on the application of AGILE to meet quality system requirements.

Following the guidance provided by this TIR can help medical device software manufacturers obtain the benefits provided by AGILE and satisfy regulatory requirements and expectations.

Initial recommendations

This TIR provides recommendations for ways to effectively apply AGILE to medical device software. Here are some of the initial recommendations that are explained further later.

AGILE is driven by the value statements written in the Manifesto for AGILE Software Development. These value statements can seem to be contradictory to the values of the regulated world of medical device software, but they need not be interpreted that way. Instead, they can be aligned to enhance the effectiveness of the quality management system.

Apply the values of AGILE in a way that enhances a robust quality management system.

AGILE emphasizes the need for the team to own its practices, inspect them, adapt them, and optimize them to their context. Regulatory requirements emphasize the need to establish a robust quality management system. Within the context of an established quality management system, AGILE practices can be applied without disrupting the quality system and without raising undue concern among regulators.

Apply the practices of AGILE within the context of an established quality management system.

AGILE embraces a highly INCREMENTAL/EVOLUTIONARY lifecycle for software development. Although regulations and standards do not mandate a particular lifecycle model if stakeholders have expectations for linear lifecycle models, an INCREMENTAL/EVOLUTIONARY lifecycle might bring challenges.

Set the correct expectations by defining the SOFTWARE DEVELOPMENT LIFECYCLE MODEL.
Demonstrate how an INCREMENTAL/EVOLUTIONARY lifecycle satisfies regulatory requirements.

As part of its INCREMENTAL/EVOLUTIONARY lifecycle, AGILE emphasizes the ability to respond quickly to change. Because rapid change can increase risks to product quality, effective change management systems are essential to align the desire to change quickly and the need to manage risk.

Establish robust change management systems to manage changes and mitigate risks associated with rapid change.