Agile Medical Device Development: Do or Don’t?
Today, software development is predominantly applying Agile practices. Scaling agile from a couple of teams to hundreds or even thousands of people, developing software in different locations world-wide is today’s challenge.
Medical devices however do not only consist of software. Hardware is also an important element to develop and so is compliancy to regulatory standards. Compliancy in the form of a Design History File (DHF) and a Quality Management System (QMS) are important deliverables to demonstrate compliancy and “must-haves” in releasing the device to the market. The question arises whether Agile practices can also improve the development of hardware and compliancy dossiers.
In a recent survey among medical device development professionals, we tried to find an answer to the question “Agile Medical Device Development: Do or Don’t”.
The following questions were asked in the survey:
- Are you familiar with Agile?
- Are you familiar with the Scaled Agile Framework (SAFe ®)?
- Agile development for medical devices can be successfully applied to?
- What is the biggest challenge to adopt Agile in your organization?
- Do you think Agile can help improve the adoption of engineering tools?
Are you familiar with Agile?
The survey shows that the majority of the medical device development professionals are familiar with Agile and apply it in their day to day activities. Many of the organizations are applying Agile only to software development. In total you can conclude that the vast majority – 82% – of medical device professionals apply Agile methods & practices.
Agile at team level – Scrum
Among the medical device professionals, Scrum is predominantly used as an Agile method (78%). Scrum is an agile method to implement agile at a team level. As a result, we can conclude that agile is mostly used at team level and has not been scaled to implement cross-domain alignment and collaboration.
Are you familiar with the Scaled Agile Framework (SAFe ®)?
The Scaled Agile Framework (SAFe®) is one of the most adopted frameworks to scale Agile development to a large number of teams and ensure a cross-team cadence and synchronization.
No Agile at Scale
Looking at the usage of one of the most popular agile scaling frameworks, SAFe®, none of the survey participants has implemented this framework. Moreover, 75% of the attendees has never heard about SAFe and only 25% has heard about. The conclusion is that medical device development is not yet applying scaled agile methods and practices to align a large number of teams during the development process.
Agile development for medical devices can be successfully applied to …?
The previous questions were predominantly focused on identifying to what extent Agile has entered the development processes for medical devices.
The next questions are much more focused on identifying what the respondents think is possible in the future with regards to adopting and implementing Agile methods and practices in their organization.
Agile all the way
It is therefore interesting to see that 64% of the respondents think that Agile can be successfully implemented for all aspects of medical device development, including software, hardware and compliancy (Design History File and Quality Management System).
Currently, most of the respondents still use waterfall-oriented methods to develop the compliancy deliverables. One of the respondents said, that this results in a bottleneck to adopt Agile across all aspects of medical device development. If you are delivering the product (e.g. compliancy deliverables) in a waterfall-oriented method, it is hard to profit from the benefits of Agile development. You must take the whole value stream into account.
What is the biggest challenge to adopt Agile in your organization?
To the question what the biggest challenge is to adopt Agile in their organizations, more than half of the respondents view management support and endorsement of Agile as the biggest hurdle.
Removing the silos and creating cross-functional teams is the second largest challenge within medical device development. This one is related to the first challenge, because if management doesn’t endorse Agile, they are not open to change the organization from a control-oriented structure to a value-driven structure.
Interesting to see is that the respondents don’t see combining software and hardware development as a challenge at all. This seems to contradict with the second biggest challenge of breaking the silos and building cross-functional teams. However, in the discussion with the respondents it appeared that integrating other disciplines in the agile process, such as compliancy (DHF & QMS), is much more challenging.
Do you think Agile can help improve the adoption of engineering tools?
In discussions with the respondents it became clear the adoption of Product Line Engineering tools in organizations has many challenges. But they think that adopting a common process, such as Agile, could improve the adoption of tools to support and drive the product development process.
Engineers love their tools and don’t like to switch to something else, unless it makes their job a lot easier. The issue with this is that a lot of engineers are sticking do their own tools not realizing that this creates lots of delays and rework during the total development cycle of medical devices.
In addition, it makes the creation of a consistent Design History File a challenging job with a lot of converting and reformatting of information, delaying the time-to-market of the medical device.
What is required to successfully apply Agile to medical device development?
To successfully transform from a traditional project-oriented organization to an agile development organization requires some fundamental changes which truly take another approach to the same problem. These changes may feel like the world upside down comparing to what is used to be done in a traditional project organization. These mindset changes can be divided into three groups: organization, process and content.
- Organization
- Resource allocation
- Organizational structure
- Process
- Flow of value
- Cross-team collaboration
- Content
- Continu-ish integration
- Solution intent
Each mindset change is explained in 3 follow-up articles, which will appear in this blog area, so stay tuned.
