Agile Development + Agile Change + Agile Compliance = The Agile Organization

 Agile software development has been around for nearly two decades, and its popularity is increasing as its practitioners demonstrate their ability to deliver customer-focused software quickly. Now, Agile is moving into the organizational change arena, with practitioners using Agile methods to make changes to processes and organizations smoother and more painlessly than previously. If we can institute Agile tools in other areas, can we do the same in Compliance?

Absolutely. So how do we do it?

AgileMethdologyScrumProcessCompliance has typically been a fairly static area since once a regulation is implemented, it very rarely goes away. This leads to inefficiencies as new processes and systems are dropped on top of old processes without a review of the entire Compliance structure, processes, tools, and objectives.

First, let’s review some of the key tenets of Agile.

  1. All work is measured by the amount of customer value it adds. Compliance has two customers: the company’s end customer, and also the regulatory agency that oversees the company. These two may have conflicting desires and objectives, so it’s important to understand what each one wants.
  2. Projects should be broken down into the lowest viable release. A release can be software or a business process, new or changed.
  3. Developing the backlog of what needs to be done and prioritizing the backlog. This is a joint effort between all stakeholders-business, technology, and compliance.

The first step is to identify what needs to be done. It’s easy to identify the new regulation that we need to comply with, but if the thought of adding one more series of reports to the monthly stack fills you with dread, then examine your Compliance eco-system as a whole. Keep in mind who your customer is!

  • Where does your data originate?
  • Is the data manipulated in spreadsheets, opening you to errors? Or does the data you receive need to be cleansed or adjusted before you submit it?
  • How labor intensive is it to get the data you need?
  • Are your technology tools working for the benefit of your customers?
  • Do we provide summary and detail data in a format that our customers can easily consume? When did you last ask them what they wanted?
  • Are the Compliance requirements built into the product development process?
  • Are Internal Controls embedded in our tools and processes, or tacked on afterward?

The answers to these questions will lead you to develop your backlog of work. In most cases, at first pass, your backlog items will need to be split into more granular problems and solutions. Keep splitting until each idea is decomposed into the minimum viable product, the smallest unit that can be delivered and still add value to your customers. Now, prioritize the backlog, and start your first sprint with the highest priority item.

AdobeStock 105677753AgileDev

Keep in mind that Agile fosters continuous improvement. Don’t let your backlog stay static. Keep adding items to your backlog that benefit your customers, and remember that Agile is a journey, not a destination!

If you’d like help implementing Agile in your business processes, reach out to Paul via the contact form or directly through LinkedIn at

Paul Bayne