Agile Validation Vs Standard Validation

« Back to Previous Page
6
0

Which Validation approach we apply to validate an Agile application and how it is different than standard validation approach?

Please to read the entire article.

Marked as spam
Posted by Vishal Dogra (Discussions: 2, Comments: 2)
Replied on November 8, 2017 12:00 am
41 views
0
Private comment
Agile application you may be referring something under development. The same needs to be established for implementation in GxP environment. For both the approach one needs to follow the risk based approach based on GAMP5
Marked as spam
Posted by Amit Dekate (Discussions: 0, Comments: 11)
Replied on November 7, 2017 7:00 pm
0
Private comment
Yes the approach is the same, only the considered parameters/factors/attributes.
Marked as spam
Posted by G M Butcher (Discussions: 0, Comments: 55)
Replied on November 7, 2017 7:00 pm
0
Private comment
. . . are different.
Marked as spam
Posted by G M Butcher (Discussions: 0, Comments: 55)
Replied on November 7, 2017 7:00 pm
0
Private comment
Validation strategy for Agile will be different as what happens in normal validation cycle your URS, FRS, 21-CFR-Part-11, Annex 11, FRA should be sign off before starting the project but this practice can not be applied for agile methodology as requirements will be keep on coming once all sprints are finalized user stories developments are done you can route all documents for signature means before starting System Integration Testing
Marked as spam
Posted by Shailendra Agnihotri (Discussions: 1, Comments: 3)
Replied on November 9, 2017 7:00 pm
0
Private comment
Agile or waterfall or scrum are SDLC terminologies and used in development. Go for GAMP risk based approach for validation
Marked as spam
Posted by Suyog Kudtarkar (Discussions: 0, Comments: 4)
Replied on November 9, 2017 7:00 pm
0
Private comment
To take full advantage, Agile should integrate development, testing and validation. SDLC should define agile process, controls and deliverables taking into consideration key differences (e.g. User Story, in-sprint testing, Agile validation deliverables, automation tools).
Marked as spam
Posted by PJ Singh, PMP (Discussions: 1, Comments: 8)
Replied on November 9, 2017 7:00 pm
0
Private comment
Thanks you all for your answers, but what is the criteria for documents approval in agile? When we can get our documents approved in agile if there are different sprints? do we need document approval for each sprint (e.g. req. and design) or at the end all sprints?
Marked as spam
Posted by Vishal Dogra (Discussions: 2, Comments: 2)
Replied on November 9, 2017 7:00 pm
0
Private comment
From a validation perspective doesn't change much actually. Every time you release to production you will have to do a risk assessment and decide what to test and how.
What you might want to do, is to not release each sprint to production, but just to UAT and then do a production releases every N iterations. In this way you get feedback from users but a smaller documentation burden.
Marked as spam
Posted by Paolo Matrascia (Discussions: 0, Comments: 5)
Replied on November 9, 2017 7:00 pm
0
Private comment
Vishal define what you are going to do in your validation plan and follow it. Neither GAMP nor IEEE states only 1 absolute method to be the right approach. The requirement is that your product released should be qualified and followed a validated process.
Marked as spam
Posted by Ravi Moorthy (Discussions: 0, Comments: 4)
Replied on November 10, 2017 7:00 pm
0
Private comment
Vishal, you may want to use the hardening sprint to approve CSV documents that includes requirements Specs, IQ, OQ scripts. These documents may be drafted and revised after completion of each sprint (n+1).

I hope it helps a bit!
Marked as spam
Posted by PJ Singh, PMP (Discussions: 1, Comments: 8)
Replied on November 10, 2017 7:00 pm
0
Private comment
This is a tricky scenario as of now and I have seen lot of QMS not able to handle Agile development methodologies properly. Best way out is to make sure that risk based approach is followed throughout.
How to do this ?
Whenever a requirement/User story is updated the associated risk/impact should be reanalyzed and development/Testing should be done accordingly.

