I am often asked what types of project / products Agile can be used as a methodology / framework to deliver a quality product. My answer is, it could be any, including compliance projects, and even non-IT activities run by the business.
There are obviously some criteria that suit this type of methodology and, in fact, certain organisations where it can be implemented easier. That is not to say though that teams within organisations, where it is not adopted across the organisation, cannot use some of the practices and techniques.
In fact, Agile initially became popular through the ground swell of teams and individuals thinking about how they could do things better. A collection of those individuals got together and created the Agile Manifesto and Twelve Principles, which still hold true today.
In fact, to be truly Agile, it is about changing your philosophy and mindset to live and breathe the manifesto, not just do the practices and not realise the benefits.
Compliance projects are regarded as being characterised by;
- Fixed time delivery dates
- Impacts that often stretch across the organisation
- Large number of business stakeholders
- Considered to be stable requirements
- Mandated requirements (i.e. all high priority)
- Organisations have little choice but to fall in line with imposed requirements
- Strategic rather than tactical
Let's take some of the pain points associated with compliance projects and look at Agile techniques that can help with these:
The first question is whether you know your timescales. Is the timeline from the time the compliance changes are communicated to the industry (whichever industry that may be) to the time they became legislated?
So there is a fixed period of time and that timeline gets smaller if your organisation does not get started as soon as new legislation is communicated. Given the elements of the Software Development Lifecycle that IT teams have to go through, plus the Change Management required by the business, it is often difficult to maintain quality and deliver on time.
This could have major impacts on the business, with incorrect data given to customers, the ATO or other Government bodies, right up to significant fines or even loss of life if, for example, if the legislation is around medical devices. So how can Agile help here?
One of the fundamentals of Agile is to break features down into smaller chunks. If you have smaller pieces of functionality to work on then this is easier to estimate leading to better planning. This will give early visibility to the numbers of teams that you may need to work on these projects to deliver on time.
Maybe the most important factor is that Agile allows you to prioritise early and therefore work on the most important functionality first. This allows plenty of time for early feedback and adaption of the product, which can lead to changes in penalty if needed.
The second point is around the analysis of compliance requirements. It is unlikely that a publicised paper can be directly used to build products or services.
The analysts will need to take the individual legislative requirement and place these through various scenarios relating to the business practices, product or client group, as well as factoring in the way the current systems are built or configured. The Business Analysts (BA) will need to use Requirements Engineering and Elicitation techniques in order to understand the implications to their business of compliance changes.
The are many Agile techniques that will be very useful in exploring the impacts to both IT and business processes. Often, it is assumed that Agile can only be applied to system changes or the delivery of new functionality or features.
This is a common misconception often referenced back to the Agile Manifesto, where one of the statements say "working software over following a plan." This is now interpreted as "working products", which of course can include working business processes and, in fact, any entities that deliver value to the business or customer.
The power of three (“three amigos” or often extended to four to include UX specialists, if appropriate) is a great practice to collaborate and get varying views of a problem statement or pain point. This is when the Product Owner (Business Representative or BA), the developer and the tester talk through the requirements.
This may result in the breaking down of Epics (large stories that cannot be delivered within one iteration), more user stories or 'what if' scenarios. With the three different views, often they will cover all impacts, thereby reducing or avoiding late requirements emerging. Or even worse, missing items which could result in penalties, dissatisfied customers, or loss of life.
Having created a backlog of all possible requirements, or at least recognised where more work is needed, this allows the team to practise and plan. By having a group of stories written, at least at a high level, this allows for activities like story mapping to happen; the use of personas to identify other possible items; minimum viable product (MVP) to be identified; and prioritisation of stories based on business value and risk. This then allows the team to start building, or at least prototyping, the most important features, functionality or business process changes first.
Here is an example of why we can’t use the government specifications without interpretation and preparation of in-house business requirements:
ATO TBAR Electronic reporting specification from the ATO
- Contains no out of scope section
- But requests that A provider will be required to report to the ATO superannuation income streams for members who are receiving a superannuation income stream immediately before 1 July 2017 or an income stream that commences on or after 1 July 2017.
Example 1
- However, Transition to Retirement Pensions provide an income stream. These should not be reported, however it’s not specifically called out in the spec.
- Therefore, BAs needed to perform analysis to identify this and ensure the developers had this understanding, and that the reports to the ATO were correct in this respect.
Example 2
ATO TBAR specification requires Member valuations and withdrawals from account.
It does not clarify what to do if a member has an account which they close down and withdraw all funds, which results in a disbursement being paid into the “closed” account. The BA would need to identify this ‘feature’ with the in-house product and ensure clarity around the requirement.
Example 3
Austrac requires that the ML (Money Laundering) /TF (Terrorism Financing) risk assessment must measure the level of risk (high, medium or low) associated with providing each designated service.
Within this, a number of factors are considered:
- customer types, including beneficial owners of customers and PEPs
- customers' sources of funds and wealth (for example, by enquiring into the expected source and origin of the funds to be used in the provision of the designated service)
- nature and purpose of the business relationship (for example, the customer's business or employment)
- control structure of non-individual customers (for example, complex corporate structures and the underlying beneficial owners)
- types of designated services the reporting entity provides
- how the reporting entity provides its designated services (for example, over-the-counter or online)
- foreign jurisdictions in which the reporting entity deals (for example, customers that live or are incorporated in a foreign country)
Clearly each financial institution will have different types of customers. If they sell Self-Managed Superannuation Funds (SMSF), their customers types will include the entity ‘trust’.
If they offer corporate banking, their customer entities will include corporations of different types, perhaps overseas organisations. If they offer mortgages, their customer types are likely to be individuals, shared account individuals and, to a lesser extent, companies and trusts.
Similarly, some organisations, such as ones delivering services to SMSFs only, are unlikely to be dealing with overseas or unit trusts. So, the BA needs to identify how each one of these legislated risk factors applies within the organisation under consideration.
There are many Agile practices and techniques that can be used within Compliance Projects. I would argue that Agile Methodologies and framework are, in fact, the best solution for your Compliance Projects. They are well suited to offering solutions to your major paint points in these type of projects:
- Tight deadlines
- Discovery of all your requirements
- Impact assessments through prototyping and scenario development
- Identification of Minimum Viable Product (MVP) and prioritisation of changes