Regulated Agile

Agile methods with "individuals and interactions over processes and tools" and a regulated environment with clearly defined processes and checkpoints, how can this fit together?

One regulation example

In Germany banking and insurance companies are, among other organizations, strongly regulated and controlled by the Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin). In this article I collected all parts from Bankaufsichtliche Anforderungen an die IT (BAIT) and Versicherungsaufsichtliche Anforderungen an die IT (VAIT) issued by the BaFin which in my opinion are relevant for working agile in the IT of banks and insurances. Both documents are not only very similar but in some parts exactly equal. These parts formulate some limitations for agile projects:

This article is a collection of subjective thoughts about how to harmonize agile principles and regulative requirements. It is not intended as a substitute for legal advice. You have to consult your legal or compliance department in all questions around compliance with the regulations. Should you decide to act upon any information in this article, you do so strictly at your own risk.

Separation of development and operations (DevOps)

One central aim of most agile models is the end to end responsibility of a team for a system or product. End to end normally covers all aspects and the full life cycle from the first idea to the decommissioning. This includes the removal of the classical gap between development and operations.

BAIT 2.6 article

Conflicts of interest and activities that are not compatible with each other shall be avoided within the organisational and operational structure of IT.

BAIT 2.6 comment

Conflicts of interest between activities connected, for example, with application development and tasks performed by IT operations can be countered by taking organisation or operational measures and/or by defining roles adequately.

VAIT 2.12 article

Conflicts of interest shall be avoided within the organisational and operational structure of IT.

VAIT 2.12 comment

When designing the organisational and operational structure of IT, it shall be ensured that activities that are not compatible with each other are performed by different staff members.

Conflicts of interest between activities connected, for example, with application development and tasks performed by IT operations can be countered by taking organisational or operational measures and/or by defining roles adequately.

BAIT 2.7 and VAIT 2.13 article

The management board shall define appropriate quantitative or qualitative criteria for managing those areas responsible for operations and for the further development of IT systems, and compliance with them shall be monitored.

BAIT 2.7 and VAIT 2.13 comment

The following elements can be considered when defining such criteria: quality of performance, availability, maintainability, adjustability to new requirements, security of IT systems or the related IT processes, and cost.

Consequences

DevOps are not explicitly mentioned, but the examples in BAIT/VAIT show that a combination of roles in development and operations in one person is not desirable. There should be a clear handover for an IT change from one area of accountability (development) to another (operations) to prevent uncontrolled productive deployments. DevOps can help to work more agile. But from my point of view it is not essential that one person fulfills the development and operations roles. It is possible to coordinate the process between both roles in other ways. Developers and operators could be part of the same agile team. In this case one task of a user story could be the handover to operations.

Requirements Engineering

The agile manifest puts "working software over comprehensive documentation". This statement stands in contrast to the detailed business and technical concepts usually written in waterfall processes upfront to the implementation phase. According to agile ideas the business requirements are split into smaller pieces and described as user stories. Only the user stories for the next couple of sprints are described on a detailed level that makes the developers understand what is needed. How a user story should be implemented is mostly not described upfront to the development in agile projects.

BAIT 6.31 article

Material modifications to the IT systems in the course of IT projects, their impact on the organisational and operational structure of IT and on the related IT processes shall be evaluated as part of an impact analysis (see AT 8.2 of MaRisk). With respect to their first use and material modifications to IT systems, the requirements set out in AT 7.2 (in particular numbers 3 and 5) of MaRisk, AT 8.2 number 1 of MaRisk and AT 8.3 number 1 of MaRisk shall be met.

VAIT 6.42 article

Material modifications to the IT systems in the course of IT projects, their impact on the organisational and operational structure of IT and on the related IT processes shall be evaluated in advance as part of an impact analysis. In doing so, the undertaking shall analyse in particular the impact of the planned changes on the control methods and the intensity of controls. The organisational units integrated into the workflows shall be subsequently involved in these analyses. As part of their duties, the independent risk management function, the compliance function and the actuarial function shall also be involved, to the extent that the undertaking is required by law to establish the relevant function. The internal audit function may be involved in an advisory capacity. Sentences 1 to 5 shall also apply with regard to the initial use and material modifications of IT systems.

