Agile in Highly Regulated Environments

Can you use agile in highly regulated environments? This was one of the many great questions that came up at the recent Agile DNA Webinar. This post explores some of the recommendations to consider when introducing agile within highly regulated environments. First, lets understand the potential issues. Agile approaches, were designed for small, co-located teams who can easily validate product increments via demos and discussions.

When we look at Alistair Cockburn’s “Crystal family of methods” we see criticality as differentiator for method fit. In the diagram above, the Y axis indicates the recommended criticality level for the several variants of Crystal. It describes what is at stake if a defect were to occur in production. For video games, defects are just annoyances, for accounting systems they could have significant financial impacts. For air traffic control or pace-makers they could be life critical. This is why the Crystal approach recommends the lightest methodology “Crystal Clear” for small, low criticality projects and heavier, more rigorous approaches for projects that are more critical.

Boehm and Turner adopted this same scale of Criticality-of-defects score when they created their agile suitability filter radar chart.

When referring to the radar chart above, we can see the inner, “Agile Region” covers criticality of Comfort and Discretionary Funds, so it would seem more traditional approaches are better suited for projects with higher criticality.

While these guidelines are important starting points they are not the end of the discussion. We should understand that by default agile approaches place less emphasis on documentation and more emphasis on satisfying business needs. This might be achieved via a demo or field test by business representatives. This is fine for most low risk projects and much faster than documentation heavy alternative processes. However, it is not sufficient for high criticality applications.

I have worked on military software projects and with FDA regulated pharmaceutical companies. In both instances, there were significant mandatory conformance, traceability and documentation requirements. Yet we still used agile approaches with additional check and balances. Let me explain why and how.

First, iterative and incremental development with testing built into the process is a safer way to work than single pass development with testing towards the end. Using an iterative and incremental approach that delivers important and risky elements early ensures they receive the most testing by the end of the project. By having these elements done first, all the subsequent building along with their associated regression and integration tests mean these critical portions get tested over and over throughput the life-cycle. Also, there is less chance of testing being cut short to meet deadlines.

However, the additional safety critical measures like requirements-to-testing traceability and final certification-testing still need to occur. So, agile approaches reside at the center of the development approach, but get wrapped with additional processes.

With all this wrapping, can we really call this agile anymore? I think that’s a fair question and defend anyone’s decision to call it a hybrid approach instead. The important element to remember is that the iterative and incremental development surfaces issues sooner, drive out defects, and improve quality.

Government agencies are now recommending agile approaches for their larger, more critical projects. This CIO Magazine article “How the FBI Proves Agile Works for Government Agencies” outlines this trend. Also, for further reading here is a  Government Accountability Office (GAO) article on the benefits and challenges of applying agile methods.

The challenges come in knowing how to get the risk reduction and quality improvement benefits of agile while maintaining the conformance requirements of highly regulated environments. Hopefully these models help illustrate the benefits of having agile approaches at the heart of your development approach, but then wrapping them with the additional processes you need to be successful in your industry domain.