I've been involved in some informal discussions regarding the use of Agile methodologies for medical device software. The Medical Device and Diagnostic Industry (MD&DI) October 2007 article by Tim Bosch entitled Medical Device Software Development—Going Agile provides a good overview of the challenges that face medical device design and development organizations that want to embrace Agile. Here's Figure 2 from the article:
I liked the organization 'rejection, force fitting, or abandonment' analysis. Changing organizational behavior is a difficult thing to do. Add in the documentation requirements and you can see why adopting Agile is an uphill battle. This is especially true for an organization that already has a history of doing software development the old fashioned way.
On the regulatory side, Tim references General Principles of Software Validation; Final Guidance for Industry and FDA Staff and claims that:
An agile development approach aligns well with this guidance.
I'm not so sure about that. As I've pointed out before, because of the validation requirements those guidelines are much better suited for the Waterfall development approach. That's why most people do it that way. Agile can be applied, but it comes with increased cost and potential regulatory risk.
I think the advantages of Agile methodologies are real and application of them does have the potential to improve the functionality, cost effectiveness, and quality of medical device software. It's good to see articles that detail the issues and provide a realistic strategy for achieving those goals.
Nothing is better suited for the waterfall approach.
A system cannot be completely specified without feedback loops. Some DFSS techniques can be used during the Requirements & Design stages and some Agile techniques should also be used.
The trick is to know when to proceed from completing the specification to investigating the details necessary to start the design. Similarly for proceeding to implementing the design. Most people rely on an IEEE 830 specification standard which leads to a printed document that must be signed before design can start. This is not a reasonable approach. A requirements tracking tool should be used to track the requirements through their lifecycle with the necessary signatures. Instead of approving all requirements, each requirement is approved electronically allowing work to continue on approved requirements while other requirements are being discussed.
“Peter Wegner at Brown University demonstrated that it is not possible to fully specify or test an interactive system designed to respond to external inputs, i.e. Wegner’s Lemma. ” [Wegner, 1997, Why Interaction Is More Powerful Than Algorithms.]
“Here was mathematical proof that any process that assumed known inputs, like the waterfall method, was doomed to failure when building an object oriented system.” [Schwaber/Beedle, 2002, Agile Software Development with Scrum.]
Pingback: Agile Medical Device Software Development? | Ron Rammage Project Management Blog