In issue 10 of Insight, Ben Wicks referred to the potential commercial advantage that companies developing medical devices might gain by being ‘agile’. There are many ways in which this might be interpreted, and in this article I would like to consider what agile can mean in the world of medical product development. Anyone familiar with modern software engineering practices will I’m sure already recognise the relevance of Agile in the development of software applications, but let us take a deep breath and look beyond software to consider the benefits that might be gained by applying Agile to the development of physical medical devices.
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.
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.
Figure 1: 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 below. 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 sub-set of the user needs. Done well, Agile can provide a number of benefits over a more traditional, sequential product development approach, including:
Speed to market – a working product is delivered more quickly and successive iterations can be delivered frequently at a regular pace.
Closer communication – Agile can promote closer collaboration between developers and the business. Agile also provides a highly transparent approach to working, in terms of activity, progress and issues.
Flexibility – changes to requirements can be incorporated at any point of the process – even late in development.
Robustness – the feedback mechanism inherent in most agile practices provides a good opportunity for continuous improvement.
Figure 2: 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. However, 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 has shown that it can be 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.
There would undoubtedly be many more 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 product within the 2-3 week sprints that software developers can work to.
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 mind-set of welcoming change.
However, look closely at the 12 principles of Agile and substitute product for software, and most business owners, regulators and developers would agree that – whilst hard to do – these are all good things to apply!
Figure 3: 12 Guiding Principles of Agile
In September 2016, 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 a medical system development and emphasised the close alignment with modern system 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 development of their 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.
For example, an organisation could use Agile practices 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.
Figure 4: The above are based on the Agile Manifesto
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. A linear Gantt has its downsides, but most developers and business stakeholders can easily align expectations in terms 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.
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, see below). 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!).
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
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.
Unfortunately Agile can also be seen as an excuse for having poorly controlled product development processes, which clearly should have no place in the medical product development world. But 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.
