Lean agile feb2017-patca_a_joseph_ss

Accelera'ng Medical Device Development
with Lean and Agile Methods
Presented to PATCA - February 9, 2017

Aaron Joseph
Medical Devices Consultant
Consensia, Inc. - hDp://consensiainc.com/zipquality/

What’s the Problem?
• Design ﬂaws discovered late in development leading to
expensive delays
• Schedule overruns with soRware development
• Compliance problems with design controls
• High manufacturing costs
• Product recalls
Lean and agile methods can address all of these problems but incorporaVng them into the highly
regulated medical device industry presents mulVple challenges
PATCA - 2/9/17 Copyright 2016-2017 Aaron Joseph ConsulVng 2

Outline
1.  The Story of 2 projects (comparing lean-agile approach to
tradiVonal)
2.  Agile SW methods adapted to medical device soRware
3.  AdapVng lean-agile methods to regulated industry
4.  AdapVng quality system procedures to support lean-agile methods
5.  ConsideraVons for DHF documentaVon and SW tools
6.  Summary and Q&A

Balancing 3 Customers
Medical
Device
Development
Product Users
(clinicians &
paVents)
Manufacturing
Regulators
(FDA, etc.)

The Story: Real-life (hypotheVcal) Comparison
Walter’s Team
•  Tradi.onal (waterfall) approach
Grace’s Team
•  Lean-Agile approach NEW!
•  Company wants to develop a next
generaVon infusion pump
•  Key product pillars: smaller, lighter,
easier to use
•  Aggressive schedule: 24 months to
launch; 16 months to submission
•  Two teams:

