agile in highly regulated environments
November 2, 2016

Agile in Highly Regulated Product Development, Part 1


The Agile Manifesto has been around since 2001, so most people involved in software development have at least a passing knowledge of the methodology and its benefits. Many teams have transitioned to an Agile process of some sort.

That said, a number of organizations—especially in safety- and quality-critical industries—believe the complexities of their product prevent them from adopting Agile. But is Agile truly a bad fit? Or do these organizations simply require a better understanding and the right tools to see how Agile can work for them?

This is the first in a five-part series that defines the barriers to Agile adoption, and looks at how Helix ALM (formerly TestTrack) can help you overcome those barriers. 

An Overview of the Barriers

For instance, many barriers to Agile adoption are not as difficult to overcome as might be believed. The following scenarios illustrate a few of those barriers, both real and imagined, that make some organizations hesitate:

1. Lack of documentation: “Our product needs to have a specification up front, so we can demonstrate that the design has been approved and ultimately delivered. We can’t have the product changing every five minutes, just because someone on the development team had a good idea.”

2. Loss of traceability: “We need to be able to show traceability from high-level requirements through design, development, and testing. That’s not possible if the design and construction is done in a development process that is ad hoc and not linked with our broader end-to-end development process.”

3. Enforceability and auditability of process, including sign-offs: “Ultimately, we need to be able to demonstrate to an auditor that we have control of our process. This means that every change needs to be made in accordance with our process and must be signed off by an authorized person. Agile does not allow this.”

4. Inflexibility of Scrum tools to fully integrate with the broader development process: “We want the development team to be as creative as possible, but what they do needs to be directed by the strategic priorities and requirements that are defined by the business. So the development team must use tools that allow for traceability and compliance, but the team still needs to be flexible enough to realize the benefit of an Agile process.”

5. Difficulty integrating formal testing into an Agile process: “Agile is great for developers, but there is a big gap—testing. Agile does not allow you to do the formal testing necessary to ensure that the product does what it’s supposed to do.”

Barrier 1: Lack of Documentation

Many believe Agile prevents you from creating documentation. In fact, the Agile Manifesto says no such thing; it merely states that you should value a working product over “comprehensive documentation.” You’re free to create whatever documentation you require.

Another misconception is that you can’t have a documented plan, and developers do whatever they want. Again, this is not an Agile mandate. There needs to be some level of advanced planning, no matter what development method you’re practicing.

However, attempting to complete all of your detailed design up front is a recipe for disaster. The only thing that is certain about a fully defined and approved, detailed software specification created up front is this: it will change. Accepting that reality is a key to successfully adopting an Agile process.

The real cause of documentation issues is that Agile embraces change, rather than seeking to control and limit it. Managing reviews of large interlocking documents and gaining sign-offs is often one of the hardest, most time-consuming parts of the development process, so the idea of the documentation changing all the time makes Agile seem “just not feasible.”

And you know what? That’s absolutely correct.

It isn’t feasible to manage large levels of change if you use what most teams use to manage projects: Word and Excel documents stored in a version control system or on a shared network drive. It’s also difficult if you use an Agile-only tool that doesn’t integrate with your broader process.

The problem with a Word document is that it’s a single entity that has to be approved or rejected in its entirety. If even one requirement, test, task, or other item in the document changes, you have to review the entire document. Otherwise, it’s impossible to know what changed. That method of change management makes it too large a task to efficiently accommodate the frequency of change required in an Agile process.

If you want to be able to manage change with agility, you need a tool like Helix ALM. Helix ALM lets you manage individual items as unique records within the document they are part of. Once you can do that, you will be able to handle the level of change that is standard in an Agile process.

This sample requirements specification document shows how Helix ALM lets you manage individual items within it.


Explore Helix ALM