Untethered Healthcare

Developing medical devices is traditionally seen as a linear process with little formal feedback between stages. The  FDA’s Quality System Regulation (QSR) even tends to enforce a linear, waterfall method of product development.  Traditional waterfall development can contribute to long development cycles, costly late stage defect discovery and even missing the mark on market acceptance. However there is nothing in the QSR that precludes adopting a more iterative, Agile method of product development, even in a regulated industry. If you think about it, all product development is iterative anyway. It just gets more expensive to find and correct your design mistakes and latent defects in later stages, but you still have to loop back and correct them. Most medical device companies’ quality systems grew up in the gate-style product life cycle era. Smart companies are re-thinking their internal processes to allow more Agile development. It has been my experience that most engineers feel more empowered and productive using Agile methods, even if it means very tight tracking of tasks, daily stand-up meetings and higher accountability. Real teamwork and real results always feel better than slipping schedules and development death marches.

Moving to Agile does not mean having to throw out all the existing SOPs and starting over. Agile is a set of practices, but you don’t have to adopt them all. In the regulated world, it is still best to fully understand the requirements before you start design. The most useful techniques can be adapted to regulated industry style development and phased in, often under the existing SOPs.  Even moving to daily scrums, project velocity tracking and enhanced collaboration tools can make a significant difference in schedule predictability. I’ll talk more about what this looks like in later posts. I’d appreciate any comments on other’s experiences using Agile methods in medical device development.