0
Introduction & Agenda
‣   Bill Gaiennie, Davisbase Consulting
‣   17 years in software development.
‣   7 years working wi...
Building a Tire Swing
 How the customer described
    what they wanted...




   Copyright 2010 Davisbase LLC. Distributio...
Building a Tire Swing
  How the project manager
      understood it...




   Copyright 2010 Davisbase LLC. Distribution w...
Building a Tire Swing
             How the architect
               designed it...




   Copyright 2010 Davisbase LLC. Di...
Building a Tire Swing
       How the programmer
           wrote it...




   Copyright 2010 Davisbase LLC. Distribution w...
Building a Tire Swing
 How the business consultant
       described it...




   Copyright 2010 Davisbase LLC. Distributio...
Building a Tire Swing
         How the the project
         was documented...




   Copyright 2010 Davisbase LLC. Distrib...
Building a Tire Swing
                What operations
                  installed...




   Copyright 2010 Davisbase LLC. ...
Building a Tire Swing
             How the customer
               was billed...




   Copyright 2010 Davisbase LLC. Dist...
Building a Tire Swing
                        How it was
                       supported...




   Copyright 2010 Davisba...
Building a Tire Swing
           What the customer
            really needed...




   Copyright 2010 Davisbase LLC. Distr...
DEVELOPING SOFTWARE IS TOUGH!

•   We are building something that doesn’t exist.

•   Our customer is attempting to descri...
Pop Quiz:
Waterfall Requirements Analysis
   What percentage of overall project time is
   spent gathering, elaborating, a...
Pop Quiz:
 Waterfall Requirements Analysis
      What percentage of overall project time is
50%   spent gathering, elabora...
Pop Quiz:
 Waterfall Requirements Analysis
      What percentage of overall project time is
50%   spent gathering, elabora...
Pop Quiz:
 Waterfall Requirements Analysis
      What percentage of overall project time is
50%   spent gathering, elabora...
Pop Quiz:
 Waterfall Requirements Analysis
      What percentage of overall project time is
50%   spent gathering, elabora...
Pop Quiz:
 Waterfall Requirements Analysis
      What percentage of overall project time is
50%   spent gathering, elabora...
So what is
Software Project Reality?

31%              IT projects will be cancelled
                 before completion


...
Make No Mistake About It...


     Developing
      Software
          Is
  TOUGH!
     Copyright 2010 Davisbase LLC. Dist...
Companies Are Adopting Agile
‣ Agile adoption has increased in the last several years across
  the globe.
‣ Recent data su...
So, What Is Agile All About?

•   A philosophy about software development.

•   A collection of processes and practices th...
The Agile Manifesto

     We are uncovering better ways of developing software by doing it
    and helping others do it. T...
Complicated Vs. Complex
                Watch Making                                                                      ...
Why We Develop Software

•   We develop software for our customers’ benefit.

•   Change can be good. Change is usually the...
The BA’s Role on a Software Project

   BABOK identifies the following:
    •   Enterprise Analysis
    •   Requirements Pl...
The BA’s Role on an Agile Project

•   Enterprise Analysis

•   Requirements Planning and Management

•   Requirements Eli...
Agile: Enterprise Analysis

•   Work with the customer to develop strategic goals and a
    product vision.

•   Identifyi...
“Quality in a product or service
   Agile BA Rule                    is not what the supplier puts in.
True product qualit...
Agile: Requirements Planning

• Requirements evolve with greater product exposure.
• A lean principle: just enough, just i...
Agile: Analysis & Documentation


• Understanding the customer’s needs is essential.
• Who are your customers?
• How will ...
Agile: Analysis & Documentation

• Understanding “the why” can be as important as “the what”.


   As an speaker, I want t...
Agile: Requirements Communication

• The best method of conveying project progress.
• Building a better customer/IT relati...
Agile: Assessment and Validation


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

• ...
Business Analysts Are Crucial
        to Agile Project Success
• Great products and happy customers
  begin and end with p...
Wrap Up

• Great BA’s assist the customer is defining the best possible
  product, a standard consistently examined during ...
Your Call To Action

                                            ‣    Find experts that can point you in
                 ...
“Simplicity
   does not precede
complexity,
          it follows it.”
              - Alan Perlis



“Whether your next pr...
Your Questions, My Answers
Note: For those questions we do not have time to answer during the webinar,
      I will be pro...
WRAP-UP



• Thank you.
• Bill Gaiennie, Davisbase Consulting

• bill@davisbase.org

• http://www.davisbase.org
• (949) 30...
The Agile BA (Business Analyst)
Upcoming SlideShare
Loading in...5
×

The Agile BA (Business Analyst)

5,458

Published on

Are you a business analyst (BA) being asked to join an Agile project. Wonder what you are in for?

Published in: Technology

Transcript of "The Agile BA (Business Analyst)"

  1. 1. 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
  2. 2. Building a Tire Swing How the customer described what they wanted... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  3. 3. Building a Tire Swing How the project manager understood it... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  4. 4. Building a Tire Swing How the architect designed it... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  5. 5. Building a Tire Swing How the programmer wrote it... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  6. 6. Building a Tire Swing How the business consultant described it... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  7. 7. Building a Tire Swing How the the project was documented... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  8. 8. Building a Tire Swing What operations installed... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  9. 9. Building a Tire Swing How the customer was billed... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  10. 10. Building a Tire Swing How it was supported... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  11. 11. Building a Tire Swing What the customer really needed... Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 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 35% defined, change during the course of the project? Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  17. 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? 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
  18. 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 65% delivered, are rarely or never used by the product’s end-users? Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  19. 19. 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
  20. 20. Make No Mistake About It... Developing Software Is TOUGH! Copyright 2010 Davisbase LLC. Distribution without express permission is forbidden
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. 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
  29. 29. “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.
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. “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
  39. 39. 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
  40. 40. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×