Article

4 Keys To Accelerate Development for MedDevice Software

Bernhard Kappe

Published on: August 4th, 2015

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

I spend a fair amount of time talking to R&D directors and heads of innovation at medical device companies many of whom acknowledge feeling pressure to accelerate their product development efforts. Many are starting to extend their products with mobile, cloud and analytics software. In these areas, the pace of innovation can be significantly faster, and traditional players with 3 to 5-year product cycles are being threatened by more nimble players who can release products in as little as 6 months.

The more nimble players achieve this through streamlined processes that take advantage of agile and lean techniques and a high degree of automation.

Orthogonal is among a growing number of companies in the industry that have successfully used Agile on large-scale medical device software product development projects.

When it’s done right, using Agile can increase project velocity, quality, and maintainability. Done wrong, it can be as much of a mess (or more) as any other process.

In our case, there are a couple of keys to making it work:

Implement a clear, patient risk-based prioritization of features, and iterative efforts to mitigate or eliminate those risks. This needs to be an ongoing effort since not all risk can be fully known and mitigated at the outset. Quoting ISO 14971: “Risk can be introduced throughout the product lifecycle, and risks that become apparent at one point in the lifecycle can be managed by action taken at a completely different point in the lifecycle.”
Do enough prototyping, technology and integration spikes before you start development under design controls. This lets you surface missing requirements, usability issues, suboptimal designs, and architecture, then addresses them quickly, before more costly development processes start.
Incorporate verification and validation into the Agile process. In a classic waterfall approach, developers interpret requirements and specifications in one way, and then later, verification protocols interpret them another way. It’s easy to then end up in “verification hell,” where there are significant time delays and cost overruns as these differences get sorted out. If, instead, you extend test-driven development so that verification protocols are written first and then the code is developed to pass the tests (what we call “verification driven development”), you save yourself a lot of time and aggravation.
Automate. In a well-run Agile project, you will have as close to 100% code coverage as possible. You should include verification protocols as part of that code coverage. This way, when you check code into your continuous integration environment, you will know if any tests are broken. The longer it takes to find an initial bug, the more chance it has to propagate and interact with other parts of the code, and the longer it takes to diagnose and fix. Automation shortens the time it takes to get to bug discovery, bug analysis, fix and verification. It’s a huge time-saver.

Automation also has other benefits. For instance, it makes maintenance a lot easier. We do a lot of projects that incorporate mobile, web and server/cloud based technologies, and the underlying platforms are updated very frequently. Automation lets you see what, if anything, breaks based on your changes, and lets you fix them quickly. This can move your turnaround from weeks or months to days or hours, especially if you automate traceability.

I’m looking forward to hearing from others about what has worked, what hasn’t, where the challenges are, and where you should or shouldn’t use Agile.