How Pharmaceutical Companies Can Implement Agile Methodology Part 1 of 2

In a constantly changing world that is dominated by uncertainty, many industries have already adopted Agile software practices, aiming at enhancing flexibility within their business processes and enabling innovation. Although the medical device sector has already embraced Agile within their systems and business organization, the pharmaceutical industry is still behind, mostly due to compliance concerns and misconceptions regarding regulatory expectations in a GxP environment.

Before we jump into how to successfully implement Agile in pharma, let’s review the terminology. GxP refers to ‘good practice’ guidelines and regulations, where x could be M (manufacturing), C (clinical), L (laboratory), D (documentation), etc. GxP compliance is an essential component within the life science industries, created to ensure that food, medical devices, drugs, and other life science products are safe and effective.

Agile methodology is a development process that allows teams to respond to changing requirements and customer unpredictability through incremental, iterative project work, usually through regular developmental cycles, or sprints. It allows teams to pivot more quickly during the dev process, unlike the Waterfall methodology which waits for a phase or deliverable to be completed before trying to make changes. While they both have their place, Agile is generally more flexible in terms of client involvement, budget, and timelines and so is often the preferred choice.

How to implement Agile in a GxP Environment

In this part 1 of a two-part series, we reference the ISPE GAMP Good Practice Guide: Enabling Innovation to help clarify how Agile pharmaceutical development can be perfectly aligned with GxP and ISPE GAMP 5 principles. We discuss how it enables flexibility and innovation while maintaining all the development steps of the Waterfall model. And we cover the requirements, specifications, and overall Agile topic in regulated environments.

Figure 1: Comparison of the Waterfall and Agile methodologies regarding Software development. Adapted from easyagile.com

Requirement Identification & Design Specifications

Let’s start with a few key considerations when implementing Agile:

1. Ensure the approach fits the intended use: Agile for innovation and Waterfall for defined requirements

In a GxP environment, systems need to be fit-for-intended use. This is accomplished by identifying functional and non-functional requirements, which then shape the system specifications that will drive development. In the traditional linear or Waterfall model, requirements are identified in the form of the User Requirement Specification—URS, a document that needs to be produced, reviewed and approved. Any subsequent changes to it are required to undergo the same review and approval process. This approach may be appropriate when the development is straightforward and the developers have prior experience with similar products, or if the regulated company has a very clear set of expectations as part of the tender process for supplier selection.

However, in cases where the scope is less clearly defined, especially when it comes to customized developments, where a “discovery mindset” is followed, Agile is a more suitable approach. Its adoption enables faster initial system deployment and subsequent incremental development, and it can be executed in a controlled way that adheres to GxP requirements. This model is supported by the EU Annex 11, which is aligned with the GAMP 5 Guide: Compliant GxP Computerized Systems that states in Appendix D1: “Requirements may not initially be fully defined, e.g., for some Category 5 systems, requirements are developed during subsequent phases of the project.”

Figure 2: Scrum Framework Model, adapted from ISPE GAMP Good Practice Guide: Enabling Innovation, source scrum.org

2. Define Requirements & Acceptance Criteria in Agile

In Agile, requirements are identified within user stories, epics, or features, referred to as Product Backlog Items (PBIs), and managed on a backlog basis. Using tools that allow for the addition and change of requirements, the development can be compliant if these tools are qualified, including audit trailing, approvals, status control, filtering, reporting, and traceability. As depicted in Figure 2, Scrum uses the product backlog, which is usually stored in an Agile planning tool, thus providing the various digitalization benefits mentioned above. The PBIs should have high-level user acceptance criteria so that the Scrum team can understand their scope and use them as a basis for test cases.

In addition, the following aspects of acceptance criteria should be considered:

a) Same Attributes Agile & Waterfall

They should have the same attributes of a traditional Waterfall/linear set of requirements in respect to:

• Data
• Interfaces
• Environment
• Performance
• Availability
• Regulatory
• Maintenance
• Data migration
• Security requirements

b) INVEST

Techniques such as “INVEST” can be leveraged to check for good attributes of stories. It stands for I – Independent, N – Negotiable, V – Valuable, E – Estimable, S – Small, and T – Testable

c. Product Backlog

The product backlog needs to be kept up to date, reflecting and anticipating changes, which can be ensured via Backlog Refinement (the team reviews items in the backlog to ensure the backlog contains the appropriate items).

3. Use Product Backlog Items (PBIs) instead of User Requirement Specification (URS) to build the Minimum Viable Product (MVP)

The most important PBIs at a given point are grouped within the sprint backlog, providing a list of tasks planned for the upcoming sprint. During the sprint planning session the team discusses with the product owner each potential sprint story to understand any architectural, testing, or development tasks, issues or risks and establishes the sprint goal of having an approved and prioritized sprint backlog. This basically ensures that everyone’s expectations are set and understood.

A regulated company needs to identify all GxP-related requirements based on the intended use of the system and ensure that these are included within the MVP for the initial release of the system into production.

5 Tips for efficient requirement identification:

• Map GxP-related requirements against the Agile artifacts of the already developed software
• Use qualified tools that allow risk-based testing focusing specifically on these areas and ensuring traceability to testing/verification activities
• Break the system into its functions/features and assign a risk score to these features, which could be applied at the epic level
• Consider hierarchical relationships when applying critical thinking to avoid a potential cascade of higher-risk scores to lower-level/risk items
• Develop standard libraries of appropriate PBIs for non-functional requirements that can be reused for subsequent software development

That wraps up part 1 of the “Agile methodology in regulated environments series.” Part 2 will discuss the test and approval approaches adopted in Agile applications in GxP scenarios.

Stay on top of compliance issues and subscribe to be notified when part 2 of this series is published at GxP-cc.com. We’d love to hear from you; if you have any questions, contact us at info@GxP-CC.com.