Medical device software development: Waterfall or Agile?

SaMD product development is the process of creating through UX design and engineering software for medical purposes. This process must be rigorous and adhere to strict quality and safety standards. If you’re keen on understanding the stages involved, check out our previous article outlining the 5 phases of SaMD development. These phases ensure that your medical device software development journey aligns with all the regulations while meeting patients needs.

In the medical device industry, the Waterfall methodology has been a traditional approach for medical device hardware development. The Waterfall works in sequential phases, where each phase must be completed before moving to the next. The Waterfall methodology provides a clear, structured approach that can be especially beneficial when developing a complex medical device hardware with well-defined requirements and goals especially when we talk about hardware.

While this approach offers a structured path for medical device engineering, it’s not always the best fit for the fast-paced and evolving nature of Software as a Medical Device.

The Waterfall methodology follows a linear, sequential flow of stages, much like a waterfall cascading down from one step to the next. You start at the top with the conception of the project, then you flow down through the stages of initiation, analysis, design, development, testing, implementation, and maintenance.

The defining characteristic of Waterfall is that each stage must be completed before the next one begins, and there’s typically no going back to a previous stage without significant effort and cost.

The Waterfall methodology is linear, with each phase building on the previous one:

• Conception to Initiation: Setting the vision
• Analysis: Detailed exploration of needs and requirements
• Design: Crafting the solution blueprint
• Construction: Actual software development
• Testing: Ensuring the software meets requirements and is defect-free
• Production/Implementation: Deploying the software for users
• Maintenance: Ongoing support and updates

The Waterfall methodology is ideal for projects where requirements are well-understood and unlikely to change, such as some construction building projects, medical hardware projects or applications where the medical context and standards are fixed.

The Waterfall methodology is a linear and sequential approach used in medical device development. This model divides the project into discrete phases such as requirements, design, implementation, testing, and maintenance. Each phase relies heavily on the preceding one, meaning you can’t move to the next stage without completing the previous.

While the Waterfall method provides a well-structured framework for building hardware medical devices, it often falls short in flexibility when it comes to software as medical device development. This is a crucial point to consider, especially when comparing Waterfall or Agile for software as a medical device, a topic we’ll explore further in alignment with guidance on agile software development.

To illustrate how the Waterfall model works in SaMD development, let’s consider a hypothetical medical device software development project aimed at monitoring blood sugar levels. The project would begin with a rigorous requirements-gathering phase, followed by designing the software architecture. Only after these steps would the actual coding begin. Testing would occur after the software is built, leaving little room for changes or iterations.

While this example showcases a structured approach to medical device development, it also highlights why many are considering Agile as the optimal methodology to follow while developing software as medical device. Waterfall’s rigidity can be limiting when unforeseen changes or improvements are needed, a scenario where Agile medical device development can offer more flexibility while ensuring compliance with all the regulatory requirements.

Established in the early 2000s, Agile methodology was a response to traditional methodologies like Waterfall that often resulted in long development cycles and products that no longer met user needs by the time they were released. The Agile Manifesto encapsulated this fresh perspective, emphasizing flexibility, collaboration, and customer satisfaction and that’s why Agile is a go to methodology when developing SaMD.

Agile development is a way of working that seeks to harness change rather than resist it.  It is a flexible approach that values customer satisfaction through the continuous delivery of valuable software. Central to Agile is the concept of iterative development. Instead of extensive planning and a linear development path, Agile breaks tasks into smaller increments. These increments don’t require long-term planning, allowing teams to respond to feedback and change swiftly.

Cross-functional teams lie at the heart of Agile. These teams, encompassing a diverse set of skills, collaborate intensively on shared objectives. This collaboration ensures that software is developed holistically, with feedback loops that ensure continuous improvement.

In Agile, plans are adaptable. Rather than rigidly sticking to a set pathway, Agile teams are poised to respond to changing requirements, ensuring the end product is both of high quality and relevant.

At the heart of Agile methodology are four core values that serve to guide the processes and mindset of Agile teams:

Here’s a deeper look at the Agile process:

1. Product Vision: The process starts with defining a clear product vision that describes the overall goal and the problems the software aims to solve. It serves as the guiding light for the entire software as medical device development team and is used to inform decision-making throughout the project.
2. Gathering Requirements and Defining Product Backlog: A Product Owner, often in collaboration with stakeholders, gathers requirements based on the product vision. These requirements are transformed into a prioritized list called the Product Backlog. The backlog contains user stories, which are feature descriptions from the perspective of the user, bugs, and technical tasks. Each is assigned a priority based on its perceived value to the end user.

3. Sprint Planning: At the beginning of each sprint (a time-boxed iteration, usually 2-4 weeks long), a Sprint Planning meeting is held. In this meeting, the Development Team, Product Owner, and Scrum Master (the facilitator of the Scrum process) come together. The Product Owner presents the top-priority items from the Product Backlog, and the team collaboratively decides what they can commit to completing during the sprint based on their capacity and the estimated time for completion of each item. The result is the Sprint Backlog, which is a set of user stories and tasks the team commits to completing by the end of the sprint.

