Some software product development teams still believe that Agile methods are not compatible with the requirements of regulated industries, while others are already making the most out of Agility. Among those industry sectors where audit compliance is a must, certain companies are reluctant to embrace agile approaches, wondering if their product would actually be standard-compliant.
Are Agile and Compliance non-compatible concepts?
Here are the first main objections we still hear about whether applying Agility to regulated industries is relevant:
“Agility doesn’t rely on a paper-based system, so it can’t comply with regulatory requirements for which documentation is crucial.”
“The flexible and iterative approach of agile methods doesn’t meet the rigor level needed for validation and requirements management.”
“Agile methods focus on delivering the greatest value to customers, whereas regulated environments focus on safety assurance first.”
To be honest, agile methods don’t seem to be compatible with regulated software development at first glance. However, if many teams have started to use them – also for embedded software development in standardized industries – that’s because there are some undeniable good reasons. Software components are perfectly validated, deliverables have high-quality standards, auditors approve agile methods’ conformity and customers are satisfied. A virtuous circle actually. How is this possible?
As we also explained in another article, Agile and Compliant is both achievable and valuable. You can definitely pass regulatory audits while developing in agile. And there’s more: agility is a lever that makes compliance easier. In fact, agility helps create and ensure continuos conformity by emphasizing the importance of managing tests from the very early stages of any development; each development milestone prove regulatory requirements compliance. Agile methods allow for an easier, less risky, incremental validation.
The misunderstanding concerning the documentation comes from the fact that agility eliminates the use of documentation. It is true that agility promotes an operational software rather than complete documentation, but it also definitely recognizes the need of having documentation required for any specific activity such as for validation, tests execution or even for risk management.
You can hence develop using agile methods and generate only the documentation required by the customers and the regulatory standards, without creating any additional, unnecessary documents. For instance, documentation can be part of both the requirements criteria and the Definition of Done for every User Story.
Agile approches ensure deliveries’ adaptation to the regulatory deadlines that were either unclear or unknown when the project started.
“Process” compliance vs “Product” compliance
Standards such as those related to the Quality Management System (ISO 13485), the IEC62304 for the medical device sector or even the quality reference models like Automotive SPICE, are there to clarify and set the objectives to be met throughout the software development lifecycle via the deployment of a certain number of activities. In other words, they represent a framework enabling different organizations to monitor and assess whether their system complies with the norms. Contrarily to what is usually thought, all these regulations and standards concerning “processes” do not impose the implementation of any specific method (whereas compliance standards concerning your products leave no room for interpretation and must be strictly applied).
The difference between a compliant and a non-compliant process is not due to “WHAT” but rather “HOW”, so to the way of doing things. That’s generally where differences may be observed. Being compliant hence means proving that the implemented methods and practices within the entreprise ensure that everything is under control, that there’s a well-defined management of quality and continuous improvement and that the delivered product meet the requirements. Ultimately, methods and tools to organize and implement all the activities are not pointed out by these process standards.
As far as the management of project, requirements and quality is concerned, your teams can choose their favorite development method: Waterfall, V-model, agile approaches such as Scrum, Kanban, Scaled Agile Framework, or even opt for a hybrid methodology.
Auditors, developers… hybrid approaches work for everyone
Certain regulatory norms (such as the ISO26262 standard and Automotive SPICE) clearly consider documentation to be at the very heart of compliance. This because, in order to be compliant, you have to prove using appropriate processes, document them as well as monitor any artifact change throughout the entire development lifecycle, while ensuring 100% traceability and permissions management.
In this case, we have noticed that our customers have opted for hybrid approaches – a combination of Waterfall and good agile practices – as to satisfy auditors requirements while leveraging the benefits of Agile.
An Application Lifecycle Management (ALM) solution like Tuleap can make it easier by aligning teams, creating bi-directional links among any requirements, tests, agile artifacts and even documents. Processes and workflow can be set in advance, from the very beginning, and also push team members to provide proofs that will ultimately ease processes during compliance audits.
And it does work. Here’s what our customers say:
Tuleap makes it possible to manage quality assurance and requirements simultaneously. During audits, it’s easier to provide evidences that what we have delivered to customers complies with requirements.
Quality Manager -Embedded Software
As a company that works with PHI, we needed a platform that was either HIPAA-compliant.
Portfolio Manager- Healthcare
Tuleap has become our number-one tool for our ASPICE evaluations.
Quality Assurance Engineer- Automotive
Tuleap brings greater security, efficiency, and trust to our audit-related processes for ISO 13485 compliance
Software Manager- Healthcare
And yes, the MedTech officially approves Agile approaches
Let’s now focus on agility for medical device software development. Given the hesitation of software development teams within the medical industry, the Association for the Advancement of Medical Instrumentation (AAMI) has taken a closer look at the topic. It’s important to consider that medical device manufacturers have to comply with highly-demanding and ever-evolving standard requirements; which definitely makes developers hesitate whether to change their collaboration tools and methods or, as some of them prefer, to stick with the traditional V-model.
As to try resolving this debate, the AAMI has published a technical information report for it, which is therefore an FDA-recognized consensus standard now: the “AAMI TIR45: Guidance on the use of AGILE practices in the development of medical device software”. The purpose was to show how agile methods can actually be compatible with regulatory requirements that the MedTech industry has to meet, notably for the development of medical device software (also known as SaMD – Software as a Medical Device).
In a nutshell, this guidance highlights the following aspects:
- The more teams mature in terms of Agility, the clearer it becomes that agility is not at odds with regulatory requirements for medical device software developments.
- The FDA has officially approved agile methods as a relevant, valid approach.
More broadly, auditors now agree on the fact that agility is appropriate for medical device development.
In the end…
Despite the reluctance of embedded software development teams to go for it, field experience shows that you can definitely work more agilely even in highly-regulated industries. This is something that would actually be valuable since it makes it possible to achieve continuous compliance, keeping at hand all the necessary documentation for audit purposes. And in such transitional phases, hybrid methods have proven their effectiveness too.