Decarbonising Buildings: Making a net-zero built environment a reality
The Agile BA (Business Analyst)
1.
2. Introduction & Agenda
‣ Bill Gaiennie, Davisbase Consulting
‣ 17 years in software development.
‣ 7 years working with software development teams,
training, leading, and coaching Agile teams.
‣ Trained and coached over 500 teams ranging from
start-ups to Fortune 50 corporations.
‣ 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
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
3. Building a Tire Swing
How the customer described
what they wanted...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
4. Building a Tire Swing
How the project manager
understood it...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
5. Building a Tire Swing
How the architect
designed it...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
6. Building a Tire Swing
How the programmer
wrote it...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
7. Building a Tire Swing
How the business consultant
described it...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
8. Building a Tire Swing
How the the project
was documented...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
9. Building a Tire Swing
What operations
installed...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
10. Building a Tire Swing
How the customer
was billed...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
11. Building a Tire Swing
How it was
supported...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
12. Building a Tire Swing
What the customer
really needed...
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
13. 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
with development.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
14. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
spent gathering, elaborating, and
communicating product requirements?
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
15. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
16. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?
What percentage of requirements, as originally
defined, change during the course of the
project?
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
17. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?
What percentage of requirements, as originally
35% defined, change during the course of the
project?
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
18. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?
What percentage of requirements, as originally
35% 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?
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
19. Pop Quiz:
Waterfall Requirements Analysis
What percentage of overall project time is
50% spent gathering, elaborating, and
communicating product requirements?
What percentage of requirements, as originally
35% defined, change during the course of the
project?
What percentage of features, as ultimately
65% delivered, are rarely or never used by the
product’s end-users?
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
20. So what is
Software Project Reality?
31% IT projects will be cancelled
before completion
52% Completed projects cost on average
189% over their original estimates
17% Projects are completed on time
and on budget
Source: Standish Group Chaos Report 1995 - 2008
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
21. Make No Mistake About It...
Developing
Software
Is
TOUGH!
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
22. 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 identified improvements in the
following areas after adopting an Agile development approach:
82% Increase productivity
77% Increase product quality
78% Increase stakeholder satisfaction
37% Reduced costs
Source: Dr. Dobb’s Agile Survey, 2008
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
23. So, 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.”
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
24. The Agile Manifesto
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
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.
http://agilemanifesto.org/
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
25. Complicated Vs. Complex
Watch Making Weather
Developing Software
Is a Complex
Endeavor
‣ Thousands of parts, hundreds of steps to ‣ Difficulty to predict details about behavior or
assemble outcomes
‣ Intricate, delicate work, difficult to complete ‣ Outcomes are results of many variables
‣ Must work in specific order ‣ Variables that affect outcomes are difficult to
‣ In order for watch to work, the final build should impossible to predict reliably
reflect the original plan. ‣ Plans expect variability and deviation, then
‣ Deviation from plan is considered a defect. account for this in the plan
Complicated, but not complex Complex
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
26. 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.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
27. The BA’s Role on a Software Project
BABOK identifies the following:
• Enterprise Analysis
• Requirements Planning and Management
• Requirements Elicitation
• Requirements Analysis and Documentation
• Requirements Communication
• Solution Assessment and Validation
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
28. 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
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
29. 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.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
30. “Quality in a product or service
Agile BA Rule is not what the supplier puts in.
True product quality is more than It is what the customer gets out
just a measure of defects. and is willing to pay for. A
The customer defines quality. 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.”
s
l way - Peter Drucker
NotA
S ame
he
T ation
De stin
Simply stated,
the customer defines
quality.
31. 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.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
32. 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>.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
33. Agile: Analysis & Documentation
• Understanding “the why” can be as important as “the what”.
As an speaker, I want to As an attendee, I want to
make my presentation download the
available to attendees presentation, so that
online, so that I do not I share what I have
need to send it. learned.
• Information gems exist in knowing why our customers want
what they ask for.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
34. 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.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
35. Agile: Assessment and 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.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
36. Business Analysts Are Crucial
to 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.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
37. 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.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
38. Your Call To Action
‣ Find experts that can point you in
the right direction.
‣ Recognize that training is the
proper foundation on which
team’s build.
‣ It takes time to get good at
anything, Agile is no exception,
but the rewards are well worth it.
‣ Getting started is easier than you
might think.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
39. “Simplicity
does not precede
complexity,
it follows it.”
- Alan Perlis
“Whether your next project is
a SUCCESS or a failure
is not a matter of chance,
it is a matter of choice.”
- A wise Agile coach and trainer
40. Your Questions, My Answers
Note: For those questions we do not have time to answer during the webinar,
I will be providing a written response.
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
41. WRAP-UP
• Thank you.
• Bill Gaiennie, Davisbase Consulting
• bill@davisbase.org
• http://www.davisbase.org
• (949) 303-9109
Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden