It’s not unusual for a development team in a “highly regulated environment” to be steered away from agile methodologies and practices because of the perception that they are not a good fit. Preparing to work with auditors in these regulated environments (SOX, CFR, ISO, CMMI, etc.) usually means that an organization relies on well described documentation and processes – which on the surface appears to be at odds with the Agile Manifesto.
Initially it might seem like putting “Processes and Tools” and “Comprehensive Documentation” on the less valued side of the equation will get us in trouble when those audits come along. But we need to remember that lean and agile practices put an emphasis on transparency and communications – which fully supports the audit process.
To understand how the regulatory environment and agile development work together we need to remember my favorite agile principle:
“Simplicity–the art of maximizing the amount of work not done–is essential. “
In the same way that valuing Working Software over Comprehensive Documentation really means that we only create the necessary and important documentation, this principle encourages us to look for the simplest solution to meet the regulation. For instance, if regulations require that you can trace all software changes to specific requirements, figure out the simplest, leanest way to document the traceability and follow that method rigorously.
Who decides what this rigorously followed method looks like? Let’s look at another agile principle:
“The best architectures, requirements, and designs emerge from self-organizing teams.”
Auditors may look for any number of different criteria, but teams should always know what information they will be accountable for as they start their work. A mature agile team (and/or team with an experienced coach) can self-organize and look at the ways that Lean and Agile practices create opportunities to build in this accountability. By letting the folks who need to carry out the results of this exploration participate in the design; the resulting SOPs will be more efficient and well embraced by the teams who will execute them.
In addition, most tools used by these teams (Jira, TFS, Version One, etc.) can be customized to support this accountability. New SOPs will often incorporate how to use relationships between work items (stories, epics, features, etc.) and who is responsible for specific actions related to these work items. This allows us to create easily extracted audit trails.
Ultimately, by focusing on understanding the regulatory needs, involving the team in finding the simplest way to meet those needs and then carefully following those custom SOPs we make audits easier to perform and get better results when those audits are performed.
