1

Being Agile while Still Being Compliant: A Practical Approach

Jordi Manzano, Software QA Manager and R&D Deputy Manager, Diagnostic Grifols, S.A.

Dr. Keith Collyer, Senior Solution Manager, Electronics and Medical Devices Industry Solutions, IBM

Copyright © 2013 by IBM UK Ltd. and Diagnostic Grifols, S.A. Published and used by INCOSE UK Ltd and INCOSE with permission.

2

•Grifols:

– Plasma derivatives, in vitro diagnostic products and pharmaceutical products.

– €2,600M total turnover (40% US, 40% EU, 20% ROW).

– €130M diagnostic division turnover.

3

IBM Rational Solution for Medical Device Development

Based on Rational’s proven solutions for

systems & software engineering

• Meet regulatory compliance with enhanced

automation and reporting to simplify audits,

reputation loss, lawsuits and company collapse

• Manage product complexity by integrate

requirements and quality management

• Reduce time-to-market and cost by early defect

detection and removal

IBM Rational Solution for Medical Devices extends the core Rational solution with

integrated products, practices and guidance for:

Product compliance:

Medical device development specific processes (e.g. IEC 62304)

Traceability in medical device development

Design Control and Intended Use Validation

Evidence of regulatory compliance

Incremental migration to Agile work practices

IBM Rational Solution

for Systems and Software Engineering

Open Lifecycle Integration

Best Practices and Services

Architecture, Design and

Development

Quality Requirements

Planning, Change/ Configuration Management

Visualize, Analyze, and

Organize

4

Topics:

•Regulatory principles, activities and deliverables.

•Waterfall development – Agile development.

•Agile vs Regulatory principles: where they reinforce each other, where they (seem) to

collide.

•Making both worlds work together: conflicts and trade-offs.

•Grifols’ agile cycle.

•Where tools can help – use of DOORS to handle incremental compliant

developments.

5

Regulatory principles, activities and deliverables

•Established processes with planned activities as a means for ensuring safe and

effective software.

•Availability of objective evidence that the process was followed for a certain product

(documents).

•Descriptive over prescriptive approaches: more flexibility for compliance but tougher

audits.

6

Overview of IEC 62304

Source: European Medical Device & Technology, June 2010

• Quality management system

• RISK MANAGEMENT

• Software safety classification

• Software development PROCESS

– Software development planning

– Software requirements analysis

– Software ARCHITECTURAL design

– Software detailed design

– SOFTWARE UNIT implementation and verification

– Software integration and integration testing

– SOFTWARE SYSTEM testing

– Software release

• Software maintenance PROCESS

• Software RISK MANAGEMENT PROCESS

• Software configuration management PROCESS

• Software problem resolution PROCESS

• Documentation Requirements

Gap Analysis

6

7

Waterfall development – the “traditional” approach

•Works well in contractual environments

•Developers have “complete” knowledge

•In practice, teams always iterate

User

Requirements

System

Requirements

Architectural

Design

Component

Development

Integration &

Verification

Installation &

Validation

8

Agile development – Example: Scrum

•Recognizes that requirements will change

•Needs significant discipline to use – it is not hacking!

9

V-model

•Often interpreted as an extended waterfall.

•Better interpreted as showing time-independent relationships between artifacts.

•Consistent with both waterfall and agile.

User

Requirements

System

Requirements

Architectural

Design

Component

Development Components

Assemblies

Completed

System

Operational

Capability

Component

Tests

Integration

Tests

System

Tests

Acceptance

Tests

10

Agile vs Regulatory principles: where they reinforce each other, where they

(seem) to collide

•Skilled people with means to work well together just makes a

robust process even more robust.

•Teams continuously ask themselves how processes are working.

Established processes “Individuals and interactions

over processes and tools”

11

Agile vs Regulatory principles: where they reinforce each other, where they

(seem) to collide

Objective evidence “Working software over

comprehensive documentation”

•Shouldn’t working software equal safe and effective software?

•Agile principles help challenge documents that do not add value.

12

Agile vs Regulatory principles: where they reinforce each other, where they

(seem) to collide

Design inputs “Customer collaboration over

contract negotiation”

•Continuous customer involvement ensures that the intended use

and user needs are successfully translated into a set of design

inputs.

13

Agile vs Regulatory principles: where they reinforce each other, where they

(seem) to collide

Planning “Responding to change over

following a plan”

•Agile puts tremendous emphasis on planning.

•Regulators expect plans to be updated as development evolves.

14

Making both worlds work together: conflicts and trade-offs

Conflicts Trade-offs

Design Inputs Design Outputs

Design Inputs

Design Outputs

•Guidance from AAMI TIR 45 on applying agile in the development of medical device software.

15

Develop documents incrementally

•Regulators need to see documents

– How to create these in an agile environment

•The V-model gives the clue

– Populate the artifacts as material is developed

– End up with complete documents that can be audited

– TIR 45 gives directions:

• No need to finish a document before moving on

• At the end that all documents must be finals and synchronized

16

Grifols’ agile cycle

17

Sprint 0

•Plan field and internal releases

(synchronization with hardware).

•SRS: Comprehensive, not complete.

•Architectural & environment main decisions.

•Formal approval.

18

Releases

•Planning – building – hardening.

•Off - sprint tasks:

– Backlog “grooming”.

– Formal test procedures.

19

Sprints

•Definition of done (Story):

– SRS complete (DOORS).

– SDS complete (DOORS).

– Test design complete (DOORS)

– Coding rules & UT/IT passed (Jenkins).

– No relevant defects unresolved.

20

Intermediate hardening sprints

•If release longer than 3-4 sprints.

•Need to take stock to and prevent accumulation

of regulatory and/or technical debt.

•Synchronization of design inputs (e.g. SRS

document) with design outputs and formal sign -

offs.

21

Final hardening sprint(s)

•Complete all regulatory tasks.

•Ensure no unacceptable unresolved defects

remain.

22

Synchronizing agile software development and hardware development

•Issues:

– Agile develops in time-boxed sprints

– Hardware developers need to know timing of other teams

•Grifols approach:

– Planning intermediate software releases that are linked to hardware milestones – Hardening sprint also prevents accumulation of regulatory or technical debt

– synchronization of design inputs (e.g. req document) with design outputs and sign offs

23

Where tools can help – use of DOORS to handle incremental compliant

developments

•DOORS is being used in Grifols to handle:

– Risk management.

– Software requirements.

– Architectural design.

– Detailed design.

– List of source files that implement the detailed design.

– System test procedures, records and summary reports.

– Traceability information between all the above.

•Information is created incrementally.

•At synchronization points (hardening sprints), modules are baselined and exported

into documents that are introduced in the validated document management system for

formal review and approval.

24

Summary:

•There are certainly challenges using Agile in regulated environments.

•Regulatory and Agile principles reinforce themselves in some areas, but there are

conflicts that need trade-offs to be solved.

•AAMI TIR 45 gives important directions on the medical devices field on how these

trade-offs can be made acceptable from a regulatory standpoint.

•It’s important to map regulated activities into the actual Agile cycle that is followed:

– This map should be formalized in a procedure.

– When regulatory submissions / audits take place, this map will help auditors understand

how regulatory requirements are met throughout the (Agile) development cycle.

•Tools like DOORS are essential to support the development cycle and be able to

build the formal documents that are needed to show compliance with regulations.