Sprint to the Finish - Agile methods such as Scrum are beginning to dominate in software development over the classical "waterfall" approaches, to which computer validation has been oriented. Basic features of agile methods, such as short internal and independent development cycles, are often viewed as contrary to or problematic for computer validation principles. Is the concern justified? An analysis of the basic features and potentials of the Scrum method with regard to computer validation sheds light on this question.

Basic Features of Scrum

The goal of Scrum is to respond fast and flexibly to changes in requirements during the project, without sacrificing quality, cost control, motivation or especially user needs. Instead of orientation upon high-level and extensive planning, as well as their documentation, there is a heavy emphasis upon interaction with the users during incremental practical and focused development cycles.

The basic principle of Scrum is to divide the development process into short development cycles, so-called sprints, which have pre-defined tasks to address pre-selected goals of the project. Sprints are limited to no more than 30 days, and the sprint team manages itself. A "Daily Scrum," lasting 15 minutes, is used to compare current results with the tasks and its difficulties or problems. At the closing of the sprint, the results are presented, which should be potentially deliverable.

Advantages over "Waterfall" Approaches

Disappointing practical experience with "waterfall" or top-down approaches is commonly raised as justification for agile development methods. "Waterfall" methods follow a basic principle of sequential, non-iterative development phases encompassing a software release, as displayed in the common V model of software development. Problematic characteristics of these approaches include the assumption that problems and goals can be thoroughly analyzed to yield detailed, documented development plans up front. Scrum circumvents many of the typical problems of these methods:

• Lack of Prioritization
With "waterfall" approaches, requirements generally all have the same or similar priorities, whereas priorities of tasks are reassigned with every sprint in Scrum. Lack of focus upon priorities often results in implementation of required functionalities relatively late in the project. If time and money become limited near the project closing, then important functions can suffer more from lack of resources than less important features.

• False Precision
All requirements are expected to be known at the beginning of a project so that accurate and detailed project estimates and plans can be made. This leads often to detailed and extensive product specifications, which are based upon unrealistic assumptions from lack of practical experience, and thereby deliver a false sense of precision. There is a danger of creating very detailed but outdated documentation. The same applies to tests, which can be based upon an outdated design and not reflect the actual risks. This is an especially critical concern for regulated products. Scrum does not start with the premise that all requirements are known.

• Inflexibility
Progression through sequential project phases is inflexible when responding to changes. This leads to situations where changes needed for new requirements, which are recognized during later project phases, are not implemented, and the product is already obsolete upon release. Another consequence of this inflexibility is that lessons learned during the project cannot be applied. By comparison, Scrum is via sprints inherently flexible for learning effects and changes.

Possible Reasons Against Using Scrum in Regulated Industries

It is commonly argued that using the Scrum method inhibits achieving the requirements for validation in regulated industries. This reasoning is analyzed in the following paragraphs.

• V Models are Needed for Validation
In GAMP 5, the industrial guideline increasingly relied upon as the standard for computer validation, the classical V model is no longer exclusively specified. Rather, according to GAMP 5, "it is now recognized that other models and approaches are equally acceptable." Risk-based approaches and economy are the focus of the new GAMP version, and agile models are not excluded. User requirements must no longer be finalized before functional and technical specifications are written (already a common practice).

• Complete Documentation
It is sometimes argued that Scrum does not require or need documentation. One of the ground rules of the Agile Manifesto, upon which Scrum is based, is that a complete product has priority over complete documentation. That doesn't imply that no documentation is needed.
Sprints should start with requirements, user roles and concrete uses, which are specified in the form of User Stories. It is expected with the Scrum method that a processed work package is included when closing a sprint. Complete processing is indicated by DoD ("Definition of Done"), which includes a detailed description. The method can be adapted to include documentation requirements for validation and their approval with the DoD. It should be recognized that the Scrum method can mitigate a typical problem with "waterfall" approaches: An uncontrolled accumulation of incomplete documentation is inhibited via short development cycles and their approvals.

• Extensive Test Documentation
Because requirements can frequently change during a Scrum development, a complete documentation of testing is a valid concern. Here, adaptation of the method to validation requirements needs consideration.

In the many sprint cycles to be expected, specification, implementation and testing activities are needed to meet good manufacturing practice (GMP) expectations. Of special importance are the acceptance tests for a cycle. Formally documented tests are demanding, and changes to requirements demand retesting. It is therefore important, especially for agile methods, to determine when the product design has achieved relative stability. At this point (and in later iterations), a sprint cycle should be conducted with the goal of obtaining formal test documentation and validation compliance. Such special sprints need to focus on formal aspects only. It has to be assured that the perspective of a formal test documentation later on is not used as an excuse for not substantially finishing, documenting and testing products at the end of each sprint.

Further Reasons for Using Scrum in Regulated Industries
Close contact between developers and users, as well as the emphasis upon refactoring, are further good arguments for using Scrum, also in regulated industries.

• Close Contact in Scrum
Agile requirements management anticipates direct user input for the formulation and prioritization of user requirements. The customer tries using the product at the end of a sprint cycle and can give feedback quickly. These trials can be interpreted as User Acceptance Tests, and ensure that the users are included at an early stage and obtain extensive knowledge of the product.

• Emphasis upon Refactoring
Refactoring is an important element of agile methods to improve software structure. Its aim is to improve readability, simplify code maintenance, and improve flexibility of program code without altering its function. Via refactoring it is possible to continually improve the quality, which is certainly central to the goals of computer validation.

Conclusions

Regulators do not prescribe specific validation methods. GAMP 5 accepts other methods besides the classical V model, a "waterfall" approach, to development. Agile software development methods, such as Scrum, are therefore not excluded from GMP. By the evaluation of the risks and opportunities with agile methods, it should be recognized that in reality, software development is not practiced optimally on either a technical, economical or regulatory basis.

Agile methods strive to achieve results and quality with the help of simple rules and less bureaucracy. They must be integrated into the Quality Management System when used in regulated industries. It is recommended to add special sprints for covering formal documentation requirements, without changing the basics. A combination of agile with conventional methods (hybrid models) can also be considered.

Scrum appears to be a relevant option for regulated industries. In several aspects its focus upon results, clarity and transparency correspond better with the basic goals of computer validation than conventional methods, as they are often practiced.