Your SlideShare is downloading. ×
Dollars and Dates are Killing Agile
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Dollars and Dates are Killing Agile

1,376

Published on

Agile teams speak in points and iterations, but project and business managers think in terms of dollars and dates. This conceptual and language barrier makes strategic business planning, funding, and …

Agile teams speak in points and iterations, but project and business managers think in terms of dollars and dates. This conceptual and language barrier makes strategic business planning, funding, and progress management a significant challenge for sustained large-scale Agile. This session will include multiple case studies from large-scale Agile adoptions that we were part of and have supported over the past 7 years and how Agile values/principles went beyond just the development organizational boundaries into strategic planning and management.

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

No Downloads
Views
Total Views
1,376
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Dollars and Dates are Killing Agile Brent Barton But I really DO have a & good excuse!Chris Sterling (in absentia) Agile 2012 Wed Aug 15, 2012 1
  • 2. Brent Barton•  Product Line Director, Rally Software•  Formerly President, Agile Advantage, Inc. (acquired by Rally in 2012)•  Passionate about business being able to take advantage of what Agile has to offer bbarton@rallydev.com•  Active practitioner delivering value www.rallydev.com.com using Agile Blog: gettingagile.com•  Previous roles include: CTO, Twitter: @brentbarton Development Manager, PMO Manager, Agile Coach, Mentor, Certified Scrum Trainer, ScrumMaster, Product Owner 2
  • 3. Agenda"  What is Business Value?"  How are Dollars and Dates Killing Agile?"  An Agile Business Roadmap –  Year 1: Reduce Carryover –  Year 2: Optimize Portfolio –  Year 3: Incremental Funding"  Questions & Answers 3
  • 4. Value 4
  • 5. An Agile Story… Hi Mom! 5
  • 6. Executive Feedback from Sonia This is the best, simplest, easiest to use application we have ever gotten inboth Customer Careand the Retail Stores!Whatever you all did, I want more of that! 6
  • 7. Pilot Agile Team Delivered Great Value Cost•  Employee Satisfaction Savings•  Customer Sat Revenue New Retention Revenue•  Cost Savings•  New Revenue •  through efficiency Shareholder Value Compliance Value Employee Customer Satisfaction Satisfaction 7
  • 8. * This diagram shows Scrum. Could be XP, Kanban, etcAgile* 8
  • 9. Value What’sIn-Between? Agile 9
  • 10. Value Demand Rhythm of the Business HumanCFO ResourcesCost Constraints People ConstraintsPortfolio/Budget 10
  • 11. Value DemandPortfolio/Budget Perfection Goes Here Agile 11
  • 12. ?Conclusion:(Except in cases of Perfection)Adaptive Planning StressesStrategic Portfolio Planning 12
  • 13. Typical Scaled Outcomes•  Business cannot take advantage of what Agile offers•  It is decided that Agile can’t scale•  Suboptimal results•  Agile is restarted several times –  (this time it will be different…) 13
  • 14. OK, SO WHAT SHOULD WE DO? 14
  • 15. Triple Constraints – Recognize Agile does not make constraints go away Scope Schedule Cost 15
  • 16. Is Value Defined in Contracts?•  Time and Materials (T&M)•  Fixed Price•  Cost Plus Incentive Fee•  IDIQ/Delivery orders –  or task orders These are cost-based! 16
  • 17. Balancing Decision Indicators Strategic ValueRequired tomake good Informs and Decisions Guides Quality Constraints (Schedule, Cost, Scope) Source: Jim Highsmith 17
  • 18. Complexity Requires Adaptive Planning•  It is not possible to completely specify an interactive system. Wegner’s Lemma, 1995•  Uncertainty is inherent and inevitable in software development processes and products. Ziv’s Uncertainty Principle, 1996•  For a new software system the requirements will not be completely known until after the users have used it. Humphrey’s Requirements Uncertainty Principle, c. 1998 18
  • 19. TipFocus on value delivery, informed by constraints and quality 19
  • 20. THE AGILE BUSINESS ROADMAP 20
  • 21. Agile Business RoadmapYear 1:    Reduce carryover"  Identify issues sooner"  Make decisions earlier"  Demonstrate progress frequently"  Focus on quality 21
  • 22. Planning for the Whole Organization
  • 23. m Roadmap Program Roadmap – Holistic view of Software, Hardware and Operations
  • 24. Story Map"  Areas of functionality/capabilities on top"  Place associated user stories vertically 24
  • 25. Story Map"  Draw line that represents viable release –  Customer features above the line are “in” –  Dotted line represents negotiability 25
  • 26. PATTERNS FOR SCALINGAGILE DELIVERY 26
  • 27. Component Teams "   “Component Team” structure "   Separate Product Backlog "   Managing dependencies is often serialized "   Problematic integration issues are typically faced if multiple components are required to release "   Use an “Integration Team” to pull components together "   Causes more rework than “Feature Team” structure 27
  • 28. Feature Teams "   “Feature Team” structure "   Uses common Product Backlog "   Integration is done in parallel "   Requires high levels of communication across teams to resolve integration issues "   Forces Product Owners to be more coordinated "   Sprints should be synchronized "   Cross team fertilization is a requirement to successfully deliver in parallel 28
  • 29. Definition of Done - Assert Quality"  Acceptance defined criteria for each"   Code checked in with reference to user story US#/Task#"  Unit tests written and passed "  Integration test written & passes"  Code compiles with no errors and no "   Test code reviewed warnings "  Environment requirements"  New code doesn’t break existing documented code "  Interface document updated/added"  Test case review (Dev to review and checked in to SVN test case written) "  Acceptance criteria verified"  Architectural impact assessed and complete artifacts updated if necessary "  All P1-P3 bugs for the story are"  Comments in code closed"  Error codes added "  Test approves user story"  Code reviewed by peer "  Story demonstrated to product owner and accepted on Target Platform 29
  • 30. Release Definition of Done"  Every release should have clear quality criteria"  With a “Release Definition of Done” you can understand targets better"  Measure the gap between the teams’ Definition of Done and a Release Definition of Done. –  This gap is a source of quality issues and represents significant risk to schedule 30
  • 31. Forming the Meta-Scrum “Establishing and Maintaining Top to Bottom 31 Transparency Using the Meta-Scrum”, AgileJournal
  • 32. Agile Business RoadmapYear 2:  Optimize Project Portfolio"  Identify emergent value"  Compare performance across portfolio"  Increase overall value/cost ratio"  Lower cost of compliance"  Deliver smaller batches"  Reduce stabilization periods"  Coordinate across groups 32
  • 33. PROCESS AUTOMATION &OPTIMIZATION WITH ADDITION OFAPPROPRIATE “SLACK” 33
  • 34. Traditional Source Control Code   Management Complete  Version  1   Integrate  for  Branch   Version  2   Debt   Main  Branch   Death  March   {   Debt  accrues  quickly  within  stabiliza7on  periods   34
  • 35. Flexible Source Control ManagementVersion 1 Version 2 Main Branch {Not Easy! Must have proper infrastructure to do this. 35
  • 36. Continuous Integration 36
  • 37. 37
  • 38. Agile Business RoadmapYear 3:  Incremental Funding"  Safe-fail environment"  Use experimentation as a competitive advantage"  Combat competitive threats"  Integrate technical & customer feedback promptly"  Aggressively use commit/transform/kill for portfolio optimization"  Pull initiatives through teams rather than pushing resources to projects 38
  • 39. Source: Johanna Rothman“Manage Your Project Portfolio”http://www.amazon.com/Manage-Your-Project-Portfolio-first/dp/B004SMU0OWPORTFOLIO MANAGEMENTDECISIONS:COMMIT, TRANSFORM, KILL 39
  • 40. Balancing Decision Indicators ValueQuality Constraints (Schedule, Cost, Scope) Source: Jim Highsmith 40
  • 41. Estimates are Unreliable and Still Useful"  Estimate using relative size"  Affinity Estimating technique* Affinity  Es7ma7ng  How-­‐To:  hJp://www.geMngagile.com/2008/07/04/affinity-­‐es7ma7ng-­‐a-­‐how-­‐to/   41
  • 42. Portfolio Level Interactions 42
  • 43. Transform 43
  • 44. Early Warning SignsEarly  Warnings:  • Broken  Builds  • Broken  Automated  Tests  • Broken  Custom  Thresholds   44
  • 45. Early  Warnings:  • Design  Debt  in  Duplica7on  (DRY)  • Technical  Debt  in  Code  Complexity  • Quality  Debt  in  Bug  DB  (Break/Fix)  • Other  Custom  Thresholds   45
  • 46. Quality – Technical Excellence Enhances Agility* Interaction Design Collaboration Build MonitorsTarget Hardware 46
  • 47. Project Portfolio Kill? Early  Warnings:   • When  transform  and  re-­‐”commit”  is  not  a  valid  op7on:   • “Kill”  should  be  an  op7on  on  the  table  MORE   47
  • 48. • Thank you!• Questions & Answers 48

×