Lean: methods to maximize value and minimize waste
Value-Added
Total Work Performed
Type I Waste
(necessary)
Type II Waste
(unnecessary)
Value-Added
Type I Waste
(necessary)
ELIMINATE!
Knowledge Management
Agile: methods for rapid learning and communica'on
(highly itera've)
Both Lean and Agile are based on

The Knowledge Timeline
Don’t force team to make key
decisions early based on
incomplete knowledge
Knowlege
Product Launch
Product Development Timeline
What happens to the knowledge a0er product launch?
Concept Planning Pre-Produc.on Produc.on Development Veriﬁca.on

Knowledge-Driven Product Development
•  Successful new product development demands deep
knowledge of:
1.  Product applicaVon
2.  Product technology
3.  Manufacturing process technology
•  For Medical Devices:
4.  Regulatory Approval (approval process and key
concerns of regulators)
5.  Compliance (requirements of all applicable
regulaVons and standards)
Medical Devices: understand
the clinical environment and
the needs of clinicians

Expensive design and process changes (loopbacks) caused by late learning
Concept
Phase
Feasibility
Phase
Development
Phase
Valida.on
Phase
Produc.on
Phase
IdenVfy a few
product
concepts
Select one
concept
Perform detailed design; build
prototypes and test
Pilot mfg;
Clinical tesVng
ProducVon in
volume
Learn about problems with design of
product and manufacturing processes
$$$$ $$ $
Problems with Tradi'onal (waterfall) Approach
GATE
GATE
GATE
GATE

Comparison: A Story of 2 Projects
A real-life example of (hypotheVcal) product development project

The Story: Real-life (hypotheVcal) Comparison
Walter’s Team
•  Experienced project lead
•  Fully resourced cross-funcVonal team (ME, EE,
SW, clinical, UX, Mfg, Quality, Purchasing,
Regulatory, etc.)
Grace’s Team
•  Experienced project lead
•  Fully resourced cross-funcVonal team (ME, EE,
SW, clinical, UX, Mfg, Quality, Purchasing,
Regulatory, etc.)
•  Advanced Research Dept.:
•  designed a new pump mechanism that is
more precise and lower power than
exisVng technology
•  IdenVﬁed new baNery technology
(smaller, faster charging)
•  Launch in 2 years

Product Development Phases
3
Veriﬁca.on
4
Pre-Produc.on
5
Produc.on
0
Concept
510k submission
Product Launch
Project begins at Planning Phase with the
following key inputs:
•  Product intended use and user needs
•  Business case including MarkeVng, Legal,
Regulatory, Financial, and Technological
consideraVons
•  Product Concept
GATE
GATE
1
Planning
2
Development
GATE
GATE
-Product
development
planning,
-Hazard Analysis,
-Requirements &
architecture
-Regulatory
strategy
Mfg
Process
valida.on
+
Launch
readiness
-HW & SW design,
-Detailed Risk Analysis,
-Prototyping
-Test method
development
-Mfg process development
-Design freeze
-Design veriﬁca.on
-Mfg process
development
-Clinical tes.ng,
-Human factors
tes.ng
-Prepare
submission

Comparison Story: Start
Walter’s Team
•  Begin detailed project planning
•  Begin wriVng product requirements and
soRware requirements
•  Perform hazard analysis

Grace’s Team
•  Begin high-level project planning
•  Begin wriVng preliminary requirements
•  IdenVﬁcaVon of knowledge gaps:
•  Plan tesVng of new pump mechanism
•  Plan tesVng of new baDery
•  Plan tesVng of UI designs
Year 1 Year 2
+Set up project “War Room” (obeya)
Expensive!
TesVng uses up
Vme and scarce
resources

Comparison Story: Year 1-Q1
Walter’s Team
•  Comprehensive detailed project planning
•  Comprehensive product requirements and
soRware requirements
•  Phase 1/ Gate 1 completed ✔

Grace’s Team
•  High-level project planning
•  Preliminary requirements and hazard analysis
•  Closing knowledge gaps:
•  EvaluaVon of new pump mechanism
•  EvaluaVon of new baDery
•  EvaluaVon of UI designs
•  MulVple trips to hospitals to observe use of drug
infusion pumps
•  SoRware team sprints produced series of rough
SW demos for evaluaVon
Year 1 Year 2

Agile SoLware Development
Example of integraVng new methods into a highly regulated environment

Agile has many proven advantages for SW
Agile improves:
•  Visibility of SW project to
stakeholders
•  Flexibility in responding to
changing user needs
•  Managing SW project risks
•  Quality of released SW

The Agile Manifesto (2001)
We are uncovering beDer ways of developing soRware by doing it and helping
others do it. Through this work we have come to value:

Individuals and interac.ons over processes and tools
Working so]ware over comprehensive documentaVon
Customer collabora.on over contract negoVaVon
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 leR more.

Feb. 2001 - hDp://agilemanifesto.org/
Medical Device RegulaVons è processes & documentaVon
SoluVon: find a balance to maintain benefits of Agile while sVll fulfilling regulatory requirements
AAMI TIR45:2012 – Guidance on Use of Agile for Medical Device So]ware

2-week Sprint
Agile Scrum: Developing
SoLware in Short Sprints
Product
Backlog
Sprint
Backlog Sprint Tasks
Daily
Scrum
Daily Scrum: team
shares status and
idenVﬁes issues
Review of SW with
stakeholders
+
Sprint
Retrospec.ve
Sprint Planning:
deﬁne work tasks
for next sprint
Highest
priority
features
Working
SoRware

Waterfalls
FDA Design Controls (21CFR820.30)
IEC 62304 Medical Device So]ware Standard
5.1 SW Development Planning
5.2 SW
Requirements
Analysis
5.3 SW
Architectural
Design
5.4 SW
Detailed
Design
5.5 SW Unit
ImplementaVon
& VeriﬁcaVon
5.6 SW
IntegraVon &
IntegraVon TesVng
5.7 SW
System
TesVng
5.8 SW
Release

