There is no doubt that agile is an accepted development methodology. However, if you work in a regulated industry like health care where you have to comply with its standard operating procedures, heaps of paperwork, and frequent audits, don’t these conflict with agile’s core tenets? Chris Ampenberger describes his operating environment and the applicable regulations that define the constraints for the software development process he can use. He shares how they overcame the incongruity between agile and regulatory requirements. With real-world examples, Chris demonstrates how you can produce the required documentation as a byproduct of the scrum team’s everyday work and illustrates how his teams succeeded in an agile way, achieving significant increases in productivity. Chris points out common pitfalls, details the hurdles they had to overcome, and discusses how to obtain buy-in from stakeholders at all levels of the organization. If you are working in a regulated environment, this session is for you.

1.
AT3
Session
6/6/2013 10:15 AM
"Agile Development in a
Regulated Environment"
Presented by:
Chris Ampenberger
PHT Corporation
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

2. Chris Ampenberger
PHT Corporation
Chris Ampenberger is a development manager at PHT Corporation, the leading provider of
innovative systems used to collect patient-driven eData for clinical research. Chris manages
three agile development teams which maintain PHT’s back-end systems that receive and
process all acquired data. He has several years of experience managing software development
teams in a number of industries. Chris started practicing agile seven years ago and managed its
complete implementations in two companies. He has brought PHT’s Scrum implementation to a
new level by: shortening sprints; measuring team and stakeholder satisfaction; and focusing on
automating unit tests, functional testing, and release documentation.

3. Agile Development
in a Regulated
Environment
Chris Ampenberger,
Directory Engineer, PHT
y g
,
June 2013
Trust your Patient-Driven eData with PHT
Discussion Topics
1
Background
2
Say what you do and do as you say!
3
Audit Readiness is a Deliverable
4
Practice, practice, practice
5
Contact Info
2

4. Background
• About Me
― Chris Ampenberger
― ~27 years in IT
― Working with Agile/Scrum since 2006
― Since 2011 with PHT Corporation
• About PHT
― Develops trials to capture patient reported outcomes (ePRO) through mobile
devices
― Class 1 medical device manufacturer
― Over 540 trials in 14 therapeutic areas
p
― >70,000 mobile devices
― Fulfillment in 68 countries, supporting 97 languages
3
Say what you do and do as you say!
4