Validation and test plans should be written in such a way that it allow such updates in the CSV documents. (Approvals should be as late as possible).

Last but not the least, avoid authoring/pre-approval of OQ/PQ scripts, make a SOP which says this pre-approval will be done only after System freeze notification !
Marked as spam
Posted by Gitanshu Amola (Discussions: 0, Comments: 1)
Replied on November 12, 2017 7:00 pm
0
Private comment
Thanks all, I think if we are revising requirements, iqs, oqs after each sprint, then we also have to revise our design document as well. Because once we finalize requirements , design and scripts for a sprint only then we can start the testing for it.
Marked as spam
Posted by Vishal Dogra (Discussions: 2, Comments: 2)
Replied on November 12, 2017 7:00 pm
0
Private comment
Hi Vishal , keep the spirits to Req, risk assessment, testing and summary - repeat. Keep your design spec getting updated as it moves but sign it off before release. Remember Validation is all about keeping things under control, doing what you say and saying what you do.
There is no right or wrong method , it's about assessing risk and ensuring it is covered.
Marked as spam
Posted by Sachin Bhandari (Discussions: 1, Comments: 11)
Replied on November 13, 2017 7:00 pm
0
Private comment
Also build standards should be signed off before spirint 1 and build review before final release.
Marked as spam
Posted by Sachin Bhandari (Discussions: 1, Comments: 11)
Replied on November 13, 2017 7:00 pm
0
Private comment
The way we handle this... we have added what we call a validation sprint at the end of sprints where we have what we would like to release to clients. At that point, we re-execute all of our testing in a very controlled manner to characterize the software prior to release... the results of this testing go into our validation package (which includes all sprints, results, training, etc.).
Marked as spam
Posted by Laura Araujo (Discussions: 0, Comments: 1)
Replied on November 13, 2017 7:00 pm
0
Private comment
Vishal, you are right, there are lots of challenges related to revising requirement Specs, IQs, OQs, and PQs.

In my experience the key is user stories, it should be single source of truth and locked after acceptance. User story should be the bases of developing URS (if required), FRS, Design Specs, etc.
Marked as spam
Posted by PJ Singh, PMP (Discussions: 1, Comments: 8)
Replied on November 13, 2017 7:00 pm
0
Private comment
Maybe this quote by GAMP 5 can answer your question “at the end of the development phase, document review and approval should act as the formal verification that the document content is complete, accurate, and fit for intended use.”
In my thoughts, the criteria for document approval in agile depends on project variables. E.g. a modular SAP ERP System with own SLC documentation for each sub process: Why should you wait until the end of the project, if the documentation is completed at the end of the sprint, and further development will not have an impact on this process?
Contrariwise, a project with SLC for the whole application should be kept agile as long as possible.
The agile method / project setup has to be a case-by-case decision – the internal regulation should focus on the compliance, not on the project management.
Marked as spam
Posted by Philipp Roth-Kleyer (Discussions: 0, Comments: 1)
Replied on November 13, 2017 7:00 pm
0
Private comment
Sachin, I think if you are saying that we need to keep design spec updated then it should be approved as respective to each sprint. Alternatively, you have to write in validation plan that you will approve it at the end. But in this case, a scenario of lack of evidence can be introduced.
As per PJ Singh, I think he is right as user story is the single source of truth but it should be locked for each sprint. In mission control, they allow easy approval of user stories for each sprint.
In addition, the example given by Philip make sense.
Marked as spam
Posted by Vishal Dogra (Discussions: 2, Comments: 2)
Replied on November 13, 2017 7:00 pm
0
Private comment
Reaching out you again ,all, as per the above comments mentioned in this discussion, most of the people are in favor of updating the requirements till end, but then it fails the Agile methodology which says the we have to deploy code in production after each sprint and in other aspect if we are not freezing the requirements then we cannot deploy code in production, any suggestions?
Marked as spam
Posted by Vishal Dogra (Discussions: 2, Comments: 2)
Replied on November 26, 2017 7:00 pm
« Back to Previous Page