There have been many conversations over the years about whether our medical device design process could be enhanced by becoming more “agile”. Often the debate focuses on whether the typical Agile process implementations of Scrum, Kanban, Lean, Extreme Programming, and so-on are applicable and how to adapt them.

Although Agile development was defined specifically to optimize software development, the fundamental values that it is based upon seem to me to be equally relevant to medical device development.

Why Is Software Different?

The thing is, software development has some strikingly different characteristics compared to hardware development, even if that hardware has software in it. The most obvious difference is that to “build” an instance of a design in software is quick and virtually free. Building a hardware instance—a prototype—takes noticeable amounts of effort, cost and time. Software is also much less constrained than hardware. If a software “mechanism” does not work, you might code a new, more sophisticated one without too much impact to the overall architecture or business needs. In hardware, we’re far more constrained by limits like weight, size and cost, so the impact of such a change in hardware often has a knock-on effect that can undo a whole design. Due to these and other differences, many of the processes associated with Agile often seem ill suited to medical device development.

Back to Basics

Seeing as I’m the type of person who likes to explore problems from their basic principles, I thought that looking at Agile from such a standpoint might be helpful. At work we follow a basic principle of “enabling our clients’ success”, which often translates to developing the right medical device for our clients’ market, although often—especially for a startup—it means helping our clients maximize their value in time with their funding milestones. This principle applies to both internal and external clients. A basic principle that I personally use as a guide is to find and foster fun and interest in all the work that I do. So, what principles guide Agile?

The Four Values

The Agile Development movement was founded on four axioms that are collectively known as the Agile Manifesto. Each of these take the form of two related goals, the first of which is deemed more important than the other. That is to say the second goal of each axiom is subservient to the first. Before I dive into these four values, I should explain a few more things. In their original form, the Agile values are stated with minimal explanation, so what follows carries quite a bit of my own interpretation and bias. I’ve also tweaked them so they more directly address medical device development, instead of software.

Individuals Interactions over QMS

As medical device developers we understand the importance of having a quality management system (QMS) and all the tools we use to support it. I hope no one is fooled into thinking that simply following a QMS or using electronic document management tools will automatically ensure that we’ll develop a successful device. It seems clear to me that all value that is created during a development program is due to teams of people being creative and doing productive work.

With these two thoughts in mind, it seems clear that we should optimize our processes and tools to maximize the time that we all spend doing actual device development. Yes, it’s true that we have to work within a predictable, repeatable process that embodies all the various features that our regulatory bodies dictate. These are simply a means to an end, not an end in themselves.

Making the Best Medical Device over DHF Documentation

You might say I’ve hijacked this one completely in order to change the focus from just software to medical device development. For instance, I couldn’t help myself sticking the word “best” in there.

Time and again I see proposals that somehow suggest one can simply write a bunch of DHF documents and the results will be inherently valuable. It’s true that at some point all these documents have to be created, but they are all only artifacts of the activities associated with designing medical devices. If we have not done those activities properly or fully then the documentation is only half-baked.

Take, for example, a System Architecture: Before you produce the document, you actually need to design an architecture. It’s not something you just write down; it’s something you experiment with, something you kick against the wall and see if it breaks.

Similarly, truly understanding the real product requirements that support the intended use often requires exploring the problem from a number of varied perspectives: Human factors, clinical value, the business needs, technical uncertainty, safety, etc. This all takes a bunch of time, effort and experimentation. Only afterwards is it clear what the product really needs to be.

As a medical device developer I know that the products I work on will ultimately not be successful if I have not jumped through all the hoops that the regulations require. Part of that is documenting key milestones of the development process as evidence that we’ve done the job correctly. The final judgement of whether we’ve succeeded, however, is not passing a regulatory hurdle, but seeing the medical device launch into the market and our clients being successful.

Customer Collaboration over Contract Negotiation

I think this one is pretty obvious. We would all rather work constructively together than debate or defend why a particular task is in or out of scope or why a deliverable is either acceptable or not. Our clients invariably hold a body of knowledge that is crucial to the success of the program. Maintaining a transparent and positive communication channel during development makes it much easier and more fun to get the job done well.

In my experience, a particularly critical time in a statement of work (SOW) is towards the end. Most of the budget is used, the project may be on the verge of falling behind, and only now are we seeing how well our prototype works. The available budget to make improvements and correct any shortcomings is dwindling. It’s at this point that we all remind ourselves exactly what “done” looks like.

Spotting that the project is trending this way as early as possible is one way to avoid last minute negotiations. Discussing early in the SOW that we might end up in this position may allow us to make some decisions in advance, while we’re still in that rosy period where the budget is great and the possibilities endless. Somehow structuring the program to avoid going down the zero-sum road seems like a worthy goal.

Responding to Change over Following a Plan

If I’ve learned anything in my years developing medical devices, it’s that at the beginning, we have no clue what the real requirements are. This is actually part of the fun: Seeing the real medical, user and business needs reveal themselves.

Similarly, we can postulate that a particular architectural strategy is well suited to our problem, but it’s only when we try it that we learn the pitfalls. Designing the best medical device is a balancing act of optimizing all of the requirements we know, as well as adapting to those that present themselves later. This happens as we explore the problem more thoroughly, as technology is found to be unsuitable, and also when our clients’ business needs suddenly adapt to changing circumstances.

All of these events will likely happen over the course of a development program and we must adapt our plans to make the most of the situation.

What’s Next?

I’m interested to extrapolate these ideas into a set of working principles that apply to medical device development and see where that goes. Similarly, these axioms can be used as a yardstick for our current processes to see if they can be tweaked.

At the end of the day, it’s all about making our clients successful and designing some really great medical devices. If we can find a way to be more efficient and effective then that can’t be bad. If we can have fun along the way as well, so much the better!