I had a great discussion this morning with Caitlin Gould and Paul Massey from Bluefruit Software about Agile development practices in the medical device industry. They’ve made Agile a part of their firm’s marketing identity (and of course a deeply-valued component of their culture), and they attract clients who value it.

My experience talking with others in the medical device industry, at least in the US, is that Agile has become an empty buzzword tossed around without understanding what it actually is. People tend to have strong reactions to it because they were burned by a company practicing it poorly. Agile has become a Rorschach test, where your reaction to it says more about you than about it.

A regulatory consultant that I greatly respect asked me if I practiced Agile. I treaded lightly as I responded, and good thing too: she barely let me get a few words out before she announced that she absolutely hated it.

I guessed why: Some developers use “Agile” as an excuse to be lazy and not think through requirements. Who needs requirements? We’ll figure out how it’s supposed to work as we go! We’re Agile!

Wrong.

You still have to develop requirements.

You still have to meet IEC 62304. This means thinking through your risk analysis, requirements, architecture, code, and verification activities with rigor and discipline.

If I had to distill the Agile philosophy into a single, over-simplified, sentence so that it could actually get through people’s heads, it would be this:

Requirements will change, so your development process should make it easy for them to change.

Many of the strategic principles of the Agile Manifesto, as well as more tactical techniques such as Test Driven Development and Continuous Integration, can be derived from this statement.

Some of my pet peeves at a tactical level:

• Your regulatory documentation should be written in a format that encourages easy collaboration. Emailing word documents around is the very definition of a friction-filled process that makes your team not want to change the requirements, even when they should.
• Nothing makes it easier to confidently and safely refactor and modify software to meet changing requirements than an automatic, comprehensive, passing set of unit tests.

There is a whole Technical Information Report from AAMI on how to apply Agile to medical device software. It explicitly recognizes that some of the Agile principles need to be tweaked to apply to a safety-critical, regulated environment, but it walks you through how to do this.

From TIR 45 - Guidance on the use of AGILE practices in the development of medical device software:

[AGILE] does not denote a specific methodology, approach, or practice (i.e., there is no generally accepted, specific AGILE methodology) but rather an umbrella term that is typically applied when software or product development 1) fits with the spirit of the Manifesto for AGILE Software Development, 2) is more empirical than deterministic, and 3) is EVOLUTIONARY and frequently iterative.

Does your organization practice Agile with a capital “A”, or agile with a lowercase “a”? Do you hold SCRUM meetings but don’t deeply think about how your development process can be improved?

Hit reply and tell me what you think.

Be safe out there, and happy developing.