Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Practices Proven in Highly Regulated Environments by Craig Langenfeld

5,351 views

Published on

Many organisations operatin in highly regulated environments, such as healthcare, have concluded that in order to achieve the next level of product quality and safety improvements, not to mention enhanced competitiveness, adoption of a more Agile approach is required. In this presentation, you will learn how the Agile software development approach for high assurance systems addresses many of the challenges found in many highly regulated enterprise environments.

Presented by Craig Langenfeld

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

Agile Practices Proven in Highly Regulated Environments by Craig Langenfeld

  1. 1. Agile Practices Proven in High Assurance and Highly Regulated Environments © 2011 Rally Software Development and Leffingwell, LLC.
  2. 2. Define high assurance? “High assurance software systems are unique because they must satisfy basic functional service properties that the system intends to deliver, as well as guarantee desirable system properties such as security, safety, timeliness, and reliability.” © 2011 Rally Software Development and Leffingwell, LLC. 2
  3. 3. © 2011 Rally Software Development and Leffingwell, LLC. 3
  4. 4. Regulating bodies… FDA – Federal Drug Administration ISO – International Standards European Union MEDDEV Drug Controller General of India – Central Drugs Standard Control Organisation (CDSCO – Medical Devices Division Health Canada Ourselves (CMMI) Global Harmonization Task Force – guidance docs IEC, although not a regulation is recognized as a good standard when developing such things as medical devices Software Development and Leffingwell, LLC. © 2011 Rally 4
  5. 5. © 2011 Rally Software Development and Leffingwell, LLC. 5
  6. 6. “Although the waterfall model is a useful tool for introducing design controls, its usefulness in practice is limited… for more complex devices, a concurrent engineering model is more representative of the design processes in use in the industry. “From [FDA CDRH 1997] Design Control Guidance for Medical Device Manufacturers © 2011 Rally Software Development and Leffingwell, LLC. 6
  7. 7. Surprise? FDA and IEC Guidance doesNOT recommend waterfall [FDA CDRH 2002] It is important to note, that neither this document, nor CFR820.30 itself, constrains development to single pass, stage-gated, waterfall activities. From General Principles of Software Validation….. [FDA CDRH 2002]: While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software life cycle. From [FDA CDRH 1997] Design Control Guidance for Medical Device Manufacturers : Although the waterfall model is a useful tool for introducing design controls, its usefulness in practice is limited… for more complex devices, a concurrent engineering model is more representative of the design processes in use in the industry. IEC 62304 medical device standard states: … these activities and tasks may overlap or interact and may be performed iteratively or recursively. It is not the intent to imply that a waterfall model should be used. © 2011 Rally Software Development and Leffingwell, LLC. 7
  8. 8. Industry myth perpetuated by our own waterfall past? © 2011 Rally Software Development and Leffingwell, LLC. 8
  9. 9. Software engineering & SDLC Lean / AgileCraig Langenfeld PMP, CSM Regulatedcraig@rallydev.com environment © 2011 Rally Software Development and Leffingwell, LLC. 9
  10. 10. Dean Leffingwell© 2011 Rally Software Development and Leffingwell, LLC. 10
  11. 11. Waterfall Story © 2011 Rally Software Development and Leffingwell, LLC. 11
  12. 12. © 2011 Rally Software Development and Leffingwell, LLC. 12
  13. 13. Where are we going? ➵ Agile Proven within High Assurance ➵ Healthcare Example ➵ How? ➵ Agile Framework for High Assurance ➵ High Assurance Requirements Model ➵ Artifact generation ➵ Updated Quality Management Systems © 2011 Rally Software Development and Leffingwell, LLC. 13
  14. 14. Agile is already in high assurance Abbott Laboratories – – 20 – 30 % fewer defects were found – availability of working software early on was a significant factor – “This experience has convinced us that an agile approach is the approach best suited to development of FDA-regulated devices.” GE Healthcare Goes Agile – Dr. Dobbs article 2010 – “we are making progress and feel that the benefits of our Agile adoption have been worth the effort. Because of this we are rolling out Agile globally within GE Healthcare” AFEI DoD Agile Development Conference – “Agile Methods are in widespread use by the U.S. DoD, Prior … the commercial industry and DoD contractors believed the U.S. DoD was not committed to Agile , an enormously incorrect assumption…”Sources: Abbott Labs whitepaper: http://www.computer.org/portal/web/csdl/doi/10.1109/AGILE.2009.50.AAMI report: See http://www.aami.org/applications/search/details.cfm?WebID=P1541_D6110DoD Association for Enterprise Information (AFEI): See http://www.afei.org/Pages/default.aspx.(See http://davidfrico.com/afei-2010.doc) © 2011 Rally Software Development and Leffingwell, LLC. 14
  15. 15. Whitepapers and other references Association for Advancement Medical Instrumentation – TIR - Guidance on the use of AGILE practices in the development of medical device software – “Since AGILE is a highly INCREMENTAL/EVOLUTIONARY approach, it can therefore be mistakenly assumed that AGILE is incompatible with the expectations for a medical device software process. “ Blogs… – Scott Ambler – Agile Scaling Model – Tom Grant – Forrester Analyst – Dean Leffingwell – Scaling Software Agility Blog © 2011 Rally Software Development and Leffingwell, LLC. 15
  16. 16. Agile gets results “We experienced a 20-50% increase in productivity.” − BMC Case Study Productivity“ makes the work moreenjoyable, helps us worktogether, and isempowering” 37-50% faster to − Medtronic market Quality − QSM research Time to Morale Market © 2011 Rally Software Development and Leffingwell, LLC. 16
  17. 17. Agile drives quality, safety, efficacy …fewer defects were found − Abbott Labs Collective Coding Ownership Standards Test-Driven Development Pair Automated Programming Testing Quality Simple Continuous Design Refactoring Integration User Stories… of 131 respondents, 88%said quality was better orsignificantly better Helps us find bugs earlier − Shine Technology Survey − Medtronic © 2011 Rally Software Development and Leffingwell, LLC. 17
  18. 18. AN AGILE, HIGH ASSURANCELIFECYCLE FRAMEWORK © 2011 Rally Software Development and Leffingwell, LLC. 18
  19. 19. But high assurance development has additionalrequirements Medical device exemplar: US FDA mandates Software Verification and Validation User Review Needs Design Input Design Process Design Verification Output Medical device Validation Source: FDA CDRH 1997 Design Control Guidance for Medical Device Manufacturers © 2011 Rally Software Development and Leffingwell, LLC.
  20. 20. So we have additional mandates Code of Federal Regulations CFR 21 Part 830, Subpart C Design Controls mandates device design verification and validation. Verification Validation Provides objective evidence that the Confirmation …… that software design outputs of a particular phase specifications conform to user needs of the software development life cycle and intended uses, and that the meet all of the specified requirements particular requirements implemented for that phase. through software can be consistently fulfilled….Since software is usually part of a larger hardware system, the validation … includes evidence that all software requirements have beenYou built it implemented correctly and completely right and are traceable to system requirements.Sources:Regulation: Code of Federal Regulations 21 Part 830, Subpart CDesign ControlsGuidance: General Principles of Software Validation You built © 2011 Rally Software Development and Leffingwell, LLC. the right 20
  21. 21. And Code of Federal Regulations CFR 21 Part 830, Subpart C Design Controls mandates a requirements specification. Requirements Specification Traceability A documented software requirements FDA guidelines describe traceability and a specification (SRS) provides a baseline for primary mechanism to assure that both validation and verification. The verification and validation are complete software validation process cannot be and consistent. completed without an established software Traceability. The degree to which a requirements specification relationship can be established between (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) two or more products of the development and (g process, especially products having a predecessor-successor or master- subordinate relationship to one another; e.g., the degree to which the requirements and design of a given software component match [IEEE]Sources:Regulation: Code of Federal Regulations 21 Part 830, Subpart CDesign ControlsGuidance: General Principles of Software Validation © 2011 Rally Software Development and Leffingwell, LLC. 21
  22. 22. ITERATION MECHANICS Daily Backlog StandupGrooming Iteration Define Iteration Planning Demo, Review & Build Retrospective VerifyProduct Iteration ProductBacklog Backlog Increment © 2011 Rally Software Development and Leffingwell, LLC.
  23. 23. PROJECTAGILE LIFECYCLE System IncrementPlanning, Analysis, Architecture, QM Design S Transfer Project Verification Verification Verification Validation Inception Iteration Iteration Iteration Iteration N Production Code Set up Project Infrastructure Verification and Validation activities and artifacts driven by QMS © 2011 Rally Software Development and Leffingwell, LLC.
  24. 24. High Assurance Scaled Agile Framework
  25. 25. The User Story Acceptance Definition of Criteria Done As a <role> I can <activity> So that <business value> As an EPAT (Extracorporeal Pulse Activation Technology) technician, (<role>) I can adjust the energy delivered (<what I do with the system>) in increments so as to deliver higher or lower energy pulses to the patient’s treatment area (<value the patient receives from my action>). © 2011 Rally Software Development and Leffingwell, LLC.
  26. 26. Traceability from User Story to Code andStory Acceptance Test Software Implemented by User Story Code Requirements 1 1..* Specification 1 1 Verified by Verified by 1..* 1..* Unit Test Story Acceptance Test © 2011 Rally Software Development and Leffingwell, LLC.
  27. 27. Validating Product Claims Product Requirements Pulse amplitude is adjustable Feature from 1-5 bar Document Traced to As an operator, I can adjust the pulse As an operator, I always amplitude in .1 bar increments so as to be see the current setting able to make small changes to change on the display in .1 bar energy delivered to patient area increments, so I can be confident I’m delivering the right energy Software Requirements As an operator, rotating the energy knob past Specification the point where the system is delivering 5 bar will have no further effect User User User Story Story Story © 2011 Rally Software Development and Leffingwell, LLC.
  28. 28. High Assurance Agile Backlog ModelSource: Leffingwell. Agile SoftwareRequirements: Lean Requirements Practicesfor Teams, Programs, and the Enterprise.Addison-Wesley 2011. © 2011 Rally Software Development and Leffingwell, LLC. © 2011 Leffingwell, LLC.
  29. 29. Validating Features and System Qualities © 2011 Rally Software Development and Leffingwell, LLC. 29
  30. 30. Agile and Quality Management Systems(QMS) Continuous improvement or (re-)write from scratch Establish cross-functionalQMSscrum team Run releases and sprints to refine / establish QMS Design Controls needs to provide flexibility Software Development Life Cycle (SDLC), Tools, etc. should be specified in the Design and Development Plan (DDP), not in the QMS © 2011 Rally Software Development and Leffingwell, LLC. 30
  31. 31. Validation Sprint Activities © 2011 Rally Software Development and Leffingwell, LLC. 31
  32. 32. Quality Management StrategyMatt AndersonDirector Program Management March 10, 2012
  33. 33. MethodQ/SLIM Overview Initial “Design Input” Signature Release Plan • Roadmap • User Stories/Capabilities (Epics) •Acceptance Criteria Tasks to update for each User Story Iterations • Solution Level Requirements • Design artifacts Final “Design Input” Signature • Solution Level Requirement Document(s) Final “Design Output” Signature Release •Asset design artifacts, code, traceability © 2011 Rally Software Development and Leffingwell, LLC.
  34. 34. Change Record Management Release CR Initial “Design Input” Signature • Roadmap Capability CR Final “Design Input” Signature •Current Solution Level Requirements Release CR Final “Design Output” Signature •Solution Level Test Scenarios • Test Evidence Release • Solution Level Technical Artifacts © 2011 Rally Software Development and Leffingwell, LLC.
  35. 35. Change Record Management Release CR Initial “Design Input” Signature •User Stories • Acceptance Criteria • Initial Visual Design Capability CR Final “Design Input” Signature •Updated Solution Level Requirements • Visual Design Final “Design Output” Signature • Test Scenarios • Test Evidence Release CR • Code/Code Review • Technical Artifacts as needed Release © 2011 Rally Software Development and Leffingwell, LLC.
  36. 36. Parent/Child Relationships Release CR Capability CR Capability CR Capability CR Capability CR Capability CR Capabilities cannot span releases, but can span iterations CR can be both a Child and a Parent Each CR must have completed Design Input and Output – Initial Design Input for Child can be covered by the Parent © 2011 Rally Software Development and Leffingwell, LLC.
  37. 37. Agile extremism does not help (working software over documentation)© 2011 Rally Software Development and Leffingwell, LLC. 37
  38. 38. Agile and most regulating bodies are notat odds © 2011 Rally Software Development and Leffingwell, LLC. 38
  39. 39. Satisfy compliance while preserving Agility.© 2011 Rally Software Development and Leffingwell, LLC.
  40. 40. Implement the appropriate degree of rigor © 2011 Rally Software Development and Leffingwell, LLC.
  41. 41. © 2011 Rally Software Development and Leffingwell, LLC. 41
  42. 42. Agile – Perfect for High Assurance “Agile isn’t just good for High Assurance development – it’s better than traditional methods.” - Tom Grant, Forrester Group © 2011 Rally Software Development and Leffingwell, LLC.
  43. 43. Live long and prosper! Craig Langenfeldcraig@rallydev.com cameo by Matt Anderson © 2011 Rally Software Development and Leffingwell, LLC. 43

×