Agile Development in Laboratory Informatics
Agile development is one of those buzzwords that you’ve heard a lot if you’ve spent any time at all in the business world. Like Lean Six Sigma, it’s one of those secret handshake-type terms that will have everyone nodding in recognition, even if they’re not really sure what it’s about. But in laboratory informatics—particularly in the regulated industries of pharmaceuticals, food and beverage, or personal care—waterfall methodology is still the first choice for project management. This blog post will look at some reasons why Agile development hasn’t been widely adopted in laboratory informatics yet, and what potential there is for its use in the future.
Waterfall Versus Agile: Does It Have to Be Either or?
Waterfall methodology has been used in software development for as long as software development has been a thing. It arose from the field of engineering and has an undeserved reputation for being rigid. Waterfall is so named because of the way it follows sequential steps that cascade from one to the next, unidirectionally. Used in the way it was originally intended, however, there is scope for iterative processes.
Agile development, on the other hand, was designed to be recursive and iterative. It has the reputation of being inherently flexible. Agile proponents position it this way against waterfall methodology by making this explicit. Agile methodology works in a series of sprints that loop back around to the linear project map. Agile gurus have their own strong opinions, however, and don’t always mention that there are ways to modify Agile methodology to suit your particular business environment. You do need to have proper training, and engaging a scrum coach is a good idea.
Waterfall is the most common LIMS implementation method in regulated businesses, however Agile offers advantages that could complement the working style in regulated businesses as well. But these are not the only ways to do a LIMS Implementation. CSols has experience with a variety of implementation methodologies. For the purposes of this blog post, let’s look further at Agile methodology in regulated industries.
Agile for Computer System Validation in Regulated Industries
The regulated industries have good reason to be conservative in their approach to laboratory informatics. No one wants to be the recipient of Form 483 or, worse yet, a warning letter from the FDA. Recently, however, approaches to computer system validation (CSV) have begun to change. In December 2018, the FDA provided updated guidance, Data Integrity and Compliance With Drug CGMP: Questions and Answers Guidance for Industry. This document answers specific data integrity questions and builds on the 2002 General Principles of Software Validation; Final Guidance for Industry and FDA Staff. The data integrity guidance states that any certified good manufacturing process (CGMP) workflow needs to be validated. The level of validation is risk-based, meaning that the higher the risk there is in a workflow to the product, and ultimately the consumers, the more stringent the validation and documentation process should be.
This has steered many businesses in the regulated industries away from Agile development for laboratory informatics projects, because of the way documentation is traditionally done in Agile methodology: more iterative and layered. In any system, however, when you mix approaches you can capitalize on their different strengths. Introducing the iterative, recursive Agile approach in the traditionally risk-averse regulated industries could draw out strengths that the waterfall system may not tap into. But so far, not too many companies have been willing to give it a try.
[sc name=”arrow”] Related Reading: Agile LIMS Implementation – A Challenge
Agile Methodology Can Work in Regulated Industries
Under a traditional Agile methodology, documentation for a sprint is created as the work proceeds. If urgent work comes up during the sprint that can’t be managed without stopping the sprint, new documentation would have to be created, which may raise flags during an FDA audit. At CSols, we have worked with clients in regulated businesses, particularly in pharma, who are using some Agile development techniques in their informatics projects.
One of our pharma clients had a scrum coach come in to provide training so they could use a modified Agile methodology to deal with a backlog of LIMS issues. The client began by providing documentation that would satisfy the FDA requirements upfront but left some free capacity so that when urgent work came up, it wouldn’t push the sprint off schedule. Our client listed all of the work that could potentially be done (in their case, it was a backlog of hundreds of LIMS-related tasks). They prioritized those to determine where they could get the biggest bang for the buck. The prioritized list was then broken up into manageable chunks, as stories with a system of story points. For example, one story might have been: As a lab analyst, I want to be able to click on the LIMS main menu and print a sample code with a 15-digit bar code. This story would be assigned a certain point value depending on the amount of time and effort required. These stories were created for each item in the backlog. Developers then looked at the prioritized, weighted list and decided how much time each item might take. Every developer would choose the amount of time they had in their schedules and some combination of the backlog items that could be done in that time.
The sprint would begin when the work was chosen, and the CSV documents were then updated to include that work. Everything in that sprint gets done, regardless of what else comes in. Leaving some capacity in the schedule for urgent work allowed them to follow this modified Agile methodology. Ultimately, the client was able to clean out hundreds of items from their LIMS backlog, quickly. As an added benefit, they were able to successfully defend this approach during an FDA audit.
It is more common to find Agile methodology used in laboratory informatics systems outside the FDA purview, but we have seen that it is possible to make Agile methodology work in regulated businesses, with some modifications. The FDA has accepted the use of Agile software development since 2013, specifically for medical device software. As more success stories permeate the regulated industries, however, Agile methodology will gain wider acceptance.
Would you like some guidance around how you could make Agile work in your environment? Reach out to CSols to learn more about our experiences with modified Agile methodology in regulated businesses.
Tell us what’s stopping you from adopting the Agile methodology for your next informatics project in the comments below.
This is a very informative article. The challenge I have seen is that how much ‘testing/verification’ to apply, if using risk-based verification, when static data changes are made to a validated LIMS system. For example, changing or adding new spec limits to meet new markets requirements vs. adding new system suitability criteria/components to an existing analysis, etc. How to best assigning wt and batching these requests into sprints? Typically, these are the static data changes to support post deployment Business As Usual requests, so there is a balance between efficiency and urgency that is not always possible to predict or plan, hence, making it difficult to apply Agile methodology, unless we do mini Sprints, which would then be not much different from the Waterfall method.
This is a very informative article. The challenge I have seen is that how much ‘testing/verification’ to apply, if using risk-based verification, when static data changes are made to a validated LIMS system. For example, changing or adding new spec limits to meet new markets requirements vs. adding new system suitability criteria/components to an existing analysis, etc. How to best assigning wt and batching these requests into sprints? Typically, these are the static data changes to support post deployment Business As Usual requests, so there is a balance between efficiency and urgency that is not always possible to predict or plan, hence, making it difficult to apply Agile methodology, unless we do mini Sprints, which would then be not much different from the Waterfall method.