The perfect "Agile Validation" approach for Software Implementation in Pharma Industry
Dear Agile Experts,
I am currently a member of a compliant group at the Pharma Company. The Company is about to implement a new software, which is developed to match the user requirements. The wish of the project managers is to integrate an “agile validation”, which is in my opinion does not fully reflect the agile philosophy. But if we could imitate the agility in this situation, what would be the “best” way to do it? I understand that the idea of splitting the sprints into development and validation is not the best but possible. Do you maybe have any brilliant idea to maximally avoid the waterfall management here and bring it closer to the agile style, also for compliance?
Thank you in advance,
Anna
I'd recommend Agile Methods for Safety-Critical Systems: A Primer Using Medical Device Examples as a starting point. I don't necessarily agree with everything that the authors suggest, but very little (if anything) they talk about is what I would consider wrong.
A few suggestions that I have is to separate validation from the development. During the development process, keep your documentation up-to-date. That's probably your requirements, architectural and design documents, code, test scripts, manual test cases, and so on. Also the necessary (bidirectional) traceability. If you're using Scrum, this would all be captured in your organization's or team's Definition of Done.
The Product Owner would make the decision on when to begin the formal validation cycle. If you have enough quality built into the product development process, then the validation cycle should be a formality rather than a test cycle that finds defects for correction. The information that is updated during the Sprints leading up to validation provide all the information necessary to perform appropriate validation.
Keep in mind - you aren't imitating agility. You are embracing it. Validation is often one of the more costly steps. By being able to obtain rapid feedback from stakeholders before entering the validation activity, you can have higher confidence that what you are putting through the activity will not only pass, but be useful to the end user.
The wish of the project managers is to integrate an “agile validation”, which is in my opinion does not fully reflect the agile philosophy. But if we could imitate the agility in this situation, what would be the “best” way to do it?
Start with an understanding of what "Done" means -- including validation -- along with the cost of failing to achieve it in a timely manner. If you do that, you will stand a chance of not having to imitate success at all.
I agree to the above in general. For me, there are some very basic prerequisites for successful agile validation:
1. I think you cannot imitate agility. Either you work agile or not. It's mainly a mindset issue. But agreed, in validated environments it's one level up!
2. Define and clearly communicate validation as part of the product. It's not an add on after technical development. Any validated product development needs not only close collaboration between business and IT but also QA has to be included.
3. Dev Team should be interdisciplinary, also including validation skills. Sometimes tricky if technical resources in Dev team are from an external supplier. Dev Team does not mean Software Development Team it means Product Development Team.
4. There is no "One-size-fits-all" approach. Find your optimal individual process based on established frameworks. e.g. Validation tasks could be performed for items from current Sprint -1. -> Project will be in good shape for final formal validation as most artefacts are well prepared.
5. Align with QA that formal validation and signatures do not need to be performed early (e.g. start FS after formal approval of URS) signatures need to be ready before Go Live! That's compliant with general GAMP5 recommendations. V-Model is not mandatory.
6. include proper risc management (e.g. FRA) as early as possible and create tests based on risc assessments.
7. Include experienced resources to avoid most common pitfalls
8. Ideally have a good tool chain that supports automated Continuous Integration, Deployment and Testautomation
Hope that helps and others agree :-)