A couple of my clients are medical device companies. They have figured out how to use agile in their business. Is it challenging? In some ways. However, the advantages gained clearly outweigh the painful parts so they continue to move forward this way.

Agile doesn't say "no documentation" and it doesn't say "don't be smart." Do what is actually necessary and nothing more. Usually organizations go far overboard because their interpretation of guidelines is overly stringent. Work with the auditors to determine what is truly sufficient based on a new way of creating products and you should be able to do it.

posted November 27, 2010

Yes. I've seen some *terrible* stuff get approved by the FDA. (I even reversed-engineered assembly code for a company that wanted to submit a device but didn't even have the source code due to a spat with their programmer.)

You've got 3 choices:
- Do comprehensive documentation after EVERY change.
- Never change the software, so you don't have to change the documentation. (Sadly, this really happens.)
- Do minimal documentation during development, then flesh it out when the software stops changing so much.

That last one is the right way, since the software really is more important than the documentation. Anyone who says otherwise doesn't know much about how computers work.

> One of the main principles of the original Agile Manifesto is "Working software over comprehensive documentation"

Yes, but note that it doesn't say "no documentation". It's trying to say "only do as much documentation as is actually needed."

In a normal system, "comprehensive documentation" is a waste of time. If "comprehensive documentation" is required, then DO comprehensive documentation -- after you get the software working, because invariably there will be many changes.

posted November 27, 2010

If one were to interpret the Agile Manifesto strictly and ideologically, it is likely not possible to implement an Agile development methodology for medical software development. However, I believe in being practical, and furthermore, I believe that when you are practical, just about everything and anything is possible.

Let me look at it from another perspective, one that the strict Agile followers may not appreciate. I am suggesting that Agile, as now implemented, is not a new methodology. In fact, it has been around for a long time, as long as the hated Waterfall methodology has been around: it is merely the Waterfall methodology, repeated over and over until the product is completed. During each iteration cycle, you analyse the requirements to be implemented during that iteration, you design a solution to implement those requirements, you build the product in accordance with the design, you then test the product, and then you release the working product (as stated in IEC 62304). The only difference between the Waterfall methodology and one iteration of the Agile methodology is that when following the traditional Waterfall method, you develop and release the complete, functioning whole; when following an Agile method, you develop and release only a small, functioning part of the whole.

Now consider the development of a commercial product of medical device software (or any other piece of commercial software): you gather and analyse requirements for the product, you design a solution, you build in accordance with the design, you test and you release. You then start over again to incrementally add new, additional functionality to the working software product. Repeat the cycle until the software is “complete”. Does this not sound like an implementation of the Agile methodology? The only difference is that in the “new” Agile, iterations / cycles are short, on the order of a few weeks; in the traditional method, the cycles are longer, on the order of a few months.

posted November 27, 2010

First, I think it is very dangerous any approach that consider Waterfall and Agile as the only alternatives for a development process. Waterfall shall not be considered (maybe for very small, very simple projects). The main correct alternatives are Iterative development (most of the cases) and Spiral (for some particular cases). Iterative development offer to main approaches:
- Iterative adaptive (first adaptive, and less risk driven) - Agile Development
- RUP (first risk driven , and then adaptive) – RUP

These are the main criteria and you shall not consider one sided opinion, because the fundamental rule is “Adapt the process” and not a religious or political-like approach of type “follows my way” or “unique selling proposal”.

I have not any direct knowledge about the domain, but from a short review about IEC62304 (and about referred ISO 14971.) there are some main features of the process:
- seems to be risk driven (rather RUP than Agile)
- architecture is important (~architecture driven: rather RUP than Agile)
- detailed design is considered (rather RUP than Agile)

Agile work rather with small projects because do not consider deep risk investigation and will use instead longer adapt activities on the next project. Also in these cases you will not have long (or medium) range vision for projects because any planning must be based on risk investigation.

From these process approaches RUP is more closed to mentioned standards, but there are some warnings to be considered.

Warning 1: A bad RUP approach is also dangerous if is considered as a recipe and not as guideline. You shall start from RUP main process attributes (risk driven, iterative, and architecture-driven) and not from process details, because you shall adapt the process to your needs. The process could adopt many agile practices to be more efficient and can still preserve his main attributes.
Think first on RUP principles and not on his details (it is knowledge base, a framework and not a recipe).

Warning 2: If IEC62304 cold look in some places more like Waterfall, do not worry, because RUP-like process could completely replace Waterfall.

Warning 3: Pure Agile seems to not fit, but that is not a real problem because a particular project will never allow pure approaches. The problem is how you will adapt the Agile (or RUP). You can scale-up an Agile process more close to the RUP or you can adapt a RUP-like process to be more agile, depending on you usual approach.

posted November 29, 2010

"Corporate and Politics" can hardly be taken over.

Regards
"Knowledge as a therapy"

posted November 28, 2010

I assume you are talking about ONLY development

I looked at IEC 62304. Diagram in this document gives a feel that this impose whaterfall kind of methodology.

But you can apply Agile as long as long as you can break your task into 4-6 weeks cycle.

Or you think documentation is an issue?. In agile , we do documentation when it matters. When federal regulation needs documentation, it indeed matters.

You should follow Agile for high focus and continuous validation of your plan and work in front of the eyes of stake holder

posted November 29, 2010