In a previous blog we had explored the various methodologies (Waterfall, Prototypical, Time Bound, and Hybrid) that are used to implement a LIMS. Within the Prototypical Methodologies category, we included Agile, a very popular development philosophy where the requirements and the software solution are generated by collaborating cross-functional teams. This is a time boxed methodology (typically 3-4 weeks) that uses an iterative approach to rapidly develop, test, and deliver functionality. While Agile has had wide utilization in the IT field, there are several concerns and issues that can make it problematic for the implementation of LIMS, especially in a regulated environment.
In order to successfully utilize a pure Agile philosophy when implementing a LIMS, it is imperative that a cross functional team be established and that these resources are available for each sprint and scrum. This means that your IT experts, LIMS experts, Regulatory experts (if applicable), and Lab experts (i.e. scientists, lab managers) will all need to be dedicated to that portion (I.e. sprint) of the LIMS implementation project. Also, since LIMS feeds and is fed by numerous other information systems across an organization, access and dedicated time from other stakeholder subject matter experts will be needed. At the core of Agile is speed, rapid prototyping, quick iterations, and release. While the LIMS project sprint is going on, the ability of the team members to perform their “day jobs” will be greatly diminished. In most organizations where resources are at a premium and the credo is “do more with less”, this is problematic.
Some organizations have attempted to overcome this challenge by utilizing 3rd party consultants to fill some of the subject matter expert roles. While this is feasible for some roles such as IT, Regulatory, and LIMS, at the end of the day you will still need dedicated time from key lab and business personnel. Another approach is to backfill the lab personnel for the duration of the project. Regardless, this is still an issue when pursuing an Agile LIMS implementation.
One of the powers of the Agile Methodology is its ability to break down system functionality into manageable bites and then quickly prototype that aspect. When implementing a complex system like LIMS this can be a challenge. The sources of data and information that drive a LIMS can come from multiple systems such as lab automation and robotics platforms, lab instruments, EHS Systems, ICMS, Biorepositories, ERP, MES, and a variety of business systems. Likewise, the data and information generated and managed in the LIMS will need to flow, in the proper format, to a variety of data analysis and visualization systems as well as back to the aforementioned systems. If a particular LIMS project sprint has not taken all the information flow dynamics into consideration, there will likely be gaps and issues with the solution.
Of course, one of the strengths of Agile is its ability to then adapt and make those changes in the next sprint, but this can adversely affect your LIMS Project timeline and/or reduce the overall functionality delivered.
If you are operating in a regulated environment such as a pharmaceutical lab, then you will be required to validate your LIMS before going into production. By definition, the testing of the solution that is being developed in the Agile philosophy will test each sprint’s software prior to release. However, testing a system is not validating a system, and accomplishing full computer systems validation as per FDA requirements can be difficult when utilizing Agile. Generally, the short duration of the sprint into production does not allow enough time for quality documentation production, review, and approval.
It is feasible that one can create an Agile validation plan at the outset of the LIMS implementation project that details that a risk assessment will be performed at the planning phase of each sprint. This risk assessment would then be leveraged to determine to what testing (i.e. unit, integration, regression) will need to be carried out in that particular sprint. Of course, if during subsequent sprints, earlier solutions have been altered, then additional testing might be required.
All is not doom and gloom with regards to Agile for LIMS implementation. Utilizing a Hybrid LIMS implementation approach which takes some of the best aspects of Agile like rapid prototyping and iterative processes and leveraging them with input from the users as part of the SDLC and removing some of the releases can be very effective. Then, only major releases are validated and released to production use. Another option is to have longer iterations and use of automated testing and documentation tools to enable very efficient regression testing and documentation updating, when more frequent releases to production are desired. However, utilizing a pure Agile philosophy for your LIMS implementation can be challenging.
Have you followed the Agile philosophy for your LIMS implementation? If so, what challenges did you face and how did you overcome them? Alternatively, did you use a Hybrid LIMS implementation methodology that used some Agile concepts? If so, which ones?
I understand the issues that arise when using Agile in a regulated environment and with regards to SME availability.
However I believe that in the end the total amount of SME occupation and the quality of the system will be at a higher level opposed to the waterfall methods.
That immediately shows the real issue: management only sees the short term inconveniences instead of the long term benefits. It is the job of the business analysts and project managers to convince the management of the opportunities.
Consultant Lab Automation