Key takeaways
Written by Christian Kaestner, medical-device software expert and member of the IEC 62304 project team, with over 20 years of experience supporting manufacturers in regulated Agile development.
Developing software for medical devices, whether Software as a Medical Device (SaMD) or Software in a Medical Device (SiMD), using Agile principles brings unique challenges. Teams must balance Agile software development practices with regulatory frameworks and standards 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 that guide Agile software development:
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.
When applied correctly, its principles can enhance collaboration, maintain compliance, and improve the speed and clarity of decision-making within a well-defined quality management system (QMS).
Read our Illustrated Guide to Medical Device Software Development and IEC 62304 , a practical breakdown of how standalone and embedded software fit within regulatory frameworks.
Expert insight!
Based on experience training software teams under IEC 62304, we’ve seen that applying Agile correctly improves documentation consistency and traceability, not the opposite.
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,” that tends to combine the disadvantages of both methods rather than their 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 quality and regulatory roles, it’s important to clarify what stakeholders mean in a software for medical devices context.
According to AAMI TIR45:
Expert insight!
Based on experience training software teams under IEC 62304, we’ve seen that applying Agile correctly improves documentation consistency and traceability, not the opposite.
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,” that tends to combine the disadvantages of both methods rather than their 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 quality and regulatory roles, it’s important to clarify what stakeholders mean in a software for medical devices context.
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 the product owner plays a key role in this.
Depending on which definition you read, the product owner can seem like someone expected to have superpowers.
According to the Scrum Guide, the role is defined as:
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.
Expert insight!
In medical device development, maximising product value is not just about great functionality. It is about delivering a complete product, including the required documentation and evidence that it is safe and effective.
While Agile values working software over comprehensive documentation, medical device development still requires solid evidence, traceability, and structured quality assurance.
To meet these expectations, it helps to recognise the distinct needs of three key groups:
By addressing each group’s priorities directly within your Agile process, you can achieve 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.
Read our Illustrated Guide to Medical Device Software Development and IEC 62304, a practical breakdown of required documents, risk controls, and verification activities.
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.
Expert insight!
Treating compliance as a living process, rather than a final hurdle, keeps projects both audit-ready and Agile.
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.
Read our Illustrated Guide to Implementing and Maintaining a Medical Device Quality Management System (QMS), this article shows how QMS processes and Agile methods can work together.
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.
Expert insight!
The biggest disconnect between development and QA often stems from poor alignment on IEC 62304 requirements. Involving QA early in backlog planning helps identify requirements up front and prevent costly rework.
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.
Below are some of the most common questions we hear from teams developing software for medical devices.
IEC 62304 defines the software life-cycle processes for medical device development, ensuring traceability, risk management, and verification at every stage.
Yes. When applied correctly, Agile development can fully comply with medical device standards such as IEC 62304.
AAMI TIR45 provides practical guidance on using Agile methods in regulated environments. It encourages collaboration, transparency, and continuous stakeholder involvement.
Key stakeholders include regulatory staff, quality assurance teams, and developers. Each group contributes to safety, compliance, and ensuring the right product is developed.
The product owner balances clinical safety, user needs, business goals, and compliance requirements. In regulated environments, they must ensure that regulatory deliverables aren’t deprioritised.
Ongoing collaboration ensures that regulatory, quality, and development perspectives are aligned. As shown in our article and courses, early stakeholder involvement reduces rework and builds compliance into every sprint.
Integrating documentation tasks into the product backlog ensures compliance without slowing progress. This approach turns documentation into a continuous part of development, not a final step.
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.
