Rapid advances in the life sciences field coupled with the increasing complexity of data management necessitate efficient, adaptive, and iterative development methodologies. Implementing a life science informatics system is challenging, requiring flexibility to meet evolving scientific needs and regulatory requirements, as well as to integrate with cutting-edge technologies. Agile Scrum, a common framework for managing complex software development projects, offers an ideal solution for these implementations.
Agile Scrum is a popular and flexible, collaboration-focused approach to software development for IT projects and products. These characteristics make it suitable for use in the implementation of laboratory informatics management systems (LIMS), electronic laboratory notebooks (ELN), laboratory execution systems (LES), manufacturing execution systems (MES), scientific data management systems (SDMS), chromatography data system (CDS) or other laboratory-focused software.
Agile Scrum allows the project team to start from an initial definition of the system and then quickly adapt to changing requirements during the life of the project. The process breaks down large lists of project functionality requirements and tasks into smaller chunks that can be allocated to small, manageable, fixed-duration iterations called Sprints, as can be seen from Figure 1: Agile Scrum Framework at a Glance.
Although executing Agile in regulated environments can be challenging, it is possible to benefit from faster development cycles, cumulative outcomes, and earlier delivery of the functional features while maintaining demonstrable and documented control of the process for regulators.
There are several benefits of applying the Agile Scrum methodology when implementing life science informatics systems, such as:
There are four basic roles required to successfully implement a life science informatics system using the Agile Scrum methodology; these roles make up the Scrum team. Each has specific responsibilities (see Table).
There are five key phases involved when implementing a life science informatics system using the Agile Scrum methodology, with specific tasks or activities performed during each phase.
This is where the process of developing a life science informatics system using the Agile Scrum methodology begins; depending on the size and complexity of the project, the Initiation Phase can take several weeks. This phase develops the necessary collaboration among the members of the Scrum team—Product Owner, Scrum Master, Developer(s), and Tester(s)—as well as the system owner, customers, and business users. The purpose of this phase is to refine and prioritize the features and functionalities listed as the Product Backlog Items that will be consulted to fulfill the following activities:
The Product Backlog serves as the foundation or roadmap. It contains the backlog of User Stories, bugs, design changes, and customer requests. The refinement process of the Product Backlog is a continuous activity used to add detail, estimates, and orders to items on the Product Backlog.
Agile Scrum divides the work into goals that can be completed within each Sprint. The length of a Sprint is usually two weeks but never exceeds one month. All members of the Scrum Team participate in the Sprint Planning phase. The objective of Sprint Planning is to answer three main questions:
During the Sprint Planning, the Product Backlog Items are prioritized. An estimate specifies the effort required to complete the selected tasks. The set of Product Backlog Items selected for the Sprint by the Scrum Team is refined as the Sprint Backlog. The Sprint Backlog is used to deliver the details of the current product increment. The Sprint Backlog is refined by adding more details to the User Stories.
The informatics system’s architecture, data flow, and user interface decisions are made collaboratively among the Scrum Team. They are discussed and agreed upon quickly and the design can evolve as the project progresses.
During the Sprint Planning phase, a minimum viable product (MVP) is developed. The MVP is a version of the life science informatics system that consists of three elements: the minimum functionality to satisfy the user’s needs, viability in the market, and being a tangible product. The Scrum Team creates a “Definition of Done” for items listed on the Sprint Backlog; once the items meet the Definition of Done, an Increment is born.
During the Sprint Execution phase, the Scrum Master, Developer(s), Tester(s), and Product Owner attend daily meetings called Daily Scrums. The purpose of the Daily Scrum is to inspect the progress toward the Sprint goal and to adapt the Sprint Backlog as necessary for the upcoming planned work. The duration of a Sprint is dependent on the complexity of the project; larger projects may benefit from longer Sprints – but no longer than one month. Smaller and easier projects may benefit from shorter Sprints; the optimal duration of a Sprint is two weeks.
Task-level work is performed by the Developers to create the features selected during the Sprint Planning phase. Testing is continuous and ongoing throughout the Sprint to ensure each Increment meets the Definition of Done. Once an increment in the Sprint meets the Definition of Done, the Developers review and demonstrate the work completed during the Sprint. During the review of the increments, the Scrum Team can test ideas quickly and feasibly before investing more time and resources.
At the end of the Sprint, the Scrum team reviews the Sprint outcomes with the stakeholders and determines any future adaptations. The Product Owner is responsible for maximizing the system’s value and will often take the lead or initiate the conversation during the Sprint Review phase.
The Sprint Review promotes transparency, highlights the features, gathers feedback, and ensures the system’s vision is aligned with the requirements. Developers demonstrate the Sprint Backlog Items completed during the Sprint that meet the Definition of Done, overview the progress of all previous increments, and get approval from the stakeholders. If a Sprint Backlog Item does not meet the Definition of Done, it cannot be presented during the Sprint Review and must be returned to the Product Backlog for future consideration.
The Sprint Retrospective is the last step of the Sprint and occurs after the Sprint Review and prior to the next Sprint Planning session. The Product Owner does not attend the Sprint Retrospective.
The goal of the Sprint Retrospective is to discuss the interactions, tools and processes the team used during the previous Sprint. During the Retrospective, three important questions should be answered:
Sprint Retrospectives are limited to a maximum of three hours; the standard is to allow 45 minutes for each week of the Sprint. For example, a two-week Sprint would set the Retrospective at an hour and a half; a four-week Sprint would be set the Retrospective at three hours.
▶ Additional Reading: Agile Development in Laboratory Informatics
Applying the key phases of the Agile Scrum process, along with a well-documented, regulatory-compliant, and standard operating procedure (SOP)-driven approach to configuring life science informatics systems has been successful in many settings—from biotechnology to pharmaceutical research and development and medical device manufacturing.
By embracing the proven practices of Agile Scrum to implement life science informatics systems, companies experience improved efficiency, increased customer satisfaction, and faster adaptability, leading to transformative outcomes and results. Agile breaks a large-scale project into smaller, time-bound iterations (Sprints), which promote the following:
Have you used Agile Scrum in a life sciences setting? Share your experience in the comments.
Comments