====== How Do We Move Away from “Trust But Verify” Approach to Compliance? ======

TL;DR Move to a “assume (compliance) has drifted and address (correct)”. After all, it was Ronald Reagan talking about the Soviets that made the phrase popular, and you would think that most organizations would like to think they can leverage more inbuilt trust in the organization than that.

One idea Agile implementations promote is that if you help your people understand what the overall goals are (the why), provide an environment where the right thing to do is also the easy thing to do, and allow your people figure out the best way to get to those goals, then good things happen.

By leveraging this type of thinking you can dramatically reduce the amount of friction you in your processes, thereby improving time to market and improve quality.

The first time I saw the results of this in action was in a place where we needed to have ISO compliance in order to be able to sell our system. By explaining to all that this compliance was required and why, by providing some simple tools to help people do the right thing (templates, information, etc.) we were able to easily pass external audits with no checking, no formal approval processes, and no additional effort. People just did the right thing.

One place where you get pushback on this idea is when managers worry that, unless someone is checking compliance through compliance processes, checklists, and individual accountability set up through approvals, then people will end up just ignoring the implementation of compliancy.

In order to help organizations overcome this natural tendency, I’ve used a “trust but verify” type approach. In other words, you set things up so that as you move from an old legacy approach to a new approach the two approaches run in parallel for a while so people effected can become comfortable - trust that it will work, but verify to help people become comfortable. When it becomes such that everyone wonders why we are still doing the old verification procedures we simply shut them down.

The issue is that I didn’t take the next step. There is a behavior change (and eventually culture) that the Agile approach represents and by using this thinking approach I was not easily able to take advantage of the real benefit I could get. 

As people do work, they will react to changes based on their understanding of what needs to be done. This means that a team, for example, might decide that the designated compliance approach does not make sense for the particular work they are doing; the implementation is now “out of compliance.” While this sounds bad, it is actually a good thing. We have a potential learn from the experience. Perhaps the issue is a result of a lack of understanding of the compliance implementation. Perhaps the issue is a result of something that really needs to be adjusted. Perhaps the issue is that it really does not make sense to apply this compliance to this specific situation.

No matter what we have a potential learning. So rather than a “trust but verify” approach we need to use an “assume (compliance) has drifted and address (correct)” approach. If you have set things up appropriately (automation is your friend😀) it will be easy to detect drifting compliance. Treat this as a signal and don’t just assume the product needs to be brought into compliance. Let the organization learn.

{{tag>FAQ Behavior Culture Transformation Compliance}}