Using agile methods in medical device development

For over a decade, software teams have benefited from agile development methods, where solutions evolve through iterative and incremental delivery using self-organizing, cross-functional teams of generalizing specialist. The generalizing specialist is someone with one or more technical specialties (e.g. developer, tester, requirements engineer, etc.) who actively seek to gain new skills in these existing specialties and in other areas. Agile promotes adaptive planning, time-boxing, evolutionary architecture, high quality, and encourages rapid and flexible response to change. Everyone on the team does whatever it takes to develop the solution, crossing traditional functional boundaries. Agile teams avoid using specialist, who focus solely on one discipline to prevent what has become to be known as "waiting on a specialist."

[Get a 10% discount on ARM TechCon 2012 conference passes by using promo code EDIT. Click here to learn about the show and register.]

Traditional, non-agile approaches typically follow a "relay race" paradigm with one group of specialist passing the "baton" to the next group of specialist. Under this approach, the project goes sequentially from phase to phase: concept, feasibility, design, development, implementation and production. This is known as the "waterfall" approach. Under this method, functions are specialized and segmented. Testing and integration are typically performed only in the later phases of the project so that problems are frequently discovered late. This makes products late and also adds to the expense of fixing the issues. In medical device development, the advantage of traditional approaches is to allow requirements to be developed up front, which helps regulatory agencies sign off before development is done. This article will discuss how medical device companies can use new techniques and still meet regulatory needs.

In order to understand how to meet regulatory needs you have to first understand what the regulators are looking for. The FDA and other regulatory agencies fundamentally want to see that your product has safety in mind. To do so, they require complete traceability through the hardware and software. There is even a fairly new standard, IEC 62304, adopted worldwide that is wholly focused on software traceability from requirements through architecture to tests. These requirements and others mean we need traceability and reporting we typically only see in heavy weight processes like waterfall.

Medical devices companies are going primarily agile to respond to change and effectively manage technical complexity by collaboratively building solutions with their partners and customers to ultimately deliver what the customer wants before the competition does.

. Using agile methods, the team builds features iteratively using small chunks of functionality (Stories) that are implemented during each iteration. Traceability is manageable since requirements, functional specs and designs are developed iteratively. Compliance documentation and artifacts are continually revised and kept up to date as the system evolves. Agile engineering techniques such as Test Driven Development (TDD) and Behavioral Driven Development (BDD) turn requirements and design into tests that enforces clarity, reveals implied requirements. Traceability and quality is built in.