How Agile in General Supports Work in Regulated Environments

ABOUT THIS CHAPTER   The early Agile focus on flexibility at all costs created the impression that Agile practices were not well-suited for regulated industries such as life sciences, finance, and government. The focus on “go full Agile or go home” reinforced the impression that Agile practices were not applicable for companies that could not see how to make their customers or their overall product development cycles fully Agile.

This was unfortunate, because so much software is developed under overt regulations, including FDA, IEC 62304, ASPICE, ISO 26262, FedRAMP, FMCSA, SOX, and GDPR. And other software that might not seem regulated can still be subject to rules for privacy, accessibility, and security.

As Agile has matured, it turns out that Agile practices can be as useful and appropriate in many regulated industries as they are anywhere else. It is certainly possible to practice Agile development in a way that will not meet the standards of regulated industries, but it’s equally possible to practice Agile development in a way that does.

In 2012, the FDA adopted AAMI TIR45:2012 (“Guidance on the use of AGILE practices in the development of medical device software”) as a recognized standard. My company has been working for more than 10 years with numerous companies in FDA-regulated environments and other regulated environments to adopt Scrum and other Agile practices successfully. The discussion in this chapter applies to all but the most heavily regulated industries. FAA/DO-178 regulations, in particular, are more extensive than described in this chapter, and when I refer to “regulated environments” in this chapter, I am not including FAA/DO-178.

In general terms, the software-related requirements for regulated environments boil down to this: “Document what you plan to do; do what you said you were going to do; and prove, with documentation, that you did it.” Some environments add an additional requirement: “Provide extensive traceability to prove you did all that at a fine level of detail.”

Agile practices don’t make work on regulated products more or less difficult. The documentation around Agile practices is the greater concern. The efficiency with which documentation can be produced is probably the most important consideration in adapting Agile practices for use in regulated environments.

Sequential practices support efficient creation of documentation on regulated products. Agile’s emphasis on incremental and just-in-time practices increases the number of times that documentation must be created or updated. This is not necessarily a problem. Many leaders have told me that Agile development makes documentation easier, because documentation is created more incrementally, just as the software is. However, some aspects of Agile culture need to be modified, such as the focus on the oral tradition and tribal knowledge.

The table below summarizes how the Agile emphases affect compliance in regulated environments.

At a conceptual level, several Agile practices provide support for the intent of regulations, which is to guarantee high-quality software:

• Definition of Done (which is created in a way that meets or exceeds regulatory requirements, including documentation-related requirements)

• Definition of Ready

• Software quality maintained at a releasable level at all times

• Test development either preceding development of code or following immediately behind it

• Automated regression test use

• Regular Inspect and Adapt activities to improve product and process quality