Dollars and Dates are Killing Agile


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 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
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Dollars and Dates are Killing Agile

  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•  Active practitioner delivering value using Agile Blog:•  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
  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
  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
  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
  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” 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://­‐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