Agile in Highly Regulated Environments

Various pills sorted into different cups to represent Agile in regulated environments like healthcare.

“Individuals and interactions over processes and tools;

“Working software over comprehensive documentation;

“Customer collaboration over contract negotiation;

“Responding to change over following a plan.”

 

For those of us in the Agile community, the Agile Manifesto is a wonderful expression of the True North of Agile software development – empowered teams, swarming to solve customer problems by collaborating closely with people who will actually use the things we’re creating.

But for many, especially those who deliver software in highly regulated environments, the Agile Manifesto can seem downright hostile. When dealing with audit requirements and compliance, the thought of Working software over comprehensive documentation can result in Agile processes being dismissed out of hand.

With the pace of change happening in the world, that would not only be a shame, but organizations working in highly regulated environments would miss the opportunity to get ahead of competitors by leveraging Agile processes and principles.

Regulations – Prescriptive vs. Descriptive

When working in a highly regulated environment like healthcare, financial services, or dealing with reporting and regulatory audits for the US Federal government – I find it incredibly important to use a quick mental filter to understand the types of regulation my teams are working with. Broadly, I’ve found that regulations and their associated reporting requirements roughly fall into one of two types: Descriptive rules and Prescriptive rules.

Descriptive, Using Scrum

Descriptive rules seek to provide a definition of a system or process as it is so that it can increase the repeatability of that system or process. I’ve found the most frequent examples of these Descriptive rules used in internal auditing processes and also emerge in quality processes such as the ISO 9001 Quality Management standards.

A key factor in adopting Agile in regulated environments where Descriptive rules are in play is to make sure you work closely with whatever auditors you have, internal or external, who understand your documented processes. When I’ve introduced Agile processes into ISO 9001-compliant organizations, I quickly began close collaborative conversations with our auditors to make sure they understood the interactive and incremental processes we were introducing. Once we identified the gaps and differences in the documented process, I worked with our auditors to make sure our new processes were properly documented. Descriptive rules are made to be changed to meet the work, not to prescribe solutions! (SPOILER ALERT: We’ll cover those in a second.)

Working with clients who primarily deal with these descriptive rules, I frequently look at the artifacts we can provide while using Scrum. The controls provided by a strict SDLC, especially around documentation, audit-ability, and traceability, can nearly always be met through well-written Acceptance Criteria and a light hierarchy of Epics to User Stories to Tasks. Further, most Agile software tools like JIRA, VersionOne, and Rally can provide for and automate the traceability documentation from Epic to production.

Prescriptive, Using Kanban

While Descriptive rules are designed to document a system as-is or as-it-should-be to provide a reference for a repeatable, quality system, Prescriptive rules are designed to create contracts and govern behavior. In organizations and teams ruled by Prescriptive rules, the sea-change in process and procedures introduced by Scrum can seem insurmountable.

As Agilists, it’s important to remember that while Scrum may have emerged as the most popular of the Agile frameworks – to the point where most people mentally equate “Agile” and “Scrum” – it’s far from the only Agile methodology or framework. When working with teams dealing with Prescriptive rules – such as those legally mandated by Federal agencies like the Food and Drug Administration or Securities and Exchange Commission – I nearly always fall back to Kanban.

Many of us conflate Kanban with the task board our Scrum teams use to make our daily work transparent. Kanban is a powerful Agile framework designed around documenting existing processes and applying rigorous focus toward maximizing flow. Using Kanban, we can find opportunities to incrementally improve our existing teams and processes.

By applying the principles behind Kanban, teams working under the constraints of Prescriptive rules can quickly adopt the principles of Agile.

  • Start with what you do now;
  • Agree to pursue incremental, evolutionary change;
  • Respect the current process, roles, responsibilities, and titles

While this isn’t an article about applying the Kanban principles and practices to your work, the practices themselves require embracing the Agile principles we know and love while also respecting the reality of the environment your teams exist within. Kanban’s practice of Visualizing the Workflow aligns perfectly with Agile’s embrace of transparency and openness; Limiting Work-In-Progress (WIP) closely aligns with the principles of simplicity and frequent delivery; Improving Collaboratively directly maps to the principle of regular reflection and improvement.

By using Kanban to map out your process, and then collaboratively look for opportunities to reduce bottlenecks and increase flow while also making and keeping process policies transparent and explicit, you can leverage Kanban to bring agility to your team and still meet Prescriptive rules and regulations.

Conclusion

When done well, Agile practices provide the means to create engaged and empowered teams who understand and embrace the need for regulations – both prescriptive and descriptive – and the means for those teams to own and optimize how their work is done while still meeting audit-ability, traceability, and regulatory requirements.

 

Leave a Reply