Developing software for medical devices, whether it is SaMD or SiMD, presents a unique set of challenges, particularly when balancing Agile methodologies with regulatory and standard requirements such as IEC 62304.
Stakeholders across quality, regulatory, and development functions all have specific expectations—not only for working software, but also for the documentation and processes that support safe and compliant products.
In this article, we explore what key stakeholders need from your software development process and how you can meet those needs effectively while still embracing the principles of the Manifesto for Agile Software Development and guidance from AAMI TIR45 by using an Agile software development process.
The Agile Manifesto outlines four core values:
At first glance, these values may seem at odds with what is traditionally considered essential in medical device development; structured processes, thorough documentation, formal contracts, and detailed planning.
But the Manifesto for Agile Software Development doesn’t reject these things. It simply states a preference: that while the items on the right are valuable, the items on the left are valued more.
Agile does not promote uncontrolled or sloppy development. When applied correctly, its principles can enhance collaboration, maintain compliance, and improve the speed and clarity of decision-making within a well-defined quality system.
A common mistake in medical device software development is adopting Agile principles for the development team while maintaining a traditional waterfall approach for oversight and control. This often results in a hybrid approach sometimes referred to as “Wagile,” which tends to combine the disadvantages of both methods rather than the benefits.
In Scrum-based development, stakeholders are typically invited to review outcomes after each sprint. However, rejecting results at this stage is inefficient. Instead, key stakeholders should be actively involved throughout the development process.
This can be achieved by including stakeholders, such as regulatory and quality personnel, in early task identification. When non-product-related work, such as documentation or risk assessments, is delayed until the end, it often leads to inefficiency and rework.
For example, in Scrum, quality and regulatory staff can contribute tasks directly to the product backlog, making it the single source of truth for the team. They should also participate in sprint planning to help prioritise work items and ensure the right balance of deliverables.
If the quality department is involved in testing, there is no reason to wait until the end of the sprint to begin testing. Providing feedback during development is far more effective, especially when the design is still fresh in the developers’ minds.
Before focusing on the quality and regulatory roles, it’s worth clarifying what “stakeholders” mean in the context of software for medical devices.
According to AAMI TIR45:
a stakeholder loosely refers to anyone outside the Scrum team who has an interest in the product that the team is producing; stakeholder can include but are not limited to direct managers, subject matter experts, account managers, salespeople, legal officers, and customers.
Accurately identifying stakeholders is critical, as their combined knowledge and authority should be sufficient to make informed decisions throughout the product development process.
Managing stakeholder involvement is also essential, and this is where the product owner plays a key role.
Depending on which definition you read, you might come away thinking the product owner is expected to have superpowers. The Scrum Guide defines the role as follows:
The product owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
“Maximising the value of the product” is a major responsibility in itself, but the product owner is also accountable for managing the product backlog. This includes:
In a regulated environment, the role also comes with additional responsibilities. The product owner must ensure that regulatory deliverables are not deprioritised in favour of short-term feature gains.
Ultimately, the product owner helps balance clinical safety, user needs, business goals, and compliance. This is no small task.
One of the most important skills a product owner can bring to a regulated Agile environment is strong communication. This includes gathering stakeholder requirements, identifying resource needs, and clearly articulating goals to the development team.
In a software for medical devices context, it also means understanding the importance of prioritising backlog items related to risk management and documentation, not just new features. This ability to bridge technical and regulatory perspectives is what turns a good product owner into a great one.
While Agile prioritises working software over comprehensive documentation, medical device development still requires evidence, traceability, and structured quality assurance. To meet these expectations, it helps to consider the distinct needs of three key groups:
By addressing the priorities of each group directly within your Agile process, you can deliver both innovation and compliance without compromise.
From a regulatory perspective, the key concern is traceability; being able to show what was done, when, and why. This includes design decisions, risk mitigations, and verification activities.
While Agile development emphasises working software over comprehensive documentation, regulatory expectations still require evidence.
IEC 62304 outlines the required documentation for software development, including the software development plan, architecture, requirements, tests, and problem resolution procedures. This framework remains relevant whether you follow Scrum, Kanban, or any other Agile approach.
“That way, compliance is not treated as a separate phase but as a continuous part of development”
The product owner and regulatory staff should work closely to ensure that documentation activities are planned and integrated into the backlog. That way, compliance is not treated as a separate phase but as a continuous part of development.
Quality assurance professionals are primarily concerned with process adherence and product quality. In a medical device context, this includes risk management, verification, and validation; each of which must be documented.
One common misconception is that Agile development cannot be aligned with the requirements of a quality management system (QMS). In reality, a well-defined QMS can fully support Agile practices if the process is clearly documented and followed.
Quality teams often require early involvement to define test strategies, review risk controls, and plan verification activities. When they’re included in sprint planning and backlog refinement, these tasks can be completed alongside feature development, rather than being left until the end.
Quality also plays a critical role in maintaining objective evidence throughout the project, not just at release.
While stakeholders outside the Scrum team tend to focus on documentation and compliance, the development team needs clarity, focus, and time to deliver.
In Agile projects, developers should not be isolated from regulatory or quality concerns. On the contrary, having developers understand risk management, usability requirements, and regulatory expectations can lead to more efficient implementation and fewer surprises later in the process.
Too many concurrent priorities or vague tasks can lead to waste. Developers benefit most from a well-structured backlog, maintained by a responsive product owner, along with early clarification of requirements and direct access to stakeholders for feedback. This keeps development focused and helps ensure regulatory needs aren’t overlooked.
Software for medical devices doesn’t exist in a vacuum. It must be safe, effective, usable, and documented. Achieving this within an Agile framework is not only possible but increasingly expected by stakeholders across functions.
The Manifesto for Agile Software Development and the guidance in AAMI TIR45 both emphasise collaboration, transparency, and responsiveness to change. These principles align well with medical device development when implemented with attention to stakeholder needs and regulatory requirements.
Ultimately, the success of your Agile implementation of your software for medical devices development process depends on how well you engage with your stakeholders, regardless of whether they work in regulatory affairs, quality assurance, or software development. The goal is not to choose between Agile and compliance, but to make them work together.
With our medical device software course selection, you can choose between Software for Medical devices and IEC 62304 and SaMD, IEC 62304 and IEC 82304-1 depending on your interest and need.
Already familiar with the standards and interested in Agile? See our Agile medical device software development course.
The courses are suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The courses do not cover actual coding.
Or if you’re looking for a tailored training to align with your company’s specific needs – contact us for inhouse training options.
Christian Kaestner is a consultant and entrepreneur with a wealth of knowledge about the medical device industry. He is an expert member of the project team authoring IEC62304 and also actively participated in the creation of IEC82304-1.
He has extensive experience of medical device development and, as a software developer, a strong dedication to software development. In the software domain he has worked in many roles such as software developer, project manager, auditing and quality management.
Receive FREE templates and quarterly updates on upcoming courses that can help you in your career! Subscribe to our newsletter now.
When you submit this form, you will be sending personal information to medicaldevicehq.com. To comply with GDPR requirements, we need your consent to store and use the personal data you submit. Take a look at our Privacy policy for more details.
Special launch offer: 349 299 EUR for the online plan & 449 349 EUR for the online lifetime plan.
