Help with Agile in MedTech

I'm having some serious issues wrapping my head around this and need to make some recommendations as to the content of a SW Development/Lifecycle SOP (and they'll have a separate SWDevPlan, which it seems like they will use for multiple similar but different medtech softwares).

I am not used to seeing SOPs for this, usually only Dev Plans including or with separate Maintenance Plans (and sometimes specific WIs)

All my references however refer to activities and deliverables that are worded in the traditional Design Phasing (so more like waterfall) describing inputs, outputs etc. I know this should also work in Agile where there are multiple cycles of these phases (so multiple mini waterfalls) but I am looking for inspiration on what the best way to write these kinds of documents are. So many references also seem to just take boiler plate templates with sections formulated the same way and containing what look like lists from standards (including 62304), is this because this is basically what's expected?

Any inspiration warmly received.


Also, I understand the iterative process, but even with Agile, surely the process still needs to consist of well defined requirements AND acceptance criteria, followed by a sprint of development which might adjust some of this but then a final set of reqs/criteria before testing (and needing some QA signoff at the start and end prior to any testing). I am not used to seeing requirements "as an export" along with test reports, and without criteria, which sometimes appear in a different report but the reqs themselves are not written at all like I am used to seeing but are more fluffy, wordy functionality type User Stories that often contain paragraphs of different things that happen when a part of the software is being used.

Is this a common thing? Any tips or experiences you can share. I feel like if the development team are not used to MedTech (yet somehow are working in it) and don't really get the concept of regulatory requirements and Design Control, Risk driven safety and objective evidence for control and safety in a NB audit it's hard to know where to start when they see "software that works".

The Agile approach want to get iterations in front of users in rapid succession and build functionality up from there (what's the manifesto: 'functionality over documentation' or something like that?). That's ok for a website, maybe, but you can't obviously release a partially-functioning heart-lung bypass machine to the field. The "end game" has to be the focus - and since it's a medical device, that means documentation. The iterative cycles can certainly be done to build up the product and you can build up the documentation as you go. With each cycle, you update requirements, update design documentation, etc. Risk Management (14971) needs to be done from a systems perspective so that, at least, doesn't fit the iterative cycle model very well.

One of the bigger challenges we see is how to translate what agile folks like to use as requirements, user stories into verifiable (and traceable) requirements. I don't have a good answer for that. If you take the user stories and try to create "shall" type requirements, you are kind of duplicating work and will likely get pushback.

Funny you should say that, as this is my experience so far, exactly that pushback from requirements reformatting to shall type wording from very fluffy user stories that are half descriptions, half use case, half something else.

I did find the TIR45 report which is very interesting, so I will try to see if its possible to concretely offer options

yodon said:

If you take the user stories and try to create "shall" type requirements, you are kind of duplicating work and will likely get pushback.

Click to expand...

"Duplicating work" has been, in my experience, the most likely outcome of (typical) Agile development methodologies in Medical Device design and development. I have seen duplication of both (what we would recognize as) "quality efforts" (e.g. documentation) but also in implemented solutions... because the Agile efforts ended up stepping on/breaking work done in previous Agile efforts.

My personal recommendation is to NOT incorporate Agile methods into QSP or WI... true phase gates are pretty much the gold standard by which a group "knows they are done (developing, iterating, testing, reworking)" so there is extremely limited necessary tracking of "incomplete items" from earlier phases.

I have no objection to using Agile methods within any particular development phase. Ideally, the project manager is focused only on that phase's deliverables, and has mechanisms(*1) to appropriately restrict work such that an Agile approach is focused correctly.

(*1) In software development, a correct and complete architecture paired with an implemented software configuration management plan are the two necessary mechanisms for directing Agile development during the "code writing and fixing" phase. As a project manager, I had better know precisely which units a team member is touching during an Agile iteration... if a development team can't identify those architecture elements precisely before starting work, or if they start working in other areas of the architecture... I consider that to be a failure of Agile working.

I have worked with some developers who imagine Agile methodology to be something like "you can't tell me what to do, because we don't know what to do" as the reason for "iteration". The fundamental problem here (as I see it) is that with NO exit strategy from an iterative cycle, this approach essentially guarantees that stakeholders will be left unsatisfied. Maybe some developers can internalize a set of requirements they are trying to satisfy during an Agile process, but when this happens we end up getting the code they wanted to write, not the code we needed.

Ugh, thanks also for this, if slightly depressing, my current situation is even more a mess than this but your replies both confirm to me the underlying suspicions I have that this is likely to result in a lot of uncomfortable confrontation and a painful lesson learned from a rejected Notified Body audit report.