The value system and practices that embody Agile Software Development have been around for well over a decade, and have been touted as having “crossed the chasm” by organizations such as the Agile Alliance, Gartner, and Forrester Research. Numerous studies indicate that — when implemented properly — it can result in higher quality, shorter time to market, and better visibility into the development status than traditional software development approaches. Despite that, many organizations that develop products for highly regulated industries, such as Medical Devices, Aerospace or Automotive, claim that Agile “does not work” within their industries.
The common objections are that:
- The regulatory bodies will not accept Agile-based software development practices as being rigorous enough to comply with their regulations.
- The need for a requirements-driven development lifecycle and extensive documentation of both the software development activities and the processes used to develop that software conflict with Agile principles.
- “Waterfall” or plan-driven approaches to software development are entrenched in such organizations and moving to Agile approaches will be too disruptive to succeed
Adrian Barnes of ResMed, a Medical Device manufacturer, provides an example of that first point: he states “A brave man would try to convince the FDA that Agile is OK“. This claim that the “regulators won’t accept Agile” is probably the most common objection, and arises from a misguided perception that Agile eschews documentation and process. This perception likely comes from the fact that the Agile Manifesto (the original basis for Agile principles) was deliberately written in a provocative manner.
The first of the four values stated within the Agile Manifesto is “Individuals and interactions over processes and tools”. This has often been interpreted as meaning Agile is against process-centric development, and anti-tool.
The second value statement is “Working software over comprehensive documentation”, which can be misinterpreted as “don’t document”. The follow-on statement to those values, however, is key to interpreting the value statements appropriately: “while there is value in the items on the right, we value the items on the left more”.
The proper interpretation of the first value statement is that processes and tools should support and aid effective product development teams, rather than developers contorting themselves to conform to tool limitations or blindly implementing process for the sake of process. The second value statement should be interpreted as “keep your eye on the end goal: delivering value to the customer”. The intent of that second value statement is first to avoid creating unnecessary documentation, or over-documenting things, and secondly to focus on retiring risk as soon as possible, by delivering working software iteratively and incrementally.
The problem of poorly documented software activities, particularly software requirements, is a well known and long standing one — poorly defined requirements (both due to obfuscating over documentation, as well as inadequate documentation) is cited as the primary reason for software project failure in the annual Standish Group’s CHAOS Reports. Research performed at Simula Labs in Norway has shown that irrelevant or misleading information will result in larger-than-necessary estimates of project effort, and based on Parkinson’s law, such estimates will be self-fulfilling.
In recent years, much thought and investigation has been focused on the topic of Agile requirements engineering, with publications from experts such as Dean Leffingwell and Karl Wiegers identifying techniques and practices that combine the benefits of Agile approaches with the traditional requirements engineering discipline to produce better requirements that support iterative and incremental development approaches.
The net of this is that the regulators have been listening, and are aware of the potential benefits of Agile. Within the aerospace and defense industry, organizations such as the Software Engineering Institute have been working to show that formal, rigorous, process-centric approaches such as the CMMI can be complementary, rather than adversarial, to Agile approaches.
The publication CrossTalk, The Journal of Defense Software Engineering, has for many years published case studies of Agile implementations within defense projects and research on how to adapt Agile practices for large scale, highly regulated environments. In fact, their May/June issue was devoted entirely to the topic of large-scale Agile. The fiscal 2010 National Defense Authorization Act even went so far as to mandate that new defense acquisition programs implement the key practices of Agile.
The Medical Device industry has also seen the light; at the end of 2012, the Association for the Advancement of Medical Instrumentation (AAMI) released Technical Information Report 45 “Guidance on the use of AGILE practices in the development of medical device software“. This report concludes that Agile practices can be applied to develop medical device software, and can be done so in such a way that it complies with the regulatory framework. In fact, it goes so far as to provide a mapping between Agile terminology and practices and the activities called out by the IEC 62304 standard.
The TIR45 report also acknowledges that Agile practices can bring value to medical device software. Among the business advantages that Agile practices can provide are:
- Improved risk management through early and continuous system integration and testing, and the tight feedback loops that iterative and incremental development approaches provide
- Better visibility into the status of the software development, and improved predictability of software releases
- Improved quality of the software through rigorous definition of done, the better understanding of the user needs through collaborative development and improved feedback from rapid iterations, and an emphasis on regular, ideally continuous, review and testing
- Productivity gains through rigorous prioritization of backlog items, more effective response to changes in requirements, and strict control on the amount of work in progress reducing the potential for wasted effort
The report also identifies that there are challenges to implementing Agile in a manner that is compliant with the regulatory framework. The main recommendations for addressing these challenges are to apply the values of Agile to enhance your quality management system, and to apply the Agile practices within the context of that established quality management system. Given that FDA requirements for the QMS already mandate an active and ongoing hazard assessment and risk management program, and one of the strengths of the Agile value system is the focus on early identification of risk, the two frameworks are already fairly well aligned — if your organization truly understands and commits to the values of the Agile approach.
Agile values and practices are relatively simple concepts that can be hard to implement effectively. To truly gain the productivity benefits touted by Agile advocates, organizations need to automate as much as possible within their software development lifecycle (SDLC), and to invest in training and ongoing support to educate the development teams on the new practices and how they will benefit from them.
Part two of this blog will go into some of the key processes and practices that need to be addressed in order to implement Agile practices effectively within a medical device regulatory environment.
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.
