Adapting Agile Software Development to Regulated Industry. Paul Buckley Section 706 Section Event June 16, 2015

Transcription

1 Adapting Agile Software Development to Regulated Industry Paul Buckley Section 706 Section Event June 16, 2015

2 Agenda FDA s expectations for Software Development What is Agile development? Aligning Agile concepts to Medical Device Software Aligning Agile practices to Medical Device Software Challenges can you be an Agile development team but still be compliant? 2

3 Disclaimer I am not a software engineer, developer, or designer, (but portray one at ASQ events), hence this presentation will be more academic than practical. With that being said, there are many resources available on both Agile Software development and integrating Agile practices in regulated industry. I ll list some of these at the end of this presentation for those who would like to explore the topic further. 3

4 Medical Device Software Design FDA s Perspective The US Food & Drug Administration is charged with oversight on the manufacturing and distribution of all medical devices. What is a Medical Device? An instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is: intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes." 4

5 Medical Device Software Design FDA s Perspective Devices can be relatively simple, ranging from a simple tongue depressor, to incredibly complex, such as a implantable pacemaker or a robotic surgical system 5

6 Medical Device Software Design FDA s Perspective No matter what the device or product, the FDA s mission is to ensure public health and safety, by making sure that any device that it allows a manufacturer to market is: Safe and Effective This is accomplished by making sure that all manufacturers operate under the same set of rules the Quality System Regulation, or QSR. 6

7 Medical Device Software Design FDA s Perspective In the United States, the FDA is responsible for regulating medical device software, using a well-structured set of laws, regulations, and guidances. For Medical Devices in which software is a component of the device function, subpart C of the QSR requires that Design Controls be established for the device and it s associated software 7

8 Design Controls Control over product design is a requirement of the QSR and is intended to follow the life of the product, (including software), across the entire product lifecycle. In software design, controls start with identifying user requirements, developing your product to meet those requirements, coding, integration, verification testing, and deployment The QSR in general, and Design Controls in particular, do not define a development process or prescribe a specific development methodology or a specific software development lifecycle; rather, they specify controls that must be integrated into the manufacturer s development processes 8

9 Design Controls Although FDA requires design controls, they don t specify what type of Design Control process you follow as a manufacturer One method is the Waterfall model. In this method, each step in the process is linear with completion of one step before beginning the next For complex projects, this is a very risky approach, since requirements and functionality are liable to change over the course of development and what you end up with may differ dramatically from what you originally envisioned. 9

10 Waterfall development 10

11 Agile development 101 Agile as a software development process was first instituted in February, 2001 by a group of Developers who met to find an alternative to the documentation driven, heavyweight software development processes common at the time. Following a weekend of discussion at The Lodge at Snowbird Ski Resort in the Wasatch mountains of Utah, the Agile Manifesto was born. 11

12 Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work 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 That is, while there is value in the items on the right, we value the items on the left more. 12

13 Key Features of Agile 1. Evolutionary and incremental development with increments being as short as a week. 2. Define what DONE means and use that definition to get to DONE at each boundary of the INCREMENTAL life cycle. 3. Deliver customer value, with the highest priority features first, through close collaboration between the customer and the project team. 4. Accept that customer needs and requirements are likely to change, so accommodate this in an efficient and effective way. 5. Manage project risk through increased visibility of progress and stronger team accountability. 13

14 Key Features of Agile 6. Use self-organized teams empowered to manage the daily tasks of producing software. 7. Seek technical excellence in the software through high-quality designs and thorough VERIFICATION practices. 8. Reflect at regular intervals and adapt the process to constantly improve quality and efficiency of work. 9. Satisfy business stakeholders, both internal and external 14

15 Scrum One of the most common methods of Agile development is through the use of Scrum Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts within this framework Scrum uses fixed-length iterations, called Sprints, which are typically 1-2 weeks long (never more than 30 days). Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration. 15

16 Scrum Roles Product Owner - The single wringable neck Single person responsible for maximizing the return on investment (ROI) of the development effort Responsible for product vision Constantly re-prioritizes the Product Backlog, adjusting any long term expectations such as release plans Final arbiter of requirements questions Accepts or rejects each product increment Decides whether to ship Decides whether to continue development Considers stakeholder interests 16

17 Scrum Team Scrum Roles Cross functional team including testers, developers, business analysts, etc, that meet without externally assigned roles Negotiates commitments with Product Owner Intensely collaborative Most successful with long-term, full-time membership Typically 3-9 members 17

18 Scrum Roles ScrumMaster Facilitates the Scrum process Helps resolve impediments Creates an environment conducive to team selforganization Captures empirical data to adjust forecasts Shields the team from external interference and distractions to keep it in group flow (a.k.a. the zone) Promotes improved engineering practices Has no management authority over the team (anyone with authority over the team is by definition not its ScrumMaster) 18

19 Sprint Planning Meetings The timed iterations that the team uses to work on the work items assigned to them is called a Sprint. Sprints can range anywhere from a week to a month, but two weeks is common. At the start of a Sprint, the Product Owner and ScrumMaster meet in a Planning Meeting to determine which items from the Product Backlog the team will attempt to convert to working product during the Sprint 19

