Your SlideShare is downloading. ×

Postcards From The Agile Frontier Final


Published on

Chicagoland IIBA presentation, March 3, 2010

Chicagoland IIBA presentation, March 3, 2010

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Note about title: shows I’m a BA: a really agile person would have entitled this “tweets frm the frntr”
  • Colors here are hard to read—for “Visibility, Adaptability, and Business Value,” the top line represents agile development. For “Risk,” the top line represents traditional development and the bottom line represents agile development.
  • Product Owner: says what should be done and whyScrum Master: makes sure agile processes are followedTeam: does everything else
  • Oh oh. (Comes from Dean Leffingwell’s site)
  • Anecdote: Bally Scrum Master Training
  • The Goal Eliot Goldratt – read it! Simon Sinek “Start with the Why”
  • Transcript

    • 1. Postcards from the Agile Frontier
      IIBA Meeting
      March 3, 2010
      Elena Yatzeck
    • 2. Agenda
    • 3. Agenda
    • 4. Agile Basics
      For purposes of this presentation, “agile” means an iterative software development process based on the Agile Manifesto, drafted in 2001 and signed by a set of people who have gone on to define significant additional details since then.
      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.
      Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning,JimHighsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
      Visit: for more!
    • 5. Obligitory Blurry Photo of Manifesto Signers
    • 6. Sample Agile Process (Scrum)
    • 7. Full Project: the Agile Difference
    • 8. Why is Agile Popular?
    • 9. Agile Artifacts
    • 10. Agenda
    • 11. Classic Agile Roles
    • 12. Where does the BA fit in?
    • 13. Two Helpful Facts To Know
      Classic Agile “simplifies” by removing the BA role from the roster.
      Actual Agile Projects of Any Scale Always Use Business Analysts
      Standard role at ThoughtWorks (their roles are: PM, BA, Dev, and Test)
      Standard in WBS illustration used by Rally SCM trainers
      Standard in most classic texts on “Agile at Scale”
    • 14. Agile BA Roles Attempted at NAVTEQ
      Role 1: Business Analyst
      Role 2: Part of 4-Headed Product Owner Team
      Role 3: Representative for Product Owner (“Product Proxy”)
      Role 4: Scrum Master
      Role 5: Tester/QA (not tried, but we’re intending to)
    • 15. Role 1: Business Analyst
    • 16. Agile Artifacts at Scale
    • 17. Role 2: Part of “Product Owner Team”
    • 18. Role 3: Representative for Product Owner (“Product Proxy”)
      At NAVTEQ, Product Management is not available for daily scrum
      For our 2010 Pilots, we have created a “Product Proxy” role
      PO is available at product inception, and for start and end of sprints
      PP is 100% dedicated, and stays in frequent contact with PO
    • 19. Role 4: Scrum Master
      Ferry versus Bridge
      Fowler describes the relationship between business and technology as the “Yawning Crevasse of Doom”
      The traditional BA might be described as building a ferry (over the crevasse) between business and technology through written requirements
      Fundamentally, the SCM is a person presiding over a process which builds a permanent bridge over that chasm—same function, different technique
    • 20. Role 5: Tester/QA Role
      “Post-Agile” Techniques Include:
      Test Driven Development
      User Acceptance Test Driven Development
      At simplest:
      BAs write unit, system, and user acceptance criteria for each story, and QA approves
      BA/QA role melds: the user acceptance criteria IS the requirement set
      BA/QA/Dev role melds: automated testing tools allow the requirements to be actually encoded as part of the code base. BA/QA/Dev are all able to do this tool-based encoding.
    • 21. What You Found
      …what has worked at your company?
    • 22. Agenda
    • 23. The Bottom Line
      First principle of the Agile Manifesto: We Value…“Individuals and interactions over processes and tools”
      In our experience, the BA is often the individual who makes a project make sense.
      That is not going away!
    • 24. Three Classics for More Reading
      Agile Project Management: Creating Innovative Products (2nd Edition) by James A. Highsmith (Paperback - July 20, 2009).
      Agile Project Management with Scrum (Microsoft Professional) by Ken Schwaber (Paperback - Feb. 11, 2004)
      Agile Software Development: The Cooperative Game (2nd Edition) by Alistair Cockburn (Paperback - Oct. 29, 2006)
    • 25. About Elena
      Elena Yatzeck is Director of Software Specifications within the Architecture and Software Engineering group at NAVTEQ. She has 25+ years of experience in IT software engineering, mostly in the education and digital data industries.
      Elena is PMP and Scrum Master certified. A Phi Beta Kappa graduate of Dartmouth College, she earned her MA and PhD at the University of Chicago, as well as completing 8 of 20 courses towards her MBA at the Chicago Booth School of Management.
      Reach her at