At the Bits&Chips Software Engineering conference Jan van Moll, senior manager quality & regulatory management at Philips Healthcare, talked about application of agile practices in domains that are regulated by laws and standards, like the medical device industry, automotive and avionics.
InfoQ interviewed van Moll about regulatory demands for software in healthcare, satisfying these demands with waterfall project or with a mix of waterfall and agile, and introducing agile in an R&D organization that needs to fulfill regulatory demands.
InfoQ: Can you mention some of the main regulatory demands that need to be considered when developing software for health care products or systems?
Van Moll: Any medical device shall be safe and effective. Basically, the same requirements apply to software contained in medical devices, or even standalone software that is used for medical purposes. Medical device manufacturers operate in an industry heavily regulated by laws and standards. These require them to provide sufficient evidence that a Quality Management System (QMS) was employed when developing their medical devices. Medical device manufacturers wishing to sell their products on the international markets need market approval and hence must follow various regulations that for example ensure proper design and development control.
Moreover, regulatory bodies require manufacturers to provide documentation which provides information on areas such as risk management and to maintain traceability between the requirements stage and the development stages of a development project. Development life cycles used shall cover medical device software from its birth to retirement and shall also explicitly support software validation and verification.
InfoQ: What is the "traditional" approach that is mostly used for satisfying these demands in waterfall projects?
Van Moll: It is generally acknowledged that medical device regulatory requirements recommend software should be developed in accordance with a plan-driven software development lifecycle such as the Waterfall Model or the V-Model. Whilst no specific software development lifecycle is mandated by the regulations or standards medical device software developers typically develop software in accordance with the V-Model.
By following the V-Model the necessary deliverables are produced that are required in order to achieve regulatory approval. The need for clear and adequate documentation describing the design history of the software is crucial and is one of the main forms of "evidence" during a regulatory inspection of having applied sufficient control over the development of the software.
InfoQ: Is it possible to comply with the V-model while using an agile approach?
Van Moll: The V-model is most often considered a plan-driven model. For Agile the V-model is typically used as the "container" to hold the Agile practices in. So yes, the V-model is capable of meeting regulatory requirements while holding Agile practices embedded in it.
InfoQ: Can you elaborate how you can meet regulatory demands when applying agile software development?
Van Moll: Regulatory requirements do not mandate the usage of any particular software development lifecycle. In recent years regulatory bodies started acknowledging that following a plan-driven software development lifecycle is not always feasible and that agile practices can be used in compliance with regulatory standards without jeopardizing the process of achieving regulatory approval.
Frequently heard statements in regulatory scrutiny are "Say what you will do, show what you did" and "Not documented is not done". This may sound contradicting to the fact that the agile manifesto puts greater value in people rather than processes and documentation. Also in agile software development, the existence of and formality around technical and design reviews (if held) is perceived not to be to the same extent as in a typical plan-driven software development process. Additionally, some agile principles suggest that individuals work together daily and project information should be shared through informal, face-to-face conversation rather than through documentation.
Therefore, most medical device manufacturers are using a kind of "mixed-mode" SW life cycle where they integrate agile practices in an "overall" traditional lifecycle. This ensures for example that overall aspects of software development like risk management and traceability are performed while projects still can benefit from the effectiveness and speed that the agile practices can bring.
InfoQ: How can such a mix of agile and traditional software development look?
Van Moll: Such a mixed-model lifecycle can take the form of a V-model lifecycle where the Agile practices are explicitly allocated to the various stages of the V. Examples include user stories mapped onto Requirements Development stages or Sprints in the Construction and verification of individual modules/components at the lower stages of the V. These stages are then typically iterating but in the end eventually followed by a single Software System Integration and Software System Verification stage.
InfoQ: Are there any agile techniques that are being used successfully to meet regulatory demands? Do you have examples how they are used at Philips Healthcare?
Van Moll: Many practices encountered in agile methodologies are suitable for integration with more traditional approaches. Typical successful examples include sprint backlogs, task boards, burn down charts, standup meetings, continuous integration, TDD, pair programming and user stories. Also SW development in Philips is using these practices partly or to the full extent, depending on the maturity of the internal development entities.
The practices are locally used at various stages of an overall development lifecycle for embedded and control software, but also at software for user interfaces aiming to deliver a workable software object at every increment.
InfoQ: Are their specific things to be aware of when introducing agile in an R&D organization that needs to fulfill regulatory demands?
Van Moll: The biggest challenge when implementing Agile in a regulated environment is to manage expectations of all stakeholders involved. This specifically holds true for aligning the perception on, and mutual expectation of both development teams and quality assurance staff. Agile shall never be a "blank cheque" for development teams to only speed up development at the cost of producing the required documents and conducting the associated formal reviews.
The working relationship between quality staff and developers needs to be mature enough to allow both parties to learn from each other and to be open for corrections or adaptations to the overall way of working, as the agile practices mature.
What most people tend to forget, is that Agile is also a process in itself that (when properly defined and followed) is of great benefit to regulated development projects. Therefore the Agile methodology needs to be documented and consolidated into the local quality management system and consistently applied and controlled via the project management plans.
InfoQ: If people want to know more about applying agile and meeting regulatory demands, are there any resources that you can recommend?
Van Moll: The amount of information on experiences with Agile in regulated environments is still limited despite the widespread experience nowadays with Agile in other branches of industry. However, a valuable reference source of information is the AAMI TIR45:2012 titled "Guidance on the use of AGILE practices in the development of medical device software". This document "links" the Agile principles to the expectations and requirements as set by the regulators.