An Iterative and Incremental Process Model for Agile Development in Regulated Environments

In this series of posts, I’ve been using Medical Device Development (as Regulated by US FDA via CFR 820.30, and internationally as regulated by IEC 62304) as an exemplar for suggesting ways to develop high quality software in regulated (and other high assurance, high safety, high economic cost of failure) environments in an agile manner.

In an earlier post, based on my reading of the 820.30 regs, I described the chain of regs and explanatory documents that might tend to imply a “waterfall” (sequential, one-pass, stage-gated) development model, which might look something as follows.

An implied, high assurance, waterfall lifecycle model

Whether based on CFR 820.30 or not, this would seem like a reasonable conclusion based on our historical approach to such development. With the addition above of a single pass “verification” and “validation” activities, this closely follows the requirements>design>code>test models of the past. On the surface, at least, this model has some obvious advantages:

–       it is simple and logical (what could be more logical than code following requirements, and tests following that?)

–       you only have to do “it all” (especially verification and validation, which can be both labor intensive and error prone) once.

Of course, readers of this blog know it doesn’t work well that way at all, and that’s why we strive for agility in the high assurance markets, just like we do everywhere else. But for many, the apparently beguiling (but false) simplicity of the model is one reason that it has made its way into the various governing corporate quality standards, etc., if for no other reason than “that’s the way we’ve always done it”. (And admittedly, most of the rest of the software industry is doing it that way too).

It Doesn’t Have to be that Way

Momentum aside, however, we now note that while such a thing could be inferred by the various governing documents and our own quality affairs personnel (and it certainly has been applied by countless FDA reviews and other quality audits), in point of fact the specific regs we are using in the exemplar DO NOT require such a process:

1)   From US General Principles of Software Validation; Final Guidance for Industry and Staff (US FDA CDRH 2002) we note the following:
This guidance does not recommend any particular lifecycle models…. “

2)   Even more specifically, as Pate and Russell note from IEC62304 (a widely recognized international standard for medical device software which is largely harmonized with FDAs interpretation of CFR 820.30)
“these activities and tasks may overlap or interact and may be performed iteratively or recursively. It is not the intent to imply that a waterfall model should be used.”

3)   And finally, from the 2009 Abbott Labs case study describing the successful application of agile development in a Class III (the most stringent FDA regulatory category) Adopting Agile in an FDA Environment:
“we will describe the adoption of agile practices…..This experience has convinced as that an agile approach (multiple iterations during the course of development) is the approach best suited to development of FDA-regulated medical devices.”

There you have it. If we are using waterfall development in support of high assurance systems (at least in the case of the regs we have described here), it is evidently because “we have always done so” (indeed, as this is still mostly case in much of the rest of the software industry) rather than “the regulators made us do it.”

So if, as an industry, we do want to increase the productivity, quality, and yes, even safety and efficacy of the software we produce, it’s time to move on!

Moving to an iterative and incremental, and … agile model.

With a nod to Abbott Labs whitepaper and the associated presentation, and with due respect to the verification and validation activities that will still be required in high-assurance development (see High Assurance Agile Development in Medical Devices: Prove It post), we offer the following figure as a potential, general model for iterative and incremental (and increasingly, as we will see) agile development in high assurance, regulated markets:

Iterative and Incremental High Assurance Lifecycle Model

It can be seen from the figure that development of software in this model does not follow a waterfall, sequential reqs-code-test time line. Instead we use a series of short iterations, each of which “defines|builds|verifies” some new, and valuable user functionality. [note: I described this as the Define|Build|Test atomic building block of agile development in Scaling Software Agility.)

Periodically (typically after 3-4 iterations) this new increment of software can then be validated and reviewed, prior to being made available for alpha or beta testing, or general availability release. (The shorter the iterations and increments-the faster the feedback;the faster the feedback-the higher the quality. The shorter and faster we go-the more agile we become.)

With respect to additional elaboration of the model, it occurs to me that I’ve used the terms “verify” and “validate” here, as if we knew what they actually meant. Indeed, there is much confusion on the topic, so I’ll try to clarify that in the next post as I go one to explain more about the model above. When we do so, we’ll also hit that nifty high assurance bugaboo called “traceability”. (And doesn’t that one already just sound like some fun?)

2 thoughts on “An Iterative and Incremental Process Model for Agile Development in Regulated Environments

  1. This is a good overview but it might help to separate the informal from the formal verification and validation. Nothing prevents great teams to “informally” verify and validate along the way. With a good software engineering principles and discipline, we gain product quality while not getting overburdened and slowed down with the review and approval process(es) required for formal verification and validation.

    Applying that to the picture above, we would basically do a formal verification + validation for each System Increment rather than for each iteration. It would and should however be done informally for every sprint, to the extent that it is feasible. Hence, it addresses two points: the teams to strive for high “product quality” as well as accomplishing “Quality compliance”. Depending on how the regulations get applied / interpreted, the two are not the same, unfortunately too often they are not.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s