Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. A time-boxed iterative approach, Agile software development methodology promotes adaptive planning, and encourages rapid and flexible response to change. It also provides a vehicle for evolutionary development and delivery of the product. Agile methodology is a conceptual framework that promotes foreseen tight interactions between functional groups throughout the development cycle.
The Agile approach to software development, configuration and project planning has recently become very popular for implementing and developing complex systems, and for good reasons:
- Builds confidence in the product
- Something in the hands of the users sooner, rather than later
- Constant contact with stakeholders allows for speedy design changes and requirement refinement
To determine and analyze some of the obstacles and issues that are likely to be encountered doing a LIMS implementation using Agile methods.
The scope of this article is limited to the Scrum Agile method used in LIMS implementation of a CLIA (or otherwise regulated) laboratory. Not intended for GMP or IVD software solutions, but some information can be leveraged for these.
The below are a list of issues to be considered and mitigated when using an agile method on a LIMS implementation.
Data Management and Continuity
Clinical laboratories collect an array of different data sets to conduct their business. Data sets include client and patient demographics, laboratory workflow data, inventory management transactions, QC data, intermediate and final patient results, and billing information. Data from the different data sets are often sourced from separate systems and interfaces, and must be integrated to ensure positive patient identification and result traceability.
Using an Agile method means that not all of these data sets will be implemented at the same time. There needs to be stakeholder buy-in for the planned data flow gaps in early releases. It may require some other methods for transferring data from the current system to the new one.
A traditional waterfall project management approach can require a data migration task as a part of the cutover activities, the scope of which had been previously determined and approved. After the migration, all of the data (agreed upon in the plan) will reside in the new system.
How do you address data continuity in an Agile method?
Regulatory requirements affecting user stories and priorities
There are regulatory requirements and quality system guidelines that the laboratory follows in conducting their business. Certain requirements and guidelines are specific to electronic/computer-based systems. These items must be identified as such in the user stories to ensure that the system requirements derived for regulatory compliance are appropriately represented and complete in early sprints.
One of the most effective features described in agile methods has to do with the rhythmic, continuous involvement with the business stakeholders. With increasing costs and shirking reimbursement rates, clinical laboratories are running increasingly leaner when it comes to staffing. Finding availability for the subject matter experts operating in production can be daunting.
Timing of sprint cycles and meetings should be approved by the business prior to finalization of the Project Plan. If possible, the business should provide proof that they have adequate resources to accommodate the proposed schedule.
Although CLIA does not require a validation of computer systems in the way that the FDA does, CAP and other voluntary accrediting agencies require documentation of system testing before initial implementation and during change events. Therefore, many laboratories may choose to validate its CLIA-regulated systems.
A waterfall project management approach can require validation and/or user acceptance testing of the computer-based system, either in whole or in part, prior to release to production. Upon approval of a given sprint implementation, a validation plan must be created, approved and executed prior to release to production. The project timings should account for validation efforts.
One suggested approach to validation a system developed using an Agile method is to write an “Agile” validation plan at the beginning of the project that calls for risk assessment at the planning phase of each sprint cycle. The results of the risk assessment will be used to determine which testing activities (unit testing, integration testing and regression testing) to perform for the upcoming sprint. As a part of the project plan, the validation plan can also describe specific milestones of “doneness” to perform full or partial system validations.
When planning the project, it may be useful to discuss the level of effort in validating the proposed requirements in a sprint to determine the proper scope of the sprint.
Traditionally-approached LIMS implementation projects are prone to pitfalls that can lead to projects being delayed, over budget and ultimately failed. Agile methodology attempts to diminish the likelihood of falling into these hazards by maintaining close engagement of users and project members and using iterative, adaptive project planning. However, Agile methods can introduce new challenges when implementing a system in a regulated, resource-lean environment such as a clinical laboratory.
The challenges described in this article may deter many project managers from attempting to use such an approach, especially the first time. As in life, identifying the challenges, planning for them, and facing them head on can lead to great success.
NO EVENT SHALL LAB INSIGHTS, LLC BE LIABLE, WHETHER IN CONTRACT, TORT, WARRANT, OR UNDER ANY STATUTE OR ON ANY OTHER BASIS FOR SPECIAL, INCIDENTAL, INDIRECT, PUNITIVE, MULTIPLE OR CONSEQUENTIAL DAMAGES IN CONNECTION OR ARISING FROM LAB INSIGHTS, LLC SERVICES OR USE OF THIS DOCUMENT.