In this series of posts, I’ve been laying the background for describing a set of practices that I believe can help development teams working in high assurance and regulated industries build the highest quality software possible…. using agile methods. It’s not an idle thought. In the last 3-4 years, I’ve had the privilege of working with some extraordinary agile teams, in addition to their obvious market success, one things stand out: they have the highest quality solutions and products that I’ve experienced. It isn’t accidental. Properly applied, agile methods build software quality in, rather than leaving gobs of untested code for a nasty waterfall test/triage/death march at the end. And we know the elimination of a large number of reported defects does not induce quality. It’s too late for that. In my new book Agile Software Requirements, I cover a lot of the basic agile requirements practices and how they produce endemically higher quality. This book will be released in the next 30 days or so, and I hope it provides value to all agile development practitioners.
But in this environment, we must go one step further, we not only have to have quality, we have to prove it, as there are QA governance and regulatory affairs people watching our every step.
The Rules of “Prove It”.
In an earlier post, I introduced a useful briefing presented by SoftwareCPR at the recent GE Agile Conference, Based on their experiences and interpretations with FDA 820.30 and IEC62304, Brian pate and Mike Russell posit that there are a set of immutable rules, the “gotta haves”, if you will, that are necessary for development and deployment of medical device software. I agree with the assessment, and with their permission, I now don’t have to make those up myself! Figure 1 below, provides their view of the “gotta haves’ for medical device development (and by inference at least, a comparable set of gotta haves occurs in most other high reliability, regulated environments):
It’s probably obvious that most of these items would not be required in typical agile environments, even environments where the cost of errors is prohibitively high. But if we are going to use agile in this environment, we are going to have to make our peace with these requirements, and then use agile, iterative and incremental approaches to building the code we will eventually deploy. That means that many of the above artifacts, (for example: Software Requirements Specifications, traceability, and verification and validation activities) will need to be iterative and incremental, too. We can’t just do them once, whether at the beginning, or we will fall back in the waterfall trap.
I guess we expected that.
In the next post, I’ll describe one view of such an agile model, and then proceed to address these key requirements, without killing the goose that laid this golden agile egg.