Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Presenter: Tim Questions for audience How many of you have experience using agile? How many of you have experience working on medical devices? How many of you have experience using agile on medical device projects? Any audience members from the FDA? Brief AgileTek company overview Presenter: Rod Brief Abbott company overview
  • Presenter: Rod
  • Presenter: Rod Describe Architect and m2000 Describe software process used for both products Talk about evolution of agile at Abbott Talk about staffing and inherent inefficiencies in the process
  • Presenter: Rod - One strategy: use existing process with ruthlessly narrow scope. - Pick a few features and do them Aim for short scope 4 to six weeks - Better still do them independently and in parallel - Integrate - Rinse and Repeat - EMPHASIS: DON’T NEED ALL REQUIREMENTS UPFRONT - Stayed in feasibility for about ½ of m2000 project - Evolving artifacts
  • Presenter: Rod - Describe the 3 C’s in more detail
  • Presenter: Rod - Describe how work products were allocated to phases - Earlier iterations had more emphasis on characterization, planning, product definition - Indicate that artifacts map to regulatory requirements Question: Should we include an example of a regulatory requirement and how we satisfied it?
  • Presenter: John Build a matrix of artifacts Living documents Monitor progress at every iteration planning session Treat with same importance as code and test cases The final version of these documents will comprise most of the technical portion of your submission
  • Presenter: John - Lead off with the “concern that lesser documentation will not be acceptable with the FDA” - This terminology is pervasive in the FDA’s guidance documentation - Testing Tendency to write overly detailed tests One small change and poof all your tests are wrong and MUST be rerun (due to change) Be Less Prescriptive - KISS
  • Presenter: John - Risk Focus Not all risks are equal Emphasis on high risks and mitigations Impacts requirement details and testing effort - Focuses design on critical areas - Provides a basis for defining different levels of test and review - Increasingly emphasized by FDA and ISO/IEC - Integrates external standards compliance (IEC, UL, etc.)
  • Presenter: John - Plan on spending a disproportionate amount of time/detail on testing the requirements/features that are safety related (e.g. results calculation that impacts patient treatment) Minor: No injury or damage to health is possible (e.g. tongue depressor) Moderate: Non-serious injury is possible (e.g. clinical chemistry medical device) Major: Death or serious injury is possible (e.g. dialysis instrument) - PMA Guidance for the content of pre-market submissions for software contained in medical devices
  • Presenter: Rod - Requirements Be Less Prescriptive Detailed requirements will simply be wrong quicker.
  • Presenter: Rod Wedding analogy justice of the peace vs. formal big wedding
  • P resenter: Rod - Early Integration Find problems faster Process People Hardware Software (problems? Who me?) - Show me something working - Getting stakeholder feedback: “ What were you thinking???” Pre-market rules will encourage use of good internal proxies. - Tradeoff analysis extensibility maintainability quality
  • 1. Compliance Strategy: Map required documents to submission checklist
  • presentation

    1. 1. Moving to Agile in an FDA Environment An Experience Report August 27, 2009
    2. 2. Introduction <ul><li>Available for download at </li></ul><ul><li>Agile Resources </li></ul><ul><ul><li>Agile Manifesto </li></ul></ul><ul><ul><li>Agile Alliance </li></ul></ul><ul><li>Agile Books </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li>“ Agile Software Development” by Alistair Cockburn </li></ul></ul><ul><ul><li>“ Agile Project Management” by Jim Highsmith </li></ul></ul>
    3. 3. Outline <ul><li>The Abbott Experience </li></ul><ul><li>Lessons Learned </li></ul><ul><ul><li>The least burdensome approach? </li></ul></ul><ul><ul><li>A Risk Based Approach </li></ul></ul><ul><ul><li>Control what you don’t know, don’t let it control you </li></ul></ul><ul><ul><li>Dispense with ceremony </li></ul></ul><ul><li>Results </li></ul>
    4. 4. The Abbott Experience <ul><li>Comparing two FDA-regulated medical device projects </li></ul><ul><ul><li>One not agile, one agile </li></ul></ul><ul><ul><li>Class III devices (most stringent) </li></ul></ul><ul><ul><li>Results of agile adoption </li></ul></ul><ul><ul><ul><li>Lower cost </li></ul></ul></ul><ul><ul><ul><li>Shorter duration </li></ul></ul></ul><ul><ul><ul><li>Better, less prescriptive test cases </li></ul></ul></ul><ul><ul><ul><li>Accommodated change </li></ul></ul></ul><ul><ul><ul><li>Higher quality </li></ul></ul></ul><ul><li>See paper “Adopting Agile in an FDA Regulated Environment” </li></ul>
    5. 5. Moving to Agile <ul><li>Convincing Management </li></ul><ul><ul><li>Will vary widely depending on corporate culture </li></ul></ul><ul><ul><ul><li>Our experience: </li></ul></ul></ul><ul><ul><ul><ul><li>Hit targets </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Produce regulatory artifacts </li></ul></ul></ul></ul><ul><ul><li>Engage quality organization early </li></ul></ul><ul><ul><ul><li>Describe mapping of ‘agile’ artifacts to traditional artifacts </li></ul></ul></ul><ul><li>Test drive </li></ul><ul><ul><li>While still in Concept or Feasibility. </li></ul></ul><ul><ul><li>Late development or support probably NOT a good strategy for success. </li></ul></ul><ul><li>Change happens </li></ul><ul><ul><li>Get used to it </li></ul></ul><ul><ul><li>Deal with it </li></ul></ul><ul><ul><li>Get over it </li></ul></ul><ul><li>Plan for ‘face time’ </li></ul><ul><ul><li>Iteration planning minimum </li></ul></ul><ul><ul><li>Ideal is co-location </li></ul></ul><ul><ul><ul><li>Not always feasible </li></ul></ul></ul>
    6. 6. Software Development Lifecycle
    7. 7. Iteration Model
    8. 8. Sample Design Control Documents Courtesy of: Certified Compliance Solutions, Inc.
    9. 9. Lessons Learned
    10. 10. Least Burdensome <ul><li>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 . </li></ul><ul><li>--The Least Burdensome Provisions of the FDA Modernization Act of 1997: Concept and Principles; Final Guidance for FDA and Industry </li></ul>
    11. 11. A Risk Based Approach Courtesy of: Certified Compliance Solutions, Inc.
    12. 12. <ul><li>IEC 62304 section 5.1.1, page 31: </li></ul><ul><li>Note 1: The software model can identify different activities for different software items according to the safety classification </li></ul><ul><li>FDA General Principles of Software Validation, page 7, section 3.1.2: </li></ul><ul><li>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. </li></ul>Risk Based Approaches Courtesy of: Certified Compliance Solutions, Inc.
    13. 13. FDA Reviewer Guidance 2005 Courtesy of: Certified Compliance Solutions, Inc.
    14. 14. Control What You Don’t Know, Don’t Let It Control You <ul><li>What you do know: </li></ul><ul><ul><li>A typical medical device is developed over a 3-5 year time horizon </li></ul></ul><ul><ul><li>It is a myth that you can predict in detail your end product requirements up-front </li></ul></ul><ul><ul><li>Start with a core set of features that you must implement </li></ul></ul><ul><ul><li>Implement the core features first </li></ul></ul><ul><ul><li>Defer the most volatile features as long as possible </li></ul></ul><ul><li>Iterative approach allows the team to: </li></ul><ul><ul><li>Manage scope and limit feature creep </li></ul></ul><ul><ul><li>Negotiate scope and tradeoffs with key stakeholders </li></ul></ul><ul><li>“ 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.” </li></ul>
    15. 15. Dispense With Ceremony <ul><li>If it is not adding value, and it is not required, do not do it </li></ul><ul><li>The design history files should contain the minimum set of documentation that satisfies the regulatory requirements </li></ul><ul><li>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 </li></ul><ul><li>Avoid doing things because “that’s the way we’ve always done it” </li></ul><ul><li>If it feels like you are wasting your time you probably are </li></ul>
    16. 16. Results
    17. 17. Results <ul><li>High visibility </li></ul><ul><ul><li>Easier to manage and control </li></ul></ul><ul><ul><li>Far fewer surprises </li></ul></ul><ul><li>Lower cost and shorter duration </li></ul><ul><ul><li>Estimated schedule and team size reduction of 20%-30% </li></ul></ul><ul><ul><li>Estimated cost savings of 35%-50% </li></ul></ul><ul><li>Higher quality </li></ul><ul><ul><li>Availability of working software facilitated continuous testing instead of back loaded V&V </li></ul></ul><ul><ul><li>Resulted in fewer overall defects, especially at the end of the project </li></ul></ul><ul><li>Better work life balance and team morale </li></ul><ul><ul><li>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 </li></ul></ul>
    18. 18. Q & A
    19. 19. 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
    20. 20. Back-Up Slides
    21. 21. 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
    22. 22. Roadmap of Releases <ul><li>Every iteration should be deployable code </li></ul><ul><li>Most agile teams work within a roadmap of milestone releases </li></ul>A B C 1 D E F G H I 2 J K L M 3 N O P 4 5
    23. 23. Sample Submission Documents Courtesy of: Certified Compliance Solutions, Inc.