BAIT 6.37 article

Requirements for the functionality of the application must be compiled, evaluated and documented in the same way as for non-functional requirements. The organisational units shall be responsible for compiling and evaluating the requirements.

VAIT 6.50 article

Both requirements for the functionality of the application and non-functional requirements must be compiled, evaluated and documented appropriately. The organisational units shall be responsible for compiling and evaluating the requirements.

BAIT 6.37 and VAIT 6.50 comment

Examples of requirements documents include:

Examples of non-functional requirements for IT systems include:

BAIT 7.49 and VAIT 7.62 article

Change requests for IT systems shall be accepted, documented, evaluated taking due account of potential implementation risks, prioritised and approved in an orderly way. The change shall be implemented in a coordinated and secure way.

BAIT 7.49 and VAIT 7.62 comment

Steps to securely implement the changes to live operations include, for example:

For low-risk configuration changes/parameter settings (e.g. changes to the layout of applications, replacement of defective hardware components, installation of processors), different process rules/checks can be defined (e.g. dual control principle, documentation of changes or of downstream checks).

Consequences

An IT system change must be described in a way that its consequences and risks for the IT organization and IT processes can be analyzed. In an agile project the user stories must cover all important parts of the project and must be described on a detailed level in the project proposal. This also includes the non-functional requirements. A full estimation about consequences and risks of an IT change is only possible, if most of the user stories of an IT change are documented. The detail level of the user story description should depend on the expected risks. Complex cases with high risks may require an iterative process. First the user stories should be described on a high level. Afterwards the risks should be checked. In the next iteration the use stories should be detailed to check additional risks or to get better insight into already known risks.

Quality Insurance and Testing

In agile software projects testing is an integral part of every sprint. All workproducts of a sprint are only ready "done" if the acceptance (quality) criteria are fulfilled. In the software development nightly automated tests are best practice.

VAIT 6.43 article

The IT systems shall be tested before they go live and approved by the staff members with specialist and technical responsibility. To this end a standard process of development, testing, approval and implementation in the production processes shall be established. The production and testing environments shall generally be kept separate. These requirements shall generally also apply to material modifications of IT systems.

BAIT 6.32 and VAIT 6.45 article

Appropriate rules shall be defined for the organisational framework of IT projects (including quality assurance measures) and the criteria for its application.

BAIT 6.41 article

A methodology for testing applications prior to their first use and after material modifications shall be defined and introduced. The scope of the tests shall include the functionality of the application, the security controls and system performance under various stress scenarios. The organisational unit responsible for the application shall be tasked with performing the technical acceptance tests. Test environments for performing the acceptance tests shall correspond to the production environment in aspects material to the test. Test activities and test results shall be documented.

VAIT 6.54 article

A methodology for testing applications prior to their first use and after material modifications shall be defined and introduced. The scope of the tests shall include the functionality of the application and the security controls. If system performance is important for an application, it shall also be tested under various relevant stress scenarios. The organisational unit responsible for the application shall be tasked with performing the technical acceptance tests. Test environments for performing the acceptance tests shall correspond to the production environment in aspects material to the test. Test activities and test results shall be documented.

BAIT 6.41 and VAIT 6.54 comment

This comprises relevant expertise as well as appropriately structured independence from the application developers.

Test documentation contains the following points as a minimum:

Consequences

Testing must be a multistage process. The end user, i.e. usually the business department, is responsible for the last test phase. Each test and each test activity in all stages should be documented comprehensively. In a real interdisciplinary agile project team with participation of business people it would be possible to conduct the tests inside each sprint.

Unfortunately in practice there are some factors leading to separate test sprints:

