“Agile” consists of a philosophy as well as multiple methods. The most well-known method and what most people associate with agile is the highly iterative scrum method, where scrum teams operate in 2-4 week sprints with daily meetings (scrums). Other agile methods are test-driven development, continuous integration, automated unit testing, planning poker, and pair programming.
Many companies have found that agile methods provide multiple benefits:
- Better visibility of software projects to all the stakeholders
- Increased software productivity
- Increased flexibility in responding to changing user needs
- More predictability of software releases (decrease in software project risks)
- Improved quality of released software
Despite these benefits, agile methods have not been adopted widely in the highly regulated medical device industry. Described below are the 3 main challenges to adopting agile methods for medical device software development, listed in increasing order of difficulty (in my opinion):
1. Concerns about regulatory compliance
On the surface these highly iterative, non-linear agile methods, which emphasize rapid execution over careful planning and documentation, seem antithetical to FDA-mandated design controls. However, that’s partly because of a misperception of regulations and standards—even though they are generally presented in a linear, waterfall style, that doesn’t mean they have to be implemented that way. And, if properly implemented, agile methods can actually enhance compliance for product development. Because agile teams are required to integrate and test their software at frequent intervals, there are many opportunities to discover design flaws early. By contrast, a traditional waterfall/linear approach to software development tends to drive discovery of important design flaws until late in development, especially problems involving HW-SW integration, interfaces with other devices (i.e. wireless communication), and usability. Design flaws discovered earlier in development mean less chance of one popping up late in development when the cost of fixing it can be many times greater and can undermine carefully written DHF documentation. Because medical devices are highly regulated, the importance of avoiding late-breaking design flaws is even greater than in non-regulated industries. Therefore, agile methods are potentially even more valuable for medical device companies.
There are two important considerations that are key to maintaining regulatory compliance when transitioning to agile methods:
- Agile methods may need some adjustments to fit with medical device design controls. Don’t assume that methods described in books and articles from non-regulated industries can be directly applied to your medical device development (a common source of confusion). For example, many agile teams do away with software requirements and rely only on user stories to drive development sprint-to-sprint. This may be efficient but it is not an option for medical device software development. Regulators expect detailed, traceable software requirements and you will need to integrate this rigor into your agile processes. [Author’s 2023 update: the FDA has recently broadened its definition of software requirements to include “…well elaborated stories, use cases, textual descriptions, screen mockups, and data flows …” and the TIR45 software guidance considers user stories as acceptable software requirements. So a software team could define their software requirements as a set of user stories as long as (1) they have unique identifiers for traceability, (2) are approved in formal documentation, and (3) are maintained for the life of the product.]
- Your quality system procedures will likely need revisions to support and integrate with agile methods. For example, regulations do not mandate that you complete all the software requirements before starting on software design and coding but your own quality system may require this (all design inputs completed before proceeding to design outputs). A thorough analysis of affected portions of your quality system should be part of any transition to using agile methods.
Fortunately, there is an excellent guidance document from AAMI on how to balance the streamlined efficiency of agile methods with rigorous compliance to FDA design controls and the IEC 62304 standard:
AAMI TIR45:2012 – Guidance on Use of Agile for Medical Device Software
I recommend anyone contemplating adoption of agile methods to start with this guidance—it is well worth the purchase price (and recognized by FDA).
One last note about compliance: agile methods can produce large gains in productivity by, among other things, eliminating unnecessary software documentation. The key thing to understand in this statement is what documentation is unnecessary—medical device software entails a great deal more necessary documentation (for compliance) than in non-regulated fields.
2. Integration of HW and SW development
How can an agile software team deliver new embedded software every 2 weeks if it’s going to take 16 weeks for the first prototype hardware to be ready? Questions like this illustrate the challenges of integrating rapid software development with development of the complex hardware often needed for medical devices. Agile methods will still work in this environment but additional measures are needed to structure product development so that a software team can be running software from the beginning. Some approaches I’ve seen used successfully in multiple projects are:
- Off-the- shelf development boards
- Desktop HW simulators
- Test beds with partial HW functionality
- Re-use of platform HW from previous products
Many of these test platforms can still be valuable later in development when actual product hardware is available by, for example, supporting SW unit testing and automated testing of new builds.
For more information on integrating agile software methods with hardware development, take a look at this set of blog postings:
www.playbookhq.co/blog/agileinhardwarenewproductdevelopment/
And the Scaled Agile Framework (SAFe) provides a proven approach to development of larger hardware-software systems:
3. Organizational Change
This I believe is the most difficult set of challenges for adopting agile methods. Changing the way an organization operates is always difficult and runs the risk of making things worse instead of better. Despite its many advantages, agile is not a panacea; it won’t solve underlying organizational problems—it will often just make those problems more prominent. That may be one reason why some people feel ‘burned’ by an initiative to adopt agile at their company (just do a search on “fake agile” to see how widespread negative experiences are). Those larger organization problems, such as poor product strategy or insufficient staffing, need to be tackled first if agile methods are going to be successful.
Most of us don’t want to be told that we have to change the way we do our work so we need a really good reason to change. Any initiative to adopt agile methods needs to start with a clear agreement on the problem(s) to be solved; an agreement that includes all of the stakeholders in product development (not just the SW engineers). This problem statement serves as both the driving rationale for change and the focus to avoid unreasonable expectations (‘agile hype’). For example, the product development group could focus on reducing the number of software defects at key milestones or on improving the predictability of their software releases.
The most important consideration for dealing with the organizational challenges of adopting agile methods is to think of agile as a continuum and not a binary state—the organization steadily becomes more agile instead of is/is not agile. This means thinking of change in terms of months and years, not weeks. This more gradual or iterative approach is especially important for larger organizations. The Plan-Do- Check-Adjust (PDCA) of the Deming cycle is a good framework for managing adoption of agile methods. The company can start off with a limited, targeted change in software development (for example a hybrid of agile/waterfall methods) and then build on that over time. At a medical device company this makes it easier to manage changes to the quality system which need to accompany the adoption of agile methods. Finally, this gradual, iterative approach provides the necessary confidence in the new methods (and sufficient time) to support big structural changes in the organization such as changing titles, changing reporting relationships, and changing responsibilities.
Overcoming all of these challenges in adopting agile methods for medical device development is difficult but well worth it—the benefits are many and long-lasting for companies that are willing to invest in these changes.
Resources
After more than 20 years, agile methods for software development are well-established, with extensive information and expertise available for anyone who wants to adopt them:
- https://www.agilealliance.org/ – Agile Alliance is a non-profit organization; good material for beginners (Agile 101) and many articles and links
- https://www.scrumalliance.org – Scrum Alliance is a non-profit organization; has many articles and links on scrum and other agile methods
- http://agilemanifesto.org/ – Manifesto for Agile Software Development
- http://playbookhq.co/blog/ – excellent blog postings on concepts and methods for agile (and lean) product development; links to lots of additional resources
- https://www.mountaingoatsoftware.com/agile – extensive set of blog postings on multiple aspects of agile software development by consultant Mike Cohn
- http://www.scaledagileframework.com/ – Scaled Agile Framework (SAFe) a management system for large scale projects
- https://less.works/ – Large Scale Scrum (LeSS) framework for large scale projects
Originally posted on 4/6/17 at http://consensiainc.com/2017/04/06/challenges-adopting-agile-methods-for-medical-device-software-development/