Pharmaceutical and software development projects have quite a bit in common. They are highly complex, rely on multidisciplinary teams, and usually come in late and over budget.  In addition, they are often judged based on the same quality factors: reliability, safety and efficiency.¹

While both software and drug development teams aim to produce compliant, efficacious, safe, effective, and commercially viable products, they take very different approaches to development, with pharma using the “waterfall” approach, and software, agile approaches.  This article looks at current approaches in software development, and asks whether they might prove useful in drug development.

What is Agile?
Highsmith defines “agility” as the ability to balance flexibility and stability.² In the software industry, “Agile Development” is an umbrella term for a set of methodologies. According to Larman, methods of agile development apply time-boxed iterative and evolutionary development, adaptive planning, evolutionary delivery, and other values and practices to encourage rapid and flexible response to change in process.^{3, 4}

The pharmaceutical industry still uses the Waterfall development approach, one of the most common and known sequential design process methodologies. It was originally designed for manufacturing and construction industries and gets its name from the way its phases flow downward like a waterfall. The best project types to utilize this methodology are the ones where the requirements are static and clearly stated. Also its up-front requirements and settled timeline and budget lend itself to a robust management structure.⁵

In a waterfall product development approach, project managers traditionally identify a number of steps to accomplish a project, which typically must be completed sequentially and depending on type of project could include: Requirements, Design, Implementation, Verification, Completion, and Maintenance.

The Waterfall method relies on the impractical assumption of gathering up front all requirements during the first phase.⁶  With this approach, communication with the customer/user is front-loaded into “Requirements” phase. Once this stage is completed, the process runs “downhill.”⁷ This approach may cause detailed and extensive product specifications based on impracticable assumptions because of a lack of practical experience. Thus, it can deliver a false sense of precision. It also brings the risk of creating very detailed but out-of-date documentation.⁸

Agile Product Development Method
On the other hand, the agile product development approach is rooted in principles of “human interaction” management. Different than the Waterfall method’s pre-planned process, in an agile product development approach project manager defines the project as a series of small tasks and completes them in a responsive and adaptive manner. This approach does not require the impractical assumption of “knowing all requirements.”⁹ Out of the potential methodologies such as Extreme Programming, Crystal, Dynamic Systems Development Method, Lean Development, and Feature-Driven Development, “Scrum” is one of the main agile software development methodologies.¹⁰

From Rugby Football to Software Development
The first used definition of Scrum, a word that comes from rugby football, was “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach.”¹¹
In rugby, after an interruption, Scrum is one of the ways to restart the game. Forwards of each side get together in a tight formation and struggle to gain possession of the ball when it is tossed in among them.¹² In the corporate world, this same word is used to denote an agile process for managing and controlling product development in rapidly changing environments.

