Why Science-Driven Companies Should Use Agile

Organizations in wildly different contexts and competitive situations have firmly embraced agile methodology. But one area is notably absent from this trend: R&D in science-driven businesses. While agile practices and concepts are transforming corporations across industries, these departments have been left, all but untouched, in their old ways of working.

This is partly because the scientific approach remains resolutely traditional. It is very linear, with one stage progressing to the next only when the previous stage is complete. Organizational units are designed around narrow scientific domains and provide resources to loosely defined teams to complete tasks.

For example, at one of our biotech clients, we found that clinical development groups were working without much coordination. They followed strict scientific process protocols and team members turned to their functional heads for all key decisions. The only real team activity was to prepare a great PowerPoint presentation for the steering committee every month or so to show progress. Our analysis found that the waste and inefficiency of this back-and-forth between individuals and their reporting functions cost about 30% of their time and productivity — and, most importantly, reduced the ability to iterate quickly despite the obvious benefits that faster adaptation would bring to a capital-intensive and uncertain process like drug development.

The traditional scientific way of working is also expensive. Avenues are laboriously explored even if they eventually reach a dead end. According to recent studies of the pharmaceutical industry, the average out-of-pocket expenses for each newly approved drug is $1.4 billion; the figure has grown steadily over the past decades. Overall research productivity in the U.S. is falling, too: Estimates from academics at Stanford and MIT put the decline at an average of 5.3% per year.

Other factors putting pressure on corporations to move products through the pipeline faster and with greater cost efficiency include rapidly changing regulations and growing shareholder expectations for higher-performing R&D investments.

Given all the challenges that most science-driven R&D groups are facing — in pharma and beyond — agile frameworks might provide new value in supporting teams along their journey from groundbreaking discoveries to successful commercial developments.

Agile Science at Work

In our work at relevant companies, we are seeing the emergence of what we describe as agile science: a new way of working characterized by the pragmatic and context-specific use of agile methods and tools.

Consider a German chemicals company that adopted the agile principle of rapid iterations with early customer involvement in its R&D process. This new approach allowed it to increase its R&D productivity by 20% by either discontinuing projects or pivoting them in new directions early in the process. For example, thanks to early prototype testing with a small number of industrial detergent customers, the company decided to shelve research that would have otherwise resulted in a costly failure.

Or take PTC Therapeutics, a New Jersey–based biopharmaceutical company focused on discovering, developing, and commercializing rare-disease drugs. PTC faced the challenge of quadrupling the number of planned research and clinical development projects in 24 months due to its ballooning R&D investments and pipeline. It adopted a team-based structure to reduce inefficiencies and enable rapid scaling through empowered, cross-functional research, clinical development, and commercial groups. While this shift is still in progress, senior leaders are now more confident about smoothly managing greater complexity. Early results also suggest that the increase in productivity may be sufficient to manage twice as many programs, while also increasing the success rate of the projects.

This gives us a framework for how more organizations can join the agile science movement.

1. Anticipate skepticism. Perceptions matter, especially in a field infused with a natural sense of skepticism. Scientists are trained to trust only controlled experiments. To change any initial negative views on agile, you’ll need the right approach for spreading and executing on the concepts.

It helps to point to strong examples, and we have one in the Broad Institute of MIT and Harvard, a biomedical and genomic research center. In 2016, agile enthusiasts at the Broad Institute launched an open agile community of practice called “Agile Academia” in order to learn more about the practices and how they might be applied to help non-software teams. The group now includes representatives from more than 20 of Broad’s laboratory and administrative departments and meets monthly to discuss agile practices and coordinate in-depth agile training and agile meetup events for the Broad Institute community. As a result, agile values, routines, and tools have naturally spread into teams through the organization as more people learned about their benefits

2. Emphasize the “why.” Focus more on the “why” of the change to agile than you do on the “what” and “how” of incorporating the methodology. Consensus around goals should drive decisions on which organizational model and practices to apply.

At PTC Therapeutics, agile was first discussed by the executive committee team in a workshop to understand if it would be a good fit for the company. The “why” discussion was particularly valuable, leading to the alignment of executives on the rationale for an immediate change. The company was experiencing accelerated growth and needed to quickly transform its way of working to manage dramatically more scale and complexity and meet its mid-term goals. The CEO and COO then shared the plan — emphasizing this “why” — with employees at a companywide town hall. The result was broad buy-in and strong pull for companywide training.

There could be several rationales for an agile transformation: reducing costs, increasing productivity, becoming more customer-centric by quickly adapting to feedbacks, speeding up decision making, boosting employee engagement, and so on. When that “why” is identified and communicated, people are much more likely to accept and even welcome the change.

3. Implement flexibly. Agile does not require an all-or-nothing approach. Some routines and tools will be valuable and applicable, other less so depending on your context and business needs. Process-rigidity is the antithesis of agility. Agile R&D teams might not —almost certainly will not — look like agile software teams, and that is perfectly acceptable.

For example, during their agile explorations, several laboratories at the Broad Institute quickly realized that a daily scrum was too much for them. Many of the lab procedures stayed the same from day to day, and the teams weren’t finding value in meeting so often. So they adjusted the cadence and scope of their scrums. Some met once a week to align on work and remove dependencies. Other, more project-based teams varied the frequency of routine meetings according to the flow of the laboratory project — for example, daily during phases that require a lot of coordination (sample processing, paper writing etc.) but weekly or biweekly at other times.

4. Organize around the right kind of teams. Teams are the basic unit of delivery for an agile organization. But the right kind of team-based organization is hard to find in science-driven businesses. People are assigned to projects, but they continue to identify with fiercely independent functions and departments that use their scientific knowledge domain as a way to take control of “related decisions.” In addition to the typical organizational silos, knowledge domains create fiefdoms, removed from any questioning by outsiders.

At PTC Therapeutics, cross-functional agile teams became the basic unit of the new clinical development part of the organization. The company created what we called “pooling functions” that could dynamically assign resources “on-demand” to newly defined agile teams that were empowered to drive decision-making within their defined scope, without any friction from old-fashioned functional silos.

For example, for a drug program in advanced clinical development, the core team is typically composed of full-time people from clinical operations, regulatory, and medical affairs. The product owner is a marketing person supported by an agile coach (similar to the scrum master at other organizations). The pooling functions operate as staffing pools and take care of the balancing of the demand and supply of talent in the medium term.

Teams are clustered around a therapeutic chapter, with a leader who balances priorities and interdependencies for projects related to the same drug among multiple teams in the chapter, and ensures a two-way integration of the company’s strategic priorities and goals with the bottom-up autonomy and results of the teams. PTC Therapeutics expects not only more efficiency from this agile organizational model (i.e. to scale more smoothly using fewer resources), but also to speed up its clinical development cycles.

The use of agile in science is just beginning. Entrenched scientific communities will resist changing their working habits. But, as these pioneering organizations report back on their positive results and experiences, the demand for agile science is likely to increase. Learning and adapting is, after all, at the heart of what science is all about.