Agile Software Development in Regulated Environment

For years now, pharmaceutical companies struggle with the adoption of various iterative software development methodologies for computer system applications that support regulated activities and must be validated. Industry best practices for computer system validation are structured around the standard “Waterfall” software development life cycle (SDLC) approach, in which there’s a clear linear progression, and the deliverables of each phase are completed before the team moves to the next phase of the SDLC. Iterative SDLC methodologies are based on multiple iterations of requirements definitions, software development, testing, and user experience with the system that lead to a refined software product that meets the users’ needs.

Some of the iterative methodologies consider the software product of interim iterations to be a prototype and not a production system. Once the users determine that the development team captured their requirements, the final stage of development, documentation, testing, and validation takes place and the system is released to production use. However, today’s Agile SDLC methodology promotes the idea that the software can always be refined and that the development continues throughout the life of the system. Therefore, production releases occur on a regular basis, often every two weeks. These cycles are called Sprints.

There are significant benefits to following the Agile SDLC methodology. It allows the development team to deliver a usable product to the users in a short period of time, even if early releases of the product don’t have all the functionality that will be eventually added to the software. While the idea of the development teams working closely with the users to create a software product that best fits the users’ needs appears attractive, there are real and perceived risks that make Agile acceptance difficult, especially in regulated environments. Not having a well-defined set of user requirements before development starts or a clear idea of what the production release of the system will be, evolving system documentation throughout the SDLC and frequent releases create the impression that Agile is an uncontrolled, unstable, and a poorly-documented SDLC. It appears that there’s no clear direction or plan, requirements change too frequently, and that the SDLC doesn’t fit the common “V- model” Waterfall approach with its expected sequence and dependencies. The short duration of each iteration raises a concern that there’s not enough time for thorough document reviews by QA and Management.

As I mentioned earlier, some of the concerns have more to do with perception resulting from fear of taking a new and different approach and bad experience with poorly controlled projects. Agile development can be tightly planned and controlled and produce systems that are fully tested and are well documented. Agile development enforces interaction between the developers, testers, and users and reduces the risk of requirements being misinterpreted by the developers and users getting a system that doesn’t meet their needs. Agile ensures continual alignment of user expectations with the solution that the development team is building. Yes, there’s a risk that the development team will use the Agile approach, where system specifications and project documentation are not completed until close to system release, as an excuse for running a poorly controlled and documented project, but the risk of poor quality exists for any type of SDLC. While current industry best practices for validation are based on the traditional Waterfall approach, FDA regulations and guidances do not require any specific approach to be followed. There are certain requirements that apply to any formal process (e.g., activities follow a management-approved plan, they produce evidence that demonstrates compliance with the plan, and are summarized in a final report), but these can be met when Agile SDLC is used.

In order to address the concern with frequent releases after very short development iterations (Agile Sprints), a hybrid SDLC approach can be adopted, where not every iteration produces a production release. Instead, interim system releases are used for user review and interaction with the development team. Then, only major releases are validated and released to production use. Another option is to have longer iterations and use of automated testing and documentation tools to enable very efficient regression testing and documentation updating, when more frequent releases to production are desired.

Agile methodology can be effective and produce quality and compliant system. It should be considered a valid one for regulated system. The reality is that more and more software development firms, including ones that develop and support regulated applications, already adopted Agile and are no longer following the traditional Waterfall SDLC methodology. Pharmaceutical and other life science companies should focus on planning how to work with Agile and make it compliant rather than reject it altogether. Even if the organization is not ready to adopt the Agile methodology, it should be prepared to address its benefits, risks, and mitigations when challenged internally or in regulatory inspections. Chances are that, in not too long, some regulated software used by the organization will be developed and maintained following Agile.