During the 1990′s the global business community was investing enormous sums of money on the automation of resources leveraging advancements in modern technology and systems software (Boom and Bust in Information Technology Investment), as well as supporting the consolidation of organizations via mergers as a means of gaining competitive advantages. Failure was commonplace and despite the subsequent increase in investments, firing of personnel, and executive leadership support, the business community continued to fall short in their efforts to produce innovative advantages.  Big stakes for the international economy were at hand, so something had to change.

In February 2001 software developers met at resort in Snowbird, Utah to discuss lightweight development methodologies as a potential alternative for traditional heavyweight waterfall methods, which several were beginning to suspect as a contributing factor for why so many project teams were failing to provide the continuous innovation objectives their business management teams were demanding. The group gathering in the Rocky Mountains of Utah understood that early lightweight development methods were born out of challenging requirement projects; from the Easel Corporation project that helped spawn the SCRUM methodology in 1993 to the Chrysler Comprehensive Compensation System (C3) project that was credited with creating the Extreme Programming methodology in 1996. As the group of software developers discussed these case studies and analyzed other similar lightweight methodologies such as the Rational United Process (RUP), Crystal Clear, Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development (DSDM), a common theme was emerging.

“We are uncovering better ways of developing software, through this we have come to value – Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan”.  They concluded their insightful meeting by publishing the Manifesto for Agile Software Development, as a means of helping others realize the potential benefits offered within emerging lightweight software development methodologies.

Early adopters of the Agile Manifesto Principles were enabling their organizations to systematically achieve both disciplined execution and continuous innovations.  One of the biggest advantages within this new approach was the principle of building projects around motivated individuals by providing them the environment, support, and trust they need to get the job done. Combined with regular face-to-face conversations about how they can become more effective, the best architecture, requirements and designs were emerging from the self-organizing teams as they adjusted their behaviors accordingly.

Over the past decade software development teams supporting consumer and business technology needs have realized innovative solutions from self-organizing, cross-functional teams of generalizing specialists.  Agile software development methods promote growth challenges for the generalist (one with one or more of the applicable technical specialties), as everyone on the team is asked to do what ever it requires to develop the solution even if it is outside of their previous technical area of experience or expertise.  Agile essentially creates new perspectives that can result in evolutionary architecture and adaptive planning as it also encourages rapid and flexible response to change.

In an April 2012 article Forbes Magazine made a case for how time and time again we see that when a bold new idea challenges an entire way of thinking of an international community, if the idea comes from an unexpected source, it can languish in obscurity even though it offers the solution to a problem that needs to be solved.  In the article, The Best-Kept Management Secret on the Planet:Agile, contributor Steve Denning indicates that something similar seems to happening in business management which for decades has struggled to solve a fundamental conundrum: how do you get disciplined execution along with continuous innovation?

A recent Wall Street Journal networking event in San Diego, CIO Hardwire to the Business, rated Agile software development as the fifth most important strategic priority to be successful in supporting their organization’s business objectives.  The CIO’s top 5 strategic priorities focused upon cross-functional integration, fiscal discipline, transparency, and developing innovative solutions that impact customer and client satisfaction – all of which can be found within the agile development methodologies.

A cursory glance at current business news indicates recent acceptance of the potential benefits Agile management could provide an organization in their efforts to increase productivity and customer satisfaction:

• Oracle Introduces New Releases of Oracle’s Agile Product Lifecycle Management (PLM) and Oracle’s Agile Product Lifecycle Management for Process
• HP Launches Agile Manager & Performance Anywhere as SaaS Offerings
• IBM Rational Solution for Medical Devices Demonstration
• Rally Software Advances Agile Portfolio Management Solution
• Introduction to Agile Methods for European Medical Product Software Development

Over the past two decades practitioners have validated that Agile software development methods support iterative functionality feature builds, turning specifications and design into tests that enforce clarity, thus revealing implied requirements. Plus demonstrated that traceability and quality is essentially embedded within the process, as compliance documentation can be continually revised and updated as the system evolves.

So why are very few within the medical device community aware of agile software development methods?

Almost two decades after the birth of Agile software development methods the U.S. Food and Drug Administration published the following in their January 15th Issue of Recognized Consensus Standards and K Software/Informatics Recognition #13-36: AAMI TIR45:2012, Guidance on the use of AGILE practices in the development of medical device software.  Affecting medical devices that contain software, accessories to medical devices that contain software, and “standalone software” that meets the definition of a medical device or accessory, as well as FDA 510(k), IDE, PMA, HDE, and Software Validation Processes.

So now that the FDA has acknowledged Agile, how do you leverage a dynamic development method within a traditional (linear) medical device industry process of regulatory review of requirements prior to development?  Fundamentally medical device innovators need to approach the application of Agile methods with the primary objective of the FDA regulatory process in mind, which is that they require complete traceability throughout the hardware and software (IEC 62304) to fulfill their product safety role and responsibilities.  This approach could be useful for medical device company’s with strategic opportunities to collaboratively develop solutions with partners and users for 510(k) submissions.

Specifically Agile methods may have potential benefits for improving user interfaces and thus adoption, as the medical device regulatory process is still very much a waterfall process.  At it’s core, the Agile method empowers the device users to self-organize cross-functional teams to ensure that their day to day job functions are considered within the applicational usage of the device.  This time-boxed opportunity within the Agile software method could enable medical device businesses to improve satisfaction and ultimately effectiveness, as any improvement in the application of procedures and treatments will increase efficacy.  And in the case of 510(k) submissions, there typically are medical device options already available within the marketplace.  The challenge is how do you foster a dynamic user interface approach and allow it to blossom, as you employ a traditional waterfall development process for the device hardware and mechanisms to reduce regulatory risk.

The art of applying Agile methodologies within medical device development is synchronizing the self-organized and cross-functional evolving software iterations within the hardware release and testing processes.  Continuous integration of software code should occur frequently, thus ensuring that all iterations are tested often and provide opportunities between commit and build to ensure developers can identify and correct errors.

Only time will tell if Agile development methodologies can provide the continuous innovation that today’s financial markets demand from business leaders within the medical device industry. The FDA still needs to provide further clarification regarding how 510(k) and PMA approvals will be handled when Agile software development methods are utilized as a means of increasing customer satisfaction from device users.  In the interim, early adopters may find the competitive advantage they seek.

About the author: Rod Cain is a practicing strategic marketing professional at RBC Medical Innovations, who previously helped support the development of profitable new market share for Samsung, Rodale, and Meredith.