This presentation looks at some of the potential challenges involved in employing Agile requirements management approaches in a regulated product environment. The key is finding the right blend of agile and plan-driven methods depending upon the development context.
Agility With Care: Managing Requirements Change with Agility In A Regulated Product Environment - IIBA 2009
1. 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
5. 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
7. 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
8. 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
9. 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
10. 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
11. 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
13. In the beginning … ?
Cowboy Coder
(Wanted: Dead or Alive)
CHAOS Report (1994) – “Incomplete Requirements”
leading cause of project impairment
9/13/2009 13
14. Comprehensive Requirements
“Design input requirements must be
comprehensive.”
Design Control Guidance for Medical Device Manufacturers, FDA
9/13/2009 14
15. 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
16. 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
19. 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
21. 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
22. 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
23. Agility with Care
Balance between agility and plan-driven
─ Scaling factors: regulated, distributed, roadmap, …
─ E.g., Documentation (Dev vs. Maintenance)
9/13/2009 23
24. 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
25. 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
26. 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
27. 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
30. 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
31. 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
32. 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
33. 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