Test automation can help to a certain extend but will not completely obviate separate test sprints. The topic testing in an agile software project will be part of a later article.

Process Model and Controlling

Depending on the chosen agile process the detail level of the description is very different. Compared to the descriptions of processes and controlling tools for classical project management models the most agile processes are described only on a much higher level.

BAIT 6.33 and VAIT 6.46 article

IT projects shall be managed appropriately, particularly taking account of risks in relation to the duration, use of resources, and quality of IT projects. To this end, model procedures shall be defined and compliance with them shall be monitored.

BAIT 6.33 and VAIT 6.46 comment

For example, the decision to transition between project phases can depend on clear quality criteria set out in the relevant model procedure.

BAIT 6.36 and VAIT 6.49 article

Appropriate processes shall be defined for application development which contain specifications for identifying requirements, for the development objective, for (technical) implementation (including coding guidelines), for quality assurance, and for testing, approval and release.

BAIT 6.36 and VAIT 6.49 comment

Application development includes, for example, the development of software to support bank-specific processes or the applications developed internally by end users in the organisational units (e.g. end-user computing, EUC). The processes are designed in a risk-oriented way.

Consequences

The software development process must be documented. It must include gateways for the transition into the next phase. A controlling of the stage of completion and consumption of resources must be in place. An agile process can be described similar to a waterfall process. This description could as well include all customizations and adaptations of the standard model. Controlling can be done based on a backlog with estimated user stories and the team velocity. If the project follows a clear definition of done for all work products, controlling in an agile project can be easier as in a classical project. A work product is ready or not after a sprint. There are no uncertain percentages

Documentation

As already stated in the chapter "Requirements Engineering", agile methods are not well known for comprehensive documentations. But this does not mean necessarily no documentation. It only means no useless documentation.

BAIT 6.40 article

The application and its development shall be documented in a clearly structured way and in a manner that is readily comprehensible for competent third parties.

BAIT 6.40 comment

The application documentation includes the following content as a minimum:

The comprehensibility of the application development is aided by a version history of the source code and requirements documents, for example.

VAIT 6.53 article

Both applications developed by third parties for the undertaking and applications developed in-house shall be documented in a clearly structured way and in a manner that is readily comprehensible for competent third parties.

VAIT 6.53 comment

The documentation of the application and its development shall as a minimum answer the following questions:

The comprehensibility of the application development is aided by a version history of the source code and requirements documents, for example.

Consequences

Beside the technical administration and end user documents the documentation must also cover the development process of a particular IT change. A handbook for the end user, for the technical system and operations must be created. Preparation and updates of technical, administrative and end user documents must be part of the definition of done. The documentation of the development process change can be extracted from tools supporting the agile process. For technical documentation the comment and description possibilities of the used tools should be applied as much as possible. This documentation will most likely be updated if something changes in the future.

Conclusion

The requirements in the previous chapters conflict with the principle formulated in the agile manifest and some - if not most agile methods. But if we have a look at the intention behind both, the regulatory requirements and the agile principles, it is possible to find solutions for agile projects in an regulated environment.

Copyright 2021, last updated 11.01.2021

References

BAIT

English: https://www.bafin.de/SharedDocs/Downloads/EN/Rundschreiben/dl_rs_1710_ba_BAIT_en.html, found 07.10.2020

German: https://www.bafin.de/SharedDocs/Downloads/EN/Rundschreiben/dl_rs_1710_ba_BAIT_en.html, found 07.10.2020

VAIT

English: https://www.bafin.de/SharedDocs/Downloads/EN/Rundschreiben/dl_rs_1810_vait_va_en.html, found 07.10.2020

German: https://www.bafin.de/SharedDocs/Downloads/DE/Rundschreiben/dl_rs_1810_vait_va.html, found 07.10.2020

Agile Manifesto

Agile Manifesto, https://agilemanifesto.org/iso/en/manifesto.html, found 30.01.2020