.png)
I’ve often heard the misconception that Agile Scrum does not fall in line with the Design Control requirements of the FDA or IEC 62304. Indeed, the regulatory agencies are all about design control - about processes, plans, and comprehensive documentation. The implication is that planning is first, followed by requirements, then architecture and design, coding, and test. Add to the mix that stakeholders want/need to know the cost of development up front. So the project will start with a huge Gantt chart.
But the Agile manifesto declares:
“Individuals and interactions over processes and tools”
“Working software over comprehensive documentation"
“Customer collaboration over contract negotiation”
“Responding to change over following a plan”
After developing software for over 30 years now, I can attest that, indeed, thinking that one can plan out the development of a device of any complexity into a sustainable Gantt chart is ludicrous. I still do it - I need to estimate how much development will cost (time and money) as part of our contracts, and a Gantt chart is the best tool to attempt to be accurate. I fill it out, trying to capture everything I can think of, but then basically tear it up a week or so into the project. The chart then becomes the tool to track the budget, and backlog reference.
And requirements? I have never seen a project whose requirements did not change midstream. Humans are simply not smart enough to be able to consider everything a device needs before it is built. We are not designing things that have been built before. You have industrial design, mechanical systems, chemistries, electrical, software, human factors, and more to consider. In any project, you give it your best shot based on the information you have, then modify, adjust, and reconsider later. Iterate and Evolve.
And what about the idea that every Sprint should output shippable software? Forget about that. It might work for web software, but for a medical device? Shoot for getting done what was planned in the Sprint.
So, what does TIR45 say?
TIR45 maps correlation of IEC 62304 and Agile in almost 60 pages of detail, but the essence is that all of the requirements of IEC62304 and the FDA can be met in the incremental/evolutionary methods of Agile. If you realize that IEC 62304 does not specify that any one activity must be complete before the other, you simply iterate and let the requirements evolve as the stakeholders desire. The specification has all sorts of diagrams with detailed mapping, but frankly, I do not think its mapping is really achievable. So instead, I recommend following the high-level concepts of the TIR45 specification:
1) Agile and regulatory perspectives both value high-quality software.
2) Align the goals of quality, productivity, and predictability to be supportive of one another.
3) Find the proper balance of what is valued.
4) Augment the discipline of necessary robust processes and tools with the discipline of a team that is responsible for its processes and practices.
5) Produce documentation that is valuable to both the development team and the regulatory stakeholders.
6) Apply Agile within the context of an established quality management system.
You might ask whether it is worth it to use Agile. The visibility and control Agile provides to the stakeholders, along with its inherent support of change, make it worthwhile. It supports the reality of project development. But your organization needs to make it fit your quality system, and your quality system needs to provide the flexibility to support iterative and evolutionary development.
Do you have a product that you need developed? Promenade offers extensive code frameworks and tools to facilitate and accelerate the development of your product while ensuring robust connectivity and quality.
