How to Use Agile Frameworks in the Medical Device Industry

“If it’s not broken, don’t fix it” is a widespread mindset in highly regulated industries. While change aversion has its place in preventing unnecessary risks, it also impedes progress and innovation in the development of life-sustaining devices, such as insulin pumps and pacemakers. 

Having spent the majority of my career in medical device development, I’ve been told time and again that I must follow specific processes or use particular tools. The reasons range from “that’s how it has always been done,” to “it ensures we’re compliant with the FDA,” or “if there were a better way, we would have figured it out by now.” Reluctance to refactor functional code to prevent bug introduction is reasonable, but the resistance towards utilizing well-known and effective agile frameworks is stifling innovation in an industry that desperately needs it. 

If agile frameworks are known to increase productivity, foster predictability, and improve software quality (all of which are highly valued in medical device development), why aren’t many medical device companies changing their processes to take advantage of such frameworks? Many people in the medical device industry argue that agile frameworks don’t fit well with regulated product development, unlike consumer products and services developed by tech giants, such as Google, Apple, Amazon, and Microsoft. However, the principles behind the Agile Manifesto align with software development in medical device industries more closely than most people think.

Principles Behind the Agile Manifesto and Medical Device Development

The Agile Manifesto, based on a series of principles, emphasizes satisfying customers, delivering working software frequently, encouraging collaboration, and empowering individuals to get work done. Medical device companies echo these values, but at first glance, the manifesto may seem to contradict some values in medical device industries. 

The Agile Manifesto states the following:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

However, this isn’t to say agile frameworks don’t value processes, tools, documentation, contract negotiation, and following a plan. Instead, it means that when a conflict in values arise, individuals and interactions, working software, customer collaboration, and responding to change come first. 

For example, it encourages us to do what makes sense, instead of doing things “because that’s how they’ve always been done.” It also requires us to deliver the proof in the pudding and hold ourselves accountable by frequently providing working software. 

Besides, delivering working software early and often allows testers to work in parallel with developers, creating a feedback loop to find bugs early and fix them as they’re discovered. Many medical device engineers claim that they’re in it for the benefit of the patients, and the Agile Manifesto ensures customer feedback is incorporated into the product. 

Most importantly, agile frameworks enable the product team to respond to changes throughout development. Any engineer would be naive to think it’s ever perfect the first time.

Applying the Agile Methodology in the Medical Device Industry

Of course, this all sounds intuitive, but is it practical? If you haven’t completely disregarded the idea of applying agile frameworks in medical device development, you’re likely and understandably brimming with questions and concerns. 

Here are just a few that I’ve come across when pushing to use agile frameworks at previous companies:

Don’t medical devices require up-front requirements definitions? 

To some extent, yes. Defining requirements up front is acceptable, primarily to accommodate tasks such as risk analysis, and agile frameworks don’t disallow you to do so. On the contrary, agile frameworks support embracing changes to requirements as they come and ensure you’ve planned for a change. 

Avoid the analysis paralysis that results from trying to perfect requirements the first time around. Spoiler: they won’t be anyway! Design and implementation early in the development process will help you identify flaws and challenges earlier in the process and allow you to pivot accordingly.

How many times have you followed the waterfall process without having to loop back to a previous step? I’d be willing to bet not many.

Doesn’t the FDA require extensive documentation during product submissions and audits? 

Most definitely. As I touched on earlier, agile frameworks don’t disregard documentation; they just value working software more. Simply put, ensuring your work is documented and traceable is required, but generating documents to create more documentation is not.

I know someone whose organization tried going “agile” and failed miserably… I don’t want to make the same mistake!

I, too, have heard of many teams that were unsuccessful in their attempts to deploy agile frameworks. I’ve been a part of such a team. I found that in many cases, the groups that fall short are those that pick and choose bits and pieces of agile frameworks to employ. 

For example, a mix between waterfall and agile, sometimes known as “agile-fall,” is a common direction for many teams transitioning from traditional waterfall processes. The inherent danger in cherry-picking is ending up with a process that allows you to reap a few agile benefits and, instead, gain overhead and/or challenges. Agile frameworks are effective if employed appropriately. If your organization is looking to transition to an agile framework, it would be wise to invest in an agile coach to ensure your success.

There are so many agile frameworks to choose from! Where do I start?

This is something that is up to you and your team to decide. Fortunately, there are many online resources to describe XP, Kanban, Scrum, and other agile frameworks. Scrum is the most popular agile framework, as it’s the most natural to transition to from a traditional waterfall process, but every team is different. I encourage you to try one or more of these processes and see what works for your team! As mentioned previously, if you need a little more guidance, invest in an agile coach to help you get started.

While I’m sure there are many other questions and concerns, I can only speak to my research, observations, and experiences. Having worked with many teams in several divisions of some of the most well-known medical companies in the country, I have experienced teams that refused to change, teams that tried and failed, and, of course, teams that have succeeded and continue to reap the benefits of improving their processes to become agile. Now, as a consultant, I have the privilege to assist client teams (many of which are medical device companies) transition to using Scrum and watching it transform the way their team works for the better.