What are the benefits of using Agile in medical device development? Anyone familiar with modern software engineering practices will already recognise the relevance of Agile in the development of software applications, but what if we look beyond software to consider the benefits that might be gained from Agile medical device development?
For the developers of software applications, Agile is generally taken to refer to methods and practices associated with the Manifesto for Agile Software Development published by the Agile Alliance in 2001. This Manifesto, and the associated 12 principles of Agile software development, were born out of the real life limitations and challenges experienced with using traditional waterfall development methods when developing complex software systems.
Figure 1: 12 Guiding Principles of Agile
Instead of the extensive planning, requirements definition and analysis upfront normally associated with a waterfall development, Agile methodologies allow for evolving requirements over time by allowing cross-functional teams (covering the main software development functions of planners, designers, developers and testers) to work on successive iterations of the product, typically over fixed time periods.
For me, one of the key differences between an Agile approach and a more traditional waterfall approach is the extent to which requirements are defined and analysed in the initial stages of a product development. I believe this is why Agile has proven to be so popular for software development.
Trying to analyse the multiple pathways and interactions of a complex software system can actually be better performed by developing working code, to “make it real”. Where requirements can be well defined early in a development, Agile may offer little benefit over a traditional waterfall development approach. However, for organisations developing innovative medical products where this may not be the case, or where it is possible to flex scope and adopt an incremental release train, then Agile development practices may well offer advantages to organisations prepared to look beyond the traditional ways of developing a medical product.
Figure 2: A simplified view of a traditional waterfall development
Agile therefore relies on a more incremental and evolutionary approach than the sequential flow associated with a traditional waterfall development. A classic waterfall development process is illustrated above. This is a series of sequential steps that cover the entire development. In contrast, an Agile approach would seek to slice the development into a series of incremental design iterations, each building on the previous release and the feedback gained from actual use of a released, tested software product, as illustrated above.
One of the key principles behind the use of Agile for software development is to satisfy customer needs through the early and continuous delivery of working software. Agile provides regular and frequent releases of software that are viable products that satisfy a subset of the user needs. Done well, Agile can provide a number of benefits over a more traditional, sequential product development approach, including:
Figure 3: An Agile incremental development road map
At first sight, the use of an incremental approach with evolving requirements may seem to be a poor fit with the regulated world of medical device development, whether it is for the development of software as a medical device or for a physical medical product.
In 2012, The Association for the Advancement of Medical Instrumentation (AAMI) published TIR45:2012 “Guidance on the use of Agile practices in the development of medical device software”. This guidance showed that was possible for businesses to gain the benefits of using Agile practices in the development of medical device software while still maintaining compliance with international standards, including IEC 62304:2006 Medical device software –Software life cycle processes, and U.S. Food and Drug Administration (FDA) guidance documents. The most up-to-date guidance on Agile medical software development was published by the AAMI in 2023.
There are undoubtedly challenges associated with applying Agile beyond a software-only product development. While it is relatively straightforward to release working code at regular and frequent intervals, this is not necessarily the case when, for example, a development requires the release of several hundred mechanical drawings to multiple vendors. They will almost certainly not be able to provide specialist or custom products within 2-3 week sprints.
Planning is one of these challenges (when is predicting the future not a challenge?). When planning software development, we often estimate the complexity of a backlog of required software features using arbitrary story point units. This is used with the velocity (story points per sprint) at which a team has burned through story points in the past to generate a so-called ‘burn-up chart’. This gives us an estimate of the number of sprints likely to be needed to develop a software feature set (estimated as a total number of story points) at a given team velocity.
One of the biggest challenges in applying Agile successfully is the shift in mind-set away from what work needs doing, to what needs to be achieved. This can work against long standing organisational processes and so create inefficiencies. Agile methodologies (e.g. Scrum, XP, Kanban, Crystal, etc) are often more difficult to understand than linear, sequential methodologies (at least initially).
The terminology used (e.g. sprints, stories, epics, increments, release) is probably familiar to most software engineers but may have little meaning to a mechanical engineer or human factors specialist.
Hardware is also not as easy to change as software late in the development. In general, changing requirements late in a development doesn’t work well! Traditional medical device development has a need for lock down, which conflicts with the Agile mindset of welcoming change.
A linear Gantt has its downsides, but most developers and business stakeholders can easily align expectations in terms of what needs to be done, when by and with what dependencies. There is no such equivalent in Agile, but a Feature Gantt chart that focuses on the work (and not on the workers) can be very helpful in wider communication about progress and priorities. At the moment, we unfortunately have to do this manually, but it does allow planning to make sure other system elements (for example hardware or test infrastructure) are available so as not to block or delay software development. Similarly, we can estimate when velocity may drop due to external factors (such as holidays, hardware bring-up or system availability).
The above approach can lead to another challenge. In Agile medical device design, it is sometimes possible to flex the scope of what is delivered by a software development team (having a fixed velocity) and time period (each increment of software is intended to be working code).
In a non-Agile world, plans are often made to have something available at a certain time, for example, having a prototype ready for a key meeting or for a device going into a clinical trial. This typically doesn’t allow for the scope of what is to be developed to be flexed.
Taking out the option of flexing the scope of software features working at a given point in time puts more emphasis on getting the backlog estimate as accurate as possible. However, backlog features are often loosely defined early in a development and an Agile approach would look to refine the definition of these features incrementally as the development proceeds.
It is therefore advisable to factor in a greater contingency for estimation error when plans extend beyond 3 to 4 sprints in our experience. This may mean planning around a reduced set of software features needed for a key point in a project or building in contingency into the velocity of software development early in the project.
One common misconception associated with Agile is the lack of emphasis placed on documentation (this perhaps stems from a misinterpretation of the reference to documentation in the Agile Manifesto). However, there is no reason why the user stories used in Agile cannot be used to describe documentation as value adding features in exactly the same way that they describe product features (which also negates the need for a complex integrated Agile and requirements documentation management tool!).
A few years ago, AAMI ran a training course entitled “Agile for Medical System Development”. This course provided guidance on how Agile practices could be applied beyond software development. It was interesting to note that more than half of the attendees at this course were from large, well-known organisations in the MedTech world. The course looked at how the Scaled Agile Framework could be applied to medical device development and emphasised the close alignment with modern systems engineering practices, referencing work done on Agile systems by the International Council on Systems Engineering (INCOSE).
What was evident to me from this course is that Agile can provide similar benefits and improvements in medical product development, as well as the development of medical software applications. The key message is to apply the principles of Agile at the most appropriate stages in the development process and to do this systematically as a business improvement initiative.
Figure 4: The above are based on the Agile Manifesto
For example, an organisation could use Agile in medical device development to develop a set of user needs into a product that proves particular elements of technology, or to meet an investor milestone. Another approach may be to use Agile practices for a particular phase of development, such as translating user needs into product requirements (where the “product” developed may be a set of documents), or by generating user stories during the feasibility phases that will augment requirements documents and help developers during the detailed design phases.
As software developers following AAMI’s TIR45 guidelines are discovering, Agile practices can be used to provide effective controls in their development processes. When designing medical products Agile might provide clear advantages when the requirements aren’t clearly defined.
Looking for industry insights? Click below to get our opinions and thoughts into the world of medical devices and healthcare.
