That is one of the purposes, yes. Another is to get earlier feedback on whether what we are building actually works the way it is supposed to work, and to build that learning into future iterations. Another is to more reliably measure progress, in terms of Running Tested Features.

“I just don’t see how a cost-effective quality system process implementation can be accomplished.”

Anecdotal Evidence seems to suggest that an Agile approach actually is more cost effective than a waterfall approach. I think the most important reason is that the earlier we get feedback - for example from a failing test - the less costly it is to incorporate that feedback into the product.

“If you are (or have ever been) part of an Agile development team for a FDA regulated product I’d love to here about your experiences and how you were able to resolve the types of issues presented here.”

I suggest you do some research on PatientKeeper.

We typically use a waterfall approach for requirements (although there are changes expected, often TBDs remaining, at the approval) and for the software architecture. Then we use an iterative approach on the detailed design, coding, and verification steps. Validation is done at the end. This approach is certainly not agile. Our concern in using Agile is justifying to the FDA the lack of the design input stage gate. While I think this could be done, our typical clients are somewhat regulatory risk adverse.