How Scrum in Particular Supports Work in Regulated Environments

Regulations can be slow to be updated. The regulated environment requirements I described in the previous lesson were initially created decades ago, at a time when software development amounted to the Wild West. An organization could have been using practically any approach to develop software, and most of the approaches didn’t work very well. Regulations are intended, in part, to avoid chaotic, ad hoc practices with unknown levels of efficacy.

U.S. federal regulations do not generally require a specific software development approach or lifecycle. They require that organizations choose an approach, define it, and document it, as described above. In addition, sometimes they require obtaining approval from the regulator.

Agile practices, especially Scrum, have been formalized and extensively documented (including in this book), which supports this requirement. If a team agrees to use Scrum and documents that it’s using Scrum, as defined in a specific document, that contributes to creation of a defined process, which supports regulatory compliance.

Mapping Scrum onto required process documentation

Regulations vary, and this section uses IEC 62304 (“Medical device software—Software life cycle processes”) for the sake of illustration. IEC 62304 requires activities and documentation in the following categories:

• Software development planning

• Requirements analysis

• Software architectural design

• Software detailed design

• Software unit implementation and verification

• Software integration and integration testing

• Software system testing

• Software release

As suggested by AAMI TIR45, these activities can be mapped onto an Agile lifecycle model, as shown in the illustration below. This approach effectively divides the regulated Agile project into four layers:

• The project layer—the entire set of activities for a project. A project consists of one or more releases.

• The release layer—the activities needed to create a usable product. A release consists of one or more increments. (Certain regulatory environments impose significant requirements on releases—for example, the requirement to be able to recreate an exact bit-wise image of any software that has ever been released for the life of the device—which makes releases rare.)

• The increment layer—the activities needed to create useful functionality but not necessarily a usable product. An increment consists of one or more stories.

• The story layer—the activities needed to create a small, possibly incomplete, piece of functionality.

In a Sequential approach, each activity would be performed mostly in a single phase. With an Agile approach, most activities are spread across layers.

In a non-regulated Agile approach, most activities would be documented informally. With a regulated Agile approach, the activities will be documented more formally.