Agile validation in the context of an existing CSV V-Model framework (Part I)

Computer System Validation (CSV) in GxP-regulated industries like pharmaceutical and medical device manufacturing is the testing and documenting to see if the software is fit for its intended use, is compliant to external regulations and internal procedures, thus providing a high degree of assurance that risks to patients, product quality and data integrity are minimized. This first part of the blog describes how to plan and what to do prior commencement of the project to fit in the agile validation approach with an existing CSV V-model process.

In software development projects, the agile approach became the standard and the challenge is to fit the validation activities that may be based on the V-model to the agile development approach. For organizations that are new in the field of software development, for example a start-up developing a medical device software, it is easier to align the agile development process with an agile validation approach. On the other hand, there are organizations with an established and mature V-model CSV framework (with all its processes, supporting instructions or templates) that will experience a time-consuming process to adapt to agile validation.

Good news is, that there are certain prerequisites to start – and simplify – such a process change:

1. Alignment with the quality department: The starting point should always be contacting your quality department which is ultimately accountable for any validation documentation. The quality responsibles may have varying degrees of experience with agile methodology and may therefore only provide limit guidance on how to set up a thorough agile CSV approach. At the best, they have already produced an agile validation framework. In the worst case only a V-model SOP is available, and discussion is needed on how to fit in some parts of the agile development process and artifacts.

2. Unifying CSV deliverables with agile artifacts: It should be borne in mind that an existing and well-working CSV V-model framework cannot fully be adapted to the agile methodology and that the result will always be a hybrid agile CSV approach. However, at first there should be an agreement on how to deal with the documentation: The validation master plan can be used to describe the agile approach and how it will differ from the existing CSV framework and where the agile artifacts being produced will fit in the CSV documentation. The user requirements (or user stories) and functional specification (acceptance criteria) should be left in draft status as long as possible as the agile development makes it likely that requirements and specifications undergo a change during the sprint phase. It is emphasized that agile validation does not mean less documentation than traditional CSV.

3. Alignment with supporting functions and processes: Also, consider that other quality management and supporting processes such as change management, security, infrastructure, data privacy may not be aligned to the agile development approach, as it is the nature of agile development projects that requirements are evolving over time. Here, it is recommended to discuss and find a common understanding for the agile validation topic with the respective stakeholders early on and especially on a regular basis, based on the outcomes of the backlog refinement.

4. Planning of the supporting tool chain: Consider how the tool chain of your software development should look like. An agile development is only successful with the appropriate usage of tools. Prior to the project start, a working IT tool chain should be set up. This includes the usual issue tracking and agile project management tools, wikis and code repositories. In this case it is necessary to have experienced users who can configure these tools to the needs of the project team. Parts of the tool chain may require prior validation itself as prerequisite for being used within the CSV project for example as electronic requirement or test documentation repository. This tool validation is actually a project on its own and should not be underestimated. You may even want to use test automation to some extent to ease the manual test burden. Here, the framework and tools for the test automation would need to be established prior to the project as well. It is recommended to get an experienced test automation expert on board to compose the test scripts.

5. Defining the product road map: Defining the product scope on a high-level as well as the most relevant/critical business requirements should be done and clear by project start. Although it is the nature of agile development that some changes and the addition of new user stories occur, adding a new epic that significantly enhances the scope and/or complexity may have a huge impact on the validation activities and other supporting processes (see point 3 above) during the project.

6. Project organization and team set up: Consider whether the organization and the project team have the capacity to absorb such a project, as agile does not mean less but much more thorough project planning and structure. Also, a good involvement of business operations is essential, because only the input by business will make a good product. However, this means that resources from business need to be allocated to the project so that sprint demos and workshops can be attended. This alone will assure the necessary user acceptance of the product and the subsequent operational use.

7. Agile Validation Manager: For the agile validation activities, it is recommended to onboard an experienced validation manager to lead and oversee the documentation and testing activities. The development team may have varying experience in a regulated environment and the validation manager also serves as the single point for any validation-related questions.

8. Defining quality gates in the project plan: It is recommended to define quality gates to ensure that the CSV documentation is complete at a certain stage and the project can proceed. For example, a quality gate could be defined as certain CSV deliverables are approved.

9. Forming-Storming-Norming-Performing: In addition, at the start of an agile software development, there are other challenges which add complexity. The team members need to get to know each other first and they need to get used to the agile team collaboration and processes also involving the CSV part. All this may cause frictions in the first project phase, however normal this is. The development team has little experience with the number of story points that can be achieved during the sprints, so the first sprints will usually be accompanied by an adjustment of the initially overestimated achievable story points during an individual sprint.

Summary

As mentioned, fitting an agile development project within an existing V-model CSV framework is not an easy task, but can be realized by addressing some important topics prior to the start of the project:

Define the product roadmap with the most relevant requirements to estimate the system risk and the business impact of the product. The discussion with relevant stakeholder needs to take place. Especially with the quality department to be clear on how to fit the agile approach in the existing CSV framework. Don’t forget to include other relevant stakeholders of supporting processes and business and get allocated resources from them for the project. It is recommended to introduce quality gates and have a dedicated validation manager role during the project. Think thoroughly about setting up an appropriate tool chain, possibly test automation and have dedicated resources to configure the tools and writing the test scripts.

In this first part of the blog it was shown how an agile development project within a V-model CSV framework can be achieved with a good project planning. In the second part of the blog the operational validation activities during the sprints are described.

Part two

There is a second part of this blog series written by my collegue Katharina Gimbel.

Read now