• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agility With Care: Managing Requirements Change with Agility In A Regulated Product Environment  - IIBA 2009
 

Agility With Care: Managing Requirements Change with Agility In A Regulated Product Environment - IIBA 2009

on

  • 2,053 views

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 ...

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.

Statistics

Views

Total Views
2,053
Views on SlideShare
2,041
Embed Views
12

Actions

Likes
6
Downloads
0
Comments
0

2 Embeds 12

http://www.linkedin.com 8
http://www.slideshare.net 4

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agility With Care: Managing Requirements Change with Agility In A Regulated Product Environment  - IIBA 2009 Agility With Care: Managing Requirements Change with Agility In A Regulated Product Environment - IIBA 2009 Presentation Transcript

    • 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