Agile Engineering in Safety and Medical Technology: A Contradiction?

Requirements are strict in safety and medical engineering. Is it possible to apply both the
V Model and the SCRUM method to this field?

Andreas Schlaffer, Head of R&D at Kontron Austria, explains the pros and cons of both approaches and shows how a combination of the two methods can be used to successfully implement projects.

The V Model originated in the field of military engineering. First published in its original version in 1988, the model has undergone a continual evolution since that time. For decades, this tried and proven method has been state of the art, even though it demands very rigid procedures, planning, development and testing. It remains the go-to approach and recommended procedural model e.g. for the following norms:

·       IEC 60601-1 General requirements for basic safety of medical devices

·       IEC 62301 Medical device software

·       IEC 61508 Functional safety

·       IEC 13849 Safety of machinery

·       VDI 2206 Directive

A characteristic of the model is that it divides project workflows into separate, detailed phases. The process begins with an analysis of the general system requirements, followed by a definition of the functional and non-functional requirements in terms of system architecture. System design then addresses components and interfaces and finally moves on to engineering and implementation. Quality assurance aspects include unit testing, integration testing and system integration as well as commissioning and validation. But one should consider what happens when a team stubbornly adheres to a plan: In the end, it will achieve only what was planned and not necessarily what was in fact needed.

The SCRUM engineering model was formulated in February 2001 as an agile manifesto based on four guiding principles. In the four bullet points below, the first-named aspects are rated more highly than traditional considerations. (Source: Manifesto for Agile Software Development agilemanifesto.org)

·       Individuals and interactions are more than processes and tools 

·       Working software is more than just comprehensive documentation

·       Customer collaboration is more than contract negotiation

·       Responding to change is more than following a plan

The SCRUM model approach is empirical, incremental and iterative. It is based on the premise that many engineering models are too complex to be collated into a single comprehensive plan. At first, the model leaves the approach to the solution unclear. It relies on interim results to eliminate these uncertainties, because using these results to resolve requirements definition and solution strategies is more efficient than doing so via an abstract clarification phase. Rather than a detailed list of technical and performance specifications, the model formulates a vision – aimed at engineering a high-quality product quickly and at low cost. The model has only a few hard and fast rules: short communication paths, high flexibility thanks to adaptive planning, high transparency thanks to regular meetings, and rapid realization of new product features and increments. However, a lack of overview of the overall course of the entire project and the scarcity of concrete recommendations for action can be seen as a disadvantage.    

What typifies requirements on processes in the safety and medical field?

Activities must be planned before a project can move ahead. The degree of planning detail depends on the specific safety considerations, the design input depends on the design output. Safety and medical engineering must adhere strictly to change management methodology, i.e. documentation is mandatory. Because various regulations have to be observed, the recommendations of the V Model must often be applied as well.

Applying the V Model and SCRUM to implementation

How can one combine the advantages of the two engineering approaches? As indicated by its name, the XT version of the V Model permits ready adaptation (XT = extreme tailoring); this model should therefore serve as a foundation.

SCRUM is now introduced as a special project management methodology beneath the V Model XT umbrella. The requirements and specifications of the V Model are equivalent to the SCRUM product backlog which contains information that becomes ever more detailed as the project progresses.

Applying the SCRUM method to the V Model’s different levels of system development is usually not a contradiction. Short iterations of equivalent length can certainly be implemented in this way. The agile approach can be applied to any phase of the V Model, e.g. to system architecture, validation, integration testing, hardware design, etc. Iterations in hardware and mechanical engineering must be viewed more critically because these often require somewhat longer sprints, and one should always be careful to keep them from becoming too long. Task descriptions such as documentation, review, test report and additional criteria are included as decision-making factors for the SCRUM status definition of “done”.

What does experience with the interaction of the two models show?

Integrating the SCRUM approach with the V Model is not easy, but certainly possible. It should be viewed as a learning process that will require a series of iterations. Particular challenges may be encountered in aspects such as mind change, new approaches to planning, discipline regarding the “definition of done”, as well as staff acceptance of the new way of doing things. Collaboration tools can be a great help in implementing projects that use both models. We have achieved good results with the tools JIRA and Confluence.

In summary, we believe the following aspects are particularly important during the implementation phase:

·       convincing and supporting the team during the implementation phase

·       maintaining discipline regarding the “definition of done”

·       maintaining control regarding the “definition of done”

·       using suitable tools for implementation and documentation support

·       making the transition to the SCRUM approach an agile project in itself

Summary:  We believe that merging the two models is a worthwhile effort. However, it should be noted that the combined approach will remain an agile one that needs to be reviewed frequently with regard to possible adaptation and optimization.