ABSTRACT: Is agile feasible for a company that must adhere to regulatory compliance (in the finance / banking industry)? What are some of the main considerations?
Agile methodologies appear to be considered part of the new trend in software testing. Executives, managers, testers and other business stakeholders seem frustrated with some of the limitations, delays and inefficiencies apparently inherent with traditional SDLC models. Much of this revolves around slow time to market, fast paced industries and heavy reliance on initial requirement gathering, documentation and process formalities. Further to this, the structure, culture, knowledge and dynamics of a team become a consideration when deciding on the ability to implement an agile methodology successfully. This whitepaper will discuss some of the deliberations that may arise when contemplating the implementation of agile methodologies for a regulated industry.
Starting Point
Throughout this whitepaper I would like to address the following considerations for projects that rely on regulatory compliance and the effect an agile methodology may have on:
- Documentation – New vs Existing Regulatory Requirements
- Team Skills – the “best people”
- Business / Industry / Regulation knowledge
- Extraction of requirements as and when needed
- Tooling
Documentation
Agile should not be misunderstood to mean that there is hardly any documentation needed as part of the testing process. The agile manifesto principles state that only the amount of documentation that is needed should be applicable. On compliance projects it is likely that there will be a great deal of documentation needed, particularly for new compliance applications or new compliance companies.
A brand new company / application is probably going to need a great deal of documentation initially set up – to meet audit requirements. Some of the questions that may arise could be:
- Can this be prepared in an agile way?
- Can a team focus on various sections that need to be determined under regulatory compliance measures and consequently be tested against business processes or applications under various iterations?
- Where Commercial-Off-The-Shelf (COTS) software is already available or in place – could this have an impact on reducing some of the risk around not meeting compliance standards?
Perhaps there are challenges around the time needed to prepare documentation. Consider the prospect of having more people on an agile team assisting to develop the requirements (including the required documentation). The benefits of this would be:
- Assistance from people “pairing” – discovering inconsistencies or errors quicker due to reviews happening immediately while people are working on an item at the same time. An example of this is when a paired team sit together, with one person preparing requirements (user stories), while the other person reviews and contributes to this process at the same time it is being done. The reviewer could be validating that requirements are testable.
- Input from ‘Developers’ (or anyone who understands what will be required to develop the software) – to advise any areas that may be deemed impossible or ineffective if delivered or implemented in a certain way. There should be a focus on developing software in a way that is testable. Typically these types of issues would arise later in the process under a traditional Waterfall or V-model.
- Testing at an earlier stage – by ‘testers’ (or people who understand testing principles)
- Just in Time Documentation – high level user stories or features noted in the product backlog may not need to be defined at a lower level until it is time to begin working on that item. This helps to avoid waste and enhance focus.
For an existing company / application it could be much more feasible to use agile to make amendments to regulations – perhaps more easily contemplated as achievable due to the potentially smaller scale of updates.
Team Skills
Agile teams should be adaptable to incorporate the “best people” for the roles required – whether these are people with IT technical knowledge, or people with compliance and regulatory requirement business knowledge. It is all about what works for a specific team. Ideally it is important to have “Team Players”. All members in the team need to apply a collaborative approach to their work. There is no room for people to keep knowledge, ideas or opinions to themselves.
If any member of an agile team does not wish to engage fully in the agreed process, things can go wrong. If critical business users have no time to be involved in the requirement gathering process, or if they are not supported by their management to participate in the process, they may find themselves receiving a product they do not want or need, or they may be asked to test a system or product they have had no prior exposure to and know nothing about.
Industry Knowledge
Certain individuals know company, industry and complex business rules in great detail. For people with such detailed knowledge, requirements may only need to be initially defined at a higher level of detail. Instead of having all new regulation requirements and their impacts defined for all features at the beginning of the project, the focus could be placed on high level changes to requirements, which will be elaborated on when needed during an agile process. Supporting this, there could be an existing repository of information that could be referenced separately, as and when needed.
If confidential information arises or exists due to the nature of the work, this should be immediately addressed. As with traditional methods, confidential information needs strategies to mitigate the way it is handled. Confidentiality disclosures could prove useful for this. Alternatively, by ensuring certain experts become team members in an agile project, more emphasis could be placed on establishing the importance of extracting the correct requirements and testing relevant business scenarios, to ensure that such scenarios can be easily maintained when the software is released into a production environment.
For example: An Underwriter may not wish to disclose specific information about how an insurance claim is being calculated due to the sensitive nature of the material. By ensuring that underwriters are involved as agile team members they may better understand the importance of defining the correct requirements and testing those requirements against compliance measures. The risk may be reduced below that of a traditional model – where the Underwriter may prove unwilling to co-operate since all requirements need to be supposedly defined and clearly documented at the beginning stages of a project. Information that may not normally be raised may be mitigated by the contribution of that team member.
Extracting Requirements as needed
Team members must be trusted to analyse and extract the correct requirements, as and when needed. When comparing this to traditional methods a similar thing often occurs in practice. Business Analysts or System Specialists are relied upon to determine the compliance or regulatory changes, which may sometimes be subject to interpretation. By using an agile method – particularly where there are more people determining the requirements – different perspectives can be considered, as and when needed. Typically, this occurs when a feature is pulled from the product backlog to be worked on during the next iteration.
Since there may be a number of requirements to be implemented, it is likely that different requirements / features (or product backlog items) will be implemented across a number of iterations. It should be noted that if it is not feasible to move the code to production at the end of an iteration, because not all relevant functionality is included, the iteration does not have to be released to a production environment, until a later iteration.
Tooling
A compliance project or regulated industry is likely to require metrics to be presented to a management team or an audit committee. Tools may prove to be a great support for an agile project.
Tooling would be highly recommended to keep track of features completed. Application Lifecycle Management (ALM) tools are worth investigating to determine if they can be utilised for a specific project. These would assist with having visibility and traceability of requirements and to produce metrics / reports to help with iteration planning. They could also be beneficial for other reports requested by regulators, progress reports of features delivered, testing progress, and overall performance of User Stories completed per iteration. ALM tooling would assist larger or distributed teams greatly.
Conclusion
Agile allows faster time to market by deploying working code more quickly. Application of user stories and iterations in a regulated industry can help to keep the team focused for large projects. Compliance regulations or legislation can sometimes change quickly. The opportunity to more easily cater for change gives the business stakeholders value earlier. As requirements change there is an avoidance of waste, due to not designing and detailing all requirements upfront.
A successful agile compliance project requires the right people, the right team culture and the right amount of regulation / industry knowledge in the team.
A tool may assist in enabling the appropriate levels of communication and reporting – so that the status of the project can be easily visible.
Various considerations for agile projects in a regulated industry have been discussed here. Although there may be challenges, for a team with the right focus and frame of mind it is a matter of “where there is a will there is a way”. Some areas may need to be adapted – however that merely seems to be in line with the whole essence and concept of what agile is all about – agility and responsiveness.