Mark Foley Agile Methods And The Business Analystc

30
Agile Methods and the Business Analyst Mark Foley

description

a BA's role in an agile environment

Transcript of Mark Foley Agile Methods And The Business Analystc

Page 1: Mark Foley   Agile Methods And The Business Analystc

Agile Methods and the Business Analyst

Mark Foley

Page 2: Mark Foley   Agile Methods And The Business Analystc

Session Objectives

• Review key characteristics of agile processes• Understand agile practices that impact the

BA• Learn to tailor agile requirements

techniques to match your project environment

Results 1 - 10 of about 1,190,000 for agile development

Page 3: Mark Foley   Agile Methods And The Business Analystc

Top 10 Reasons for Success – why are we here ?

Page 4: Mark Foley   Agile Methods And The Business Analystc

Snapshot: Borland’s Agile Transformation

• Austin• Linz• Santa Ana• Singapore

>300 Developers

4 Locations March 2006- Unacceptable delivery cycles - Executive support for moving to Agile- First “Adoption” – 2 teams - Austin

Today- 40% of teams Agile- Still learning- Predictable delivery- Faster response to market- Improved morale

Borland Agile- 3 and 4 week sprints- Sprint vary by team- Some products require coordination of multiple teams

Page 5: Mark Foley   Agile Methods And The Business Analystc

Our Results

• Increased number of product releases per year by 100%

• Deepened relationships with strategic customers, who have participated in over 50 sprint reviews

• Increased customer sat by including minor features in maintenance releases

• Increased product quality, reducing open issues from one release to next by 50%

• 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

Page 6: Mark Foley   Agile Methods And The Business Analystc

The other view

Page 7: Mark Foley   Agile Methods And The Business Analystc
Page 8: Mark Foley   Agile Methods And The Business Analystc

Manifesto for Agile Software Development

Individuals & Interactions over Processes & 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.”

http://www.agilemanifesto.org

Page 9: Mark Foley   Agile Methods And The Business Analystc

Bad Ideas?

Page 10: Mark Foley   Agile Methods And The Business Analystc

Agile Today

Page 11: Mark Foley   Agile Methods And The Business Analystc

The Business Analyst Role in Agile

Page 12: Mark Foley   Agile Methods And The Business Analystc

Scrum, FDD, XP

Agile Methodologies

Project ManagementProject Management EngineeringEngineering

FDD

XPScrum

Page 13: Mark Foley   Agile Methods And The Business Analystc

Scrum: Lifecycle

8. Product Increment(potentially shippable)

6. Day

5. Sprint(2-4 weeks)4. Tasks

detailedby the team

1. Vision(ROI, milestones,

releases)

2. Product Backlog, with features

prioritized by the Product Owner

3. Sprint Backlog

7. Daily StandupMeeting

9. Inspect and Adapt

Page 14: Mark Foley   Agile Methods And The Business Analystc

Evolution of BA Role in XP

• XP view of requirements1. Onsite customer (implied singular customer)

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

Page 15: Mark Foley   Agile Methods And The Business Analystc

Evolution of BA Role in Agile

• XP view of requirements1. Onsite customer (implied singular customer)

2. Recognition that customer could be a team of people

‘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

Page 16: Mark Foley   Agile Methods And The Business Analystc

Evolution of BA Role in Agile

• XP view of requirements1. Onsite customer (implied singular customer)

2. Recognition that customer could be a team of people

3. Recognition of the role of a customer representative

Page 17: Mark Foley   Agile Methods And The Business Analystc

Scrum: Roles

• Alternative Name: User, Customer• Role Definition: The Product Owner represents the custumer/user/sponsor of the project,

and is part of the team which will deliver the product.•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.

• Alternative Names: Project Manager/Leader, Coach• 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.•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.

• Alternative Names: Developers, Technicians, Testers• Role Definition: A team member is someone committed to do the necessary work to

achieve the Sprint goal.•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.

Product Owner

Scrum Master

Team members

Page 18: Mark Foley   Agile Methods And The Business Analystc

Agile Requirements Techniques and Practices

Page 19: Mark Foley   Agile Methods And The Business Analystc

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

Page 20: Mark Foley   Agile Methods And The Business Analystc

Story Issues

• Content \ Level of Detail• Team size, distribution• Availability of Stakeholders

• Transitory• What Requirements Documents do we want\need to preserve

• How are they Evolved• Do we really want to jump straight to system functionality?

Page 21: Mark Foley   Agile Methods And The Business Analystc

Context

• Good Requirements (IEEE definitions)• Set is complete• Set is consistent• Set is modifiable

• Decomposition• Organize stories by relating to higher level artifacts

“If you lose a card, and if the customer does not detect that loss, then the card wasn’t very important.”Robert C. Martin

Page 22: Mark Foley   Agile Methods And The Business Analystc

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

Page 23: Mark Foley   Agile Methods And The Business Analystc

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

Page 24: Mark Foley   Agile Methods And The Business Analystc

User Involvement

• BA a substitute for user?• Agile characteristics to promote user involvement

• Frequent “releases”• Daily stand up

Page 25: Mark Foley   Agile Methods And The Business Analystc

The Agile Lifecycle

BA Effort

Time

Project Duration

Page 26: Mark Foley   Agile Methods And The Business Analystc

Up Front Effort

• JIT Requirements Elaboration vs Up front elaboration• JIT

• Rapid progress early• Earlier customer feedback• Could get blind-sided

• Up front Elaboration• More up front effort, more time till customer feedback• Clarify overall scope and size sooner

• Considerations• Cost\Effort of development• Governance framework, funding model• Uniqueness

Page 27: Mark Foley   Agile Methods And The Business Analystc

Cost to Change Curve

Cost of Change

Lifecycle Stage

$$

$

$

$‘What if we got good at reducing the costs of ongoing changes?Kent Beck, 1999

Page 28: Mark Foley   Agile Methods And The Business Analystc

The BA as a Tester

• Consider• Value of independent view• Specialized test activities

• Usability • Performance• Security

Page 29: Mark Foley   Agile Methods And The Business Analystc

Embrace Change

Individuals & Interactions over Processes & 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.”

http://www.agilemanifesto.org

Page 30: Mark Foley   Agile Methods And The Business Analystc

Session Objectives

• Review key characteristics of agile processes• Understand agile practices that impact the

BA• Learn to tailor agile requirements

techniques to match your project environment