Upload
bill-gaiennie
View
1.557
Download
0
Embed Size (px)
Citation preview
The Agile BAUnderstanding the BA Role
on an Agile Project
Presented byBill Gaiennie, Davisbase Consulting
Introduction and Agenda
Introduction and Agenda• Bill Gaiennie, DavisBase Consulting
– 15 years in software development– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda
Introduction and Agenda• Bill Gaiennie, DavisBase Consulting
– 15 years in software development– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda• A Brief Overview of Agile
Introduction and Agenda• Bill Gaiennie, DavisBase Consulting
– 15 years in software development– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda• A Brief Overview of Agile• The Role of a Business Analyst on a Project
Introduction and Agenda• Bill Gaiennie, DavisBase Consulting
– 15 years in software development– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda• A Brief Overview of Agile• The Role of a Business Analyst on a Project
• The Role of a Business Analyst on an Agile Project
Introduction and Agenda• Bill Gaiennie, DavisBase Consulting
– 15 years in software development– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda• A Brief Overview of Agile• The Role of a Business Analyst on a Project
• The Role of a Business Analyst on an Agile Project• Why Business Analysts Are Vital to Successful Projects
Introduction and Agenda• Bill Gaiennie, DavisBase Consulting
– 15 years in software development– 4 years working with software development teams, training,
leading, and coaching Agile teams.
Agenda• A Brief Overview of Agile• The Role of a Business Analyst on a Project
• The Role of a Business Analyst on an Agile Project• Why Business Analysts Are Vital to Successful Projects• Wrap-up and Q&A
Building a Tire Swing
Building a Tire SwingHow the customer described
what they wanted...
Building a Tire Swing
Building a Tire Swing
Building a Tire SwingHow the project manager
understood it...
Building a Tire Swing
Building a Tire Swing
Building a Tire SwingHow the architect
designed it...
Building a Tire Swing
Building a Tire Swing
Building a Tire SwingHow the programmer
wrote it...
Building a Tire Swing
Building a Tire Swing
Building a Tire SwingHow the business consultant
described it...
Building a Tire Swing
Building a Tire Swing
Building a Tire SwingHow the the projectwas documented...
Building a Tire Swing
Building a Tire Swing
Building a Tire SwingWhat operations
installed...
Building a Tire Swing
Building a Tire Swing
Building a Tire SwingHow the customer
was billed...
Building a Tire Swing
Building a Tire Swing
Building a Tire SwingHow it was
supported...
Building a Tire Swing
Building a Tire Swing
Building a Tire SwingWhat the customer
really needed...
Building a Tire SwingWhat the customer
really needed...
Building a Tire Swing
Developing Software is Tough!
Developing Software is Tough!• We are building something that doesn’t exist.
Developing Software is Tough!• We are building something that doesn’t exist.• Our customer is attempting to describe what they
imagine this non-existent product should be.
Developing Software is Tough!• We are building something that doesn’t exist.• Our customer is attempting to describe what they
imagine this non-existent product should be.• We then try to imagine what they are describing.
Developing Software is Tough!• We are building something that doesn’t exist.• Our customer is attempting to describe what they
imagine this non-existent product should be.• We then try to imagine what they are describing.• We then try to build the product we believe we
heard them describe.
Developing Software is Tough!• We are building something that doesn’t exist.• Our customer is attempting to describe what they
imagine this non-existent product should be.• We then try to imagine what they are describing.• We then try to build the product we believe we
heard them describe.• And finally, the first opportunity we have to
really see if we built a product that they need and want is after we are done withdevelopment.
Pop Quiz:Waterfall Requirements Analysis
Pop Quiz:Waterfall Requirements Analysis
What percentage of overall project time is spent gathering, elaborating, and communicating product requirements?
Pop Quiz:Waterfall Requirements Analysis
What percentage of overall project time is spent gathering, elaborating, and communicating product requirements?
50%
Pop Quiz:Waterfall Requirements Analysis
What percentage of overall project time is spent gathering, elaborating, and communicating product requirements?
50%What percentage of requirements, as originally defined, change during the course of the project?
Pop Quiz:Waterfall Requirements Analysis
What percentage of overall project time is spent gathering, elaborating, and communicating product requirements?
50%
35%What percentage of requirements, as originally defined, change during the course of the project?
Pop Quiz:Waterfall Requirements Analysis
What percentage of overall project time is spent gathering, elaborating, and communicating product requirements?
50%
35%What percentage of requirements, as originally defined, change during the course of the project?
What percentage of features, as ultimately delivered, are rarely or never used by the product’s end-users?
Pop Quiz:Waterfall Requirements Analysis
What percentage of overall project time is spent gathering, elaborating, and communicating product requirements?
50%
35%
65%
What percentage of requirements, as originally defined, change during the course of the project?
What percentage of features, as ultimately delivered, are rarely or never used by the product’s end-users?
DevelopingSoftware
IsTOUGH!
What is Agile All About?
What is Agile All About?
• A philosophy about software development.
What is Agile All About?
• A philosophy about software development.• A collection of processes and practices that
uphold this philosophy.
What is Agile All About?
• A philosophy about software development.• A collection of processes and practices that
uphold this philosophy.• A grassroots movement to fundamentally change
the approach to software development.
What is Agile All About?
• A philosophy about software development.• A collection of processes and practices that
uphold this philosophy.• A grassroots movement to fundamentally change
the approach to software development.
“Agility is more attitude than process, more environment than methodology.”
The Agile Manifesto
The Agile Manifesto
Individuals and interactions, over processes and tools.
The Agile Manifesto
Individuals and interactions, over processes and tools.Working software, over comprehensive documentation.
The Agile Manifesto
Individuals and interactions, over processes and tools.Working software, over comprehensive documentation.Customer collaboration, over contract negotiation.
The 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.
The 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 simply value the items on the left more.
Companies are Adopting Agile
Source: Dr. Dobb’s Agile Survey, 2008
Companies are Adopting Agile• Agile adoption has increased in the last several years across
the globe.
Source: Dr. Dobb’s Agile Survey, 2008
Companies are Adopting Agile• Agile adoption has increased in the last several years across
the globe.• Recent data suggests 69% of companies have adopted an
Agile approach in some form.
Source: Dr. Dobb’s Agile Survey, 2008
Companies are Adopting Agile• Agile adoption has increased in the last several years across
the globe.• Recent data suggests 69% of companies have adopted an
Agile approach in some form.
• Respondents to a recent survey shared improvements in the following areas after adopting an Agile development approach:
Source: Dr. Dobb’s Agile Survey, 2008
Companies are Adopting Agile• Agile adoption has increased in the last several years across
the globe.• Recent data suggests 69% of companies have adopted an
Agile approach in some form.
• Respondents to a recent survey shared improvements in the following areas after adopting an Agile development approach:– Productivity (82%)– Product Quality (77%)– Stakeholder Satisfaction (78%)– Reduced Costs (37%)
Source: Dr. Dobb’s Agile Survey, 2008
Why We Develop Software
Why We Develop Software• We develop software for our customers’ benefit.
Why We Develop Software• We develop software for our customers’ benefit.• Change can be good. Change is usually the result
of new information and learning.
Why We Develop Software• We develop software for our customers’ benefit.• Change can be good. Change is usually the result
of new information and learning.• The software we develop does not create value
for our customer at ‘point of plan’.
Why We Develop Software• We develop software for our customers’ benefit.• Change can be good. Change is usually the result
of new information and learning.• The software we develop does not create value
for our customer at ‘point of plan’.• An Agile approach may require us to be
comfortable with the traditionally uncomfortable.
The BA’s Role on a Project
The BA’s Role on a Project
BABOK identifies the following:
The BA’s Role on a Project
• Enterprise Analysis• Requirements Planning and Management• Requirements Elicitation• Requirements Analysis and Documentation• Requirements Communication• Solution Assessment and Validation
BABOK identifies the following:
The BA’s Role on an Agile Project
The BA’s Role on an Agile Project
• Enterprise Analysis• Requirements Planning and Management• Requirements Elicitation• Requirements Analysis and Documentation• Requirements Communication• Solution Assessment and Validation
Agile: Enterprise Analysis
Agile: Enterprise Analysis• Work with the customer to develop strategic
goals and a product vision.
Agile: Enterprise Analysis• Work with the customer to develop strategic
goals and a product vision.• Identifying the “value stream” for the proposed
product.
Agile: Enterprise Analysis• Work with the customer to develop strategic
goals and a product vision.• Identifying the “value stream” for the proposed
product.• Brokering effective information exchange
between the customer and the IT team.
Agile: Enterprise Analysis• Work with the customer to develop strategic
goals and a product vision.• Identifying the “value stream” for the proposed
product.• Brokering effective information exchange
between the customer and the IT team.• The correct scope for Agile projects isn’t defined
requirements, but the well articulated product vision.
Agile: Enterprise Analysis
Agile: Enterprise Analysis“Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for. A product is not quality because it is hard to make and costs a lot of money, as manufacturers typically believe. This is incompetence. Customers pay only for what is of use to them and gives them value. Nothing else constitutes quality.”
Agile: Enterprise Analysis“Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for. A product is not quality because it is hard to make and costs a lot of money, as manufacturers typically believe. This is incompetence. Customers pay only for what is of use to them and gives them value. Nothing else constitutes quality.”- Peter Drucker
Agile: Enterprise Analysis“Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for. A product is not quality because it is hard to make and costs a lot of money, as manufacturers typically believe. This is incompetence. Customers pay only for what is of use to them and gives them value. Nothing else constitutes quality.”- Peter Drucker
Simply stated, the customer defines quality.
Agile: Requirements Planning
Agile: Requirements Planning
• Requirements evolve with greater product exposure.
Agile: Requirements Planning
• Requirements evolve with greater product exposure.
• A lean principle: just enough, just in time.
Agile: Requirements Planning
• Requirements evolve with greater product exposure.
• A lean principle: just enough, just in time.• Requirements are planned for delivery in
time-boxed iterations.
Agile: Requirements Planning
• Requirements evolve with greater product exposure.
• A lean principle: just enough, just in time.• Requirements are planned for delivery in
time-boxed iterations.• The development team creates and commits to
a definition of “done”.
Agile: Requirements Planning
• Requirements evolve with greater product exposure.
• A lean principle: just enough, just in time.• Requirements are planned for delivery in
time-boxed iterations.• The development team creates and commits to
a definition of “done”.• BA’s help to negotiate standards and the
specifics of product requirements.
Agile: Analysis & Documentation
Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.
Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.• Who are your customers?
Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.• Who are your customers?• How will your customer use your product?
Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.• Who are your customers?• How will your customer use your product?• What are your customers priorities?
Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.• Who are your customers?• How will your customer use your product?• What are your customers priorities? • User Stories capture requirements using the
following form:
Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.• Who are your customers?• How will your customer use your product?• What are your customers priorities? • User Stories capture requirements using the
following form:As a <user>, I want <product requirement>,
Agile: Analysis & Documentation
• Understanding the customer’s needs is essential.• Who are your customers?• How will your customer use your product?• What are your customers priorities? • User Stories capture requirements using the
following form:As a <user>, I want <product requirement>,
so that <desired benefit>.
Agile: Analysis & Documentation
Agile: Analysis & Documentation
• Understanding “the why” can be as important as “the what”.
Agile: Analysis & Documentation
• Understanding “the why” can be as important as “the what”.
As an speaker, I want to make my presentation available to attendees online, so that I do not
need to send it.
Agile: Analysis & Documentation
• Understanding “the why” can be as important as “the what”.
As an speaker, I want to make my presentation available to attendees online, so that I do not
need to send it.
As an attendee, I want to download the
presentation, so thatI share what I have
learned.
Agile: Analysis & Documentation
• Understanding “the why” can be as important as “the what”.
As an speaker, I want to make my presentation available to attendees online, so that I do not
need to send it.
As an attendee, I want to download the
presentation, so thatI share what I have
learned.
• Information gems exist in knowing why our customers want what they ask for.
Agile: Requirements Communication
Agile: Requirements Communication
• The best method of conveying project progress.
Agile: Requirements Communication
• The best method of conveying project progress.• Building a better customer/IT relationship.
Agile: Requirements Communication
• The best method of conveying project progress.• Building a better customer/IT relationship.• Emergent requirements.
Agile: Requirements Communication
• The best method of conveying project progress.• Building a better customer/IT relationship.• Emergent requirements.• The product backlog.
Agile: Requirements Communication
• The best method of conveying project progress.• Building a better customer/IT relationship.• Emergent requirements.• The product backlog.• Burndown charts can help drive better project
decisions.
Agile: Requirements Communication
• The best method of conveying project progress.• Building a better customer/IT relationship.• Emergent requirements.• The product backlog.• Burndown charts can help drive better project
decisions.• Taskboards can visually radiate project progress.
Agile: Requirements Communication
• The best method of conveying project progress.• Building a better customer/IT relationship.• Emergent requirements.• The product backlog.• Burndown charts can help drive better project
decisions.• Taskboards can visually radiate project progress.• Project documentation.
Agile: Assessment & Validation
Agile: Assessment & Validation
• Delivering the solution in small bites.
Agile: Assessment & Validation
• Delivering the solution in small bites.• Reviewing requirements during planning.
Agile: Assessment & Validation
• Delivering the solution in small bites.• Reviewing requirements during planning.• Reviewing requirements during demo.
Agile: Assessment & Validation
• Delivering the solution in small bites.• Reviewing requirements during planning.• Reviewing requirements during demo.• Requirements describe solution to business
needs.
Agile: Assessment & Validation
• Delivering the solution in small bites.• Reviewing requirements during planning.• Reviewing requirements during demo.• Requirements describe solution to business
needs.• Determining requirements as late as possible.
Agile: Assessment & Validation
• Delivering the solution in small bites.• Reviewing requirements during planning.• Reviewing requirements during demo.• Requirements describe solution to business
needs.• Determining requirements as late as possible.• Validating requirements through prioritizing
delivery.
Business Analysts Are CrucialTo Agile Project Success
Business Analysts Are CrucialTo Agile Project Success
• Great products and happy customers begin and end with pliable requirements.
Business Analysts Are CrucialTo Agile Project Success
• Great products and happy customers begin and end with pliable requirements.
• Change happens, how do we embrace it?
Business Analysts Are CrucialTo Agile Project Success
• Great products and happy customers begin and end with pliable requirements.
• Change happens, how do we embrace it?• Expanding our toolkit, redefining nails as
opportunities.
Business Analysts Are CrucialTo Agile Project Success
• Great products and happy customers begin and end with pliable requirements.
• Change happens, how do we embrace it?• Expanding our toolkit, redefining nails as
opportunities.• Continuous planning recognizes that change can
be good.
Wrap-Up
Wrap-Up
• Great BA’s assist the customer is defining the best possible product, a standard consistently examined during the entire project.
Wrap-Up
• Great BA’s assist the customer is defining the best possible product, a standard consistently examined during the entire project.
• Great products emerge from designs that evolve as a result of information made available to the customer and project team.
Wrap-Up
• Great BA’s assist the customer is defining the best possible product, a standard consistently examined during the entire project.
• Great products emerge from designs that evolve as a result of information made available to the customer and project team.
• Great project teams promote open and honest communication, and utilize this information to tune their behavior.
Questions and Answers
• Previously submitted.• From the attendees.
Meeting Close
• Thank you.• Bill Gaiennie, Davisbase Consulting• [email protected]• http://www.davisbase.org• (949) 303-9109