This article is on agile in compliance and not agile as a focus area. Therefore, the article will only highlight principles and values relevant in the compliance context.
What does “agile” actually stand for?
‘Agile’ is a methodology that was established in the software industry. The ‘agile manifesto’ was created in Utah by 17 developers on February 11-13, 2001. It established four values and twelve principles. As for the four values, the 17 developers wanted to put interactions over processes, working software over comprehensive documentation, collaboration with the customer over contract negotiation, and welcoming change over following a plan. From these, the developers then derived twelve principles.
This article is on agile in compliance and not agile as a focus area. Therefore, the article will only highlight principles and values relevant in the compliance context. For the rest, please refer to the manifold materials on ‘agile’ available on the internet. As a good starting point, www.agilemanifesto.org could serve, where the original manifesto and further links can be found.
Failing and Retrying in Compliance
When people think of compliance and agile, often the very first reaction is that compliance is an area with a “zero failure tolerance.” Agile’s iterative approach would by design imply rapid trial, fast failure and upon failure, a new rapid trial, potentially with another failure (see below). As failure in compliance often results in drastic fines and damages, people often conclude that compliance and agile would obviously not go together.
However, if one looks into it with more scrutiny, compliance, like many other disciplines, is perfectly suited to an iterative process that can also involve failure and retrying. The trick is to clearly define the scope for an experiment and to plan accordingly for failure and its effect. One has to make sure that a (potential) failure does not expose the company to risk. Accordingly, experiments in compliance must have clearly defined guardrails, clear KPIs to measure and, most importantly, must be in an area where failure in compliance is acceptable. Hence, failure in compliance is a way to test ideas and prototypes. It is limited to that experience with proper guardrails. It contributes to increasing success in the long-term view of what compliance does, as one is consciously designing the expected outcome.
A good example is guidance; in setting up new compliance guidance, it is possible to be less prescriptive and allow for more freedom in operations, which leads to experimenting in certain areas. Upon learning from these experiments, one can then, together with colleagues, apply the guidance, co-create and iterate (see below).
What’s important in all this is that taking an agile approach and working in iterative cycles does not imply going wild. Being agile means to be highly adaptive, act fast, adapt fast and accept “fail” as the First Attempt In Learning. “Failure” per se in this context is nothing bad. It is just one potential outcome of an experiment and brings an important insight: that a particular approach does not work or function as intended, and one has to re-try differently.
Establishing Guidance as an Example
Iteration & Co-Creation
If you look into the self-understanding of a traditional compliance function, people know what laws and regulations are prescribed in a particular setting and accordingly tell their customers what they are and are not to do. Traditionally, when guidance is set up, the aim is to cover all potential constellations and find meaningful and compliant solutions. This resulted in multi-page long, detailed and lengthy guidance, sometimes with detailed RACI charts. Nobody enjoyed working through this guidance and even worse – people mostly did not understand it as it was too detailed and complex. Expecting anyone to understand the red thread or even the underlying principles and to find an alternative if a solution was not covered by the guidance was almost absurd.
Such guidance was then trained, often with a train-the-trainer approach and implemented region by region, country by country. The effect was a mass of questions to all the compliance responsible as people were overwhelmed and over-stretched.
Today, there is a different approach to this: One could issue a quick 2-pager highlighting the risks and principles in a particular setting. Accompanying this, people could be asked to get in touch if in doubt. What then can be observed is people having a lot fewer questions as they understand the rationale and “why” behind. Often they can find an appropriate solution themselves and only reach out when truly in doubt. And those questions then truly are difficult and tricky to answer.
From the questions, we can learn what further points need to be clarified or covered by the guidance. Customers propose or co-create solutions that fit both compliance requirements and the customer’s needs. The biggest challenge in this quite often is to refrain from delivering detailed guidance in this co-creative iteration as many colleagues ask for the “checklist” or “cookbook,” that again over time reverts the traditional approach guidance.
Welcoming Change
Before agile, our customers asked for “a clear guidance” and wanted long-term stability so they could plan their activities accordingly over a longer period of time. Agility can offer a higher flexibility, and solutions tailored to actual needs. In return, it requires an understanding that sometimes such guidance has to be revisited and more often adapted. Obviously this can result in customers having to make considerations on their end. So welcoming change is a must on both sides.
Cross-Functional Teams
Previously, compliance led and drove the establishment of new compliance-relevant guidance and then included stakeholders along the way. This resulted in a lengthy process and burdensome back-and-forth discussions between the business and compliance. Compliance tried to balance different customers’ needs and moderate opposing interests while having a vested interest in ensuring that the approach was compliant. In agility, compliance brings together a group of experts impacted by the guidance. This allows the effect of a guidance on the stakeholders to be directly visible and enables the customers’ needs to be directly integrated into the proposed guidance. Additionally, stakeholders with opposing interests balance themselves out, without compliance sitting in between as the “referee.” Instead, compliance moderates the discussion, and focuses on finding a solution that compiles with all applicable regulations.
Simplify & Keep it Simple
One of the more challenging things regarding agility in compliance is the need to simplify and keep things simple. The agile solution is to drastically shorten all guidance and take out all the rules. Moving guidance from rule-based to principle-based. The relevant risks are explained along with how to safeguard against them, and maybe some tangible examples to show how this ideally is done. This approach allows for flexible and tailored solutions. Frequently the customers themselves develop their own, very pragmatic and fully compliant solutions – without compliance being involved. The freed-up resources can be allocated in further co-creation with customers.
