Agile Methods and the Business Analyst Mark Foley
Session Objectives <ul><li>Review key characteristics of agile processes </li></ul><ul><li>Understand agile practices that...
Top 10 Reasons for Success – why are we here ?
Snapshot: Borland’s Agile Transformation <ul><li>Austin </li></ul><ul><li>Linz </li></ul><ul><li>Santa Ana </li></ul><ul><...
Our Results <ul><li>Increased number of product releases per year by 100% </li></ul><ul><li>Deepened relationships with st...
The other view
 
Manifesto for Agile Software Development That is, while there is value in the items on the right, we value the items on th...
Bad Ideas?
Agile Today
<ul><li>The Business Analyst Role in Agile </li></ul>
Scrum, FDD, XP Agile Methodologies Project Management Engineering FDD XP Scrum
Scrum: Lifecycle 8. Product Increment (potentially shippable) 6. Day 5. Sprint (2-4 weeks) 4. Tasks detailed by the team 1...
Evolution of BA Role in XP <ul><li>XP view of requirements </li></ul><ul><ul><li>Onsite customer (implied singular custome...
Evolution of BA Role in Agile <ul><li>XP view of requirements </li></ul><ul><ul><li>Onsite customer (implied singular cust...
Evolution of BA Role in Agile <ul><li>XP view of requirements </li></ul><ul><ul><li>Onsite customer (implied singular cust...
Scrum: Roles Product Owner Scrum Master Team members <ul><li>Alternative Name:  User, Customer </li></ul><ul><li>Role Defi...
<ul><li>Agile Requirements Techniques and Practices </li></ul>
Stories “ A User Story is a story, told by the user, specifying  how the system is supposed to work , written on a card, a...
Story Issues <ul><li>Content  Level of Detail </li></ul><ul><ul><li>Team size, distribution </li></ul></ul><ul><ul><li>Ava...
Context <ul><li>Good Requirements (IEEE definitions) </li></ul><ul><ul><li>Set is complete </li></ul></ul><ul><ul><li>Set ...
Traditional RM Functional Nonfunctional Business Requirements Vision and Scope Document User Requirements Business Rules Q...
Large Scale Agile Functional Nonfunctional Business Requirements Vision and Scope Document User Requirements Business Rule...
User Involvement <ul><li>BA a substitute for user? </li></ul><ul><li>Agile characteristics to promote user involvement </l...
The Agile Lifecycle BA Effort Time Project Duration
Up Front Effort <ul><li>JIT Requirements Elaboration vs Up front elaboration </li></ul><ul><li>JIT </li></ul><ul><ul><li>R...
Cost to Change Curve Cost of Change Lifecycle Stage $ $ $ $ $ ‘ What if we got good at reducing the costs of ongoing chang...
The BA as a Tester <ul><li>Consider </li></ul><ul><ul><li>Value of independent view </li></ul></ul><ul><ul><li>Specialized...
Embrace Change That is, while there is value in the items on the right, we value the items on the left more.” http://www.a...
Session Objectives <ul><li>Review key characteristics of agile processes </li></ul><ul><li>Understand agile practices that...
Upcoming SlideShare
Loading in …5
×

Mark Foley Agile Methods And The Business Analystc

1,987 views

Published on

a BA's role in an agile environment

Published in: Business, Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,987
On SlideShare
0
From Embeds
0
Number of Embeds
68
Actions
Shares
0
Downloads
75
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • Point out that there is a lot of interest in Agile at the moment (Google results) Ask who is working on an agile project right now?
  • Mark Foley Agile Methods And The Business Analystc

    1. 1. Agile Methods and the Business Analyst Mark Foley
    2. 2. Session Objectives <ul><li>Review key characteristics of agile processes </li></ul><ul><li>Understand agile practices that impact the BA </li></ul><ul><li>Learn to tailor agile requirements techniques to match your project environment </li></ul>Results 1 - 10 of about 1,190,000 for agile development
    3. 3. Top 10 Reasons for Success – why are we here ?
    4. 4. Snapshot: Borland’s Agile Transformation <ul><li>Austin </li></ul><ul><li>Linz </li></ul><ul><li>Santa Ana </li></ul><ul><li>Singapore </li></ul>>300 Developers 4 Locations <ul><li>March 2006 </li></ul><ul><li>Unacceptable delivery cycles </li></ul><ul><li>Executive support for moving to Agile </li></ul><ul><li>First “Adoption” – 2 teams - Austin </li></ul><ul><li>Today </li></ul><ul><li>40% of teams Agile </li></ul><ul><li>Still learning </li></ul><ul><li>Predictable delivery </li></ul><ul><li>Faster response to market </li></ul><ul><li>Improved morale </li></ul><ul><li>Borland Agile </li></ul><ul><li>3 and 4 week sprints </li></ul><ul><li>Sprint vary by team </li></ul><ul><li>Some products require coordination of multiple teams </li></ul>
    5. 5. Our Results <ul><li>Increased number of product releases per year by 100% </li></ul><ul><li>Deepened relationships with strategic customers, who have participated in over 50 sprint reviews </li></ul><ul><li>Increased customer sat by including minor features in maintenance releases </li></ul><ul><li>Increased product quality, reducing open issues from one release to next by 50% </li></ul><ul><li>Increased team productivity through lifted morale. Teams like having ownership & accountability, as well as the feeling they have in releasing working product every 3 weeks </li></ul>
    6. 6. The other view
    7. 8. Manifesto for Agile Software Development That is, while there is value in the items on the right, we value the items on the left more.” http://www.agilemanifesto.org Individuals & Interactions over Processes & Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
    8. 9. Bad Ideas?
    9. 10. Agile Today
    10. 11. <ul><li>The Business Analyst Role in Agile </li></ul>
    11. 12. Scrum, FDD, XP Agile Methodologies Project Management Engineering FDD XP Scrum
    12. 13. Scrum: Lifecycle 8. Product Increment (potentially shippable) 6. Day 5. Sprint (2-4 weeks) 4. Tasks detailed by the team 1. Vision (ROI, milestones, releases) 2. Product Backlog, with features prioritized by the Product Owner 3. Sprint Backlog 7. Daily Standup Meeting 9. Inspect and Adapt
    13. 14. Evolution of BA Role in XP <ul><li>XP view of requirements </li></ul><ul><ul><li>Onsite customer (implied singular customer) </li></ul></ul>Being an XP customer is not easy. There are skills you have to learn, like writing good stories, and an attitude that will make you successful. Most of all, though, you have to become comfortable influencing a project without being able to control it. Kent Beck, 2000
    14. 15. Evolution of BA Role in Agile <ul><li>XP view of requirements </li></ul><ul><ul><li>Onsite customer (implied singular customer) </li></ul></ul><ul><ul><li>Recognition that customer could be a team of people </li></ul></ul>‘ Some larger teams doing XP have teams of customers. The important thing isn’t so much that there is a single customer, but that the ‘customer speaks with one voice.’ Michael Feathers, 2001
    15. 16. Evolution of BA Role in Agile <ul><li>XP view of requirements </li></ul><ul><ul><li>Onsite customer (implied singular customer) </li></ul></ul><ul><ul><li>Recognition that customer could be a team of people </li></ul></ul><ul><ul><li>Recognition of the role of a customer representative </li></ul></ul>
    16. 17. Scrum: Roles Product Owner Scrum Master Team members <ul><li>Alternative Name: User, Customer </li></ul><ul><li>Role Definition: The Product Owner represents the custumer/user/sponsor of the project, and is part of the team which will deliver the product. </li></ul><ul><li>Main Activities: Define the vision for the product, manage the Return On Investment (ROI), present the needed requirements to the team for the product delivery, prioritize requirements, manage addition/changes to requirements, plan releases, assure the Domain Experts are available to the team. </li></ul><ul><li>Alternative Names: Project Manager/Leader, Coach </li></ul><ul><li>Role Definition: The role of Scrum Master, unlike a Project Manager in many practices and methodologies, differ from the traditional “command and control”. In Scrum, the Scrum Master works with and, more important, for the team. </li></ul><ul><li>Main Activities: Allow the team to be self-managed, guide and help the team to correctly follow Scrum practices, remove any impediment found by the team, protect the team from external interference, facilitate the daily meetings. </li></ul><ul><li>Alternative Names: Developers, Technicians, Testers </li></ul><ul><li>Role Definition: A team member is someone committed to do the necessary work to achieve the Sprint goal. </li></ul><ul><li>Main Activities: Define the Sprint goal, be committed to the work and to the high quality, work towards the product vision and the Sprint goal, estimate items on the Product Backlog, attend the daily meetings. </li></ul>
    17. 18. <ul><li>Agile Requirements Techniques and Practices </li></ul>
    18. 19. Stories “ A User Story is a story, told by the user, specifying how the system is supposed to work , written on a card, and of a complexity permitting estimation of how long it will take to implement. The User Story promises as much subsequent conversation as necessary to fill in the details of what is wanted . The cards themselves are used as tokens in the planning process after assessment of business value and [possibly] risk. The customer prioritizes the stories and schedules them for implementation.”
    19. 20. Story Issues <ul><li>Content Level of Detail </li></ul><ul><ul><li>Team size, distribution </li></ul></ul><ul><ul><li>Availability of Stakeholders </li></ul></ul><ul><li>Transitory </li></ul><ul><ul><li>What Requirements Documents do we want eed to preserve </li></ul></ul><ul><li>How are they Evolved </li></ul><ul><ul><li>Do we really want to jump straight to system functionality? </li></ul></ul>
    20. 21. Context <ul><li>Good Requirements (IEEE definitions) </li></ul><ul><ul><li>Set is complete </li></ul></ul><ul><ul><li>Set is consistent </li></ul></ul><ul><ul><li>Set is modifiable </li></ul></ul><ul><li>Decomposition </li></ul><ul><ul><li>Organize stories by relating to higher level artifacts </li></ul></ul>“ If you lose a card, and if the customer does not detect that loss, then the card wasn’t very important.” Robert C. Martin
    21. 22. Traditional RM Functional Nonfunctional Business Requirements Vision and Scope Document User Requirements Business Rules Quality Attributes Use Cases System Requirements Functional Requirements Constraints External Interfaces Software Requirements Specification
    22. 23. Large Scale Agile Functional Nonfunctional Business Requirements Vision and Scope Document User Requirements Business Rules Quality Attributes Use Cases System Requirements Story Constraints External Interfaces Backlog
    23. 24. User Involvement <ul><li>BA a substitute for user? </li></ul><ul><li>Agile characteristics to promote user involvement </li></ul><ul><ul><li>Frequent “releases” </li></ul></ul><ul><ul><li>Daily stand up </li></ul></ul>
    24. 25. The Agile Lifecycle BA Effort Time Project Duration
    25. 26. Up Front Effort <ul><li>JIT Requirements Elaboration vs Up front elaboration </li></ul><ul><li>JIT </li></ul><ul><ul><li>Rapid progress early </li></ul></ul><ul><ul><li>Earlier customer feedback </li></ul></ul><ul><ul><li>Could get blind-sided </li></ul></ul><ul><li>Up front Elaboration </li></ul><ul><ul><li>More up front effort, more time till customer feedback </li></ul></ul><ul><ul><li>Clarify overall scope and size sooner </li></ul></ul><ul><li>Considerations </li></ul><ul><ul><li>CostEffort of development </li></ul></ul><ul><ul><li>Governance framework, funding model </li></ul></ul><ul><ul><li>Uniqueness </li></ul></ul>
    26. 27. Cost to Change Curve Cost of Change Lifecycle Stage $ $ $ $ $ ‘ What if we got good at reducing the costs of ongoing changes? Kent Beck, 1999
    27. 28. The BA as a Tester <ul><li>Consider </li></ul><ul><ul><li>Value of independent view </li></ul></ul><ul><ul><li>Specialized test activities </li></ul></ul><ul><ul><ul><li>Usability </li></ul></ul></ul><ul><ul><ul><li>Performance </li></ul></ul></ul><ul><ul><ul><li>Security </li></ul></ul></ul>
    28. 29. Embrace Change That is, while there is value in the items on the right, we value the items on the left more.” http://www.agilemanifesto.org Individuals & Interactions over Processes & Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
    29. 30. Session Objectives <ul><li>Review key characteristics of agile processes </li></ul><ul><li>Understand agile practices that impact the BA </li></ul><ul><li>Learn to tailor agile requirements techniques to match your project environment </li></ul>

    ×