Agile has become one of the most frequent buzzwords in biopharma, used to sell any number of services and software solutions. Beyond the hype however, biopharmaceutical companies have begun to adopt agile solutions, initially developed as a software development best practice, with powerful results. Agile philosophies embed a creative mindset necessary to adapt to rapidly changing environments, and with recent highly successful commercial launches, initial results are compelling!
Most bio-pharmaceutical and even device companies struggle with embedding agile practices across the end-to-end commercial launch value chain- this is mainly because of the perceived risks of Agile practices. For example, Agile launch teams are given the autonomy to dictate when governance readouts are required, and should be encouraged to iteratively develop launch solutions, vs. adhering to strict ‘waterfall’ activities. As a result, most firms would rather ‘dip their toe’ into agile practices and measure results before adopting an end-to-end rollout or implement these practices on only accelerated programs.
That being said, we have seen Agile solutions span the entire set of launch activities, from marketing and regulatory activities to medical affairs, tech ops and commercial operations, with compelling results.
One of the most powerful approaches has been to set up an autonomous, small core team of cross-functional SMEs to oversee end-to-end launch. This team doesn’t assume titles or functional responsibilities, but is ultimately accountable for end-to-end delivery. Applying Agile methodologies means constant iteration. What teams should be formed and disbanded? What critical path deliverables should be addressed? What are risks that can be proactively addressed? This flexible and creative team can navigate the process, especially if it is made up of individuals who are both experienced and empowered.
Companies should always be wary when people try to ”sell” them a complex definition of Agile. Costly software or lengthy archives of content are not required. In fact, we’ve seen major capital investments prove detrimental to making an organization truly agile. An effective approach that we have used is to train a sub-set of experienced SMEs in commercial operations, clinical operations and PMO officers. The training should be highly interactive, and designed to ensure that the teams are empowered to co-create Agile solutions.
This group can then help to ideate strong use cases, applications and pilot studies. Often these initiatives require heavy communication and change management, as the goal is to convert the organization into a network of autonomous teams, operating in a rapid learning environment in a fast and flexible way. This requires a complete paradigm shift that not all organizations are ready for. Also, where possible it is critical to baseline launch performance against ‘typical’ launch timelines and best practices. This helps to highlight where Agile practices have made a tangible difference.
Agile is a philosophy and approach that is optimal for high-complexity, high risk and high-novelty situations. If projects, or specific steps don’t meet this criteria, then Agile methods may not apply. For example, in areas where extensive documentation of each development cycle is required, or where much of a process or production phase is already known, Agile is not ideal.
Lastly, Agile methods can be quite costly to implement with respect to time and resources. If the program does not warrant this level of investment, or does not need to explore creative options, it may not be optimal. One useful thought exercise is to consider the level of target Agile capability for each group. Our Scimitar Agile Maturity Model can help groups target the maturity level that is right for them. Ultimately this helps teams organize in a way that is best to do their work- balancing strategy, speed and flexibility.
| Level 1 Limited |
Level 2 Evolving |
Level 3 Project Excellence |
Level 4 Integrated Excellence |
Level 5 Agile Advantage |
|
|---|---|---|---|---|---|
| People |
– Low competencies and skills level in Agile – Undefined roles and responsibilities with no shared accountability – Lack of individual incentives for Agile adoption |
– Skill level in Agile varies by project team and functional department – Agile Roles and responsibilities are inconsistent |
– Consistent level of skills and competency in Agile across project teams – Well defined roles and responsibilities and shared sense of ownership at the team level |
Department leaders have ownership in and support Agile | Enterprise Performance Metrics support and encourage Agile collaborations |
| Process | No processes in place for identifying, intake, estimating or mobilizing Agile projects | Some processes are in place for identifying, intake, estimating or mobilizing Agile projects, but not always followed | Documented processes are in place for identifying, intake, estimating or mobilizing Agile projects |
– Process for integrating Agile and waterfall activities – Interfacing occurs with other functional areas leveraging different methodologies |
Documented processes in place to measure quality and performance of Agile projects |
| Tools & Practices | Limited use of Agile practices and tools for managing user stories, builds and testing | Agile teams leverage tools for planning and managing user stories and have some flexibility in installing new tools | Agile teams are co-located, can support off-shore team members adopt key Agile practices and leverage continuous integration practices in place | Agile tools are adopted across division and supported at the enterprise level | Adoption of Agile practices such as Continuous Delivery is pervasive in Agile projects |
| Structure |
– Little to no direct communication between departments – No formal Agile training |
– Some involvement between teams – Limited business support for Agile – Limited willingness to make the changes needed |
– Business stakeholders communicate directly and frequently with the Agile teams – Sufficient Agile training |
Organizational structure supports the alignment of Agile teams with the organization |
– Organizational policies and procedures support Agile adoption – The organization is adaptable and |
| Team |
– Limited visibility into team capacity – Team members are not accountable for outcomes |
Team members have some accountability for outcomes | Team tracks actuals vs. planned releases | There is visibility into team capacity across departments | Teams frequently report progress against the plan to leadership |
Zeid Barakat brings over 20 years of expertise across the biopharmaceutical value chain as a consultant and entrepreneur. Zeid also serves as an adjunct faculty member in the Tufts CSDD and enjoys playing tennis (former Davis Cup Team of Jordan), chess, and painting.
T: +1 917 363 3438
[email protected]
| Intended Reader Functional LeadersBusiness Managers | Key Takeaways Effective team management benefits from structure Business managers are central to high performance Begin with a
| Intended Reader Biopharma leaders | Key Takeaways Striking a Balance Between Speed and Safety Global Collaboration for Effective Regulatory Pathways Agile Regulations for Rapidly
| Intended Reader Biopharma leaders | Key Takeaways Striking a Balance Between Speed and Safety Global Collaboration for Effective Regulatory Pathways Agile Regulations for Rapidly
| Intended Reader Biopharma leaders | Key Takeaways Emerging Modalities: Cell and Gene Therapies Engineered Live Biotherapeutics Regulatory Adaptations to Facilitate Innovation Implications for Clinical
| Intended Reader Biopharma leaders | Key Takeaways Harmonization’s impact on RWE and RWD integration Leveraging AI to drive Data Standardization The potential of Harmonization,