Using Agile in a Regulated Environment

Using Agile in a Regulated Environment

Stanley Curtis, Chief Technology Officer & Senior Vice President of Software Engineering, Pilgrim Quality Solutions

Recently, I was reviewing a MOOC (Massively Open Online Course) that teaches how to use Agile methodology in the development of SaaS (Software as a Service) products. This is a great scenario for the Agile SDLC (Software Development Lifecycle) since SaaS solutions typically change on a frequent basis as new features are added, or defects are fixed and released on a defined and regular schedule that fit into one or more sprints that range in length from 1-4 weeks. As there are changes, the software is updated and pushed to production to meet new or changing market requirements. If you read the textbooks about Agile, what I just described fits the Agile narrative very closely.

So far, so good, as I watched the video in this MOOC. Then, the instructor made a comment about Agile not fitting in a regulated environment. Having implemented Agile SDLCs in both regulated and non-regulated industries for more than 10 years, and hearing this comment many times, I felt it was time to start a conversation about the reasons why it does make sense to use Agile development methods in a regulated environment.

Does Agile Methodology Belong?

Lack of planning and documentation are the most common myths surrounding Agile when used in a regulated environment such as pharmaceutical or medical device software development. The FDA has recognized Agile as an acceptable SDLC and lists Agile as a Recognized Consensus Standard on their website. If you read the Manifesto for Agile Software Development it describes preferences, not absolutes. The four values of Agile are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Note that none of the values state that you should not plan or document your software development. The following statement is listed under the four values on the Manifesto for Agile Software Development website.

“That is, while there is value in the items on the right, we value the items on the left more.”

This statement is what most people miss in the context of the Agile Manifesto. It is not suggesting, for example, that you should not document your software development. What it is suggesting is that working software is a better indicator of quality, and that the software needs to meet the requirements, over reams of documentation. Some level of documentation is still required, but you only document what is necessary rather than document for documentation sake. The four values represent a continuum rather than a binary of one or the other, but not both.

It’s important to note that Agile can and should be deployed within your existing regulatory framework. This means that your organization’s current change management process, procedures for reviewing metrics, and other regulatory compliance processes will provide a solid foundation for control of the Agile SDLC.

Adapting Agile to Your Organization

When I first started down the Agile path more than 10 years ago, it felt very rigid and prescriptive. Over time, and with experience, as well as learning from my mistakes, I realized that you must adapt Agile to your circumstances. Your company, culture, product mix, and industry all influence what your final implementation of Agile looks like. That is what Agile is all about. When done well, Agile provides more flexibility, predictability, quality, and transparency to an organization and its business. This flexibility is evident when you look at the various flavors of Agile being used such as Scrum, XP, Kanban, and SAFe.

Despite Agile’s flexibility, there are core principles that should be followed. As you adapt Agile to your organization, try not to stray from the 12 principles of Agile. They are tried and true by the many companies that have made the change to Agile. I have found that even with the many adaptations I have made over the years while implementing Agile in different environments, living by the 12 principles has served me well.

The Adoption Rate is Increasing

The federal government has embraced Agile for software development. In 2012, the FDA co-authored a guidance document (AAMI TIR45:2012) with industry representatives from the AAMI Medical Device Software Committee outlining the use of Agile development methods for medical device software. This is a very comprehensive document which discusses the use of Agile in the regulated medical device field, and does an excellent job of outlining the four values of the Agile Manifesto in the medical device software development lifecycle.

Finally, implementing Agile as your SDLC does not conflict with the various quality frameworks in the market. Pilgrim Quality Solutions is ISO 9001 certified and we use Agile as our SDLC. Our process and products are well documented, but not over documented. We continually review our processes and metrics to ensure that we get the greatest benefit from our SDLC. An SDLC is supposed to be a tool/framework that helps, not hinders. Pilgrim’s predictability for releases is high, with a corresponding high level of product quality, including validation of the delivered releases.

Agile has become an accepted mainstream SDLC across most industries and is well documented from both process and results standpoints.


SmartSolve Platform for Compliance

Data Sheet

SmartSolve Platform for Compliance provides a powerful foundation for building a mature quality system.

SmartSolve Platform

Stanley Curtis

Head of Software Engineering for SmartSolve EQMS, IQVIA