Jeff Cody
President, Cascade Quality Services, LLC.
With over two decades of experience, Jeff consistently delivered sustainable and scalable compliance solutions globally in the MedTech industry. As a Quality Leader, he led acquisition integrations, scaled up manufacturing and supply chain capabilities, and contributed to launching many new products in heart failure, diagnostic and life science consumables, and capital equipment.
His expertise includes integrating Lean Methods, Agile Thinking, Dfx, and Data Analytics into quality systems in large companies and start-up organizations to meet evolving regulatory requirements.
Jeff recently founded a consulting company, Cascade Quality Services LLC., to deliver a competitive edge to companies using electronic PLM-eQMS systems to reduce design cycle times and to realize the benefits of a connected and collaborative Quality System. Jeff has a Master’s Degree in Electrical Engineering from Arizona State University.
Agile Methods for MedTech Hardware Development: Embracing Innovation within Regulatory Constraints
In medical device hardware development, embracing Agile methods presents exciting opportunities and unique challenges. Unlike software development, where Agile practices have been widely adopted and standardized (as seen in the AAMI TIR45 Guidance), the transition in the hardware sector has been slower.1 This hesitancy stems from a range of factors. First, one challenge is the perceived conflicts between the Agile Manifesto and stringent medical device regulations. Next, the inherent complexity of hardware design, with its long development and validation cycles, can make an Agile framework seem like a mismatch. Finally, the manual and legacy quality systems have limitations in supporting Agile methodologies.
However, it’s critical to recognize that the FDA’s Quality System (QS) regulation doesn’t mandate a singular development approach. While the traditional Waterfall method has its merits, especially in simpler device development and introducing design control, it falls short in managing the complexity of more advanced products.
Originally rooted in software development, Agile methodologies can be adapted to FDA-regulated hardware development. These methodologies, encompassing Concurrent Engineering, Design and Development Planning, and compliant project management tools, can be applied to address the complexities of MedTech hardware development (Figure 1).2
Implementing Agile in Medical Device Hardware Development
The Agile method, within a framework of a robust quality system and based on iterative, time-boxed development sprints, can overcome the unique challenges of FDA-compliant hardware development.3 The key elements of Agile development within the capabilities of today’s Modern Product Lifecycle Management and electronic Quality Management Systems (PLM-eQMS) tools to enable medical hardware teams to realize the benefits of Agile development.
There are eight key factors to consider when adapting Agile to a medical device context.
- Iterative Development: Agile’s strength lies in its promotion of iterative, concurrent, and incremental development. Teams can foster continuous improvement and adaptability by breaking down hardware into smaller units like components and subassemblies. This approach is particularly beneficial for prioritizing units with higher risks or longer lead times.
- User Stories and Requirements: Agile challenges the traditional reliance on extensive upfront documentation. Instead, it leverages user stories and dynamic requirements to perform a thorough analysis of regulatory requirements to comply with ISO 13485. Agile teams adapt by balancing detailed documentation and the ability to respond to changing requirements and risks.
- Sprints and Time-Boxed Development: Agile development uses time-boxed iterations, known as sprints. Teams structure their development cycles to comply with ISO 13485 processes, ensuring that each sprint addresses specific aspects of the development lifecycle, such as design, development and test. Use daily meetings following modified Software SCRUM practices to hardware sprints.
- Continuous Integration and Testing: Agile methodologies use continuous integration and testing to identify and address issues early in development. Risks are addressed during each cycle while failing fast to eliminate design options not meeting requirements. This aligns with ISO 13485’s emphasis on testing and verification activities throughout the development lifecycle.
- Cross-Functional Teams: Agile teams are cross-functional and comprehensive, with members contributing to different aspects of the development process. With good project planning using project management software to establish needed resources, this approach supports the collaborative and interdisciplinary nature required by ISO 13485.
- Adaptive Planning: Agile methodologies embrace adaptive planning, allowing teams to update their plans based on changing requirements or feedback rapidly. With a robust and electronic change management process, this flexibility aligns with ISO 13485’s recognition of the need for adjustments in response to new information or changes in the development environment.
- Documentation within Iterations: To meet ISO 13485’s comprehensive documentation requirement, Agile teams integrate documentation tasks and approvals within each iteration, incrementally producing necessary documentation aligned with the overall development process. This reduces the burden of creating and assembling documentation during design reviews.
- Regular Review and Retrospective: Agile teams conduct regular team reviews and retrospectives to assess progress, identify improvement areas, and use subassembly prototypes to demonstrate performance to stakeholders. Combined with formal design review phase-gate milestones, the continuous and formal feedback loop is consistent with ISO 13485’s emphasis on regular assessments, adjustments to change, and documentation requirements.
The Role of Modern PLM-eQMS in Agile Adaptation
The success of implementing Agile in hardware development heavily relies on an organization’s ability to manage projects at various scales and complexities. Modern Product Lifecycle Management and electronic Quality Management Systems (PLM-eQMS) can play a pivotal role. These systems include capabilities like requirements management, risk management, Gantt charts, electronic approvals, traceability matrices, and full lifecycle management of the product record. With electronic data management and control, meeting regulatory compliance is simplified, and development agility is enhanced.
Tailoring Agile for Medical Device Hardware Development
For medical device organizations, the key lies in tailoring Agile methods to the specific nature of hardware development in a regulated environment. This requires an open mindset, a willingness to adapt, and a commitment to maintaining regulatory compliance while leveraging Agile practices for improved adaptability, collaboration, and speed.
For more information on medical devices and Agile hardware development, check out the advice from Product Realization Group’s experts.
- Why Is Failing To Adhere To Regulatory Compliance One Of The Biggest Challenges When Bringing A Medical Device To Market?
- How Can An Agile Methodology Be Part Of The Hardware Product Development Process?
- How to Overcome a Medical Device’s Biggest Barrier to Launch: Regulatory Compliance
Is your hardware ready to scale? Download a free Agile Hardware Product Realization: Mastering the Journey from Concept to Scale chapter, and learn how to apply the 10 best practices of Agile hardware realization to your new product introduction process, or get the book on Amazon.
References:
- Recognized Consensus Standards, January 15th, 2013, U.S. Food and Drug Administration – Recognition Number 13-36: AAMI TIR45:2012, Guidance on the use of AGILE practices in the development of medical device software.
- Design Control Guidance for Medical Device Manufactures, US Food and Drug Administration, p. 13.
- Agile Hardware Product Realization, Michael Keer and David Eden, 2023, pp. 29-32.