1. Agile and Medical Device Software
Kelly Weyrauch – Medtronic
- AAMI Agile TIR Committee

2. Topics AAMI Technical Information Report
Align Agile Values with regulated Values
Add Agile to an existing, robust, effective Quality Management System
Align Agile's Incremental/Evolutionary lifecycle with (mis)expectations of more Linear models
What does the FDA think of Agile?
Challenges unique to Medical Device Software
Continuous Release
Myths, misperception, miscommunication, and mistakes
Others?

3. Using Agile for Medical Device Software
You Can
Agile TIR
You Should
Benefits not unique to Medical Device Software
Productivity, Predictability, Team Intangibles
Benefits for Medical Device Software
Emphasis on User Needs and Intended Use
Test-Driven Development
Team discipline, responsibility for continuous improvement of the development process

4. Technical Information Report: Guidance on the Use of Agile Practices in the Development of Medical Device Software

5. The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The FDA does not have singular or specific written manifesto that is simply focused on medical device software.
The FDA regulates medical device software as an integral part of a well structured set of laws, regulations and guidances.
Manifesto for Agile Software Development,

6. Design Controls
FDA Design Control Guidance For Medical Device Manufacturers

7. Aligning Agile with a Quality Management System
Add Agile to an existing Quality Management System
Agile by itself is insufficient
Don’t disrupt the existing system
Avoid raising undue concerns
“Don’t tell us you are using Agile, we don’t need to know”
Agile practices insufficient
Need Risk Management, Configuration Management Change Control

8. IEC 62304: Medical device software – Software life cycle processes
7 Software Risk Management
8 Software Configuration Management
5.1 SW Development Planning
5.1 SW Requirements Analysis
5.1 SW Architectural Design
5.1 SW Detailed Design
5.1 SW Unit Implement. & Verification
5.1 SW System Testing
5.1 SW Release
9 Software Problem Resolution

9. Mapping 62304’s activities…
5.1 SW Development Planning
5.1 SW Development Planning
5.1 SW Development Planning
5.1 SW Development Planning
5.1 SW Development Planning
5.2 SW Requirements Analysis
5.2 SW Requirements Analysis
5.3 SW Architectural Design
5.3 SW Architectural Design
5.4 SW Detailed Design
5.4 SW Detailed Design
5.5 SW Unit Implement. & Verification
5.5 SW Unit Implement. & Verif
5.6 SW Integration and Integr. Testing
5.6 SW Integration and Integr. Testing
5.6 SW Integration and Integr. Testing
5.6 SW Integration and Integr. Testing
5.7 SW System Testing
5.7 SW System Testing
5.7 SW System Testing
5.8 SW Release
5.8 SW Release
5.3 SW Architectural Design
5.2 SW Requirements Analysis
5.7 SW System Testing
…into Agile’s Incremental/Evolutionary life cycle
For Each Project
5.1 SW Development Planning - Project
5.2 SW Requirements Analysis – High-Level, Backlog Management
5.3 SW Architectural Design – Infrastructure, Spikes
For Each Release
5.1 SW Development Planning - Release
5.6 SW Integration and Integration Testing
For Each Increment
5.1 SW Development Planning - Increment
But provides a Software Development Process Model, addressing Lifecycle activities.
Even it does not
5.6 SW Integration and Integration Testing
For Each Story
More Releases …
5.1 SW Development Planning - Story
5.7 SW System Testing & Regression Testing
5.2 SW Requirements Analysis – Story Details
More stories …
More Increments …
5.3 SW Architectural Design - Emergent
5.7 SW System Testing & Regression Testing
5.4 SW Detailed Design
5.5 SW Unit Implementation and Verification
5.8 SW Release
5.6 SW Integration and Integration Testing
5.7 SW System Testing

10. What does the FDA think of Agile?
The FDA does not prohibit or encourage the use of any specific software development methodology
Based on the intended use of the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used, and the level of effort to be applied. While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software lifecycle. [GPSV: Page 1 General Principles of Software Validation: Final Guidance for Industry and FDA Staff]
The FDA does not prohibit the use of Agile

11. What does the FDA think of Agile?
They have indicated some expected characteristics of the selected software lifecycle
The quality system requirements do not dictate the types of design process that a manufacturer must use. Manufacturers should use processes best suited to their needs. However, whatever the processes may be, it is important that the design controls are applied in an appropriate manner. [Design Control Guidance for Medical Device Manufacturers]
FDA believes that Agile Methods can be tailored for use in a regulated environment

12. What does the FDA think of Agile?
Demonstrate that you satisfy Design Controls, be in control
Explain what you do
Demonstrate that you do it
Don’t use Agile as an excuse to not do something

13. Challenges Frequent Releases When software is part of a larger system
Regulatory cycles
Field updates

14. Challenges Myths, misperception, miscommunication, and mistakes
“Doctor, it hurts when I go like this…”

15. Agile and Medical Device Software
Kelly Weyrauch