In February 2001, seventeen software developers gathered at the Snowbird ski resort in the Wasatch mountains of Utah to discuss an alternative to documentation-driven, heavyweight software development processes (i.e., Waterfall methodology). These developers were motivated by the understanding that traditional, heavyweight methods were not working well in a world dominated by rapid change, often leading to situations where the developed software was outdated by the time it was delivered.
Out of this meeting came the Manifesto for Agile Software Development, a lightweight development methodology with four key values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Over the last two decades, the Agile approach has become one of the most popular development methodologies among software developers and project managers because of its flexible and adaptable nature. Agile methodologies are designed for a fast-paced world where rapid change is the norm, making them the go to approach for achieving successful, high business value implementations.
Despite Agile’s popularity, heavily regulated industries such as healthcare and pharma have been slow to adopt Agile methodologies. The reason for this can be traced back to the four key values of the Agile approach listed above. The values on the left in each bullet point are esteemed over the values on the right by Agile advocates, yet the case is precisely the opposite for regulators enforcing GxP guidelines. The second bullet point is particularly problematic for regulated environments in pharma, as the FDA’s regulation 21 CFR Part 11 in 1997 and the related guidance of 2003 outline extensive documentation requirements for computer system validation (CSV).
Based on this initial assessment, one might conclude that Agile methods and regulated environments are fundamentally incompatible. Agile does value working software over documentation; however, it can be adapted to provide the necessary documentation. The Agile Manifesto simply describes preferences, not absolutes. In fact, one of the defining features of Agile methodology is its adaptability.
In addition, the FDA is planning to release a new guidance document later this year (2021) entitled Computer Software Assurance for Manufacturing and Quality System Software that creates opportunities for streamlining documentation for software implementations. This guidance will shift regulatory focus away from excessive CSV documentation and instead stress critical thinking in the validation process to encourage innovation and eliminate unnecessary costs, an approach which clearly aligns with Agile methodologies.
In this blog, we will discuss how Agile methodology addresses Waterfall’s shortcomings in IT projects, and how it can be best adapted to meet the requirements of regulated environments.
Agile vs. Waterfall Development Methodologies
The Waterfall method – the traditional approach to software development – got its start in the manufacturing and construction industries, both of which produce physical products that are difficult and costly, if not impossible, to change late in the development cycle. In this approach, each activity, from requirements development to system testing, follows a sequential blueprint laid out in the initial project plan, with each step of the process needing to be completed before the next activity can begin.
The Waterfall methodology can work well when requirements are clearly understood and defined, and there are no late-stage changes to the system that are necessary. This traditional development approach has, in fact, a long history of facilitating successful delivery of software systems. One of the biggest challenges with this model, however, is that the intended user of the system only gets to deliver feedback right before system go-live during User Acceptance Testing. As a result, Waterfall methodology can lead to costly system rework because of the discovery of misaligned expectations, system bugs, missed or misconstrued requirements, or changing user needs late in the development cycle.
In today’s fast-paced, ever-changing world, there are very few cases where requirements don’t change throughout the course of software design, development, and testing. In contrast to the Waterfall approach, Agile development methodology does not lock down all requirements up front. Instead, it assumes that the requirements will change as the development process proceeds and empowers the development team to identify and implement changes as the system evolves through short (typically 1-3 weeks), iterative release cycles known as “sprints”. Each sprint is focused on delivering a small amount of functionality defined by user stories, which are prioritized and brought into production via collaborative design, development, and testing activities.
Instead of waiting until just before go-live to get user feedback, the Agile approach puts the user at the center of the software development process by facilitating frequent communication, collaboration, and alignment of goals between users, developers, managers, and testers during each sprint. This allows real-time user feedback to be incorporated into development activities, ensuring the end product evolves in a way that brings maximum value to users.
Agile development emphasizes adaptive planning, along with evolutionary development and delivery. From a high-level, the Agile approach could be described in the following way: some development activity is performed, the results are inspected, and the process is adapted to resolve any problems that have arisen. Because of its ability to enable a rapid and flexible response to change, the Agile software development methodology has become the framework of choice for businesses where continuous change is the norm.
Implementing Agile Methodology in a GxP Environment
GxP regulations and quality guidelines were established by the FDA to ensure the safety and efficacy of products produced by the life science industry by maintaining quality standards of processes throughout the drug development lifecycle. GxP focuses on three main areas:
- Traceability – Ensuring that the development history of a drug or medical device can be reconstructed
- Accountability – Ensuring that the contribution (what they did and when) of everyone who contributed to product development can be identified
- Data Integrity – Ensuring that data records used in the development and production of the product are accurate, complete and maintained within their original context.
Organizations in the life science industry are subjected to frequent audits and stringent scrutiny to ensure adherence to GxP regulations, with noncompliance resulting in serious financial consequences due to one of more of the following: facility shutdown, product recalls, delayed or denied drug approvals, substantial remediation costs, import and/or distribution bans, and loss of customers due to a damaged reputation.
Life science organizations have been slow to adopt Agile methodologies because of lingering perceptions that agile principles are fundamentally at odds with the well-defined and repeatable processes that regulated environments require. Yet the FDA itself has embraced Agile development as an acceptable software development lifecycle (SDLC) and lists Agile as a Recognized Consensus Standard on their website. With careful attention, Agile methodology can be adapted to meet the requirements of regulated environments. A few best practice recommendations to bring Agile into alignment with GxP requirements include:
Implement an appropriate toolset. Using validated computerized systems and tools is vital for smooth execution of Agile methodology in a regulated environment. Atlassian, for example, specializes in an integrated collection of Agile tools that help manage the following: user stories, code and release management, issue and bug tracking, change tickets with e-approvals, test cases and test runs/execution, planning and project management, and document compliance (including electronic signatures, audit trails, version control). Once an Agile toolset is implemented, it is important to make sure that all subject matter experts (SMEs) are properly trained on how to use these systems.
Apply effective organizational change management. There are two scenarios for organizations who are considering utilizing Agile methodology to implement a new system in a regulated environment.
- Your organization is experienced with software implementations in a regulated environment but is new to Agile methodology
- Your organization is experienced with Agile methodology but is new to the regulated space
In either situation, a culture change will be required. As such, an effective organizational change management (OCM) initiative will be necessary to make sure key stakeholders within your organization are fully on board with and understand the Agile approach and how it will be adapted to meet regulatory requirements. If your organization is new to agile methodology, for example, you’ll want to implement OCM to ensure the full support and engagement of senior management, business analysts, developers, product owners, the quality team, etc. in Agile processes. Organizations moving into the regulated space for the first time will want these stakeholders to clearly understand the regulatory and compliance guidelines that apply to your products and the ramifications of any lapses, along with how Agile methodology will be adapted to meet these requirements.
Note that both of the scenarios represented in the above bullets are a significant shift, and a gradual transition (baby steps) is much better than trying to make a seismic shift all at once. Finally, don’t forget about the change management activities which will be necessary for the users of the new system.
Create cross-functional teams that include quality assurance (QA). An important key to optimizing Agile methodology is ensuring rapid feedback from outside the development team. You can do this by creating a cross-functional team (e.g., developers, project managers, business analysts, quality assurance, etc.) that contains all the skills necessary to move the user stories associated with each sprint to completion in a compliant manner. All sprints should be audited by QA to ensure compliance and approve release. In addition, testing teams should be full participants in requirements development, design reviews, creating acceptance criteria for user stories, and implementing test cases. By testing user stories as soon as they are implemented, testing teams discover defects early in the process when they are easiest to fix. The defects should be identified in a non-conformance report and then fed back to the product backlog list for resolution in a subsequent sprint. QA should also attend sprint reviews and retrospectives.
Categorize User Stories. When Agile methodology is used in regulated environments, user stories should be categorized and prioritized based on their regulatory impact. In this way, compliance risk is reduced as the risk process is incorporated early in every sprint. Validation and documentation requirements for a user story will be determined by its categorization. All user stories and/or sprints categorized as having a GxP impact will require significant involvement from the QA unit.
Document the process. Comprehensive documentation is essential in a regulated domain. In an Agile project, documentation should be updated on a per iteration basis. Once the project is complete and QA has released the system to production, regulators will want to see records (paper, electronic, or some hybrid of the two) and associated audit trails that clearly demonstrate:
- what was supposed to be built
- what was actually built
- what testing was done
- what version of the system the validation report was issued against
In addition, the following records are subject to retention rules when managed in an electronic process:
- system description/architecture
- all versions of user stories
- all versions of code releases
- all versions of test cases
- test execution and associated evidence (in last versions)
- test execution reviews and traceability to user stories (in last versions)
- change controls associated with each sprint
- audit trails/logs associated with the above records.
Do not equate a user story with a requirement specification. When operating in a regulated environment, it is important to avoid equating a user story with a requirement specification. A requirement specification (i.e., user requirement) expresses a regulatory requirement that the system needs to meet, while user stories describe small changes that are introduced as the product evolves throughout the development lifecycle.
While a story can also be a requirement specification, this is usually not the case, especially as the system matures over the SDLC. User stories tend to be short (1-2 sentences) and describe an incremental change that is required. They are written from the user’s perspective, and capture who the user is, what feature they want, and why. Requirement specifications, on the other hand, tend to be more detailed (sometimes very technical) and are intended to guide the development team on how to build a new feature or functionality.
Requirement specifications should be updated on an ongoing basis as the product evolves. As you need to have all the design specifications in place for the release in a regulated environment, it is wise to not leave the update of these specifications until just before release (i.e., sprint completion) but instead consider it an integral part of the story work. Best practice is to consider a user story complete only when specifications have been updated to reflect how the story impacted the software.
Conclusion
Given the rapid change driving today’s digital economy, customer preferences and needs often shift after the initial “blueprint” for a software development is created. When using traditional development methods, this can be problematic, as the cost of making changes increases exponentially the later they are detected in the SDLC.
Agile development methodology offers a positive solution to this problem, as it is designed to provide abundant feedback early and often during product design and use this feedback to continuously improve the product. As a result, the Agile approach works well for developing complex software with emergent requirements.
When properly adapted to the FDA’s quality system regulations and supported with appropriate tools, Agile methods can deliver significant business benefits. The fast feedback cycles, combined with Agile practices, can allow organizations in regulated environments to:
- Speed development
- Align more closely with user needs
- Improve user adoption
- Adapt to change
- Reduce risks, costs and defects
- Maintain regulatory compliance
Companies in regulated environments adopting Agile methods for software implementations are well positioned to better adapt to a changing regulatory, economic, and technology environment, and ultimately improve competitiveness and market success.
