Using Agile Scrum to Implement a Life Science Informatics System

Blog: Agile Scrum

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.

What Is Agile Scrum?

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.

Benefits of Using Agile Scrum 

White Paper: Readiness Checklist for your LIMS Implementation

There are several benefits of applying the Agile Scrum methodology when implementing life science informatics systems, such as:

  • User Stories: Short, informal descriptions of features told from the perspective of subject matter experts (SMEs) in the laboratory process to be automated. User Stories are created during the initial planning phase of the Agile Scrum project. User Stories can help the validation team populate the User Requirements document.
    • The structure of a User Story helps keep the focus on the user’s requirements and addresses their basic needs when stated in the form of “As a [type of user], I want [some goal] so that [some reason]”.
  • Examples of a User Story for a life science informatics system might include “As a Lab Manager, I want to view all available specimens so that I can generate a report by the various statuses;” or “As a customer, I want to select samples, so that I can generate barcodes on labels for sample containers.” 
  • Agile Scrum takes a time-bound approach and makes it easier to navigate the various project phases by breaking down the complex and cumbersome informatics system requirements into smaller Sprints. Each Sprint helps stakeholders understand the aim of the Sprint and gives the team members more flexibility to adapt to change.
  • Sprints make the workflow more productive and efficient and take the project closer to completion. Sprints reduce the number of resources (roles) needed to implement the informatics system while also reducing the need for overall project risk mitigation.
  • Sprints also allow users to develop the system in manageable pieces that become part of a much larger project.

Key Roles and Responsibilities

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).

Blog Image: Agile Scrum Table

Key Phases of Agile Scrum 

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.

Initiation 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: 

  • Identify the needs of the customer.
  • Set the business goals
  • Define the project’s vision and scope and identify the Scrum team 

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. 

Sprint Planning Phase

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: 

  • Why is this Sprint valuable?
  • What can be done during the Sprint?
  • How will the chosen work get done?  

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.

  • Examples of items found on the Sprint Backlog to implement a life science informatics system might include:
    • view the system audit trail entries to see when users modify the status of a Sample.” 
    • enter results for a sample in a LIMS.”
    • retrieve approved completed results entered by customers on a GxP system.” 
  • Examples of items on the Sprint Backlog to add enhancements to an existing ELN system might include:
    • “create and assign a new ELN Entry to an existing project.”
    • “export all files attached to an Entry and import into a comprehensive .zip file.”
    • “retrieve the audit trail logs to view all modifications made to Entities by a user on a specific date”

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. 

Sprint Execution Phase

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.  

Sprint Review Phase

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.

Blog_Agile Scrum Framework At A Glance

Sprint Retrospective

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:

  • What did the team do well?
  • What didn’t go well?
  • What can be improved for the next Sprint? 

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:

  • Transparency and effective communication
  • Flexibility to respond quickly to changes
  • Ability to easily test and validate, which can result in fewer postproduction errors
  • Better product quality and customer satisfaction
  • Cost-effectiveness and reduced documentation 
  • Speed to market

Have you used Agile Scrum in a life sciences setting? Share your experience in the comments.

Share Now:
Categories:
Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.