Skip to main content

The perfect "Agile Validation" approach for Software Implementation in Pharma Industry

Last post 02:36 pm July 17, 2020 by Mathias Fuchs
3 replies
02:52 pm May 5, 2020

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

 


06:53 pm May 5, 2020

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.


03:21 pm May 13, 2020

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.


09:44 am July 17, 2020

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 :-)

 

 

 

 

 

 

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.