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.
