“Intelligence is the ability to adapt to change.” (Stephen Hawking)
Introduction
To date, classical methodologies, such as Waterfall or V-model, are standard practices. But Agile frameworks like Scrum are lately gaining more and more popularity. Several big companies started to work in an agile way, like IBM1, Microsoft2 or Spotify3. Agile software development can contribute to businesses being more efficient by supporting a faster implementation and validation, and thus enabling the development and delivery of cost-effective, safe, and compliant products with a decreased time to market4. Although a complete switch to an agile framework would be most effective, this is often not realizable. On the one hand, such a change is time-consuming and expensive at first. And on the other hand, it is also a question of compliance in regulated industries: “Will following this new framework ensure compliance?”. Introducing agile in GxP environments can present some challenges in this regard. This article aims to address the possibilities of incorporating and adapting the agile framework in practice.
Background
A group of software developers laid the foundation for agile software development in 2001 with an Agile Manifesto5,6. The ISO, IEC and IEEE define agile development as a “development approach based on iterative development […], frequent inspection and adaptation, and incremental deliveries in which requirements and solutions evolve through collaboration in cross-functional teams and through continuous stakeholder […] feedback”7. The agile approach differs from the classical one, especially in:
- The way the solution is produced.
- How teams are organized to work together.
- How requirements and results are documented.
Classical methods are built on different successive phases, requiring a lot of planning and paying special attention to interactions between various team’s processes. Finally, the end-user gets a complete solution. Working agile allows for more flexibility and adaptation to changes. The final solution is split into smaller pieces, potentially delivered one after the other to the end-user. In Scrum – the heart of agile frameworks – those pieces are developed within a sprint which consists of five basic steps:
- The Planning Meeting
- The development Work
- The Daily Scrums
- The Sprint Review
- The Sprint Retrospective
Brisk and brief 15-minute daily scrums allow teams to evaluate the progress toward the goal of the respective sprint and adjust their activities to reduce complexity and continually improve the process.
GxP stands for good practices in a certain field for which x is a variable. Those include, inter alia, Good Manufacturing Practices and Good Documentation Practices. In a GxP regulated environment, it is important to comply with regulations, standards, and guidelines. Therefore, a change from a classical approach to an agile way must take those requirements into account.
How can classical procedures be transferred into an agile approach?
A switch of approaches needs to consider that the different models use varying terminologies and documentation methods. Just transferring the classical terms and documents into the new approach should be avoided. Documents in question are, for instance, the quality or validation plan. How and where could their content be named and stored? A solution would be to integrate the quality plan’s substance into the project vision. Thus, it is about making Quality related attributes key elements in project deliverables. The same will apply to documents and records. The content is what matters, regardless of where it is stored. The BioPhorum Operations Group provides “Guidance on the use of agile in a GxP environment”, in which it keeps the classic elements of the validation plan and report, but changes the stages of design, build and test into an agile way4.
Especially from a regulatory perspective, the substance of documents needs to be reconsidered and mapped to the agile framework. In a classical approach, it is common to store similar information redundantly in different documents. Now, in agile, the documents vs. records discussion falls away. The employment of supporting tools consisting of validated computerized sytems, such as Lifecycle Management Systems, Testing Management Computer Systems and Electronic Document Management Systems, is recommended4. Documents are produced once and updated through the project lifecycle, directly from the tool used for managing it (e.g. Jira, MS Azure). Once the documentation is finalized, it is electronically signed. It is not static anymore; changes can be added and tracked, producing new versions that are then signed again. The specific moment for this depends on the individual project which could be, for example, after each sprint, after a deliverable has been met or on a major release of bundled deliverables. The Validation Plan has to define which documents will be updated when.
Using the tools mentioned above, it is beneficial when the entire implementation, validation and operation process is included. Thus, there should be either a tool that contains different managing functionalities by design (e.g. Lifecycle, Testing, Documents, Training etc.) or a higher level tool that is able to integrate or interoperate with different tools in use. This implies that the solution comes again from the tools: on the main tool the connections to other tools can be referred to – as soon as all the tools are validated, and documents/records are managed under Data Integrity principles.
GxP compliance
In a GxP regulated environment it is not enough to focus only on the technical solution. The requirements, processes, functionalities, and training as well as the documents, evidence and signatures also have to be taken into consideration. To ensure compliance, records must be immutably kept, to have a proof in case of an inspection. An electronic Document Management System, which should also be integrated in a supporting tool as previously mentioned (e.g. Confluence with Jira, SharePoint with MS Azure), must be used to store documents and records. It can also manage electronic signatures to be compliant with the FDA 21 CFR Part 11.
Such a tool also allows the categorization of documents into dynamic and static ones. This is required since certain information (such as records or reports) must not be changed. Nevertheless, to avoid the need of always producing a new document version, the outcome of some user stories could complement the previously created static documentation. The tool will indeed guarantee the flow, acting as a Traceability Matrix.
The Guidance document of the Biophorum Operations Group also suggests that with a computer system – including prescribed audit trails and electronic signatures – paperless validation can be enhanced: changing from documents to electronic documentation/records.4
In Scrum, the requirements to comply with certain regulations could be on the one hand clearly defined in the user stories. On the other hand, they should be incorporated in the definition of Done, setting the standard for a finished increment: it has to take into account both user acceptance, technical changes, quality review, and a final signature and approval. In the end, a tool could make use of an algorithm which checks the deliverables against the requirements.
Furthermore, roles and responsibilities need to be newly defined to fit into the agile framework. The core roles provided in Scrum are the Product Owner, the Scrum Master and the Development Team. In a GxP environment it is also beneficial to involve the Quality Assurance Unit for support in development work and validation4. Furthermore, support from senior management is crucial for a thriving agile adoption4.
Conclusion
Changing to an agile approach requires a rethinking of the entire development process in terms of “what needs to be delivered from a Quality perspective”, rather than “which documents have to be delivered”. Everything is about finding an individual solution that ensures compliance and is not just transferred from classical methods. In the end, the whole organization needs to live and work with the agile approach to be efficient.
References
1 De Ycaza, M. (2018): How IBM’s Biggest Business Unit Got Agile. URL: https://www.ibm.com/blogs/think/2018/05/how-ibms-biggest-business-unit-got-agile/ [last accessed on January 11, 2021].
2 Microsoft (2020): Agile at Microsoft. URL: https://azure.microsoft.com/de-de/resources/videos/agile-at-microsoft/ [last accessed on January 11, 2021].
3 Rigby, D.K.; Sutherland, J.; Takeuchi, H. (2016): Embracing Agile. URL: https://hbr.org/2016/05/embracing-agile [last accessed on January 11, 2021].
4 BioPhorum Operations Group (2017): GUIDANCE ON THE USE OF AGILE IN A GxP ENVIRONMENT. URL: https://www.biophorum.com/wp-content/uploads/bp_downloads/Agile-Guidance-in-a-GxP-Environment.pdf [last accessed on January 20, 2021].
5 Denning, S. (2016): What Is Agile URL:
https://www.forbes.com/sites/stevedenning/2016/08/13/what-is-agile/ [last accessed on January 11, 2021]
6 Beck, K. et al. (2001): Manifesto for Agile Software Development. URL: http://agilemanifesto.org/ [last accessed on November 11, 2021].
7 ISO/IEC/IEEE 26515:2018: Systems and software engineering – Developing information for users in an agile environment.
Authors:
Sonja Vorwerk, Life Science Consultant KVALITO
Estanislao Maria de Ferrater Pagani, Life Science Consultant KVALITO
KVALITO is a strategic partner and global quality and compliance service and network for regulated industries. To learn more about our service, please visit us on www.kvalito.ch.
If you would like to benefit from KVALITO’s expert services, feel free to send us an email to contact@kvalito.ch. Are you looking for an exciting and challenging position as a consultant in Europe? Send your complete application to recruiting@kvalito.ch.
