Agile for Medical Devices

Q&A by Brian Shoemaker, Shoebar Associates, and Nancy Van Schooenderwoert, Lean-Agile Partners, with contributions from Tony Raymond, Nov 30, 2012, who will be offering a full day tutorial course called "Introduction to Agile Methods for European Medical Product Software Development" at IQPC on Thursday, Jan 31, 2013 in Munich. This article and subsequent ones will highlight typical questions that we are often asked.

Do Iterations need a formal sign-off?

Q: What kind of review process should be applied on Requirement, Design and Test Specs at the end of each iteration when updated versions are available? Is there any formal sign off needed?

A: There is no formal sign-off mandated in IEC 62304 (or by the FDA) at each iteration. There must however be evidence to show that proper professional care has been exercised (hazards evaluated, mitigations designed, traceability established from design to tests, etc.).

The regulatory agencies require that Requirements, Design, and Tests be reviewed – but do not specify how often and when these reviews need to occur. If a single documented design review occurs prior to release, and this review covers requirements as well as design and testing, that evidence is sufficient. In some companies, or for some projects, a single review and sign-off prior to final testing may not be the most efficient approach to ensure complete review, but how often to conduct documented reviews is up to each organization. The key word here is "documented" since the core of the Agile approach is for stakeholders to review the implementation continuously as it takes shape.

Agile methodologies all call for certain checks to occur at each iteration. The essential things are:

• Before Iteration: Project’s stakeholders must have agreed what actions will prove successful implementation of each feature and hazard mitigation

• During Iteration: Tests (may be manual and/or automated) must be created for all scheduled features.

• By Iteration End: Stakeholders (usually represented by a product owner) formally accept each feature as it is completed by the project team, and demonstrated for acceptance.

We recommend that there be documented sign-off for accepting features during development (whether individually or in groups). This is generally done in Agile safety-critical projects. But here is what separates the successful Agile projects from the others: successful Agile projects build the groundwork for meaningful sign-off by:

• Making sure that QA and internal regulatory people have the time to participate as stakeholders defining the "conditions of satisfaction" as the requirements are formed into "Agile Stories."

• Establishing a learning environment early in the project for continuous improvement of team technical skills – improving basic coding and design skills plus learning test-driven development and related Agile practices.

With these foundations in place, documented approval of implemented stories is normally a brief activity between the product owner and team. For this to work, approvers must already be familiar with those elements they are to sign off, and must be available to witness and sign when needed. The process of documenting approval cannot become a drag on the rest of development and implementation.

How Does Risk Analysis fit in?

Q: There is a circular dependency between risk analysis and functional specs, i.e. the risk analysis is based on the features described in the functional spec on one hand, on the other hand the risk analysis will provide input to the functional specs in form of mitigations. So how to resolve this situation? Have a released version of the functional spec first and a second review after the mitigations are defined?

A: Yes, the mutual dependence of features and hazards can be seen to create a circular process, but this is true of any lifecycle approach. The advantage of a flexible, iterative method is that each iteration gives the team a chance to re-examine the hazards to see if anything new needs to be considered. It is good practice to look ahead a few iterations at the next batch of features to be implemented, imagine what hazards might arise when those are implemented, and figure out what mitigations to implement at the same time.

Rather than a circular process, this can be viewed as a bootstraps process – each time we bring the entire design a little farther along in both the feature implementations and the mitigations (which are simply another feature).

The trap to avoid, in any case, is to try to itemize every possible feature up front, before ever looking at hazards and mitigations. Start with the "Must have" feature set and then do your first wave of risk analysis.

Send us your questions for the next segment of our Q&A series! Please email

To find out more on the subject, you may be interested to attend the Software Design for Medical Devices Europe 2013, taking place 29 January - 01 February, 2013 - Munich, Germany. Please visit for details, Contact us on 0800 652 2363 or +44 (0) 20 7368 9300 or email now!

Have Your Say
Rate this feature and give us your feedback in the comments section below