How agile methods and software development according to GAMP5 (Good Automated Manufacturing Practise) match
In many industries, special legal and regulatory requirements apply to assess and ensure product quality, risks and the effects of software. One such so-called ‘regulated environment’ is the pharmaceutical industry and the entire healthcare sector as such. Here, too, an approach known as ‘Good Automated Manufacturing Practice’ has become common practice almost without exception, known by the abbreviation GAMP5.
GAMP5 provides a set of rules for automatable processes. This also includes a recommended approach for software development and maintenance. As a rule, GAMP5 is based on a V-model approach to map quality-assured and documented development, maintenance and operation within a quality assurance system.
GAMP5 regulations in software development
An essential part of the GAMP5 standard is the assumption that all requirements have been recorded and documented before development begins, so that in the event of problems or damage, the responsible parties can be contacted and countermeasures planned. It also allows the success of a project to be clearly measured and documented at a later stage.
In contrast to the GAMP5 approach, an agile project management approach allows more freedom in short-term planning and can react more flexibly to changes and unexpected events. In addition, the flow of information between all parties involved is significantly faster due to direct communication. This means that errors can be detected and eliminated earlier.
Since the GAMP approach is highly standardised in a regulated environment and clarifies the expected results, the project duration, the approach and the costs in advance between all parties involved, this model has undeniable advantages for compliance and governance. However, the disadvantage of the V-model is that it is only partially suitable for the development process due to its strict specifications and low flexibility.
GAMP5 regulations and an agile approach
However, there is nothing in the GAMP5 model that argues against making the development team's approach agile. By taking advantage of both models, there is an opportunity to improve the overall quality and speed of a development without violating the regulatory requirements.
A purely agile approach in a regulated environment has the disadvantage of having to reimplement the entire documentation process. In practice, this often leads to considerable effort for coordination and release. These expenses are often underestimated and cost the project a lot of resources, which are then no longer available for the actual development and quality assurance.
Agile software development in a regulated environment – how to
If the advantages of the V-model and the agile approach can be successfully combined and the disadvantages kept to a minimum, it is possible to improve quality and development speed while still meeting regulatory requirements.
In principle, the organisation of the project must be adapted to the specific requirements that arise from the project objectives. Therefore, at this point, some rather general approaches that facilitate the start of agile software development in a regulated environment:
1. Agile methods can be used in the development teams
Experience shows that development teams are more productive and satisfied when they are released from the rigid organisational constraints of the V-model and allowed to organise themselves. In this context, software testing is an explicit part of the work: DONE means developed, tested and also documented.
2. All other parts of the project are organised according to the rules of the V-model.
Usually, especially in large regulated organisations, the project management guidelines are strictly defined and can only be changed with a considerable amount of coordination effort. In most cases, the planned project duration and budget are simply not sufficient for this.
3. Clear communication interfaces between the agile and conventional sub-projects involving the establishment of an adapted role model
Since responsibilities are organised differently in the V-model and in the agile approach, the distribution of roles, responsibilities and communication channels should be coordinated at the start of the project. Without this coordination, there are often frictional losses and misunderstandings in communication.
4. Completed requirements engineering phase and fully defined acceptance criteria before development activities begin
In the V-model, subsequent changes or additions to the requirements can usually only be implemented with considerable organisational effort. One way to resolve the conflict between the rigid V-model and the flexible agile approach may be to define the requirements and acceptance criteria in such a way that the development teams are granted sufficient freedom in the implementation. Here, the Requirements Engineers are particularly challenged to strike a balance between resilient requirements and flexible implementation.
5. Transfer of defined and tested releases from the development team to the project
A good prerequisite for a successful project is the clear definition of milestones, each of which, when reached, is accompanied by a new release for the higher test levels. Among other things, this facilitates the communication of the project's progress and the management of expectations for the overall project.
6. High test frequency in the development team, lower test frequency for the other test levels
Ideally, each build process in the development team should be concluded with an automated test run. This is easiest to implement if the unit tests are created by the developers in the source code. The higher the test level, the less often testing is required, since the lower test levels already ensure a large part of the quality requirements. Here, it has proven useful to strive for the most complete coverage possible of the unit tests, taking into account the identified risks.
7. Taking into account the different speeds and approaches in the project plan
In the project plan, there will most likely be different requirements for the frequency of progress and defect reports, since the development teams usually generate daily builds with defect reports, while the other testers may work with weekly or monthly releases and reports.
8. Test management and release processes must be adapted to the hybrid approach.
In the agile development process, the degree of automation of testing should be very high and the release process should be based on milestones. The higher the test level, the more formal and manual the testing will be, which puts the focus of test management on the completeness of documentation and the organisation of the tests.
Taking these key aspects into account, the introduction of agile software development can also be successful in a regulated environment. A systematic approach is the basic requirement for integrating agile software development methods while adhering to regulatory requirements.
If you would also like to benefit from our expertise in regulated environments, then let's talk about your specific challenge. You can contact us at techtalk@trendig.com and we look forward to talking to you.