5.1 SW Development Planning
5.2 SW
Requirements
Analysis
5.3 SW
Architectural
Design
5.4 SW
Detailed
Design
5.5 SW Unit
ImplementaVon
& VeriﬁcaVon
5.6 SW
IntegraVon &
IntegraVon TesVng
5.7 SW
System
TesVng
5.8 SW
Release
7. Risk
Mgmt
7. Risk
Mgmt
7. Risk
Mgmt
Transposing Waterfall to Agile (IEC 62304 Medical SW Standard)
5.1 SW Development Planning (sprint planning)
5.2 SW Requirements Analysis
5.3 SW Architectural Design
5.4 SW Detailed Design
5.5 SW Unit ImplementaVon & VeriﬁcaVon
5.6 SW IntegraVon & IntegraVon TesVng
5.7 SW System TesVng & Regression TesVng
5.8 SW Release
For each Sprint
AAMI TIR45:2012 – Guidance on Use of Agile for Medical Device So]ware
For each Release
5.7 SW System
TesVng
5.1 SW Development Planning (release planning)
For each Project 5.1 SW Development Planning (project)
5.2 SW Requirements Analysis (high-level, backlog mgmt)
5.3 SW Architectural Design (infrastructure)
5.6 SW
IntegraVon &
IntegraVon TesVng

Agile Cycles and Design Planning
Day
Plan
Sprint Plan
Release Plan
Project Plan •  Design controls are organized around
mulVple cycles (layers)
•  Project = one or more Releases
•  Release = one or more Sprints
•  Planning performed at all layers
•  UVlizes rolling wave planning
•  Regular updates to DHF documentaVon

Agile Methods Break Up the Work
Design Input Ac.vi.es Design Output Ac.vi.es
Design Input Ac.vi.es
Design Output Ac.vi.es
… …
Design Output Ac.vi.es Design Input Ac.vi.es
Waterfall (batch) Agile

The Story Con'nues
“An investment in knowledge pays the best interest” – Benjamin Franklin

Success Assured!
Knowledge First (then everything else)
Concept
Learning
Dominant
Focus of Project Team
Product Launch
Planning Pre-Produc.on
Task
Dominant
100%
Produc.on Development Veriﬁca.on

Walter’s Team
•  Hardware design completed (mech/elec) ✔
•  Prototype build completed ✔
•  SoRware team doing integraVon
•  Detailed risk analysis completed (dFMEA) ✔
•  Test method development underway
•  Manufacturing process development underway,
including qualiﬁcaVon of suppliers
•  Preparing documents for Gate 2

Grace’s Team
•  Finished extensive tesVng of new pump mechanism
as well as 2 backup designs
•  Finished extensive tesVng of new baDery as well as
3 backup designs
•  Conducted mulVple formaVve human factors tests
of UI designs, using prototype soRware generated
every 2 weeks running on HW testbed
Why is Grace’s team so
far behind?
PROBLEMS!
1.  Reliability: new pump mechanism someVmes fails aRer 3000 cycles
2.  OverheaVng: new baDeries overheat when fully assembled in product
housing
3.  User Interface: ﬁrst and second designs were a failure (but third design
tests well with lots of posiVve user feedback)
Year 1 Year 2

Quality System Adapta'ons
Make your SOPs and Lean-Agile methods ﬁt together

The Facts:
•  Lean-agile methods do not conﬂict with the
requirements of FDA regulaVons, ISO 13485, IEC 62304,
or other medical device standards
•  Lean-agile methods do conﬂict with the quality systems
of many medical device companies
•  Quality system procedures must be adapted for lean-
agile methods and likewise the methods must be
adapted for compliance (addiVonal documentaVon and
approval steps)

Design Controls – Elements
Design
Planning
Design
Transfer
Design
Output
Design
Input
Design
Valida.on
Design
Review User
Needs
Design
Veriﬁca.on
Lean/agile/hybrid approaches vs Waterfall – companies have ﬂexibility in implemenVng regulaVons

Business Case &
Product Concept
Intended Use
Clinical purpose, types of
users/ paVents, usage
environment
Regulatory Strategy
Hazard Analysis
Design Requirements Tes.ng
Design IteraVons
Design Space Limits
Applicable Standards
Establish Regulatory-Risk Framework First

Risk Management (Product Safety)
•  Need ‘upfront’ risk assessment:
•  needs to be fast but comprehensive and cannot require detailed design
•  High-level/ top-down
•  Example: “System Hazard Analysis” provides the framework and is
complementary to subsequent detailed risk assessments (dFMEA, uFMEA,
pFMEA)
•  Lean-agile methods improve risk management:
•  IteraVons improve idenVﬁcaVon and assessment of risks
•  IteraVons improve design and tesVng of miVgaVons
•  Use error and miVgaVons can be addressed early in development
•  Risk traceability needs to be maintained throughout development
(riskà reqtàdesignàtest); –don’t try to do tracing just at the end

Phases without Gates
•  Phases organize large numbers of interrelated acVviVes and deliverables (good!)
-BUT-
•  “Rigid Gates” (determining whether team can proceed) assume product
development is purely sequenVal and insVtute batched hand-offs where lots of
work and lots of knowledge is transferred at one Vme across groups:
Planning Pre-Produc.on Produc.on Development Verifica.on
•  Instead, allow work to be done in mulVple phases simultaneously; use Phase End
Review to mark successful compleVon of each phase:
GATE
GATE
GATE
GATE
Planning
Pre-Produc.on Produc.on
Development
Verifica.on

AdapVng Design Controls for Lean-Agile
Design Control
Element
Adapta.ons
Design Planning High-level planning covering enVre project; detailed planning only for
short-term; make planning VISUAL—all team members and stakeholders
can clearly see all key aspects of project at all Vmes
Requirements Don’t mandate complete and detailed requirements to start project; allow
requirements to be elaborated and refined throughout development
Design V&V TesVng Don’t mandate that all verificaVon tesVng be completed before validaVon
begins; allow for staged design freeze where verificaVon can be
performed on some parts of product while other parts of design are being
finalized (allows maximum flexibility to the project team to make design
changes up to the “last responsible moment”)
Regulatory submissions Communicate early to enVre team everything required for the submission
(all test evidence, key areas of concern, etc.)

Design History File (DHF)
•  DHF should serve as a knowledge repository, not just compliance documentaVon
•  Include raVonale for design requirements, background for test methods, etc.
•  Organize for easy retrieval of informaVon (searchable, cross-linked)
•  Manage DHF documentaVon so that work can be done on many documents
simultaneously (de-centralized) with many iteraVons, while sVll maintaining
integrity and consistency and traceability
•  IteraVons during early development can improve compliance:
•  Everyone learns more about the quality system processes
•  Helps ensure the final output is complete and consistent
•  Methods can be refined as needed before product is finalized
•  ExponenVal increase in compliance/ documentaVon effort near product launch
(don’t iterate at this point!!!)
= relaVonal database

The Story Finishes
What can we learn from Walter and Grace’s teams?

Walter’s Team
•  Phase 3 integraVon tesVng and system tesVng
revealed problem with baDery overheaVng; team
has begun invesVgaVng alternaVve designs
•  SoRware tesVng revealed a large number of bugs
(SoRware team now fixing them)
•  Human factors tesVng delayed unVl SW fixed
•  Test protocols being wriDen for V&V tesVng
•  Manufacturing process development conVnuing

Grace’s Team
•  Design verificaVon tesVng completed, including
60601 cerVficaVon (elec safety, EMC, etc.)
•  Preparing for Phase 4 validaVon tesVng

PROBLEMS!
1.  Reliability: new pump mechanism someVmes fails aRer 3000 cycles
2.  OverheaVng: new baDeries overheat when fully assembled in product
housing
3.  User Interface: first and second designs were a failure (but third design
tests well with lots of posiVve user feedback)
When will Walter’s team discover
the problems with the pump
mechanism and UI design?
Year 1 Year 2

When were design issues iden'ﬁed?
•  Lean-Agile methods encourage rapid
idenVﬁcaVon of design issues early in
development (and therefore more rapid
soluVons)
•  Peak problem solving acVvity in the
tradiVonal approach (blue) happens near
the end of development and oRen
extends beyond the deadline (“100%”)
Based on presentaVon by Takashi Tanaka - Lean Summit 2011
(Lean Enterprise Academy)
Grace’s
Team
Walter’s
Team

The Moral of the Story
Walter’s Team
Grace’s Team
•  Regulatory submission on .me ✔
•  Product launch on .me ✔
•  InnovaVve new product development always
involves risks
•  Focusing early eﬀorts on project risks makes
later stages predictable (fast learning to
close knowledge gaps)
•  A project that is on schedule during its early
phases does not mean it will deliver on
schedule at the end

Success Assured!
Product Development with “Two Minds”
Concept
Learning
Dominant
Focus of Project Team
Product Launch
Planning Pre-Produc.on
Task
Dominant
100%
Produc.on Development Veriﬁca.on

Summary
“A bad system will beat a good person every Vme.” – W. Edwards Deming

Is It Really Faster?
Key ways that Lean-Agile methods shorten Vme to market:
1.  IdenVfy knowledge gaps early and tackle them
aggressively (avoid late-breaking problems that lead to big
delays)
2.  At a medical device company late-breaking problems can
trigger a cascade of issues—can lead to regulatory
problems on top of technical problems (re-submit, etc.)
3.  Frequent tesVng and feedback to ﬁnd design defects early
and adjust development accordingly
4.  Only spend Vme on what customers really need and want
(free up engineering Vme from non-value added tasks)
+ there are more ways that Lean-Agile methods accelerate product
development which are not as straighyorward to see (e.g., beDer
communicaVon, increased moVvaVon, process opVmizaVon, etc.)
Cost of Delay
= $$$

Knowledge-Driven Product Development
•  Successful new product development demands deep
knowledge of:
1.  Product applicaVon
2.  Product technology
3.  Manufacturing process technology
•  For Medical Devices:
4.  Regulatory Approval (approval process and key
concerns of regulators)
5.  Compliance (requirements of all applicable
regulaVons and standards)
Medical Devices: understand
the clinical environment and
the needs of clinicians

Challenges in Adop'ng Lean and Agile Methods
Undermining Lean-Agile Methods:
•  Decision by HiPPO
•  Employee turnover
•  Knowledge handoﬀs (scaDer)
•  Overloaded engineers
•  Responsibility separated from
control
•  Fear
Why do some organizaVons feel threatened by these principles of lean-agile methods?
•  Design decisions based on knowledge
•  VisualizaVon (transparency) of product development

Lean-Agile Methods for Medical Device Development
1. Lean-agile methods accelerate medical device development
2. If the team can’t solve the technical challenge of ‘X’ then all other
work on the product is useless
3. Focus on knowledge, not just tasks
4. Minimizing tesVng = minimizing knowledge gained
5. Quality system procedures need to be adapted to support lean-agile
methods

Two Diﬀerent Approaches for Product Development
TradiVonal (waterfall)
•  Design then test
•  Upfront planning
•  Manage task compleVon
•  Work transferred in large
batches
•  Maximize uVlizaVon
Lean-Agile
•  Test then design
•  Rolling wave planning
•  Manage knowledge compleVon
•  Work transferred in small
batches on a cadence
•  Maximize throughput
•  ConVnuous improvement

Suggested Resources for Lean and Agile Product Development
Websites:
•  hDp://www.leanprimer.com/downloads/lean_primer.pdf - good overview of lean principles wriDen by two soRware
management consultants (Craig Larman and Bas Vodde) who include aspects of soRware agile methods as well.
•  hDp://theleanthinker.com/ - a blog by Mike Rother with lots of good observaVons and real-life issues involved in
changing an organizaVon to lean
•  hDp://www.coe.montana.edu/IE/faculty/sobek/A3/index.htm - a short tutorial on the Toyota A3 technique for
problem solving by Durward Sobek
•  hDp://www.lean.org/ - Lean Enterprise InsVtute (consulVng ﬁrm and forum); large collecVon of arVcles and online
forums discussing aspects of lean product development, lean mfg, and lean services
•  hDp://theleanedge.org/ - a forum for discussions of lean management issues with contribuVons from many of the
thought leaders in the lean community
•  hDp://playbookhq.co/blog/ - lots of good blog posVngs on concepts and methods for lean-agile product development;
links to lots of addiVonal resources
•  hDps://www.scrumalliance.org - Scrum Alliance is a non-proﬁt organizaVon; has arVcles and links on agile methods
•  hDps://www.mountaingoatsoRware.com/agile - extensive set of blog posVngs on mulVple aspects of agile soRware
development by consultant Mike Cohn
•  hDps://less.works/ - Large Scale Scrum (LeSS) framework for large scale projects
•  hDp://www.scaledagileframework.com/ - a management system for large scale projects (SaFE)

Suggested Resources for Lean and Agile Product Development
Books:
•  "Mastering Lean Product Development" by Ronald Mascitelli - a collecVon of pracVcal methods to improve everything
a product development organizaVon does from product strategy to running eﬃcient design reviews (includes extensive
bibliography).
•  "The Principles of Product Development Flow" by Donald Reinertsen - detailed explanaVons of key principles to
accelerated product development, based on Theory of Constraints, queuing theory, and more.
•  "Lean Product and Process Development" by Allen C Ward - a spirited presentaVon of the philosophy and techniques
for lean product development from the guy who inspired many others (published posthumously)
•  "Ready, Set, Dominate" by Michael Kennedy et al - a more evolved presentaVon of the ideas from Ward's book, based
on the real-life experiences of Kennedy's consulVng clients. Includes case studies of two companies going through lean
transformaVons.
•  “Managing to Learn” by John Shook – an excellent introducVon to the use of the ‘A3 method’ for problem solving,
communicaVon, learning, and lean management.
•  “The Lean Startup” by Eric Ries – a must read for entrepreneurs and anyone managing projects to create something
new under condiVons of extreme uncertainty.
•  “The Elements of Scrum” by Chris Sims and Hillary Louise Johnson – a simple but comprehensive descripVon of one of
the most popular aspects of agile methods for soRware development

3 Ways to SystemaVcally Accelerate Medical
Device Development
Copyright 2016-2017 Aaron Joseph ConsulVng 47
1. Lean and agile methods
+
2. Leveraging HW / SW technology playorms
+
3. Streamlined compliance
( this presentaVon)
See hDp://consensiainc.com/zipquality/

ADDITIONAL SLIDES

Old Way: Product Documenta'on Stored in Documents
Risk
Analysis
SW Reqts
Test
Protocol
Product
Reqts
Test
Report
Revision control per document
DHF

Documents are Not a Good Way to
Manage Product Documenta'on
Managing design requirements and other product development informaVon in text or spreadsheet
documents (MS Word or Excel) is a common approach but has these serious drawbacks:
•  Traceability is staVc—because traces must be maintained manually, these are typically defined
retrospecVvely (aRer the work is done) instead of prospecVvely; trace informaVon is likely to degrade
over Vme with changes to the product (post-launch)
•  No support for process workflow: who can change what and when? What informaVon must be linked
and changed together?
•  Difficult to manage changes post-launch, to know all the documents affected by a change
•  Difficult to search across documents
•  Change control is per document—difficult to track which requirements changed, who changed them, and
when
•  No way to efficiently manage product variants where there is a lot of overlap of risks/requirements/tests
+ document-centric approach tends to reinforce a “batch mindset”
which is contrary to lean and agile methods

Test
Protocol
New Way: Product Documenta'on Stored in a Rela'onal
Database
Risk
Analysis

SW Reqts

SW Test
Protocol

Product
Reqts

SW Test
Report

Revision control per document and per element
Documents are groupings of DHF elements
PR-1020: System shall provide …
Text of requirement
Test
Protocol
ADributes (status, etc.)
Export a set of
documents from the
database for submissions

Lean agile feb2017-patca_a_joseph_ss

More Related Content

What's hot

Viewers also liked

Similar to Lean agile feb2017-patca_a_joseph_ss

Recently uploaded

Lean agile feb2017-patca_a_joseph_ss