agility and compliance (andrea tomasini, agile42)

agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2009.

Agility and ComplianceThe What and the How problem...


Andrea Tomasini

Agile Coach & [email protected]

mailto:[email protected]



Andy Carmichael

Andrea's company is called agile42 and if you think about it the name has some logic to it - "agile" is the undisputed answer to all the major questions of software engineering (mmm...?) in the same way that 42 is the answer to that only slightly larger chestnut: life, the universe and everything...


Why Agility?


Growing Software Complexity

Software complexity in FORD vehicles quadruplicated in 5 years

0

2.5

5

7.5

10

2005 2006 2007 2008 2009 2010

10

6

4.5

3.42.8

2.4

Software lines in FORD vehicles over the past 5 years

x4


Growing Software Complexity

Compared software complexity growth in aerospace and automotive

F-22 Raptor

F-35 Joint Strike

Boeing 787 Dreamliner

S-Class Daimler 98.6

6.5

5.7

1.7

x10


Time to MarketDue to globalization effects, and other economical changes, the time to market over time decreased significantly

Deepa Chandrasekaran, Gerard J. Tellis - Marshall School of Business, University of Southern California, Los Angeles, California

1915 1939 1972 1976 1983 1994 1998 2000 2002 2004

13.5 years

3 months


Why does this matter?Defined Process Control vs. Empirical Process Control


Change from this...Defined Process, suited to produce faster


... to this.Empirical Process, suited for R&D


Why Compliance?


compliance |kəmˈplīəns| (also compliancy |-ˈplīənsē|)noun1 the action or fact of complying with a wish or command : they must secure each other's cooperation or compliance.

• ( compliance with) the state or fact of according with or meeting rules or standards : all imports of timber are in compliance with regulations.


What are the reason to require Compliance?

Compliance is about guaranteeing that a product reaching the market will satisfy the rules that regulate that market...

Compliance is about adhering to a set of rules considered vital to preserve human life safe


Don’t get lost in the jungle...

EN ISO

13485:2003

Quality

Management

ISO 14971Risk Management

ISO 60601-1-4

Programmable electrical

medical devices

ISO 62304Medical Device Software Lifecycle

EN 62366:2007Usability

ISO 62304 closely guides / determinesdevelopment of medical software


Recipe for IEC/EN 62304

Based on 60601-1-4 and AAMI 68

Defines minimal levels for process Activities

Aligned with FDA terminology and expectations

Allows the manufacturer to chose the best process, techniques and tools


5.8 Software Release

5.7 Software System Testing

5.6 Software Integration & int. testing

5.5 Software Unit impl. & verification

5.4 Software Detailed Design

5.3 Software Architectural

Design

6.2 Problems and

Modification analysis

Overview of IEC/EN 62304

6.1Establish SW

Maintenance Plan

6.3 Software Modification Implementation

7 Software Risk Management

8 Software Configuration Management

9 Software Problem Resolution


The WHAT & HOW problem...


€

Comparing the Goals

Patient SafetyEffectivenessGovernance throughout product lifecycle

123456

ProductivityPredictability/Sustainability

Business ValueQuality

DIN 62304Agile/Scrum

Mainly Measure the effects

of the Product usage

Approved!


This standard does NOT prescribe a specific life-cycle model. The users of this standard are responsible for selecting a life-cycle model for the software project and for mapping the PROCESSES, ACTIVITIES, and TASKS in this standard onto that model

Compliance is Model independent...

This standard provides a framework of life-cycle PROCESSES with ACTIVITIES and TASKS necessary for the safe design and maintenance of MEDICAL DEVICE SOFTWARE. This standard provides requirements for each life-cycle PROCESS. Each life-cycle PROCESS is further divided into a set of ACTIVITIES, with each ACTIVITY further divided into a set of TASKS.

Or not?

Confusing?


Working Software over Comprehensive Documentation

Documentation is minimized and evolves in process

Test

Epics

User Stories

Design Code

Validate/Update

Dialog/Agreement

Agile/Scrum DIN 62304

Design

Requirements Specifications

Code

Test Design

Requirements specifications drive the implementation

Test Execution

Define/Execute

Verify/Approve

We can do it!

€


Standard Operating Procedures vs. Continuous Process Improvement

The purpose of standards is

1.to make it possible to any

one to do the job

2.to reduce variations

3.Standards are written by

process groups / QM

4.Written standards are to

be followed, not changed

A standard defines goals for a team to reach, and constraints to observe.

An Agile Team will use that as a Baseline for continuous process improvement

DIN 62304 Agile/Scrum

We can do it!

€


Document Driven vs. Consensus Driven

“This document is now approved as input for the next development phase”

“This document is now part of a consistent product increment”

“The Definition of Done and Definition of Ready, allow to set minimal requirements to measure fitness to the next phase”

DIN 62304 Agile/Scrum

We can do it!

€


What do we VALUE more?


...You have to update the 5.1, 5.2, 5.3 and 5.4

section of the SOP...

...yes and I have to complete the feature, write

unit-tests, check the Acceptance Criteria

and review the code...

While we agree there is value on the item(s) on the left, we value the items on the right more


so what?


Conclusions

• Agile is mainstream, enterprises need to adopt it, is growing

• We can implement agile in a Compliance Regulated environment, but won’t come for free

• The Goal of Compliance is to guarantee that we can product better Software that won’t harm humans

• Continue to challenge the status quo, push for having a WHAT to achieve and leave the HOW to achieve it to yourself!


Questions? & Answers!

For any further comment and or question, feel free to contact us [email protected]

Further References:

Scrum Alliance: http://www.scrumalliance.orgControl Chaos: http://www.controlchaos.com

Implementing Scrum: http://www.implementingscrum.comJeff Sutherland Blog: http://jeffsutherland.com/scrum

Mike Cohn “User Stories”: http://www.mountaingoatsoftware.comagile42 Website: http://www.agile42.com/



http://www.scrumalliance.org

http://www.scrumalliance.org

http://www.controlchaos.com

http://www.controlchaos.com

http://www.implementingscrum.com

http://www.implementingscrum.com

http://jeffsutherland.com/scrum

http://jeffsutherland.com/scrum

http://www.mountaingoatsoftware.com

http://www.mountaingoatsoftware.com

http://agilealliance.org

http://agilealliance.org