Agile for Business Analysts

1,903 views

Published on

A presentation to IIAB about Agile for Business Analysts

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,903
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
62
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Agile for Business Analysts

  1. 1. Agile Methods for Business Analysts © 2009 – 2010 SQUARE PEG CONSULTING, LLC ALL RIGHTS RESERVED
  2. 2. Today’s speaker John Goodpasture, PMP Program manager, system engineer, author, and coach Managing Principal Square Peg Consulting, LLC www.sqpegconsulting.com www.johngoodpasture.com
  3. 3. John’s new book • Agile in the enterprise • Multiple methodologies thoroughly explained • From business case to benefit capture PUBLISHED BY J. ROSS PUBLISHING
  4. 4. Production assistance for today’s presentation from Todd W. Ruopp A speaker, facilitator and coach who promotes understanding and integrated teamwork Co-founder & President of Unleashing Performance, Inc.™ Todd empowers professionals to develop the knowledge & ability to drive personal, professional and organizational growth. www.unleashingperformance.com
  5. 5. It’s not about productivity Dilbert We need 3 more programmers. Boss Use agile programming methods. Dilbert Agile programming does not mean doing more work with less people. Boss Find me some words that do mean that and ask again Dilbert™ is a creation of Scott Adams
  6. 6. It’s not the holy grail • Almost any methodology can be made to work on some project. • Any methodology can manage to fail on some project. • Heavy processes can be successful. • Light processes are more often successful, and more importantly, Alistair Cockburn the people on those projects credit the success to the lightness of the methodology.
  7. 7. It’s about requirements! And requirements analysis The Requirements Paradox • Requirements must be stable for successful development; but user requirements are never stable • We don’t want requirements to change, but because changing requirements are a known risk, we should provoke change now. Niels Malotaux
  8. 8. Requirements Dilemma Not everything the customer wants is known at the outset Requirements evolve with operational experience
  9. 9. Use Cases, User Stories, & Backlog Use Case Scenarios Actionable backlog User Stories Vignettes
  10. 10. Build in Increments Freeze requirements over short cycles Define a little, build a little Allow evolution Embrace change
  11. 11. No Big Bang! Waiting until the end invariably misses the mark
  12. 12. Five Essential Points
  13. 13. 1 Leadership & Management Embrace change — rather than fight it Accept incremental progress and results Respect short delivery cycles Keep value proposition current and relevant
  14. 14. 2 Best Value Method Orient best value to the customer or end-user Deliver the most bang as seen through the customer’s eyes
  15. 15. 3 Frequent & Incremental Most Important ELY REMNT EXT GE UR Deliver frequently & incrementally Respect urgency and the importance conveyed by the customer
  16. 16. 4 Small Teams Six to twelve people Self-managed Performance oriented
  17. 17. 5 Coach for success Focus relentlessly on outcomes, not activities Knock down barriers to team success Communicate to sponsor and beneficiaries
  18. 18. Value begins in the business case Business case is a framework for details The goal, the shape of the outcomes, not the details ‘Just enough’ for a mind’s eye of how it will be ‘Just enough’ for compelling attraction
  19. 19. Investment, Milestones & More Milestones, Investments, Vision, not Details will not Gantt charts not budgets specifications emerge Milestone
  20. 20. The Incremental Project 1+2+3=6 Most Urgent Most Important Least Urgent ortant Least Imp Partition project goals Sequence the most urgent first Schedule sequences to hit milestones
  21. 21. Time boxes regulate team work Increments of the backlog are delivered at milestones Work on Feedback Make Course Backlog Corrections TIMEBOX Milestone
  22. 22. Performance unit benchmarks Throughput - measures getting things into production Throughput - enables planning predictably
  23. 23. 3 Value is realized as the customer pays or accumulates an advantage 2 Project transforms investment to a more valuable outcome that advantages the customer 1 Sponsors investment
  24. 24. Throughput Accounting Measure Value Added to the business Throughput only measures “value added”
  25. 25. Cadence is the key
  26. 26. Plan to the horizon Team 1 Team 2 END Team 3 All time boxes are planned within one horizon
  27. 27. Benefit realization Each deliverable has potential benefit Benefit is not realized until customer pays and / or Benefit is realized when the deliverable advantages the customer
  28. 28. Beneficiary linkages Sponsor recovers investment Project manager earns the value of the deliverable Beneficiary pays according to the value of benefits
  29. 29. Unleashing Performance, Inc. ™ Helping people close the gap between performance and potential™ 407.401.3938 www.UnleashingPerformance.com
  30. 30. Square Peg Consulting, LLC Send John questions at info@sqpegconsulting.com PUBLISHED BY J. ROSS PUBLISHING

×