Software in Medical Devices, by MD101 Consulting

I read this technical report of the AAMI (yes, I did! No kidding!). Given the concerns of many manufacturers about agile methods, this technical report is here at first to reassure them.
The main conclusion of the TIR is:

• YES, agile methods can be used to develop medical device software,
• YES, they allow to reach the level of scrutiny demanded by regulatory framework.

To achieve this goal, a verb is continuously repeated in the document: to align.

To align

The one thing to remember of this TIR, is that the regulatory perspective and the agile perspective are not aligned at first sight. This is what generates a lot of concern about agile methods in a regulated environment.
However, both can be aligned - or reconciled - at the level of perspectives (or goals), concepts, and practices.
The whole document is in fact a discussion on how aligning the regulatory perspective and the agile perspective. It gives a list of recommendations throughout the documents. Some are conceptual, some are practical. Not all of them are immediately useful, I would say. They need to be reviewed many times before they can be applied, with teams maturing in agile methods

Agile and IEC 62304 mapping

There is a gem in this document: the mapping between agile methods and IEC 62304 activities.
Agile can be modeled as a method with levels boxed one another:

• Project,
• Release,
• Increment (or sprint in scrum),
• User-story

The TIR explains how to map the IEC 62304 activities described in sections 5.x with the levels of agile methods. A diagram in the TIR sums-up the mapping. This diagram is probably the best way to begin with agile methods in a regulated environment.

Discipline

As agile coaches say, agile methods need discipline. This is all the more true in a regulated environment. If a team wants to achieve the level of quality in software and scrutiny in documentation that is expected by regulatory requirements, then it has to be disciplined!

Done is done

A corollary to discipline is the concept of Done is done. For every artifact produced by the agile team, the concept of Done is done shall embrace the requirements of quality and regulatory frameworks. For instance, the documentation required for detailed design shall be finished and reviewed at the end of an increment.
I took deliberately the example of detailed design documentation, to show that discipline is required. That's so easy to skip detailed design documentation in a software development project!

Conclusion

This TIR is not a hands-on approach on agile methods. It's a good discussion on what can be done or what can't be done with agile methods. It's also a good way to reassure people who are skeptical about agile methods!
The best way to begin with agile methods is to hire a professional agile coach. When software development teams are comfortable with agile development, it's time to apply the recommendations of the TIR and insert quality and regulatory constraints in agile methods. Not the other way round.