4. Daily Standups: During the sprint, the Development Team holds Daily Standup meetings, usually lasting around 15 minutes. In these meetings, each team member reports what they completed yesterday, what they will work on today, and whether they have any blockers. It’s a mechanism to ensure that the team is in sync and that any impediments are quickly identified and addressed.

5. Sprint Execution: The Development Team works on the items in the Sprint Backlog. They design, develop, test, and integrate new functionalities. Agile emphasizes producing a potentially shippable product increment at the end of each sprint.

6. Sprint Review:  At the end of each sprint, a Sprint Review meeting is held. In this meeting, the Development Team demonstrates the completed work to the Product Owner and other stakeholders. It’s a time to show what was accomplished during the sprint and to collect feedback that could result in changes to the Product Backlog.

7. Sprint Retrospective: After the Sprint Review, but before the next Sprint Planning meeting, the team holds a Sprint Retrospective. In this meeting, the team reflects on the past sprint to go over what went well and what didn’t, and decides on actions to improve in the next sprint. This is a key component of the continuous improvement that Agile frameworks encourage.

8. Backlog Refinement: In parallel to the sprints, the Product Owner, often with the help of the Development Team, continuously refines the Product Backlog, adding new items as necessary, and reprioritizing existing ones based on feedback and changing requirements.

Agile works very well in SaMD development. It offers a flexible framework that can adapt to the often unpredictable and complex nature of creating medical software. Guidance on Agile software development further reinforces that Agile methodology is compliant with regulatory expectations when properly executed. So, not only is Agile effective, but it fits well within the boundaries of FDA requirements.

The primary difference between Agile and Waterfall in healthcare, particularly in SaMD development, lies in their approach to project management and adaptability. The contrasting approaches of Agile and Waterfall in healthcare and SaMD development can significantly impact project outcomes. Waterfall’s linear and sequential nature means each stage must be fully completed before advancing to the next.

This approach can become a bottleneck in healthcare software development, especially in SaMD where regulatory guidelines and patient needs can change quickly. For example, when following Waterfall in Software as a Medical Device development, if new FDA regulations are released midway through the development cycle, or in case when the team defines that patients’ needs changed, adapting to these changes can be difficult and delay the entire project.

Agile, however, offers a much more flexible and adaptive framework. Agile medical device software development encourages frequent iterations and modifications, making it easier to incorporate sudden changes in user requirements, or any legal regulations.

When teams follow Agile methodology in software as medical device development, we can  often see how they can pivot or adapt at any stage of the project without having to change or delay the entire system. This flexible methodology is especially crucial for medical device software development where time-to-market, compliance, quality and patients needs are crucial.

When comparing the two approaches—Agile and Waterfall—for building software in the medical device field, it’s clear that Agile has a lot going for it. One big advantage is how flexible Agile is. In the Waterfall method, everything is planned out in advance and you follow a strict sequence of steps. The downside is that if something changes, like a new rule from the FDA or a new piece of tech you want to include, it’s really hard to go back and make those adjustments without messing up the whole project.

With Agile, you work in small parts, often called “sprints,” that let you test and change things as you go along. Because you’re always testing and getting feedback, you can quickly make changes. This is really useful in medical device software, including SaMD, where things can change fast—whether it’s an update to FDA guidance on Agile software development or a new medical finding that affects your project.

So, if you need to keep up with fast changes and still follow all the rules and guidelines, Agile is often the better choice for software as medical device projects. It’s a way of working that fits well with the demands and quick pace of the healthcare tech world.

Agile processes are not only compatible but can also align well with FDA regulations, specifically in the realm of Agile medical device development and SaMD. Adhering to FDA guidance on Agile software development is critical for ensuring compliance with regulatory standards.

One of the key advantages of Agile is its iterative approach, which allows for ongoing testing and quality assurance. This continuous loop of improvement is particularly beneficial for meeting the stringent FDA requirements that SaMD must adhere to. Therefore, by properly implementing Agile methodologies in line with FDA guidelines, organizations can achieve a robust and compliant framework when working on software as medical device development.

When it comes to medical device software development, Agile has increasingly become the go-to methodology. While Agile may appear complex at first glance, it actually offers the flexibility and adaptability needed in the fast-paced world of SaMD development. Following guidance on Agile software development, Agile methodology can effectively meet all regulatory requirements for SaMD. Unlike the Waterfall model, Agile allows for rapid iterations and adaptability to changes which helps SaMD manufacturers to develop software as medical device that meet patients’ needs and all the regulatory requirements.

If you have a SaMD idea and you are looking for a partner to help build it, you’ve come to the right place. HTD works with customers to design and develop Software as Medical Device, ensuring that products meet all regulatory and patient experience requirements. With nearly a decade of experience building impactful digital health solutions, our team can help you turn your idea into reality.

Reach out to us at info@htdhealth.com to schedule a free consultation with a specialist today.