Agile Presentation To IIBA MInneapolis

transcript

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

Agenda• A Brief Overview of Agile

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

• The Role of a Business Analyst on an Agile Project• Why Business Analysts Are Vital to Successful Projects

• 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 SwingHow the project manager

understood it...

Building a Tire SwingHow the architect

designed it...

Building a Tire SwingHow the programmer

wrote it...

Building a Tire SwingHow the business consultant

described it...

Building a Tire SwingHow the the projectwas documented...

Building a Tire SwingWhat operations

installed...

Building a Tire SwingHow the customer

was billed...

Building a Tire SwingHow it was

supported...

Building a Tire SwingWhat the customer

really needed...

Building a Tire SwingWhat the customer

really needed...

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.

imagine this non-existent product should be.• We then try to imagine what they are describing.

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.

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

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?

What percentage of features, as ultimately delivered, are rarely or never used by the product’s end-users?

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?

• A philosophy about software development.

• A philosophy about software development.• A collection of processes and practices that

uphold this philosophy.

uphold this philosophy.• A grassroots movement to fundamentally change

the approach to software development.

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

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.

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:

• 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%)

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.

of new information and learning.• The software we develop does not create value

for our customer at ‘point of plan’.

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

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

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

goals and a product vision.• Identifying the “value stream” for the proposed

product.

product.• Brokering effective information exchange

between the customer and the IT team.

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

Simply stated, the customer defines quality.

Agile: Requirements Planning

• Requirements evolve with greater product exposure.

• A lean principle: just enough, just in time.

• A lean principle: just enough, just in time.• Requirements are planned for delivery in

time-boxed iterations.

time-boxed iterations.• The development team creates and commits to

a definition of “done”.

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

• Understanding the customer’s needs is essential.

• Understanding the customer’s needs is essential.• Who are your customers?

• Understanding the customer’s needs is essential.• Who are your customers?• How will your customer use your product?

• Understanding the customer’s needs is essential.• Who are your customers?• How will your customer use your product?• What are your customers priorities?

• 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:

following form:As a <user>, I want <product requirement>,

so that <desired benefit>.

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

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

• The best method of conveying project progress.

• The best method of conveying project progress.• Building a better customer/IT relationship.

• The best method of conveying project progress.• Building a better customer/IT relationship.• Emergent requirements.

• The best method of conveying project progress.• Building a better customer/IT relationship.• Emergent requirements.• The product backlog.

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

decisions.• Taskboards can visually radiate project progress.

decisions.• Taskboards can visually radiate project progress.• Project documentation.

Agile: Assessment & Validation

• Delivering the solution in small bites.

• Delivering the solution in small bites.• Reviewing requirements during planning.

• Delivering the solution in small bites.• Reviewing requirements during planning.• Reviewing requirements during demo.

• Delivering the solution in small bites.• Reviewing requirements during planning.• Reviewing requirements during demo.• Requirements describe solution to business

needs.

needs.• Determining requirements as late as possible.

needs.• Determining requirements as late as possible.• Validating requirements through prioritizing

delivery.

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?

• Change happens, how do we embrace it?• Expanding our toolkit, redefining nails as

opportunities.

• Change happens, how do we embrace it?• Expanding our toolkit, redefining nails as

opportunities.• Continuous planning recognizes that change can

be good.

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 products emerge from designs that evolve as a result of information made available to the customer and project team.

Wrap-Up

• 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• bill@davisbase.org• http://www.davisbase.org• (949) 303-9109

Agile Presentation To IIBA MInneapolis

Technology