Yesterday we did our second Medical Devices software seminar, this time in snowy and cold Minneapolis. Say what you will about the weather, but this city is built for winter…it has various overhead ‘tunnels’ called ‘skyways‘ connecting what seemed to be the entire downtown core, so you rarely ever need to go outside.

Anyways, our seminar drew the interest of over 75% of registrants, mostly software engineers and QA, so really another great turnout. The format was the same as our Boston event, with the same players from SterlingTech, Klocwork (duh) and Vector Software. There really didn’t seem to be too much separating this group from the Boston group with the exception being around the development methodologies being used. The Boston group all appeared to be using (or moving to) and Agile methodology, whereas this group was not using Agile at all. For the life of me I cannot explain this. I would have thought if Medical device organizations in one part of the country were primarily using Agile, perhaps it was becoming the norm for that market segment…but based on this sample, now I just don’t know. If anyone can share their observations on this, I would love to hear from you.

Yesterday we kicked off our first Medical Devices specific seminar in Boston, with our friends from SterlingTech and Vector Software. The day was all about software development for medical devices and more specifically, about managing software risk to help ensure you are compliant with all of the FDA regulations specific to software code. We had a great turnout, with over 75% of registrants showing up for this session. A couple of observations I found interesting from this event:

• The medical devices community seems to be fairly tight-knit. Everyone at the event seemed to know everyone else, and there was definitely a strong support system in place among the companies in attendance.
• And secondly, there appears to be fairly high adoption of Agile practices, particularly Scrum (albeit somewhat modified), with these Medical device companies, and the healthcare industry in general for that matter. From everything I heard, this adoption curve shows no signs of slowing down.

If IEC 62304 is important to your organization, you might want to check out this half-day seminar. The next one will be in Minneapolis in January. I’ll be packing my woolies for that one!

Main topic of today is using Agile in an FDA regulated medical device context. Sounds like an impossibility I know, but the folks from Agiletek and Abbott presented a very interesting case study on how they did it. They started off by presenting “the way it used to work”, highlighting an older product development cycle from the 1990s that had very strictly defined dev phases, including a 10-12 week integration cycle – yikes! When they decided to implement Agile on a more recent project they broke up their 3-5 year dev cycle in 6 week iterations. Here were the biggest barriers they found to achieving this:

• Documentation – they tackled this topic upfront. There is a perception that the FDA wants truckloads of docs from medical device manufacturers. The reality is, according to the presenters, that’s not the case… the FDA wants “enough” documentation to demonstrate your process (“least burdensome” in FDA-speak). The biggest area is of course documenting requirements which they did through a Capability Matrix.
• Requirements – this required a big culture shift. They talked about past projects with 14 month requirements definition phases… which still didn’t capture everything! Now, they realize it’s a myth that all the req’ts can be defined upfront, and as the gentleman from Abbott stated: “Your requirements are final when the product is retired from market.”
• Software verification and validation (V&V) – they emphasized a risk-based approach. Run code inspections and reviews on the most critical areas of code. Keep your requirements focused and high-level so testers are testing the important stuff.

Anyway, here are the results they found by modernizing their development with Agile: higher visibility, lower costs (estimated schedule and team size reduction of 20-30%), higher quality product (availability of working software allows for continuous V&V), and overall the project had a steady pace to it rather than mad integration scrambles or backend V&V chaos.

The one big aspect of Agile they weren’t able to implement is the customer feedback component. This is mainly due to the limitations med device companies have around “pre-marketing” their product.

All in all, a very interesting case study. Be interested to hear where anyone else has seen this done in a highly regulated environment.  Signing off from Agile 2009… be sure to follow us on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich

Off to Agile 2009 next week in Chicago where Klocwork will be both attending and exhibiting at the conference. We’ll blog throughout the week to keep people updated and let you know the latest. There are a few sessions in particular that we’ll be sure to report on and let readers know anything useful we learned (or not):

• Adopting Agile in an FDA Regulated Environment
• Java and Ruby Tools for Code Quality
• Effective Code Reviews in Agile Teams
• Zen and the Art of Software Quality
• Scrum and CMMI – from Good to Great

Be sure to check back often!