Device development without sacrificing compliance

Medical devices are a case in point. There are a variety of regulations and standards to observe, including FDA requirements, the Medical Device Regulation, plus IEC and ISO standards. However, while compliance can get in the way of creativity, flexibility and speed-to-market, many organisations around the world are finding that innovation and agility can comfortably co-exist.

In fact, we are beginning to see these organisations formally adopt increasingly popular ‘Agile’ methodologies, even in traditionally risk-averse markets, such as medical device development. The key to their success? They’re making traceability a priority. More on that shortly, but first, let’s re-cap exactly what Agile is, because it is often misunderstood and clouded by some misleading myths.

At its simplest, Agile is a loose philosophy, with its origins often attributed to the Agile Manifesto. This ground-breaking document promotes a focus on customer needs, cross-functional team collaboration, and responding to change (versus ‘sticking to a plan’). Agile development is an umbrella term for several methodologies, two of the most common being Scrum (a time-fixed, iterative method) and Kanban (a card-based method for continuous delivery). Also, Agile increasingly coexists with DevOps in software-centric environments, since the two are entirely complementary.

Busting some agile myths
There are also some other formal methodologies developed specifically for large scale organisations, notably the Scaled Agile Framework (SAFe) and several hybrid methods, including Scrumban (Scrum and Kanban) and Kanplan (Kanban and Gantt charts) among others. There is no one-size-fits all version of Agile, but that’s a whole other topic.

What’s important in the context of the embedded market is to dispel some of the myths, the first being that Agile does not have enough control or structure. The Agile Manifesto said nothing of the sort. In reality, there are many ways to provide the process controls and structure required, while still delivering on time, at speed and compliantly, within an Agile framework.

Myth number two is that products developed using Agile have sub-standard quality. While Agile arguably flourished initially in industries where regulation or quality control was less prevalent, it is not true that Agile development delivers low quality products by default. For example, quality can be assured through mechanisms such as having clear definitions of the terms ‘ready’ and ‘done’, as well as acceptance criteria. In fact, many organisations are moving towards Agile with the goal of improving quality.

A third misconception is that Agile is not implemented - or simply will not work - in regulated industries. This is not true. According to a Perforce 2018 survey, 38% of medical device companies have moved towards Agile development processes.

The bottom line is that Agile can be an excellent fit for medical device development, when applied properly. Let’s not forget that regulators have no concern over what combination of development processes, methods and strategies organisations use to deliver their products. Regulators simply require that developers map their processes, trace all development items and artefacts, report on risk management, and include electronic signatures for accountability.

Traceability in agile product development 
What matters is how teams execute on Agile frameworks. This brings us back to having solid traceability, because this enables organisations to deliver products on time and efficiently, regardless of the process. Where regulations exist, traceability is critical. It helps answer the question, ‘If something changes, what will be affected?’ and it can be defined as both backward and forward. Backward traceability is checking that what was designed or built is justified by an upstream requirement. Forward traceability is checking that what is needed is addressed in later lifecycle stages.

In Agile development - particularly Scrum - work items are broken down into small pieces and completed during a fixed timeframe, called a sprint or iteration. In practice, this means that managers must ensure that each work item (and its smaller pieces) has the appropriate test coverage. This kind of traceability requires a clearly defined structure from the project’s outset between ‘parent’ and ‘child’ items. The end result of such work, when completed diligently at all stages of development, is a traceability matrix that allows organisations to understand what requirements, tests, and issues are connected. This matrix provides a simple way to conduct both forward and backward impact analysis and, ultimately, ready accountability. In practice, decision makers can understand the impact of changes before they happen, helping to manage and mitigate risks (again, regardless of the delivery methods or processes used).

Above: Balancing innovation and compliance is a challenge in any heavily regulated market with a large dependency on embedded software

The right tooling strategy matters, because it can add unnecessary complexity and get in the way of traceability. For example, we commonly see requirements stored in Word, issues tracked in Atlassian’s Jira, and code stored in Git. Not surprisingly, tracking and tracing becomes a lot more complex, which in turn, introduces risk. Reliance on manual processes also soaks up time.

In Perforce’s previously mentioned medical device development survey, over 60% of respondents reported using Microsoft Word to manage requirements and test cases, with over 50% using Microsoft Excel to manage and track issues. Thirty-three percent of respondents also said that documenting and reviewing work was their most time-consuming task.

Conversely, the right tooling can actually remove, or at least reduce, some of these barriers. For example, organisations can adopt processes or solutions that integrate application lifecycle management (ALM) with popular tools (by allowing teams to import or export Word documents). Proper ALM tools also ensure traceability between requirements, testing and code to make sure that every requirement is tested and fulfilled. The ALM tool can then be used to generate the necessary traceability documentation, thus proving compliance.

Interestingly, the same survey also found that traceability provides far more benefits than just compliance, with 85% of respondents using it to meet other needs, such as managing change or risk, to support impact analysis or decision-making.

Transitioning to agile
There are a few stand-out best practice techniques that support successful Agile adoption. Much of it centres around culture. First and foremost is the need for executive buy-in.

Second, Agile transformation is best begun at team level. By localising any potential mis-steps, organisations can both lower risk and make success more attainable - lessons learned can then be scaled to department-level and even enterprise-wise.

Third, it is critical that teams involved have a clear process and nomenclature. To illustrate what this means, here are some examples. Are planned product features written as requirements or user stories, or will a mix of both requirements and user stories be used? They are similar, but user stories are an Agile term, while requirements is a more traditional description. Are estimates to be measured in days, hours, or story points? Will roles need to be redefined, for instance, do business analysts need to be trained as Scrum Masters?

These questions and many others need to be addressed and resolved early on, so that executives, managers and teams can communicate clearly during this period of change and potential disorientation. Going back to tools, creating an environment where there is a ‘single source of truth’ also helps to keep all contributors aware of progress, giving a view on activities being carried out by other users, in a highly transparent way. Plus, with these contributors often spread across different functions – including hardware and software – and different locations, it is vital that this window into a project is completely independent of any workflows, tools, systems, platforms or file types.

The right tooling and culture, with traceability as an essential foundation, are the keys to successful adoption of Agile in compliance-focused markets such as medical device development. Sure, there is a lot of work involved and success will not be overnight, but the benefits – the confidence that risks are being managed, without compromising innovation and flexibility – are worth the effort.