By Ivanna Rosendal, senior director, IT business partner, Ascendis Pharma

Our industry is embracing agility in clinical trials from both a push and a pull perspective. Agile methodology is an iterative, people-focused approach to project management that emphasizes collaboration and flexibility. The term originates from the domain of software development in the early 2000s and was codified in The Agile Manifesto³ .

The push comes from the fact that change is endemic in clinical trials. Seventy-eight percent of Phase 2 trials have at least one significant protocol amendment¹. With the increase in complex and oncology trials, this number is rising². The pull is emerging as more and more clinical data managers obtain agile methodology certifications and bring their newfound expertise to work. Being able to respond quicker to changes in the environment of a clinical trial carries great potential for matching the drug with the right indication. This means a higher likelihood of targeting the right patient population, leading to better treatment and both clinical and commercial success of the drug.

I argue that Phase 2 clinical trials in particular are more like software development than bridge building and could benefit from experimentation and pivoting to achieve a better match with the right indication and patient population. Adopting agile methodology in clinical trials makes sense, since it provides tried and true solutions for how to experiment and pivot in a complex setting such as software development. Agile methodology builds on the empiric scientific tradition, the same as clinical research. Experimenting in the agile methodology is equivalent to experimenting in the lab: building a hypothesis and testing to verify it. Depending on the outcome of the experiment, the hypothesis is revised – that is called a pivot.

Forgoing The “Waterfall” Model

To understand which problem agile software development is meant to address, let’s consider the context of the time.

Technological development created an increased demand for software in the dotcom bubble, and skilled developers became in short supply. The predominant approach for managing software development came from project management. Project management was in turn created to reduce risk in up-front, investment-heavy projects such as building bridges. In such projects, planning ahead is key, since decisions cannot be easily undone once the project is initiated. Translating this approach to software meant defining specifications up front and building the software according to specification: the so-called “waterfall” model.

The waterfall model falls short for software development in two critical ways:

1. Unlike the know-how needed to build bridges, the development of what is possible with software evolves at an ever-increasing pace.
2. The desire of the end-product consumers is rather static when it comes to bridges but is dynamic when it comes to software solutions.

This meant that software development built upon up-front definitions was often outdated at launch, and the demand for changes and rework often outweighed the original number of requirements. Having to rework and alter the software solutions created unsustainable working conditions for software developers. In light of this, a handful of developers banded together to create The Agile Manifesto, which is still a pillar within agile software development.

Clinical Trials Are Not Like Bridges

Consider the parallel between software development and clinical trials. The commonality can be described with Dave Snowden’s Cynefin model⁴: The model is a two-by-two matrix, with four domains. The model shows four stances from which work can be perceived, and the right methodology to solve the assignment can be chosen based on the stance.

In the bottom right corner, we are in the Simple domain. Work that fits within this quadrant is easily codified and replicated. An example could be filling out a user access request form. If described in sufficient detail, this work can be successfully performed by anyone.

In the upper right corner, we are in the Complicated domain. The assignment requires multiple interdependent steps to be completed in a given sequence. The steps are well understood, given sufficient expertise and experience in engineering science; a plan can be devised to manage the completion of the project. Here, project management methodologies are the right tool to apply and have been significantly honed to address the nature of the assignment. Traditionally, drug development programs are also approached as if they existed in the Complicated domain and can be predicted and sequenced using project management methodologies.

In the upper left corner, we are in the Complex domain. The scientific method fits into this domain in general. When something is not yet understood, learning is created by putting forth a hypothesis, testing it, and revising your understanding based on the hypothesis. It is not possible to create a long-term plan or call in experts, since experts do not exist when trying to understand something novel.

In the bottom left corner, we are in the Chaos domain. When work falls in this domain, there is no logic to it. The only way to respond to work in this domain is to act, then later understand whether your action was sensible. An example could be your desk catching fire. Your first instinct to address this problem will be your course of action. Only later can you make sense of whether that was an appropriate response.

Returning to the examples from above, building a bridge would fit neatly into the Complicated stance on the top right.

However, software development fails the criteria for the Complicated domain for two main reasons:

1. The problem is not well understood and changes when you interact with it.
2. The steps to solve the problem are unknown, and the sequence is unpredictable.

Instead, the Complex domain fits the characteristics of software development. The environment in this domain is unstable and unknowable. Traditional project management as a suitable tool falls short.

Agile software development soon emerged to solve the unique challenges in this domain. Instead of assuming that a problem is known and the way to solve it is well understood, agile software development relies on rapid prototyping and product testing to eventually get to the best solution as the understanding of the problem increases based on the empirical evidence collected via the experimentation. This means that by learning along the way, the best solution can be found quicker, rather than following a plan made based heavily on assumption.

