In my article, Agile Removes Limitations—You Must Now Change the Rules, I proposed that

1. Process improvements, such as agile, remove limitations that existed in the past, like the inability to deal with change and uncertainty
2. Based on Goldratt's teaching, in order to get holistic effects from such improvements, we must:

• Determine which limitations no longer exist
• Examine the rules we put in place to deal with these old limitations
• Remove or change these rules to deal only with new or remaining limitations

I believe that many organizations attempting to introduce process improvements of any kind fail to execute the second point. The process improvement is introduced but existing structures still assume old limitations. The result is either less dramatic improvement than we'd like or reversion to the old ways of doing things. This kind of "force fitting" agile into existing organizational processes will certainly hamper your results.

Let's now apply this approach to two common challenges in software product development: compliance and audit processes. Many organizations, especially large companies and those operating in heavily regulated industries, have compliance processes in place that must be met in order to approve software for release. These processes often require activities that appear to conflict with all we have learned about agile, for example, requiring waterfall-like sequential flow of heavy documentation artifacts through the life of a feature request.

Understand Compliance
Generally speaking, compliance is about managing risk. In businesses that face more risk than others—e.g., those developing medical device software upon which peoples' lives depend or software that carries millions of dollars of financial transactions form one place to another—a process, similar to the one below, is used to help manage risk.

1. Identify and assess risks
2. Establish controls that attempt to mitigate these risks
3. Monitor and assess the implementation and effectiveness of the controls
4. Communicate results
5. Remediate gaps or observations
6. Repeat

Audits
Audits generally are the implementation of steps three and four. Auditors share an opinion on the controls we establish and whether we are actually implementing them effectively. They generally do not specify what the controls are or which activities need be taken to implement them. The business establishes controls, and auditors basically test whether controls are being implemented.

Is There Already a Problem?
When I started to learn about compliance processes, I immediately recognized a common pattern. Despite the compliance steps above being cyclic, most of the compliance processes I have seen in action seem only to repeat steps three through five. That is, once risk was identified and controls were established, they were pretty much set in stone and rarely changed. At this point, I began to realize that there was nothing in principle conflicting between agile and compliance processes. In implementation, however, compliance and audit can appear as an obstacle to agility, sometimes even requiring that people create artifacts for no other reason than to complete a compliance controls checklist. Though this might satisfy the needs of the audit, it does not do the business a service—money is being spent on an effort that probably isn't actually reducing risk.

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