Scrum is a special way for a team to work together to develop a product, as it occurs in small pieces.¹³ (It is a building up process, where a piece is built on the previous pieces, and each time a small piece is completed, it encourages creativity and gives space to teams to be able to respond to feedbacks and change. Scrum can also be thought of as a simple framework for effective teamwork in complex projects which provides a small set of rules aimed to create just enough structure for teams to be able to focus.¹⁴
The aim of Scrum is to be able to respond fast and have flexibility in the development process without sacrificing quality, cost control, motivation or customer needs. In preference to orientation upon high-level and extensive planning and heavily documentation, it emphasizes the need for customer interaction during incremental and focused development cycles.¹⁵

The basic principle of Scrum is to divide the development process into pieces or development cycles. In Scrum terminology, these cycles are named as “sprints,” which have pre-defined tasks to address pre-selected goals of the project. A “Daily Scrum” only lasts 15 minutes and it is used to compare current results with tasks and its associated difficulties or problems. At the end of each sprint, the results are presented which should at that point be potentially deliverable.⁸

Each sprint is a time box of a month or less, no more than 30 days, in which the sprint team manages itself-during which a “Done”, usable and potentially releasable product increment is created. A new sprint starts immediately after the end of the previous sprint16 and each sprint involves parts such as sprint planning, daily Scrums, the development work, the sprint review and the Sprint Retrospective.¹⁷ During the sprint, it is important not to make any changes to endanger the sprint goal. Additionally, quality goals do not decrease however, scope may be clarified and renegotiated between the Product owner and development team as more is learned.

Having such a flexible structure creates a big advantage during projects where customers change their minds about what they want and need (often called requirements churn). In drug development, customers could include marketing and sales teams, supply chain and manufacturing groups, legal, regulatory agencies, contract manufactures and packagers, physicians and patients and many others. In traditional methods, these changes cannot be easily addressed and adaptation cannot be easily managed.

Concerns with Agile in the Pharmaceutical Industry
Pharmaceutical regulations currently follow mainly a descriptive approach. Therefore, the regulations in general terms define what must be accomplished and largely leave the question of how to achieve it to the companies. Consequently, regulators expect companies to establish their own documented development programs and show that their formulations and processes are capable of providing safe, efficacious, and effective products.

There seem to be at least two major concerns with utilizing an Agile approach in the pharmaceutical industry: the fact that Agile tends to “value individuals and interactions over processes and tools” and the agile value of “working software over comprehensive documentation.”⁴ However, following the agile or hybrid principle of gathering skilled people and providing them with the means to work well just makes a robust process even stronger. This is because it ensures that teams continuously ask themselves if any improvements are needed. This is what regulators explicitly ask pharmaceutical companies to do.

In addition, both agile and regulated principles serve the same purpose, if we equate working pharmaceutical product with safe and effective product.  In the pharmaceutical industry, documentation is not an end in itself. It is merely a means of showing that the product is going to fulfil its intended use in a safe and effective manner, because it has been developed via a robust process.

Given the current struggles to shrink the product development life-cycle in drug development, it is clear that a more responsive, adaptive, and agile model is needed. The goal of Scrum, responding fast and flexibly to changes in requirements during the project, without sacrificing quality, cost control, motivation or especially user requirements, is a best fit for product development life-cycle in drug development.⁸

Agile methods like Scrum are only tools and not solutions. Agile methods strive to achieve results and quality with the help of simple rules and less bureaucracy. They or hybrid models, where agile and traditional methods are combined, must be integrated into the Quality Management System when used in a regulated industry such as ours and perhaps to add special sprints for covering formal documentation requirements.

To sum up, agile methodology is showing itself a promising way of working and moving beyond software development projects and soon will find its place in other industries like pharmaceuticals. What do you think of the approach, its benefits and potential drawbacks?  Please write in and let us know. 

1. Characteristics of good software. (2013). Retrieved November 20, 2013, from http://www.ianswer4u.com/2011/10/characteristics-of-good-software.html#axzz2l1yAqJV4
2. Highsmith, J. (2002). Agile software development ecosystems. (Vol. 13). Addison-Wesley Professional.
3. Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Addison-Wesley. p. 27.
4. Beck, K.; et al. (2001). Manifesto for Agile Software Development. Agile Alliance. Retrieved  November 18, 2013, from http://agilemanifesto.org/.
5. Rising, J. (2009). Sashimi Waterfall Software Development Process. Retrieved  May 6, 2009, from http://www.managedmayhem.com/2009/05/06/sashimi-waterfall-software-development-process/
6. Kee, W. H. (2006, November). Future implementation and integration of agile methods in software development and testing. Innovations in information technology, Dubai. doi: 10.1109/INNOVATIONS.2006.301945
7. Hoffer, J. A.; George, J. F.; Valacich, Joseph S. (2008). Modern Systems Analysis and Design. Upper Saddle River, New Jersey: Pearson Education, Inc.
8. Komus, S.; Komus, A. ; Noble P. (2013). Scrum in the Regulated Environment, Opportunity or Risk for Computer Systems Validation? Retrieved November 16, 2013, from http://www.komus.de/fileadmin/downloads/public/2012-09-Scrum_in_regulated_environment-CHEManager-EUROPE-print.pdf
9. Cairns, A. (2012).Comparing Agile and Waterfall Methods of Project Management. Retrieved November 16, 2013, from http://www.pmhut.com/comparing-agile-and-waterfall-methods-of-project-management
10. Patel, R (2013). Agile 101. Retrieved November 17, 2009, from http://resource.grapii.com/articles/agile-development.pdf
11. Takeuchi, H.; Nonaka, I.(1986). The new product development game. Harvard Business Review, Jan-Feb, 137-146.
12. Scrum. (2013) Merriam-Webster.com. Retrieved November 19, 2013, from http://www.merriam-webster.com/dictionary/scrum
13. Cardozo, E. Et al. (2010). Scrum and productivity in software projects: A systematic literature review.’ 14th International Conference on Evaluation and Assessment in Software Engineering (EASE). Keele University, UK.  Retrieved November 15, 2013 from http://www.bcs.org/upload/pdf/ewic_ea10_session5paper3.pdf
14. What is scrum? (2013). Retrieved November 20, 2013, from https://www.scrum.org/Resources/What-is-Scrum
15. Scrum in regulated environment. (2013). Retrieved November 20, 2013, from  http://www.chemanager-online.com/en/topics/pharma-biotech-processing/scrum-regulated-environment
16. Scrum (2013). Retrieved November 20, 2013, from http increments://www.scrum.org/Resources/Scrum-Glossary
17. Swaner, K.; Sutherland, J. (2103) The Scrum Guide. Retrieved November 12, 2013, from https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf#zoom=100