This article first appeared in Bioscience Technology.
Using the Agile approach to software development can increase project success threefold as compared to traditional methods. So what is the Agile approach? It is an iterative approach to software development in which the requirements and solution evolve through continuous collaboration of cross-functional teams.
According to the 10th Annual State of Agile report published by Versionone.com, Agile software development has continued to gain popularity over the last decade with more than 60% of medium and large enterprises reporting that they have adopted Agile in at least some parts of their organization. The benefits of using the Agile approach are clear: accelerate time to market, better align product to customer needs, enable employee empowerment and retention and decrease the overall cost of system development. For example, in the 2015 chaos report by the Standish Group, which analyzed more than 50,000 IT projects between 2011 and 2015, it was determined that the Agile approach leads to over three times more successful outcomes than the waterfall approach for projects of all sizes. Furthermore, as the projects get larger and more complex Agile is even more successful than the traditional waterfall approach. Such success metrics should convince all organizations across all industries to adopt Agile for their system development.
Pharmaceutical business executives and IT leaders, while eager to achieve the success metrics and cost efficiencies that Agile offers, are often hesitant to incorporate this approach because they perceive a few significant challenges to implementing Agile. Based on our experience, below are examples of frequently cited problems that pharmaceutical executives list as reasons why Agile won’t work for their company, along with simple solutions to illustrate that this approach can and does work.
How organisations can stop wasting their best ideas
Myth 1: Agile is not viable for regulated systems
High among the challenges pharma IT leaders identify is that many of their systems are regulated and therefore must comply with Health Authority regulations and expectations. Traditionally, the pharmaceutical industry embraced the waterfall model—a software development process in which progress flows steadily through the phases of Define, Design, Develop, Test, and Deploy, as the way to achieve compliance.
Instead, Agile software development, with continuous integration, testing, and value delivery, not only complies with U.S. FDA’s General Principles of Software Validation, it actually adheres more closely to the risk mitigation objective of the FDA’s regulatory process than a traditional waterfall-based software development. Simply put, Agile software development better meets these quality and compliance needs.
The popular verification and validation model (“V-model”) used for developing regulated systems can be effective only if all the requirements are known upfront. In most real-life scenarios, customers’ understanding of their requirements evolve with time and engagement with the solution and, as a result, the software development team and the IT quality assurance (“QA”) teams either don’t deliver the solution the customer wants or must rework and revise the development and requisite documentation multiple times prior to release. And during this, often lengthy, development cycle, the customer does not derive any value from the system under development until it is released finally in a “big-bang.”
Myth 2: IT QA prefers waterfall development and will resist the change to Agile
IT QA has worked for years with the traditional V-model and has defended this approach during regulatory inspections. They have fine-tuned their process and SOPs around the V-model and their IT QA resource allocation is established based on the model. To overcome this resistance will require significant change management considerations including technical and cultural training of the business and IT QA teams, support for documenting deviations from the Standard Operating Procedures (SOPs), and subsequent support to rewrite the SOPs. At a large biopharmaceutical company both IT QA and business QA were made part of the core Agile team, and hence could ‘self-determine’ the approach to SOPs, continuously improve upon this, and, with the wider team, take an Agile approach to rewriting SOPs.
Myth 3: Agile is not practical for global teams in large multi-national pharma
The Agile manifesto does recommend collocated teams, face to face meetings, and sufficient real-time access to the product owners that many multi-national corporations find challenging to conform to. Take, for example, a large multinational pharmaceutical company that has geographically dispersed teams and was adopting Agile. Historically, the majority of communications across the teams in this organization were asynchronous, such as emails or changes to documents in a shared drive. As a precondition to implementing the Agile approach, the company encouraged its colleagues to have real-time communications through the use of virtual collaboration technology, flexible work schedules, and time zone sensitive alignment of people and projects. They also encouraged rigorous adherence to processes that enabled increased communication, keeping iterations short to force solution integration, and virtual socials to facilitate a “one team” culture.
Myth 4: Agile does not meet the predictability needs of pharma IT leadership and Program Managers
IT leadership and customers do require predictability of inputs (resourcing and financial investments) and outputs (outcomes) but much of the predictability they are currently offered is of inputs. In a perfect scenario, all requirements and systems are fully known and all partners, competitors and employees abide by the plans. In this ideal world, the committed resources will achieve the outcomes and meet the customer needs. Such an idealistic scenario seldom occurs, and most real-life situations require continuous adjustment to plan, and mechanisms to surface and resolve previously unknown issues, so that the customer’s critical needs are met. The Agile approach offers a commitment to working solutions at the end of each iteration, and regular demonstrations and releases provides a level of transparency and predictability that most traditional approaches struggle to achieve.
Myth 5: Business colleagues, the product owners, are not as available
IT teams often state that their product owners, who belong to a business function, are not as available as the Agile approach requires. Usually, this belief is accurate. In the traditional waterfall approach, it is common practice to involve business colleagues for short durations during the requirements phase, and once again for a short duration during the testing phase and not involve them at all during the intervening time period. Agile, however, requires business colleagues to be engaged throughout the development process and needs business participation in at least some of the Agile events during each iteration. This is a greater level of participation in IT projects than most business colleagues are accustomed to and many are unable to cope with that because their “day jobs” have not been adjusted appropriately to free some bandwidth. Resolving this challenge with leadership support is not only necessary to make the Agile approach work in the short term, it is critical to make this change stick.
Myth 6: Managing external suppliers and partners is difficult using the Agile approach
Agile requires fully empowered teams and a high level of trust that teams, including suppliers, will work in the best interest of the outcome, without considerable oversight. As a customer, you would also like the benefit of fixed price but without having to fix scope and provide all your requirements up front or default to time and materials. A different procurement model is required to achieve these goals and to align your business objectives with your supplier’s incentives.
At a top five Pharma company, they took the approach of training the procurement team in Agile early on in the Agile transformation and also adopted a two phase contracting mechanism, which enabled them to fix price without fixing scope. They also trained key existing suppliers on Agile, replacing some who were uncomfortable with the higher level of transparency and partnership that Agile entails.
Pharmaceutical IT can indeed achieve a threefold increase in project success by adopting Agile for their system development projects, for both non-regulated and regulated systems. Such higher rates of success are critical to achieve increased efficiency, especially in today’s environment in which budgets are tight and IT colleagues are being asked to “do more with less.” To address the perceived challenges and myths of Agile adoption, a change led approach and senior leadership engagement is required to drive, support and foster the cultural change needed to overcome these perceived challenges.
So, will the Agile approach work in Life Sciences? The answer is yes and like all transformations does require effort; but there are tangible payoffs. For example, a large pharmaceutical company recently adopted Agile, which resulted in teams reporting significantly faster time to value delivery, a reduction in team sizes, and improved quality. Financially, the company saved more than 25 percent as a result of the Agile adoption within the first 9 months from just a small subset of initial projects.
Raghu Raghunath, Justine Johnston and David Lerner are life sciences experts.