Moving to Agile in an FDA Environment An Experience Report August 27, 2009
Available for download at http://agile2009.agilealliance.org/
Agile Manifesto http://www.agilemanifesto.org/
Agile Alliance http://www.agilealliance.org
“ Agile Software Development” by Alistair Cockburn
“ Agile Project Management” by Jim Highsmith
The Abbott Experience
The least burdensome approach?
A Risk Based Approach
Control what you don’t know, don’t let it control you
Dispense with ceremony
The Abbott Experience
Comparing two FDA-regulated medical device projects
One not agile, one agile
Class III devices (most stringent)
Results of agile adoption
Better, less prescriptive test cases
See paper “Adopting Agile in an FDA Regulated Environment”
Moving to Agile
Will vary widely depending on corporate culture
Produce regulatory artifacts
Engage quality organization early
Describe mapping of ‘agile’ artifacts to traditional artifacts
While still in Concept or Feasibility.
Late development or support probably NOT a good strategy for success.
Get used to it
Deal with it
Get over it
Plan for ‘face time’
Iteration planning minimum
Ideal is co-location
Not always feasible
Software Development Lifecycle
Sample Design Control Documents Courtesy of: Certified Compliance Solutions, Inc.
We [FDA] are defining the term “least burdensome” as a successful means of addressing a premarket issue that involves the most appropriate investment of time, effort, and resources on the part of industry and FDA .
--The Least Burdensome Provisions of the FDA Modernization Act of 1997: Concept and Principles; Final Guidance for FDA and Industry
A Risk Based Approach Courtesy of: Certified Compliance Solutions, Inc.
IEC 62304 section 5.1.1, page 31:
Note 1: The software model can identify different activities for different software items according to the safety classification
FDA General Principles of Software Validation, page 7, section 3.1.2:
The level of confidence, and therefore the level of software validation, verification, and testing effort needed, will vary depending on the safety risk (hazard) posed by the automated functions of the device.
Risk Based Approaches Courtesy of: Certified Compliance Solutions, Inc.
FDA Reviewer Guidance 2005 Courtesy of: Certified Compliance Solutions, Inc.
Control What You Don’t Know, Don’t Let It Control You
What you do know:
A typical medical device is developed over a 3-5 year time horizon
It is a myth that you can predict in detail your end product requirements up-front
Start with a core set of features that you must implement
Implement the core features first
Defer the most volatile features as long as possible
Iterative approach allows the team to:
Manage scope and limit feature creep
Negotiate scope and tradeoffs with key stakeholders
“ At time of commercial launch, a number of features, once thought to be essential, were not included. Some were deferred as long as three years. Nonetheless, the product was considered highly successful and trading off nice to have features for three years of sales is an easy choice.”
Dispense With Ceremony
If it is not adding value, and it is not required, do not do it
The design history files should contain the minimum set of documentation that satisfies the regulatory requirements
There will be other activities that you will want to document, no need to include in design history file, make sure they add value and do it in a least burdensome way
Avoid doing things because “that’s the way we’ve always done it”
If it feels like you are wasting your time you probably are
Easier to manage and control
Far fewer surprises
Lower cost and shorter duration
Estimated schedule and team size reduction of 20%-30%
Estimated cost savings of 35%-50%
Availability of working software facilitated continuous testing instead of back loaded V&V
Resulted in fewer overall defects, especially at the end of the project
Better work life balance and team morale
Project death marches are rarer because the issues are surfaced as you go and are managed accordingly, not all saved up for the end of the project
Q & A
Tim Hughes J.R. Jenks Managing Partner Managing Partner [email_address] [email_address] 847-699-2260 847-699-2250 Thank You John Skach Senior Technology Architect [email_address] 847-699-2264 Rod Rasmussen Director, Informatics & Software Systems [email_address] 847-938-3633
Release Planning Product Feature Backlog Iteration 1 Iteration 2 Iteration 4 Iteration 3 Iteration 5 Speculating Process Iteration 0 Task Task Task Release Plan Iterations: 1 to 6 Weeks
Roadmap of Releases
Every iteration should be deployable code
Most agile teams work within a roadmap of milestone releases
A B C 1 D E F G H I 2 J K L M 3 N O P 4 5
Sample Submission Documents Courtesy of: Certified Compliance Solutions, Inc.