Agility in Compliance - Yes, please!

Published 22 November 2019

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.



Hannes Oswald-Brügel
Head Pharma Healthcare Compliance Office

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, 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.

Some Agile Principles

The following paragraphs are intended to provide a rough overview on how agile can be applied in compliance. The overview is intended to highlight relevant areas for the topic at hand. The areas covered do not follow any order or rating, and the overview does not intend to be comprehensive.

Traditionally, particularly in a German or Swiss environment, people tend to engineer to perfection. A system, tool, guidance, or anything else must have all the potentially needed specifications and functions perfectly embedded – from the beginning. It can only be implemented once it is “perfect.” This is referred to as the “waterfall method”: There is a long phase of construction (engineering), afterwards planning for implementation, nowadays usually a “pilot” (limited area of application or implementation to try and learn from), and finally the big “roll-out” in which the solution is broadly applied or implemented.

In agile, the approach is different: It aims to develop a potential solution that at least serves the desired purpose at a minimal standard as quickly as possible. It will most likely not be perfect, but it should at least serve the purpose. In agile terminology this is referred to as the “minimal viable product” (MVP). As this MVP is used right from the beginning, it is possible to immediately collect feedback from the people applying it – the customers. Their feedback will provide further insight as to what else is needed and what could be done better. These insights can then be used to adapt and improve the product. Then the process of iteration begins, the MVP is worked over and improved in several cycles; bit by bit, step by step.

The big advantage is that the most urgent customer needs are directly met and one immediately learns what does work and what doesn’t. The risk of coming up with a fully fledged, very expensive all-inclusive solution addressing a problem that nobody has or providing a solution that nobody favors is eliminated. In this process of iteration and change, failure is a key learning that cannot comprise the entire, fully engineered product, but affects just one feature of it that can be optimized in the next iteration. The task at hand is approached bit by bit, based on meeting the customer’s needs, which brings along another important principle – the co-creation with the customer.

In this way of working, there is a constant need for adaptation, alteration, trying things differently – in summary, constant change. Accordingly, individuals involved must have a mindset that welcomes change. Only by allowing for a permanent alteration can one profit from the principles of agile – can one actually be agile.

Designing an MVP in our ever more complex environment regularly demands involving a number of different experts from different disciplines. It will drastically slow the design phase down or even completely hinder the design of an MVP if all affected or relevant disciplines are not part of the design at once. A shuttling back and forth between stakeholders will turn the process into a regular waterfall process.

Finally, as the idea is to deliver and develop things fast, things have to be kept simple. It is impossible to handle all tasks and issues at once and to be fast at the same time. A high complexity will prevent the rapid implementation that allows for vital feedback and learnings, leading to iteration, co-creation, etc. Accordingly, it is crucial to always focus on a straightforward, pragmatic and simple approach for the MVP, and any (following) iteration. The fact that a product with more iterations and accordingly more features will over time become more complex does not hinder agility per se. It might well be, however, that a 2.0 or next version of a solution considered “final” at some stage demands a start from scratch as one cannot handle the complexity of the current solution any more (or it prevents the development of MVPs and iteration).

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.


8th Annual
Corporate Compliance and Transparency in Life Sciences
20 - 21 February 2019 Zurich, Switzerland