Pivoting Toward A Population Most Likely To Benefit

I argue that running a Phase 2 clinical trial is more like developing software than building a bridge. In Phase 2 especially, we are still trying to understand the potential of the compound. The effectiveness of a drug is dependent on finding and scoping the population for which it is effective⁵. Maintaining an open mind to the conclusions from the data collected — especially during the trial — can help guide the drug development process toward the population most likely to benefit. The patient population selected for the trial could be viewed as a hypothesis⁶ that needs to be verified during the trial. As with the empirical scientific method in general, this should also allow for the possibility that a more fitting patient population can be identified.

Being able to identify alternative patient populations in time to pivot requires a strong technological foundation as well as processes and systems that allow collaboration and flexibility. Most pharmaceutical companies are moving toward stronger technological foundations and are reducing manual data work. But building processes and providing opportunities for cross-functional collaboration can still be improved. This is where inspiration can be drawn from agile methodologies.

Consider the following three focus areas for allowing rapid adjustments during a Phase 2 trial:

1. Plan frequent reflections on both collected data and trial conduct.
2. Involve a broad set of stakeholders in these reflections within the sponsor company, but ideally also including CROs and site staff.
3. Make change possible by making systems simple to change and automating processes.

Putting time aside to review the data collected — especially in connection with operational data from the trial — can make a big difference. These sessions should be frequent and at a set interval, such as every two weeks, depending on the trial duration. They should have a set agenda and include all relevant stakeholders. The relevant stakeholders can be from outside of the sponsor company — especially if the trial is outsourced to one or several CROs. Including the site perspective may help uncover and interpret trends seen in the data — such as patient responses to the delivery of the treatment. The agenda should be facilitated by a person capable of holding space for all participants to bring their perspectives. It helps if this agenda is facilitated using visual collaboration tools like virtual whiteboards, where the stakeholders can interact. Once a needed adjustment is identified, the path to implementation should be made easy by using technology tools that are easily augmented to the new reality.

Adopting An Agile Mindset Means A Change In Culture

Adapting to a new meeting cadence and creating processes and tools that are easy to modify are simple compared to the challenge of changing industry veterans’ minds about the amount of adjustment that a Phase 2 trial can carry. There are three major mindset shifts required to allow for agility:

1. Change is not failure.
2. Collaboration is not lack of negotiation.
3. Transparency is not control.

Protocol amendments are expensive, and the current stance is that they should be avoided at all costs. But the reality of clinical trials is that amendments are unavoidable. Instead, we should focus on making it as easy as possible to discover when change is needed. Starting a trial with a hypothesis and uncovering that it was wrong is also progress and should be celebrated in equal measure as confirming the initial hypothesis. Bringing all the relevant stakeholders to the table to inspect the progress of the trial does not mean that the legal boundaries between organizations disappear — but that we temporarily suspend them for a common purpose. Suspending the organizational boundaries is necessary to create psychological safety in the trial team, so that everyone is eager to bring forth their observations and even difficult data. It may just be the piece of information needed to uncover the right way forward. Viewing the available data and including the perspectives of multiple types of stakeholders creates transparency. Transparency in this setting is not meant as control but rather is a necessity to create the type of platform needed to observe the trial in its entirety — and make the necessary conclusions.

Our industry is being pushed in the direction of more agility, but it is also being driven by employees exploring these methodologies for themselves. Applying agile methodologies in clinical data management bears the potential of discovering the right drugs for the right patient populations more rapidly. It requires adaptation to our processes, systems, and culture. But the promise of better drugs is worth the cost of the transformation.

Resources:

1. https://www.pharmoutsourcing.com/Featured-Articles/584137-Doubling-Down-on-Protocol-Amendments-and-Deviations/
2. https://cms.centerwatch.com/articles/25921-no-end-in-sight-for-trial-complexity-csdd-report-reveals
3. https://agilemanifesto.org/
4. The Cynefin model. https://thecynefin.co/about-us/about-cynefin-framework/
5. Graham Dutfield. https://www.buzzsprout.com/1906263/11807412
6. Alexander Gray. https://www.buzzsprout.com/1906263/11531884)

About The Author:

Ivanna M. Rosendal is the senior director of IT in Ascendis Pharma. She is a behavioral economist and has held technology leadership positions in life sciences for the past 10 years. She hosts a podcast about innovation in clinical trials called Transformation in Trials and writes about femtech wearables for TechTruster. Reach out to Ivanna via LinkedIn.