Regulatory Open Forum

 View Only
  • 1.  waterfall model or agile design and development

    Posted 28-May-2019 15:02
    Hello, 

    I am not sure if this question has ever come up in this forum.  A small company does agile development.  I come from places where the waterfall model is the norm (e.g. with phase gate reviews sequentially).  My question now is: what does a design and development procedure look like in an environment where the waterfall models doesn't exist?  The company makes electrical medical equipment (hardware + software).  Development happens in sprints, and as somebody who does not have experience dealing with the agile methodology, can somebody explain how DHFs and ECOs are documented in an agile environment?   

    Thanks.

    ------------------------------
    Karen Zhou
    ------------------------------


  • 2.  RE: waterfall model or agile design and development

    Posted 29-May-2019 05:29
    Karen,

    Explanation of transition from a waterfall or V-Model to an Agile type of methodology could probably take a book length to compare, contrast, and describe how this could be done.  I have seen a couple white papers over the years (I can not remember where or can not provide links immediately) on how to use Agile in medical device development - which is certainly handy for companies making changes.  With that said, Agile methodology is best suited when frequent changes are being made, like every few days or at least once a week.  Thus Agile is well-suited toward software products where frequent changes are often being made - especially for SaMD devices.  I would argue if your development process is a month long or months long, then an Agile methodology may not be suitable.  If you are making one change a month, maybe this is appropriate, but longer than that, I would say traditional development methods are better suited.  However, you can still use Agile methodology, it just may not look very much like Agile.

    In regard to what a DHF or ECO looks like under Agile, think of the sprints as being mini or packets of design transfer.  The entire verification and validation process is not going to be done each time and certainly not in a sequential type of manner normal with waterfall methods.  Identify those specifications, requirements, or functional areas of the device that are changing to determine what V&V you would need to do.  Then in essence you would have a Design Transfer for each sprint where there would be release of documentation to manufacturing, a Design Review conducted, and the new version "launched".  As an example, I worked on a project where we had the entire DHF as a folder in our server (or you could even use Agile edms system haha) that was version 1.0.  The next sprint being version 1.1 would be a different folder in our server with only those documents impacted.  Next version 1.2 again another folder.  Then when there was a major change or compilation of something to say version 2.0 there would be another complete folder in our server.  It can get a bit complicated because there are many electronic files around and during an audit would need to know where to get everything.  A well-structured system is vital for this aspect.  There are a few ways to do this, but it can be done.

    ------------------------------
    Richard Vincins RAC
    Vice President Global Regulatory Affairs
    ------------------------------



  • 3.  RE: waterfall model or agile design and development

    This message was posted by a user wishing to remain anonymous
    Posted 29-May-2019 11:03
    This message was posted by a user wishing to remain anonymous

    ​AAMI TIR 45:  Guidance on the use of AGILE practices in the development of medical device software