Agility with Care:
Managing Requirements Change with
Agility in a Regulated Product
Development Environment
Ken Wong, Ph.D., Senior Systems Analyst
McKesson Medical Imaging Group
IIBA, September 10, 2009

Agility … with Care?
9/13/2009 2

Overview
With Agility
Regulated Product Development
Agility with Care
Conclusion
9/13/2009 3

With Agility

In the beginning …
Waterfall Model
(i.e., Get it right the first time)
However, things change …
(i.e., Scope change/creep)
Managing the Development of Large Software Systems, Winston
Royce, Proceedings of IEEE WESCON 26, 1970
9/13/2009 5

SRS (Big Requirements Up Front)
9/13/2009 6

Embracing Requirements Change
“A late change in requirements is a
competitive advantage.”
Mary Poppendieck as quoted in The New Methodology, Martin Fowler
9/13/2009 7

Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
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 left more.
I.e., Communicate, Communicate, Communicate
9/13/2009 8

An Extreme Requirements Method
XP (Extreme Programming) example:
─ Customer and team working together on site
─ 1-line customer “User Stories” + conversation
─ Short iterations to garner customer feedback
* Agile Requirements Methods, Dean Leffingwell, The Rational Edge, 2002
Focus on user needs
─ As a <type of user>, I want <some goal> so that
<some reason>
─ Prioritized, Estimated, Sized
9/13/2009 9

Agile Analysis
Collaborative
As a payrol
Iterative l clerk, I w
add an empl ant to
oyee to the p
Just in Time that I can ayroll so
process the n
ew hires
Just Enough
“You need to do analysis, but that doesn't imply that
you need analysts.”
Rethinking the Role of Business Analysts: Towards Agile Business Analysts?, Scott Ambler
9/13/2009 10

Beyond the Triangle
SCOPE
Agile: Traditional:
Things Change On Time
Improve Efficiency QUALITY On Spec
Deliver Value On Budget
COST TIME
9/13/2009 11

Regulated Product
Development

In the beginning … ?
Cowboy Coder
(Wanted: Dead or Alive)
CHAOS Report (1994) – “Incomplete Requirements”
leading cause of project impairment
9/13/2009 13

Comprehensive Requirements
“Design input requirements must be
comprehensive.”
Design Control Guidance for Medical Device Manufacturers, FDA
9/13/2009 14

FDA Design Controls
- Based on ISO 9001:
Say what you do
Do what you say
Prove it
Design Control Guidance for Medical Device Manufacturers, FDA
9/13/2009 15

FDA Software Requirements Guidance
Guidance on software requirements includes:
─ Documented User Requirements Specification
─ Detailed Software Requirements Specification
─ Traceability
─ Review, approval and documented sign-off
─ Requirements change control
* General Principles of Software Validation, FDA
Focus on user needs
and PATIENT SAFETY
9/13/2009 16

Product Development
Market Needs (vs. Better Mousetrap)
9/13/2009 17

Product Development Roadmap
Multiple
Releases
Legacy
Product
Concurrent
Development
9/13/2009 18

Product (vs. Custom IT) Development
Developing products may involve:
─ NO single customer (geography, diverse)
─ NO single development team (large, distributed)
─ NO single release (maintenance, roadmap)
Communication across time, space and culture
9/13/2009 19

Agility with Care

In the beginning … (revised)
“risky and invites failure”
“Do it Twice”
Managing the Development of Large Software Systems, Winston
Royce, Proceedings of IEEE WESCON 26, 1970
9/13/2009 21

With Agility?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
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 left more.
9/13/2009 22

Agility with Care
Balance between agility and plan-driven
─ Scaling factors: regulated, distributed, roadmap, …
─ E.g., Documentation (Dev vs. Maintenance)
9/13/2009 23

Initial Requirements
Business
i.e., Vision
(problems, personas)
User
i.e., Backlog
(epics, themes, user stories)
Software
i.e., Envisioning
(MMF, use cases, mockups)
E.g., FDA “Concept Documents versus Design Input”
9/13/2009 24

Agile Elaboration of Concept
Establish Initial Develop iteratively and
Requirements collaboratively
─ Research (Market,
Competitive, User)
─ Proof of concept
prototyping (WPF)
E.g., Product Marketing Scrum
9/13/2009 25

Plan-Driven Construction of Release
Develop iteratively and Establish deliverables,
collaboratively i.e., FDA artifacts
─ Just in Time / Just Enough
─ SRS = Acceptance Tests?
─ BA = Product Owner?
─ Usability Testing
E.g., Development Scrum (of Scrums)
9/13/2009 26

Agile Analysis with Care
Iteratively and collaboratively…
Prioritizing and
garnering consensus
Identifying and Creating and
illuminating User specifying Solutions
Needs
Saying anyone can do analysis is like saying
anyone can code
9/13/2009 27

Conclusion

Agility (i.e., Getting off the Waterfall)
9/13/2009 29

With Care (i.e., “Faking It”)
“We will never find a process that
allows us to design software in a
perfectly rational way. The good
news is that we can fake it.”
Rational Development Process: How and Why to Fake it, David Parnas and
Paul Clements, IEEE Transactions on Software Engineering, 1986
9/13/2009 30

And Beyond (e.g., Kanban)
Visualize, Optimize Flow Process, Specialists OK
Limit WIP Iterations Optional
Kanban
in Software
Development,
Derick Bailey
I.e., Making value flow across the enterprise
9/13/2009 31

Agility with Care (The End)
“In the world of agile development, context is key.”
Voyage in the Agile Memeplex, Philippe Kruchten, ACM Queue, 2007
9/13/2009 32

Agile BA Working Group
Agile Vancouver and IIBA Vancouver Chapter
Agile Business Analyst Working Group
Thursday September 17, 5:30pm
McKesson Imaging Group
130-10711 Cambie Road Richmond
RSVP steve at wsaconsulting.com
9/13/2009 33