New Blog Series: High Assurance Agile Development in Regulated Environments

Well, I’ve about wrapped up the book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, at Addison-Wesley. Still working through the thousand nits and nats required to get it into print “hey, can we tighten the kerning on the handwriting font we are using to describe user stories….”  and “shouldn’t there be a serial comma in the title? Answer, umm, yeah.” (note late breaking title change!)

In any case, I’ve about done my work on that project and now its time to move onto other topics. Of course, I’ll continue to opine on agile development, agile requirements and agile at scale on this blog, simply because these newer methods work so well in increasing the big three software process attributes – quality, productivity and morale. In turn, agile software enterprises receive the ultimate beneficial result – improved economic outcomes, not to mention higher safety, value, convenience, efficiency and the resultant better standards of living for society at large – that we can derive when we improve on this strange mix, of art, science and engineering that we call software development. (Note: when we discover the next software process that further improves the above, I’ll for sure write about that, too, assuming I can still see the monitor.)

Speaking of quality, however, it comes as no surprise to agile proponents that properly implemented agile achieves much higher quality than its waterfall predecessor. The tyranny of the urgent defect triage can be largely mitigated with agile. And while we will always need to address defects, nonconformance and minor user needs misfires, we can focus more on truly understanding user needs and building software that has quality from the get-go, rather than using (insert your favorite workflow/defect management tool name here) as your ultimate end game-death march-process model for achieving eventual shipment-level quality. Boy are we thankful for that.

Given the emphasis on quality in agile, and given our improved results, it seems clear that as it continues to crosses the chasm from early adopters to mainstream development,  agile will also exit the dilbertesque phase of we-don’t-need-no-stinking-requirements-documents era and enter the IF you-really want-the-highest-quality-possible, THEN you-must-use-agile methods era. In so doing, agile will hit another mainstream, the mainstream of people developing software for medical devices, avionics, industrial controls, financial trading systems and other high assurance software applications where the presence of any material defect has an unacceptable human or economic cost. (Note: in many cases, agile is already there, but there isn’t yet a lot published about it….)

In the area of medical devices, for example, I have personally devoted almost two decades of my career to developing safe and efficacious medical equipment using traditional, waterfall methods. (That was the business of my first business, RELA, Inc., which evolved into Colorado Medtech.) It wasn’t always pretty or efficient, but we made it work (I survived that career with no software related device failures).

Since we were all using the waterfall model, it’s no surprise that the governing and regulatory bodies built their standards around it as well and that is still the case today. So now we face a dilemma:

How do we move the industry foreword to agile development in the face of waterfall-based governance that regulates the processes by which we use to develop software?

I have a number of stakeholders, peers and clients that face this dilemma, some in medical equipment, and some in other industries, so that will be the subject of my next series of posts (and much of my next few months work). Specifically, I plan to take the topic on in two new threads (categories on this blog):

1) Thread 1. High Assurance Agile Development and Regulated Environments: In this series, I’ll attempt to illustrate how agile development methods can be applied to produce higher quality software than we could with any prior methods. In addition, in order to help assure public safety, the development of much of such software is regulated by specific government and industry standards in Aeronautics, Defense, Pharmaceuticals and Medical devices industries,  so we’ll be keeping those standards in mind as we tell our tale. This series will be based in part on the enterprise backlog model and other methods described in Agile Software Requirements.

2)   Thread 2. Agile and the FDA. In this series, I’ll be mapping the High Assurance Software thread above to current regulatory guidelines in one specific industry: that is the development, manufacturing and sale of medical devices and medical equipment as regulated by the US Food and Drug Administration’s Current Good Manufacturing Practices. (see FDA CGMP Code of Federal Regulations (CFR) , Part 820, Quality System Regulation). While I’ll focus on this one industry and its regulatory standards, it’s a fairly common pattern that can hopefully applied outside of the United States and in other regulated software development contexts.

I recognize that these threads may not be of interest to a lot of people. If you can economically or morally afford to make a few mistakes, even somewhat nasty ones, in your released products, this may not be for you. But if you can’t – and due to the constantly expanding depth and range of software applications – more and more of us can’t, then this series may be for you.

In addition, to help assure quality in the work product, I’ll be working hard to get peer review from other professionals in the industry so that we can move forward together with a new body of knowledge, rather than just one author’s ideas.  If you’d like to participate, you can do so actively by pinging me or set your RSS reader to this blog and comment wherever applicable. I look forward to your contributions.

After all, since agile works so well, shouldn’t every industry and every consumer get the benefits?


Note: portions of this work are sponsored by, and developed in collaboration with, the folks at Rally Software Development Corp. ( makers of providers of Agile Application Lifecycle Management solutions.

4 thoughts on “New Blog Series: High Assurance Agile Development in Regulated Environments

  1. I think this is quite interesting, and quite possibly could revolutionize the way medical device software is delivered.

    Life sciences is the last bastion of waterfall development methodology. I look forward to championing the cause!

  2. Dean,

    I very much look forward to your upcoming series of articles. Having been in FDA regulated development environments for over 10 years, this truly is an area where most people live&breath waterfall. But as you said, there are a few out there already doing agile in this domain and I would argue that it can be done (relatively) easy. I would argue that what it takes is a cross-functional and open-minded team that is able to interpret the regulations rather than simply dictating what they have seen in their past work live. That means to either building or refactoring your Quality System ground-up to allow for agile and meet FDA needs.


    PS: I’d be happy to participate, if you need anymore help.

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