20 Sprint Planning Meetings II The Product Owner prioritizes the items he feels are most important to the business, but the team is responsible for agreement on the time required to complete these items. Until a team has learned how to complete a potentially-shippable product increment each Sprint, it should reduce the amount of functionality it commits to. Toward the end of the Sprint Planning Meeting, the team breaks the selected items into an initial list of Sprint Tasks, and makes a final commitment to do the work 20

21 Typical Scrum Meeting 21

22 Daily Scrum Meetings The Daily Meetings when team members update their progress and commitments to their Sprint tasks are called Scrum meetings 15 minutes in length, generally held at the same time and place. Progress is noted, work planned for that day and the next is reported to the group, and organization impediments that keep work from completion are brought to the attention of the ScrumMaster It is useful for Product Owners attend a team s Scrum, but there is a potential for stifling selforganization and emergent leadership. 22

23 Sprint Review Meeting Sprint Review Meetings Held at the end of a Sprint execution, Sprint Review Meetings are held to demonstrate a working product increment to the Product Owner and everyone else who is interested. Meeting includes a live demonstration of a shippable part of the product After the demonstration, the Product Owner reviews the commitments made at the Sprint Planning Meeting and declares which items he now considers done 23

24 Sprint Review Meeting The ScrumMaster helps the Product Owner and stakeholders convert their feedback to new Product Backlog Items for prioritization by the Product Owner. Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend. It is the opportunity to inspect and adapt the product as it emerges, and iteratively refine everyone s understanding of the requirements 24

25 Sprint Retrospective Meeting After each Sprint the team meets to discuss its process For meetings to be effective, ScrumMasters must take steps to take everyone s feedback into account for the improvement of the team. A common impediment to team improvement is creating solutions to perceived problems too quickly. Means of slowing this process down include, setting the stage, gathering data, generate insights, decide what to do, and close the retrospective 25

26 Backlog Refinement Meeting In the Backlog Refinement Meeting, the team considers effort needed to complete items in the Product Backlog and provides other technical information to help the Product Owner prioritize them Large vague items are split and clarified, considering both business and technical concerns It is common to write Product Backlog Items in User Story form. In this approach, oversized PBIs are called epics 26

27 Product Backlog example Force-ranked list of desired functionality Visible to all stakeholders Any stakeholder (including the Team) can add items Constantly re-prioritized by the Product Owner Items at top are more granular than items at bottom Maintained during the Backlog Refinement Meeting 27

28 Aligning Agile Concepts with Medical Device Software Development Agile methods have proven to be effective for software development; the challenge is how to show how these processes can comply with the regulatory requirements for medical devices. 28

29 Aligning Agile Concepts with Medical Device Software Development Regulatory agencies have a list of requirements linked to software design and Development, i.e. Design and development planning Design input Design output Design review Design verification Design validation 29

30 Aligning Agile Concepts with Medical Device Software Development These activities can be mapped out in a traditional Waterfall model, however, the FDA does not prescribe a specific software life cycle model!! 30

31 Aligning Agile Concepts with Medical Device Software Development We can overlay these documentation requirements over each of the iterative cycles so that the design process is documented over the course of the product lifecyle The main goals of both Agile development and Regulatory agencies is the design of high quality software, that satisfies user needs and requirements, and is safe for the user Agile teams would be wise to include regulatory stakeholders in their Agile development efforts, as well as customer and business ones. 31

32 Agile Design Control Mapping Here is an example of an Agile process mapped to the FDA s software design requirements Note the Safety Risk Analysis. It s essential that any medical device software development process provide added emphasis on assuring the correctness and completeness of all requirements identified as related to safety. 32

33 Agile s advantages Agile advantages over sequential models include: Applications that are more closely aligned with user needs Improve productivity because of the iterative development methods that focus on the completion of smaller more manageable work units Fewer defects because of continuous build and test processes Facilitates integration of changes because the process is iterative and flexible with respect to previous design decisions. 33

34 Agile s Advantages Agile is now recognized as a viable model for handling Software Life Cycle Development by the FDA. In January 2013, AAMI TIR45:2012 Guidance on the use of AGILE practices in the development of medical device software, was recognized as a consensus standard. Documentation requirements can be overlaid to the specific regulation for a clear picture of regulatory compliance, (see example of ANSI- AMI IEC Software Life Cycle Process, following): 34

35 35

36 In Conclusion Agile methods provide an iterative development process that offers advantages over sequential development models in that feedback on early releases can be integrated into development iterations resulting in applications that more closely map to user needs. Specifications and documentation required for design control compliance can be integrated into Agile processes 36

37 Additional emphasis must be placed on assuring the mitigation of potential safety risks for any medical device development model. Agile processes have demonstrated the ability to be more efficient in the development of software applications than sequential software development models 37

38 Questions? Below are some of the sources used for this presentation. All provide an excellent overview of Agile development methodology 1. AAMI TIR45: Guidance on the use of AGILE practices in the development of medical device software 2. Agile Methodology contains great training videos on Scrum, and Scrum Reference Card 3. Agile Software Development Streamlines FDA- Regulated Applications - Dan Oliver and Jeff Dere, Medical Electronics Design - April 11,