Is Your Agile Audit and Compliance Process Really Agile?

Implementing the Improvement
Implementing the approach described in my prior article has helped me during numerous agile introductions and other process changes. Here is an example:

What limitations are we removing with agile?

• Has risk gone away entirely thanks to agile and other improvements? Generally, I think not. Though the risks themselves might be different, I am not ready to propose that compliance processes in general are no longer needed. Also, even if I was ready to dismiss compliance processes, that would take a really long time and we have business to do today.

• Have the specific risks that our existing controls seek to mitigate been eliminated? I don't think that they have been completely eliminated, but some of them certainly are being dealt with in different ways and are no longer true limitations. As an example of such a risk one may say, "Resources may be expended on requests that are not of value or priority to warrant the expenditure.

    I believe that this one is easy. A Scrum product owner practically eliminates this risk if he is doing his basic job. It is built into the process itself.

What are the rules that existed to deal with the old limitations? For our example risk, a control might look something like this:

Control: "Provide evidence that management has made an evaluation of the request prior to using development resources on a development activity."

A particular organization may have created more explicit activities to do this. These may include formal process steps, change control boards, various types of documentation sign-offs, and more. It is this set of rules that tends to get in the way. Following former processes, these rules may have been perfectly appropriate. But now, we mitigate the same risk in a simpler way. Work with your compliance group members to help them understand this and modify the rules and audit tests.

By following this basic approach, you can begin to help your organization change the rules and adapt. On a product development effort I would likely have some short-term and long-term goals for this approach: In the short-term, I would focus on the specific activities that have been used as the tests for compliance. This can help our product development efforts pass audits and meet objectives. In the long-term, evidence can be used during the "identify and assess risks" step of the compliance process described above if there is a belief that the risks themselves have changed.

Tips
Invite compliance group members to learn about your new process in the beginning. Here are some ideas for doing just that:

• Reach out to your compliance group members as soon as you begin an agile introduction. Their expertise and knowledge can prove invaluable in educating your team about risk and resolving obstacles in existing processes.
• Learn about existing compliance processes and risks. The more everyone knows about risk, the more likely we are to do the right things all the time and not rely on checklists to build risk management in later.
• Find an interested compliance group member with whom you can work over time, an "agile compliance champion" perhaps.
• Include your new agile compliance champion in agile trainings.
• Work through a similar process like the one described above and revisit the risks and how the new process mitigates risk to establish an appropriate set of controls and tests.
• Coach the group over time so that when audit time comes you are prepared!
• Get expert help. You will likely be people-constrained just to accomplish your product goals!

Further Reading
Mike Cohn, Succeeding with Agile
Tim Bosh, Medical Device Software Development-Going Agile