Agile medical device development – what you should know

• In the software development field, agile methods have a proven track record over many years of facilitating faster, more efficient development. 

• When applied to the product development field, however, these methods throw up a number of challenges, particularly in terms of interdisciplinary collaboration. 

• The key here is effective communication and collaboration within the team, continuous system integration, and effective test automation to ensure that ongoing development work is regularly tested for regression. 

To enable faster development of blockbuster medical devices, more and more medtech businesses are employing agile methods and principles in their product development process.

Advantages include a clear and consistent market-focus, user-focused prioritisation, transparent management of development risks, and continuous technical integration. But agile product development also brings challenges. Here we discuss three challenges which frequently come up in our client projects – and offer tips on how to overcome them. 

In the software development field, agile methods and principles are already well established. That’s true even for regulated functional safety and medical technology products. When it comes to product development, however, applying these methods throws up a number of challenges. Product development requires collaboration across a number of disciplines, all of which need to understand and be understood by each other, to work closely together and to keep each other up to speed with what’s happening in their discipline. They also need to feel that they can rely on each other. In addition, agile product development projects tend to be more complex than software development projects, as they also involve continuous integration of physical system components. 

Below we discuss three major challenges and offer our tips for overcoming them. Incidentally, these challenges are not confined to the medical technology sector, but are also encountered in many other sectors. 

Effective communication within agile project teams is key 

When developers from different disciplines first work together, any initial novelty soon wears off, often giving way to a degree of scepticism. To electronics developers and mechanical engineers the way software developers go about their work can look chaotic and lacking in planning – simply not appropriate for serious hardware development. Conversely, software developers often see the lengthy mechanical engineering and electronics development cycles as slow and inflexible – simply not appropriate for serious agile development.  

Overcoming this mutual scepticism requires frank communication, and lots of it. It requires a willingness to understand the other’s point of view. It also requires each discipline to reflect on their own practice and to be willing to explain it to other disciplines. It’s not hard to understand that the cost of manufacturing means that a PCB or engineering prototype needs to be properly thought out beforehand. Or that longer lead times mean that software development will go through several iterations before the hardware components can be made available. Or that, to enable rapid implementation and testing of changing user requirements, software integration cycles are much shorter. 

A system glossary ensures frictionless communication 

The key to good communication is regular coordination (cf. Scrum). But equally important is agreeing a common language. Different ways of using technical terms can cause all sorts of communication difficulties. For a software developer, a prototype is something fairly trivial which can be readily discarded. This can cause some head-scratching among mechanical engineers, for whom a prototype represents an almost production-ready entity. 

This difficulty can be alleviated by employing a system glossary and making careful use of terminology. Developers should get into the habit of referring to prototypes, for example, as ‘software prototypes’ or ‘device prototypes’ respectively. They may initially find this usage unfamiliar and forced, but it quickly becomes second nature. This kind of common language is essential for reducing misunderstandings and facilitating communication between different disciplines.  

How can you apply agile methods and principles in your business? Register now for our webcast (in German language). 

The art of agile product development – striking a balance 

Two things need to be borne in mind when organising an agile development project. Firstly, individual functional groups should be integrated at the earliest possible stage. Secondly, no-one should be left waiting for deliverables from other disciplines. So, for example, early development might involve deploying the target processor on an evaluation board, to be replaced with an in-house motherboard once it has been developed. Or, until motor functionality has been implemented electronically and mechanically, you might use a bought in motor controller.  

The trick is to strike the right balance – to stick to the integration plan to ensure that the project progresses as intended, while maintaining the necessary flexibility to enable you to respond quickly to any challenges, particularly technical challenges. To this end, we recommend two tools, both more or less indispensable for successful agile product development – an integration vision and a system integration plan.  

The integration vision outlines the steps for integrating lab and functional models, prototypes, etc. A simple sketch specifying which components will be integrated when and at what degree of maturity (e.g. evaluation board, motherboard v0.1, motherboard v0.2) is sufficient. What an integration vision is not is a sequence of integration steps defined down to the last detail. Rather it represents a shared image of the intended vision and provides a shared basis for moving forward with the project. 

Getting started with agile product development 

Agile methods and principles offer huge potential for meeting today’s increasingly complex product development challenges. But as with all new methods, getting started involves a number of challenges. When starting out with agile methods and principles, our key recommendation is this: don't try to do everything in one go. Starting gradually with small, but consistent changes that deliver real benefits will get you to your goal quicker than a ‘big bang’ implementation – very much in keeping with the agile mindset. 

Our Agile Medical Device Development webcast offers practical tips for introducing agile methods and principles to your business and explores possible first steps. 
 

The system integration plan – the beating heart of agile product development 

The system integration plan, by contrast, specifies the technical steps needed to realise the integration vision. It is the fulcrum around which interdisciplinary system development turns, in that it defines the individual development steps, i.e. which components will be integrated at what stage of maturity and, most importantly, with what objective. The sequence of these steps is determined by the major technical risks and key system/user functions.  

It’s important to ensure that the system integration plan leaves room for integration steps to be postponed if necessary. That’s why only the immediately following steps should be planned in detail (think ‘backlog refinement’). More distant steps should initially be kept fairly vague. This preserves flexibility in responding to new insights and requirements. 

The key to success – test, test and test again 

By following the integration vision and system integration plan, a finished device comes into being incrementally, as per Scrum methodology. But this gives rise to a further challenge – each integration step needs to be tested for regression. And there’s no way around it, that means setting up automated testing.  

This enables regular, rapid validation of existing functionality when incrementally updating individual components to newer versions. It is a core component of continuous system integration. This makes it possible to implement the many planned changes and additions without imperilling existing functionality.  

Investing in test automation pays off not just during the development phase. With careful design, it can also be deployed in areas such as end-of-line testing, and is an effective tool for maintenance and ongoing development after product launch. 

Your co-workers are your guinea pigs 

As well as automated testing, it’s also important to incorporate external feedback into the individual integration steps. The point here is that without external feedback development is pretty much flying blind – with no indication as to whether the planned product actually meets market or user requirements. 

A common consequence is that expensively developed products fail to make an impact in practice and fail commercially. This point precisely illustrates one of the biggest advantages of using agile methods and principles – doing so enables you to find out how users feel about your product early and regularly, and to change course while it’s still relatively simple to do so.  

Consequently, we recommend actively exploiting the potential offered by agile methods and principles. Take advantage of the opportunities they offer and schedule intensive user testing of your integration models. From colleagues from other projects to trusted experts to pilot customers, potential test candidates are many. Sometimes a degree of inventiveness may be required – in the case of a functional model missing a display, for example, the display can be printed out on paper and ‘simulated’ by a co-worker. Conversely, if you want to test the user interface, but are still missing some device functionality, this can also be simulated manually.  

There are countless ways to obtain feedback even before performing formal usability or verification tests. Early integration and testing brings much of the risk usually embedded in the formal test phases forward, helping to reduce the likelihood that these will need to be repeated, which can quickly become very expensive and delay the product launch. 

Our recommendations: