4. The State of Software Development
(~2001)
Isolated developers working independently
Each owning a part of the project
Communicating via data flow diagrams, interface contracts,
UML, CASE tools, and detailed specs
Updating the boss through weekly status reports
Finally coming together for ‘Big bang’ integrations
Followed by endless bug fixes and ‘crunch time’
“Individuals and interactions
over processes and tools”
5. The State of Software Development
(~2001)
Design documentation handed to developers to ‘code’
Complete products requirements generated by business analysts
Software design description produced by a technical architect
Detailed design docs written ‘up-front’
No code written until design docs approved
“Working software
over comprehensive documentation”
6. The State of Software Development
(~2001)
The customer and the software teams were adversaries
Negotiated scope and expensive change orders
The ‘Iron Triangle’
Features, Time/Budget, Quality (Pick Two)
User’s got the software that was designed for them;
Not the software that they wanted
“Customer collaboration
over contract negotiation”
7. The State of Software Development
(~2001)
The Plan was a project-wide GANTT chart that fixed the
schedule for the remainder of the project
Tracking task status by percent complete
Except that tasks rapidly reached 90%
Then slowly crept to 100% (and even that was often a ‘fudge’)
New or changing requirements were met with
resistance, rejection or big budget overruns
“Responding to change
over following a plan”
11. What does typical
Agile Software Development
look like?
Small, interdisciplinary teams of developers, testers, and customer
proxies
Often co-located in an open workspace with highly visible status displays
Code is owned by the whole team and members often work together in
pairs
Test-Driven Development, Automated Builds, Continuous Integration
User stories (features with independent value) are managed in a
prioritized backlog
New stories are welcome at any time
User story priorities are determined by the project stakeholders
Level of effort is estimated by the team in arbitrary units of story points
12. What does typical
Agile Software Development
look like?
The highest priority user stories are batched into iterations (or sprints) of two
to four weeks
Teams collaborate to execute the entire lifecycle within an iteration (“Done
done”)
Design, coding, integration, test, release
Iteration Planning to bring developers and stakeholders together
Accept Completed Stories
Agree on Stories for the Next Iteration
Team Retrospective
Daily stand-up meetings (or scrums) to share plans and resolve blocks
15. Step Back to the Fundamental Goals
Regulatory agencies and Agile proponents both value
high-quality software that meets the end user’s
needs
SAFE and EFFECTIVE
So, how can the practices by aligned?
16. Medical Device Manufacturers
and the FDA
both wanted Guidance on
Appling Agile Practices to Medical Device
Software
AAMI Medical Device Software Committee approved the creation
of an Agile Software Task Group in 2009
Joint Chairs – Bakul Patel (FDA) and Patty Krantz (Medtronic)
Goal: How to best align agile concepts and practices with the
regulatory requirements for medical device software
19. Key Conclusions and Recommendations
from AAMI TIR45:2012
Agile can bring value to medical device software
Agile can be adapted to the unique needs of medical
device software
Apply the values of Agile in a way that enhances a robust
quality management system
Apply the practices of Agile within the context of an
established quality management system
22. Individuals and interactions
over processes and tools
Effective processes and tools will help a good team perform even better, but no amount of processes and
tools will help a poor team perform well.
Documented processes and supportive tools bring discipline to a development process by codifying
procedures and behaviors that have been deemed important.
But, problems can occur if the team does not feel responsibility for the process, resulting in processes that are
misunderstood or ignored, or if the documented processes do not support execution realities, resulting in the “two sets
of books” mentality where the things we say do not match what we actually do.
AGILE imposes a different focus on discipline: the discipline of an interactive team of individuals who are
aligned on shared goals, shared values, and shared principles. Following the principles of “inspect and
adapt” and “visibility,” an AGILE team is obligated to regularly ask itself how the processes and practices
are working and then make improvements.
But problems can occur if the team does not accept responsibility for its processes and practices, if the team is not
sufficiently trained on fundamental concepts for software development processes and the requirements of a quality
management system, or if schedule pressures discourage the team from committing the necessary time to the inspect-
and-adapt principle.
Apply the discipline of a clear and sufficient documented process to establish the rigor necessary for
medical device software. Apply the discipline of agile to adapt a rigorous process to the team’s context and
focus on continuous improvement.
Both perspectives place value on a development team that takes ownership of the software it creates and the
processes and practices used to create it
23. Working software
over comprehensive documentation
Working software is the ultimate deliverable, the best indicator of progress and the best
indicator that the needs of the customer are being satisfied.
Regulations and standards require certain kinds of documentation to demonstrate that a
robust process has been followed to develop a safe and effective product: that is a given
Effective documentation can help a software team produce a safe and effective product
Agile concepts should be applied to ensure that valuable documentation
is produced and wasteful documentation is eliminated
“If it isn’t documented, it didn’t happen.” is a useful notion to highlight the importance of
producing an audit trail, but over-emphasizing it can lead to a checklist mentality where
documentation is produced simply to satisfy some real or imagined requirement while
providing no value
Development team should consider what is valuable to them and what is valuable to
regulators. The most valuable documentation will satisfy both
24. Customer collaboration
over contract negotiation
Although contracts are useful, they cannot by themselves ensure that a
development team will produce a product that satisfies the customer
Understanding user needs and the intended use of the software product, and
ensuring that the software is designed and validated for that use, is a vital
element of creating a safe and effective product.
An emphasis on customer collaboration means that the software’s definition will
evolve over time
For most development projects, the full definition cannot be known upfront and
the most responsible course of action is to capture the definition, requirements,
and specifications that are known in advance and then to fully elaborate them
over the whole lifecycle of the project.
It is important for the project’s development plan to explain how the definition of
the software will emerge and how artifacts will be created to demonstrate how
that definition emerges in a controlled way.
25. Responding to change
over following a plan
Change is inevitable in new product development and should be embraced as
a good and useful thing
Clear and sufficient plans help establish reasonable expectations, set the
project up for success, and provide a means of control, but no amount of
detail in a plan can predict and control the dynamic nature of new product
development
Agile puts tremendous emphasis on planning, with varying levels of planning
happening every day during a project
Plans must not be seen as rigid mandates for how work must be done, but
instead should be used as effective guidance that can be adapted as work
proceeds
It is important to define the planning activities that occur and the artifacts
that are generated in order to be able to demonstrate them to a regulator
(2 minutes) Present the Agile Manifesto (5 minutes) Backdrop to the manifesto (waterfall, etc.)
(3 minutes) Initial reaction from medical device community
(5 minutes) Core description of what agile software development means
(5 minutes) Evolution of AAMI TIR45:2012, incl. FDA involvement and recognition as a consensus standard
(10 minutes) Walk through TIR recommendations, how to apply them, real life anecdotes
Second class status to ‘process’, ‘documentation’, ‘contracts’, and ‘plans’?
On the face of it, this can’t be relevant to medical device development with an emphasis on design controls and 62304?
What were the bad practices that led to the manifesto
What were the bad practices that led to the manifesto
What were the bad practices that led to the manifesto
What were the bad practices that led to the manifesto
There are many more features of agile development teams, but this should cover the high points for this audience.
There are many more features of agile development teams, but this should cover the high points for this audience.
The development process depicted in the example is a traditional waterfall model. The design proceeds in a logical sequence of phases or stages. Basically, requirements are developed, and a device is designed to meet those requirements. The design is then evaluated, transferred to production, and the device is manufactured. In practice, feedback paths would be required between each phase of the process and previous phases, representing the iterative nature of product development. However, this detail has been omitted from the figure to make the influence of the design controls on the design process more distinct.
Puts TIR45 on the same standing as 14971, 60601-1, 62304, and 62366
It’s no longer a question of ‘Will the FDA accept this?’
The FDA now advocates in favor of agile development practices to develop safer products that meet user needs.
