MDG Agile for Medical Device Software
6 likes793 views
The document summarizes key aspects of applying agile principles and practices to medical device software development in a way that is compliant with regulatory requirements. It discusses how agile values such as individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan can be aligned with regulatory needs to develop software that is safe, effective, and meets user needs. The document provides examples of how agile practices such as planning, requirements, and documentation can be adapted for medical device software while maintaining regulatory compliance.
MDG Agile for Medical Device Software
- 1. Agile for Medical Device Software Mike Attili, Amaxo attili@amaxo.com
- 2. Manifesto for Agile Software Development
- 3. Manifesto for Agile Software Development Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas 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. © 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.
- 4. The State of Software Development (~2001) Isolated developers working independently Each owning a part of the project Communicating via data flow diagrams, interface contracts, UML, CASE tools, and detailed specs Updating the boss through weekly status reports Finally coming together for ‘Big bang’ integrations Followed by endless bug fixes and ‘crunch time’ “Individuals and interactions over processes and tools”
- 5. The State of Software Development (~2001) Design documentation handed to developers to ‘code’ Complete products requirements generated by business analysts Software design description produced by a technical architect Detailed design docs written ‘up-front’ No code written until design docs approved “Working software over comprehensive documentation”
- 6. The State of Software Development (~2001) The customer and the software teams were adversaries Negotiated scope and expensive change orders The ‘Iron Triangle’ Features, Time/Budget, Quality (Pick Two) User’s got the software that was designed for them; Not the software that they wanted “Customer collaboration over contract negotiation”
- 7. The State of Software Development (~2001) The Plan was a project-wide GANTT chart that fixed the schedule for the remainder of the project Tracking task status by percent complete Except that tasks rapidly reached 90% Then slowly crept to 100% (and even that was often a ‘fudge’) New or changing requirements were met with resistance, rejection or big budget overruns “Responding to change over following a plan”
- 8. The Classic Waterfall Model
- 9. The V Model
- 10. Agile Development Life Cycle
- 11. What does typical Agile Software Development look like? Small, interdisciplinary teams of developers, testers, and customer proxies Often co-located in an open workspace with highly visible status displays Code is owned by the whole team and members often work together in pairs Test-Driven Development, Automated Builds, Continuous Integration User stories (features with independent value) are managed in a prioritized backlog New stories are welcome at any time User story priorities are determined by the project stakeholders Level of effort is estimated by the team in arbitrary units of story points
- 12. What does typical Agile Software Development look like? The highest priority user stories are batched into iterations (or sprints) of two to four weeks Teams collaborate to execute the entire lifecycle within an iteration (“Done done”) Design, coding, integration, test, release Iteration Planning to bring developers and stakeholders together Accept Completed Stories Agree on Stories for the Next Iteration Team Retrospective Daily stand-up meetings (or scrums) to share plans and resolve blocks
- 13. DESIGN CONTROL GUIDANCE FOR MEDICAL DEVICE MANUFACTURERS FDA, March 11, 1997
- 14. How can these co-exist?
- 15. Step Back to the Fundamental Goals Regulatory agencies and Agile proponents both value high-quality software that meets the end user’s needs SAFE and EFFECTIVE So, how can the practices by aligned?
- 16. Medical Device Manufacturers and the FDA both wanted Guidance on Appling Agile Practices to Medical Device Software AAMI Medical Device Software Committee approved the creation of an Agile Software Task Group in 2009 Joint Chairs – Bakul Patel (FDA) and Patty Krantz (Medtronic) Goal: How to best align agile concepts and practices with the regulatory requirements for medical device software
- 17. Recognized as a Consensus Standard by the FDA on 1/15/2013
- 18. Agile Lifecycle Adoption Continues to Gain Adoption IMDRF SaMD 1st Draft IMDRF SaMD Revised Draft
- 19. Key Conclusions and Recommendations from AAMI TIR45:2012 Agile can bring value to medical device software Agile can be adapted to the unique needs of medical device software Apply the values of Agile in a way that enhances a robust quality management system Apply the practices of Agile within the context of an established quality management system
- 20. AAMI TIR45:2012 Aligning on Concepts Lifecycle Design inputs and Outputs Design Review Documentations Change Management Risk Management Aligning on Practices Planning Team Structure Requirements Architecture Detailed Design Verification Traceability …
- 22. Individuals and interactions over processes and tools Effective processes and tools will help a good team perform even better, but no amount of processes and tools will help a poor team perform well. Documented processes and supportive tools bring discipline to a development process by codifying procedures and behaviors that have been deemed important. But, problems can occur if the team does not feel responsibility for the process, resulting in processes that are misunderstood or ignored, or if the documented processes do not support execution realities, resulting in the “two sets of books” mentality where the things we say do not match what we actually do. AGILE imposes a different focus on discipline: the discipline of an interactive team of individuals who are aligned on shared goals, shared values, and shared principles. Following the principles of “inspect and adapt” and “visibility,” an AGILE team is obligated to regularly ask itself how the processes and practices are working and then make improvements. But problems can occur if the team does not accept responsibility for its processes and practices, if the team is not sufficiently trained on fundamental concepts for software development processes and the requirements of a quality management system, or if schedule pressures discourage the team from committing the necessary time to the inspect- and-adapt principle. Apply the discipline of a clear and sufficient documented process to establish the rigor necessary for medical device software. Apply the discipline of agile to adapt a rigorous process to the team’s context and focus on continuous improvement. Both perspectives place value on a development team that takes ownership of the software it creates and the processes and practices used to create it
- 23. Working software over comprehensive documentation Working software is the ultimate deliverable, the best indicator of progress and the best indicator that the needs of the customer are being satisfied. Regulations and standards require certain kinds of documentation to demonstrate that a robust process has been followed to develop a safe and effective product: that is a given Effective documentation can help a software team produce a safe and effective product Agile concepts should be applied to ensure that valuable documentation is produced and wasteful documentation is eliminated “If it isn’t documented, it didn’t happen.” is a useful notion to highlight the importance of producing an audit trail, but over-emphasizing it can lead to a checklist mentality where documentation is produced simply to satisfy some real or imagined requirement while providing no value Development team should consider what is valuable to them and what is valuable to regulators. The most valuable documentation will satisfy both
- 24. Customer collaboration over contract negotiation Although contracts are useful, they cannot by themselves ensure that a development team will produce a product that satisfies the customer Understanding user needs and the intended use of the software product, and ensuring that the software is designed and validated for that use, is a vital element of creating a safe and effective product. An emphasis on customer collaboration means that the software’s definition will evolve over time For most development projects, the full definition cannot be known upfront and the most responsible course of action is to capture the definition, requirements, and specifications that are known in advance and then to fully elaborate them over the whole lifecycle of the project. It is important for the project’s development plan to explain how the definition of the software will emerge and how artifacts will be created to demonstrate how that definition emerges in a controlled way.
- 25. Responding to change over following a plan Change is inevitable in new product development and should be embraced as a good and useful thing Clear and sufficient plans help establish reasonable expectations, set the project up for success, and provide a means of control, but no amount of detail in a plan can predict and control the dynamic nature of new product development Agile puts tremendous emphasis on planning, with varying levels of planning happening every day during a project Plans must not be seen as rigid mandates for how work must be done, but instead should be used as effective guidance that can be adapted as work proceeds It is important to define the planning activities that occur and the artifacts that are generated in order to be able to demonstrate them to a regulator
Editor's Notes
- #2: (2 minutes) Present the Agile Manifesto (5 minutes) Backdrop to the manifesto (waterfall, etc.) (3 minutes) Initial reaction from medical device community (5 minutes) Core description of what agile software development means (5 minutes) Evolution of AAMI TIR45:2012, incl. FDA involvement and recognition as a consensus standard (10 minutes) Walk through TIR recommendations, how to apply them, real life anecdotes
- #4: Second class status to ‘process’, ‘documentation’, ‘contracts’, and ‘plans’? On the face of it, this can’t be relevant to medical device development with an emphasis on design controls and 62304?
- #5: What were the bad practices that led to the manifesto
- #6: What were the bad practices that led to the manifesto
- #7: What were the bad practices that led to the manifesto
- #8: What were the bad practices that led to the manifesto
- #12: There are many more features of agile development teams, but this should cover the high points for this audience.
- #13: There are many more features of agile development teams, but this should cover the high points for this audience.
- #14: The development process depicted in the example is a traditional waterfall model. The design proceeds in a logical sequence of phases or stages. Basically, requirements are developed, and a device is designed to meet those requirements. The design is then evaluated, transferred to production, and the device is manufactured. In practice, feedback paths would be required between each phase of the process and previous phases, representing the iterative nature of product development. However, this detail has been omitted from the figure to make the influence of the design controls on the design process more distinct.
- #18: Puts TIR45 on the same standing as 14971, 60601-1, 62304, and 62366 It’s no longer a question of ‘Will the FDA accept this?’ The FDA now advocates in favor of agile development practices to develop safer products that meet user needs.