bruno cochard in Directors and Executives, IT - Information Technology, Agile Coach Agile Compliance lead consultant | Agile enterprise in banking • Barclays Investment Bank Oct 4, 2016 · 2 min read · +800

Why the need for agile compliance

Why the need for agile compliance

The rift between agile and compliance

There is a disconnect between agile development and compliance management. This is due to the difference in approach between how work is achieved in these contexts:

  • Agile development involves all the activities of developing a small number of product features within a short time-frame.
  • Compliance management remediates all risks and regulatory standards through identification of the assessment of each life-cycle activity.

The core driver for an agile compliance management is be to bring governance, risk management and compliance through an iterative cycle. This doesn't mean to apply current compliance process to each and every iteration or release but to re-think the driver behind compliance and the current approach to manage it.

A note on the definition of risk

This article doesn't refer to project management risks that most bibliography on agile risk management does, such as delay of delivery, over-spent, technical debt and such.

This article refers to risks as the uncertainty for the company to achieve strategic, operational, tactical and compliance objectives. For the finance industry, it would include risks of financial crime or credit lending. For the pharmaceutical industry it would include risks of patient safety and confidentiality. For any industry it would include security, information management, legal responsibility, supplier management...

What is compliance management

Compliance management, otherwise called Governance, Risk management and Compliance (GRC), is required in most industries to demonstrate control over the development of a product. The reason for such demonstration is to provide evidence that the company is meeting its objective and more importantly is meeting regulatory standards.

Projects being developed in traditional, sequential manner demonstrate controls through the sequences or phases by which it is constructed, which are Analysis, Design, Implementation, Acceptance and Deployment. This is a simplified model in order to keep it simple, as there are usually more phases such as planning, integration, maintenance and so forth. Keep in mind though that these phases are not purely sequential but can involve returning to a previous phase if the condition of success for a given activity are not met and require additional work in earlier stage. Waterfall in pure sequential manner is mainly an invention of an agilist to explain why agile is better, which is not the point of this article. Regulated companies actually use the V-Cycle rather than waterfall.

Considering these sequences, governance, risk management and compliance are ensured through validation for each phase:

  • The underlying activities have been performed and reported (Governance)
  • The risk inherent to the phase has been assessed and mitigated (Risk management)
  • The regulatory or internal standards has been identified and taken into account (Compliance)

This demonstrate that each phase has completed its objective before passing its output to the next phase. This is one of the principles of Total Quality Management where each member of the team is responsible for ensuring that the previous owner of a task has delivered the quality level required.

An iterative approach to compliance

Considering the disconnect mentioned earlier, most companies approach agile compliance model by applying the principles of traditional governance to each and every release of the software. This actually means an extended planning phase when preparing the definition of the next release, and an extended acceptance phase once the development of the release has been completed.

For anyone working in agile software development, this goes against the main value of agile development that is small frequent releases of the product.

The opposite approach, which is the core of this agile compliance framework, is to apply agile values directly to compliance management. This means first to NOT remediate all risks for each phase but identify the actual risks raised for the next release to come and mitigate them DURING the actual development. This also mean to identify the real value of mitigating these enterprise risks.

But going further than managing better the scope of risks actually raised, the principles of an agile compliance framework is to embed an agile management of risk completely within the work of the agile development teams.

  • Continuous Compliance: The product is always in a compliant state and ready to be deployed
  • Risk Based Monitoring: the compliance is monitored through risks generated by the change.
  • Embedded Validation: the agile development artefacts are used as-is to validate compliance
  • Reverse Control: the product owner and his team set their own control environment. 

Read more here: Implementation of an Agile Compliance Framework

bruno cochard Oct 6, 2016 · #2

#1 @Gert Scholtz Thank you Gert. I opted for BeBee after reading your articles and seeing that the other medium really doesn't work anymore...

+1 +1
Gert Scholtz Oct 4, 2016 · #1

@bruno cochard.Good article Bruno and good to see you joining beBee. A warm welcome to you!