In Agile Development in Regulated Environments — Part 1: Yes, it can work, I covered the common misconceptions about Agile Software Development — specifically in highly-regulated industries like medical device. The common myth that regulators would not accept Agile practices has been disproved, with a number of industry and regulatory organizations such as the AAMI (Association for the Advancement of Medical Instrumentation) and the SEI (Software Engineering Institute) publishing guidance on how Agile values and practices can provide the necessary rigor and coverage to be fully compliant with regulatory standards.
When implemented properly, an Agile Software Development approach can:
- Improve quality by ensuring each increment of functionality is properly implemented and fully verified
- Allow organizations to be more responsive to change
- Reduce time-to-market through rigorous prioritization of backlog items and strict control on the amount of work in progress
- Reduce risk through early and continuous system integration and testing, and tight feedback loops that iterative and incremental development approaches provide
- Increase predictability and transparency of the state of releases based on tighter feedback loops and frequent short term planning cycles
Of course, the caveat is “when implemented properly“. The rest of my article will provide a number of recommendations to help you achieve a proper implementation.
Transitioning to “generic” Agile values and practices can be hard, and doing so while maintaining regulatory compliance is even more of a challenge. Luckily, a number of organizations have published guidance on how to do this, and/or case studies on the experiences of others who have gone through such transitions. The Software Engineering Institute at CMU has produced a number of reports and technical papers showing how Agile and CMMI can be complementary to one another, such as “CMMI or Agile: Why Not Embrace Both!“. Authors such as Dean Leffingwell (Scaling Software Agility) and Scott Ambler (Disciplined Agile Delivery) have published books on scaling Agile to address enterprise concerns and the challenges of more regulated environments.
The Information Technology for European Advancement programme (ITEA) ran an AGILE project from 2004 to 2006, whose mandate was to investigate the applicability of the Agile approach to embedded software development and safety critical development. That project produced a number of useful reports, including a mapping of Agile practices to the ISO 12207 software lifecycle standard. The Medical Device software lifecycle standard, IEC 62304, was based on ISO 12207 to a large extent. More recently, the AAMI released Technical Information Report 45:2012, “Guidance on the use of AGILE practices in the development of medical device software“.
Let’s focus on the medical device industry. The TIR45 report is 74 pages, and contains 87 highlighted recommendations and observations without going in depth into the regulatory standards for medical device software development. The report also doesn’t begin to go into the details about the Agile Software Development approach, its values and principles, or the various specific implementations of Agile. If your organization has little or no experience with implementing Agile Software Development, the learning curve can be significant; plan on investing in training and coaching to assist with the transition. Your Agile coaches should be familiar and experienced with developing software within a regulatory compliance environment, conversant with quality management systems and risk management in an Agile context.
Each organization is unique, and depending on the business drivers behind the desire to implement Agile approaches, your organization may want to gradually transition to Agile, or may be forced to implement it aggressively. Having participated in Agile transitions at three different organizations — as well as advising customers who were going through their transitions –I found that “gradual” is less risky than taking a “big bang” approach.
At one company, we were very successful by setting up a pilot project which used the Agile approach from the beginning. Once that project had delivered, we then used the experienced people from that project to “seed” Agile teams across the development organization of the company. We gradually converted over the other active projects to using Agile methodologies. The pilot project not only allowed us to develop in-house expertise that would persist when the Agile trainers and coaches left, it provided a very visible example of the benefits that could be achieved by changing our software development processes.
Another way to reduce the risk of culture shock and disruption is to selectively implement certain practices and supporting infrastructure before moving to a full-scale Agile adoption. For example, a key principle behind the Agile approach is to provide timely feedback and enable regular communication across the team. Implementing technical practices such as continuous integration — even if still following a plan-driven software development methodology — can provide immediate benefits by reducing the time required to provide feedback to developers on what they have implemented. Continuous integration is also the necessary prerequisite to reducing the risk of system integration and test. When we can build and smoke test candidate baselines with a reasonable turnaround time, the feedback that comes from that makes early system integration a viable activity. If a complete build and associated regression test takes weeks, then it isn’t feasible to do many iterations of system integration.
With the Agile approach’s emphasis on having each team own all aspects of the software development, an interim step may be to rework your software development infrastructure to implement Application Lifecycle Management, rather than the more siloed approach of Waterfall organizations. Even if all the roles are not encompassed within a single team, having a tool like PTC Integrity helps automate traceability management; and visibility to all development artifacts is available to all team members, improving communication and productivity. Once the walls between disciplines are broken down, the transition to small teams that are cross-functional is less disruptive.
When implementing Agile approaches within a Medical Device company, take the time to map the values and practices to the appropriate standards; IEC 62304 for the software development lifecycle, ISO 13485 for quality management systems, and ISO 14971 for risk management. For example, in a non-regulated environment, backlog grooming and story definition would likely not involve any explicit, formal risk assessment and mitigation. Within a Medical Device software development organization, these activities need to be incorporated into the Agile practices.
As well as implementing Agile practices within the context of your existing Quality Management System and risk management processes, you need to document the Agile processes and practices and train the development organization on their proper use. This software development plan documentation must address how requirements and traceability will be managed, how verification will be achieved (i.e. what reviews and testing will be performed, at what levels within the Agile methodology), how oversight and planning will be performed, and how documentation will be produced.
Remember, the standards do not dictate a particular software lifecycle implementation, nor do they dictate the format for documentation. Instead, they identify the processes and activities that must be performed, and what the documentation must cover. As long as your Agile practices and the associated work products they produce are properly documented in your software development plan — with a mapping or some other clear evidence that they cover the regulatory requirements of the standards — you should have no issue with regulatory personnel.
When implementing an Agile approach to Medical Device software development, it is important the teams understand that the regulators are stakeholders; that their needs are as important as the end customers. By proactively demonstrating that regulatory needs are being addressed by the Agile processes and practices — and by maintaining open channels of communication between regulatory authorities and the development teams — there should be no challenges or push back from those stakeholders.
Given the need to demonstrate traceability of all work products back to the product requirements, and the iterative and incremental nature of Agile development, it is essential that the development organization have robust software configuration management systems and a streamlined, responsive change management process. To aid in the automation of traceability management, systems of record should be electronic rather than hard copy. In the long run, it is easier to demonstrate the consistency between reports that are published for consumption by external parties such as CDRH auditors and the electronic systems of record than it is to manually maintain unstructured documents and their associated traceability matrices.
There are many more recommendations and issues that I could discuss, but this article has covered some of the most pertinent aspects of implementing Agile within a Medical Device software development environment. These recommendations are applicable for other regulated environments, such as aerospace, where DO-178B/C is the relevant standard instead of IEC 632304, or automotive, where ISO 26262 is the relevant standard. When bringing in software engineering consultants or trainers to assist with your organization’s transition, ensure they understand your industry as well as the principles and practices of Agile Software Development.
Next Steps:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
Colin Doyle
Systems Process Architect
SPK and Associates