5. US Regulations & Guidance
• 21CFR Part11 Electronic Records and Electronic Signatures Rule (Mar
1997)
• FDA Guidance for Industry: General Principles of Software Validation (Jan
2002)
• FDA Guidance for Industry: Computerized Systems Used in Clinical
Investigations (May 2007)
• FDA Guidance for Industry: Patient-Reported Outcome Measures: Use in
Medical Product Development to Support Labeling Claims (Dec 2009)
• FDA Guidance for Industry: Electronic Source Documentation in Clinical
Investigations (Dec 2010)
• 21CFR880 Medical Devices; Medical Device Data Systems (Feb 2011)
• FDA Guidance for Industry: Mobile Medical Applications (DRAFT Jul
2011)
5
European Regulations & Guidance
• DIRECTIVE 1999/93/EC … on a Community framework for
electronic signatures (Dec 1999)
• Reflection paper on expectations for electronic source data and
data transcribed to electronic data collection tools in clinical trials
(Feb 2011)
• Annex 11: Computerized Systems (June 2011)
• Reflection paper on the Use of Interactive Response Technologies
(Interactive Voice/Web Response Systems) in Clinical Trials
(DRAFT Aug 2011
6

6. Regulatory Environment
• General distrust of electronic systems
• Regulators lag far behind technology
• US: Field inspectors are not always familiar with software
• EU: EC’s and GCP Inspectors may include one or more
software experts on the team
7
Consequences:
Our processes and standard operating procedures used to look like the following:
Plan
=
Execute
Deliver
D li
8

7. Process Evolution
Now they look more like the following:
Execute
Deliver
Plan
Adjust
Analyze
― Documented in a framework of
policies, standard operating
procedures,
procedures work instructions etc
― The framework undergoes periodic
reviews to stay up to date
― Execution is documented in a
paper trail that accompanies every
release.
http://en.wikipedia.org/wiki/File:Scrum_process.svg
9
Then & Now
Product Requirements Specification
► Epics & User Stories
Software Requirements Specification
► User Stories
Software Design Specification
► Functional Specification Task & Wiki
1.5 year release cycle
► 6 month
Varying length phases
► 2 week sprints
Phases for requirements, design etc
► Weekly grooming
10

8. Audit Readiness is a Deliverable
• Christmas every year is not a surprise, neither are Audits!
• Plan for it:
― Break it down
▸ Every story, every bug
▸ Every sprint
▸ Every release
― Enforce it
▸ Mini audits
▸ Checklists
▸ “Nagging” scripts
11
Invest in Automation
― Use an electronic system to support your SDLC that produces an
audit trail and offers an API
― For every piece you have to produce, ask your self:
▸ Is it necessary?
▸ What is the minimum I have to produce?
▸ When is the earliest I can get it done and when is it due?
▸ How can I automate it?
12

9. Do it the Agile Way
― Start small!
― Pick highest value target first
▸ For example patch paper trail
▸ StudyWorks 4.16.0.2: 7 documents, 2 weeks, 240 person hours
▸ StudyWorks 4.16.0.4: 1 document, 2 days, 32 person hours
― Audit Trail automation and process improvements become part of
the backlog
▸ Scrum the Scrum
― Learn from audits and incorporate it in the backlog
13
Where we are today
• We use
―
Rally
―
―
―
―
▸ User Stories, Defects, Tasks
▸ Test Cases, Test Results, Test Sets
AccuRev with the GitCentric
Jenkins
J ki
Robot Test Framework
Skytap cloud
• From that we generate
― Validation Plan
― Test Plan
― Build Plan
― Product Requirements Report
― Functional Specifications
Report
― Traceability Matrix
― Unit Test Report
― Code Review Report
― Test Case Results Report
― Test Case Results Review
Report
― Defect Summary
14

10. Example: Patch Audit Trail
• We needed a report for patches that showed that we follow our
procedures
• It needs to contain:
― Plan date
― Planned release date
― Actual release date
― Defects to be fixed
― Plan for defect validation
― Plan for regression testing
― Documentation of unit testing
― Documentation of code reviews
― Test results
15
Example: Patch Audit Trail
• Plan date -> Release.CreationDate
• Planned release date ->Release.ReleaseDate
• Actual release date -> Release.RevisionHistory[].Date
16

11. Example: Patch Audit Trail
• Defects to be fixed -> Defects per iteration
• Plan for defect validation -> Owner of Tasks with prefix [SQE-EXE]
17
Example: Patch Audit Trail
• Plan for regression testing
• -> TestSets per release or iteration
• -> TestCases per TestSet
TestSet
18

12. Example: Patch Audit Trail
• Documentation of unit testing
• -> Task with prefix [DEV-UT] per defect or story
• -> Owner is engineeer
• -> Description contains result of test, or name of automated test
• -> Test results from Jenkins
19
Example: Patch Audit Trail
• Documentation of code reviews
• - > Record of promotions in AccuRev from the review stream to the integration
stream
• -> Contains list of changed files & timestamp
• -> Notes with names of member participating in the code review
20

13. Example: Patch Audit Trail
• Test results
• -> TestSets per release or iteration
• -> most recent TestCaseResult per TestSet with build belonging to release
TestSet
21
Practice, Practice, Practice
•
•
•
•
Manager audits scrum team
Have another group audit your group: Development audits Quality
Quality Management & Compliance
External consultant
22

14. A Word of Caution
• Safety is paramount
• Second is the value of the overall product to the customer
• Nobody buys your product because you have perfect paperwork
product,
and processes
• Sometimes that means to set boundaries
23
Take Away
• Main Point
― Audit Readiness is a deliverable that needs to be integrated in every
step of the scrum process
• Key Ideas
― Invest in automation
― Start Small
― Scrum the scrum and continuously improve your process
― Practice
24