Agile Practices Proven in Highly Regulated Environments by Craig Langenfeld

Editor's Notes

• #4: Examples of high assurance software systems include command and control systems, nuclear power plants, electronic banking, aerospace systems, automated manufacturing and medical systems (examples in India)HealthcareFDA 21 CFR 820.30 Sub-clause 4.4 of ISO 9001IEC 62304
• #5: Regulation of medical devices is intended to protect the health and safety of patients, users, and third persons, by attempting to ensure that marketed products are safe and effective. Different countries and regions have different agencies that regulate medical devices. While these different agencies have many different specific regulations, they share much in common and all have similar goals and guiding principles. This regulatory perspective section concentrates on regulation for quality system requirements specific to design control.Sub-clauses of ISO 13485 clause 7.3 (Design and Development) have the same overall objectives of the United States FDA regulation related to design controls. For some time the FDA, Health Canada, the EU, Japan, and Australia have been working within the Global Harmonization Task Force (GHTF) to develop guidance documents that reflect international agreement on quality management system essential principles and requirements. Information on guidance documents from the various GHTF study groups can be found at www.GHTF.org.
• #6: Who in this room is from a regulated industry?If you are in a regulated environment who is practicing Agile?Who has read their governing regulation or associated guidance in the past 6 months?
• #7: As it relates to FDA 21 CFR 820.30 and Sub-clause 4.4 of ISO 9001
• #8: Ask Micheal’s opinion on these points to offer additional color to the commentary
• #9: With respect to this one industry, and with respect to these specific guidelines, any notion that we are mandated to apply a single-pass, waterfall model to software development is an industry myth, one which has likely been perpetuated by our own waterfall past (“we’ve always done it this way”) and our existing quality management systems, and not because “the regulations make us do it”I’m asking you to do two things with our time here today…ParticipateChallenge status quo by reading and re-interpreting the standards, regulations and guidelines that you follow today.
• #14: Case studies, blogs, papers, and a cameo appearanceAgile Framework for Regulated EnvironmentsRequirements Model Artifacts and activities (output)QMS changes
• #15: Abbott Laboratories (molecular diagnostics division)– presented at the Agile Conference 2009 -> dates back to 2004“On the Agile project, fewer defects were found…Estimated project duration and team size decrease of 20 – 30%“This experience has convinced us that Agile approach is is the approach best suited for the development of FDA Regulated devicesImaging Solutions division 375+ engineers globally, 18 products, support clinician productivityChallenge: “…the problem with this approach is the ability to incorporate customer feedback early in the cycle and any significant changes could require complete changes in design that cause lengthy delays”Result: “we are making progress and feel that the benefits of our Agile adoption have been worth the effort. Because of this we are rolling out Agile globally within GE Healthcare” Further evidence would be the US dept of defense. Highly secure highly thought of as “un Agile”
• #16: Guidance in the use of Agile Practices in the Development of Medical Device Software“Since agile is a highly incremental/evolutionary approach, it can therefore be mistakenly assumed that agile is incompatible with the expectations for a medical device software process. “
• #17: Why is Agile for High Assurance getting so much attention in the past couple of years? For the same reason that Agile got everyone’s attention at the end of the last century. Because it works. And most importantly it produces quality products.
• #18: And if we look at the practices that XP alone provides us with almost every one of them provides us with a higher degree of quality, safety, and efficacy.
• #21: While regulatory agencies do not prohibit or encourage the use of any specific software development methodology, but they do indicate some expected characteristics of the selected software lifecycle and development. In particular, they emphasize that software verification and VALIDATION should be conducted throughout the software development lifecycleFrom the intended use point of view, agile’s emphasis on customer collaboration aligns very well with the regulatory perspective's emphasis on software VALIDATION.
• #23: Acceptance criteriaDefine | Build | VerifyDefinition of doneInput -> Traceability -> Output
• #24: Verification Iteration Define | Build | VerifyValidate and Review
• #25: Diff
• #26: Suggest Michael offer an Omnyx user story here to replace EPAT example.
• #31: A foundational element of regulations and standards for medical device software is that a quality management system must be “established”, where “established” means that the quality management system is defined, it is documented, it is understood by those who use it, and objective evidence is produced to demonstrate it has been properly used. A quality management system is documented within the organization’s common process documentation (such as procedures, protocols, and work instructions) as well as specific documentation unique to a project (such as in project plans and reports).Changes that agile brings to a robust and effective quality management system should not diminish or give the perception of diminishing the effectiveness of the established system. Changes should be made within the requirements of regulations, regulatory guidance, and standards, and therefore not raise undue concern among regulators.
• #32: Documentation (evidence) is necessary to demonstrate compliance to regulations, to evaluate software for regulatory approval, to facilitate the investigation into software problems, and to evaluate software for those devices requiring regulatory approval, e.g., approval, clearance, licensing, registration, self-certification, etc.
• #38: Agile extremism does not help (working software over documentation)
• #39: Agile and regulating bodies are not at odds (waterfall is not mandated by regulations)Agile and Regulations both strive to ensure high product quality
• #41: Internal interpretation of regulations often more constrainingRegulatory requirements and guidance documents recognize that different kinds of medical device software require different development processes, practices, and documentation. For example, the FDA’s “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” describes "Level of Concern", recommending that the extent of documentation to be submitted should be proportional to the Level of Concern associated with the device. The FDA’s guidance document “General Principles of Software Validation” recommends that the specific approach, techniques, and level of effort applied to software development be based on the intended use and the safety risk associated with the software. IEC 62304 describes "Software Safety Classification" and provides guidance on the development processes to be applied depending on the classification. All of these are recommending that the risk associated with a software product should be assessed in order to establish a development process with the appropriate level of rigor and robustness.
• #43: Urban Myth: Agile is not for high assuranceHigh assurance - late adoptersEarly adopters – no wayMajority adopters – stating to take noticeLate adopters – want to get on band wagonWant to reap agile benefitsHigh assurance competitors are now doing agileFaster time to marketIncreased productivityHigher qualityHigher customer satisfactionWith respect to this one industry, and with respect to these specific guidelines, any notion that we are mandated to apply a single-pass, waterfall model to software development is an industry myth, one which has likely been perpetuated by our own waterfall past (“we’ve always done it this way”) and our existing quality management systems, and not because “the regulations make us do it”I feel that management is in some ways very attached to Waterfall because it fits so nicely with phased-gated development with doing requirements, then having a stage gated requirements review, design phased, with Geoffrey Moore: “Waterfall put a man on the moon but it’s inadequate for today’s hyper connected and competitive environment.”