Archive | Agile RSS for this section

Agile Waterfall Model – Agile for Validated Projects in Pharma ?

Validation of IT Systems in Pharmaceutical Industry:

I have been working with a Global Pharmaceutical customer for the past 5 years. One visible difference I have noticed in the way projects are executed, specifically projects that need regulatory compliance is the amount of documentation that the team has to generate in order to Validate the project. Validation in it’s simplest sense is “to be able to prove that the team has followed all the steps/processes that they are supposed to”. The IT system being developed should come clean during any audits by FDA to ensure the system is built as per CFR Part 11 – Electronic Records; Electronic Signatures. This typically adds, on an average, about 20% to 30% additional effort due to the documentation efforts required.

Agile Projects:

Agile Software Development is much more liberal in terms of documentation. In fact the Agile Manifesto values “Working Software over comprehensive documentation“.  While the manifesto acknowledges the value in documentation, they prefer to ‘Get it Done’ rather than documenting ‘How it will be done’.

David Vs Goliath:

Having looked at what is required by FDA and what is valued by Agile, it is evident that using Agile for projects that are ‘Validated’ will be a challenge. However, the world has come to realize and acknowledge the fact that delivering projects using ‘Agile’  is a very good way to ensure customer satisfaction by adjusting to changing needs and delivering better quality. However, there are few people who claim that Agile  is one way the IT folks want to get away with not documenting and is for programming frenzy organisations.

Enter “Agile Waterfall Model”:

This is a fancy name that I just cooked up, but I will try and explain what we have done and will let the experts give it a name or trash it.

Step 1:  We have captured all the requirements in the form of a Business Requirements (User Stories), the traditional way, through workshops and one-on-one meetings with business users

Step 2: Provide estimates in terms of Cost, Schedule and Effort, with 20% buffer based on these requirements.

Step 3: Divide the  functionality into buckets/groups (Themes)

Step 4:  Through Usability Design, refine the requirements for the first bucket which we called Iteration 1.

Step 4: Complete the SDLC (Design, Develop & Test) in the Waterfall model for Iteration 1 and release the application.

Step 5:  Repeat steps 4 and 5 for the rest of the buckets

While this can be looked at as a Program with multiple smaller projects, we did employ some Agile techniques like Daily Stand-up meetings, Test Driven Development, Weekly builds, User Reviews of Weekly Builds for early feedback etc. We were able to overcome some pitfalls and issues that we have noticed in our Iteration 1 in the subsequent Iterations. Whether this can be called as Agile or not, in a way, trying to emulate Agile in a traditional Waterfall project helped us a great deal. 

With that, I rest my case for naming me as the father of “Agile Waterfall Model”. Jokes apart, I would love to hear from you as to what you think about this model or if there is a better way to deal with “Validation”. I am also researching a bit and will try and blog on the information I come across along the way.



%d bloggers like this: