Dollars and Dates are Killing Agile

10,483 views
11,050 views

Published on

Agile teams speak in points and iterations, but project and business managers think in terms of dates and dollars. This conceptual and language barrier makes strategic business planning, funding, and project status reporting a significant challenge for Agile teams. Because of these barriers, many successful Agile/Scrum initiatives are discontinued or never expanded.

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

No Downloads
Views
Total views
10,483
On SlideShare
0
From Embeds
0
Number of Embeds
7,970
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Dollars and Dates are Killing Agile

  1. 1. Dollars  and  Dates  Are  Killing  AgileWednesday, November 2, 2011
  2. 2. Chris  Sterling Co-­‐founder  of  Agile  Advantage  and   VP  of  Engineering  (www.AgileAdvantage.com)   Author  of  Book  “Managing  SoBware   Debt:  Building  for  Inevitable  Change” Consults  on  soBware  technology,   Agile  technical  pracKces,  Scrum,  and   effecKve  management  techniques CerKfied  Scrum  Trainer InnovaKon  Games®  Trained   Email:  chris@sterlingbarton.com   Web:  hWp://www.agileadvantage.com Facilitator Blog:  hWp://www.geYngagile.com Follow  me  on  TwiWer:  @csterwa Open  Source  Developer 2Wednesday, November 2, 2011
  3. 3. Agenda Business  Value  and  Agility • How  AdapKve  Planning  Stresses  Strategic  Planning Balancing  Signal  to  Noise  at  Scale The  Agile  Business  Roadmap • Year  1:  Reduce  Carryover • Year  2:  OpKmize  Por_olio • Year  3:  Incremental  Funding • What  we  can  do  to  help  all  along  the  way Ques:ons  &  Answers 3Wednesday, November 2, 2011
  4. 4. ValueWednesday, November 2, 2011
  5. 5. What  is  Value? 5Wednesday, November 2, 2011
  6. 6. What  is  Value? 5Wednesday, November 2, 2011
  7. 7. AgileWednesday, November 2, 2011
  8. 8. Wednesday, November 2, 2011
  9. 9. Value AgileWednesday, November 2, 2011
  10. 10. Value What’s In-­‐Between? AgileWednesday, November 2, 2011
  11. 11. Wednesday, November 2, 2011
  12. 12. Value DemandWednesday, November 2, 2011
  13. 13. Value Demand Rhythm  of  the  BusinessWednesday, November 2, 2011
  14. 14. Value Demand Rhythm  of  the  Business Human   CFO Resources Cost  Constraints People  ConstraintsWednesday, November 2, 2011
  15. 15. Value Demand Rhythm  of  the  Business Human   CFO Resources Cost  Constraints People  Constraints PorEolio/BudgetWednesday, November 2, 2011
  16. 16. Wednesday, November 2, 2011
  17. 17. Value Demand PorEolio/BudgetWednesday, November 2, 2011
  18. 18. Value Demand PorEolio/Budget AgileWednesday, November 2, 2011
  19. 19. Value Demand PorEolio/Budget Perfec&on   Goes  Here AgileWednesday, November 2, 2011
  20. 20. 10Wednesday, November 2, 2011
  21. 21. ? 10Wednesday, November 2, 2011
  22. 22. Conclusion: AdapKve  Planning  Stresses   Strategic  Planning (Fine  Print:  **  Except  in  cases  of  PerfecKon  **) 10Wednesday, November 2, 2011
  23. 23. Typical  Outcomes Business  can’t  take  advantage  of  Adap:ve   Planning  methods It  is  decided  that  Agile  can’t  scale Subop:mal  results Restarted  several  :mes 11Wednesday, November 2, 2011
  24. 24. Balancing  Signal  to  Noise  at  ScaleWednesday, November 2, 2011
  25. 25. Balancing  Signal  Indicators   Value Quality Constraints Source:  Jim  Highsmith (Schedule,  Cost,  Scope) 13Wednesday, November 2, 2011
  26. 26. The  Agile  Business  RoadmapWednesday, November 2, 2011
  27. 27. Agile  Business  Roadmap Year 1:  Reduce carryover Iden:fy  issues  sooner Make  decisions  earlier Demonstrate  progress  frequently Focus  on  quality 15Wednesday, November 2, 2011
  28. 28. PaMerns  for  Scaling  Agile  deliveryWednesday, November 2, 2011
  29. 29. Component  Teams “Component  Team”  structure Separate  Product  Backlog Managing  dependencies  is  oBen   serialized ProblemaKc  integraKon  issues  are   typically  faced  if  mulKple   components  are  required  to  release Use  an  “IntegraKon  Team”  to  pull   components  together Causes  more  rework  than  “Feature   Team”  structure 17Wednesday, November 2, 2011
  30. 30. Feature  Teams “Feature  Team”  structure Uses  common  Product  Backlog IntegraKon  is  done  in  parallel Requires  high  levels  of   communicaKon  across  teams  to   resolve  integraKon  issues Forces  Product  Owners  to   be  more  coordinated   Sprints  should  be  synchronized Cross  team  ferKlizaKon  is  a requirement  to  successfully   deliver  in  parallel 18Wednesday, November 2, 2011
  31. 31. Story  Map Areas  of  func:onality/capabili:es  on  top Place  associated  user  stories  ver:cally 19Wednesday, November 2, 2011
  32. 32. Story  Map  -­‐  Next  Release Draw  line  that  represents  viable  release • Customer  features  above  the  line  are  “in” • DoMed  line  represents  nego:ability !" 20Wednesday, November 2, 2011
  33. 33. Forming  the  Meta-­‐Scrum 21Wednesday, November 2, 2011
  34. 34. DefiniKon  of  Done  -­‐  Assert  Quality Acceptance defined criteria for each Code checked in with reference to user story US#/Task# Unit tests written and passed Tested on FE Code compiles with no errors and no Integration test written & passes warnings Test code reviewed New code doesn’t break existing code Environment requirements documented Test case review (Dev to review test Interface document updated/added case written) and checked in to SVN Architectural impact assessed and Acceptance criteria verified 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 22Wednesday, November 2, 2011
  35. 35. Release  DefiniKon  of  Done Every  release  should  have  clear  quality  criteria With  a  “Release  Defini:on  of  Done”  you  can   understand  targets  beMer Measure  the  gap  between  the  teams’  Defini:on   of  Done  and  a  Release  Defini:on  of  Done. • This  gap  is  a  source  of  quality  issues  and  represents   significant  risk  to  scheduleWednesday, November 2, 2011
  36. 36. Release  DefiniKon  of  Done Every  release  should  have  clear  quality  criteria With  a  “Release  Defini:on  of  Done”  you  can   understand  targets  beMer Measure  the  gap  between  the  teams’  Defini:on   of  Done  and  a  Release  Defini:on  of  Done. • This  gap  is  a  source  of  quality  issues  and  represents   significant  risk  to  scheduleWednesday, November 2, 2011
  37. 37. Agile  Business  Roadmap Year 2:  Optimize Project Portfolio Iden:fy  emergent  value Compare  performance  across  porRolio Increase  overall  value/cost  ra:o Lower  cost  of  compliance Deliver  smaller  batches Reduce  stabiliza:on  periods Coordinate  across  groups 24Wednesday, November 2, 2011
  38. 38. Process  AutomaOon  &  OpOmizaOon   with  AddiOon  of  Appropriate  “Slack”Wednesday, November 2, 2011
  39. 39. TradiKonal  Source  Control  Management 26Wednesday, November 2, 2011
  40. 40. TradiKonal  Source  Control  Management Main  Branch 26Wednesday, November 2, 2011
  41. 41. TradiKonal  Source  Control  Management Code Complete Version  1 Integrate  for Branch Version  2 Main  Branch 26Wednesday, November 2, 2011
  42. 42. TradiKonal  Source  Control  Management Code Complete Version  1 Integrate  for Branch Version  2 Debt Main  Branch Death  March 26Wednesday, November 2, 2011
  43. 43. TradiKonal  Source  Control  Management Code Complete Version  1 Integrate  for Branch Version  2 Debt Main  Branch Death  March { Debt  accrues  quickly  within  stabilizaCon  periods 26Wednesday, November 2, 2011
  44. 44. Flexible  Source  Control  Management 27Wednesday, November 2, 2011
  45. 45. Flexible  Source  Control  Management Main Branch 27Wednesday, November 2, 2011
  46. 46. Flexible  Source  Control  Management Version 1 Main Branch 27Wednesday, November 2, 2011
  47. 47. Flexible  Source  Control  Management Version 1 Version 2 Main Branch 27Wednesday, November 2, 2011
  48. 48. Flexible  Source  Control  Management Version 1 Version 2 Main Branch { Not Easy! Must have proper infrastructure to do this. 27Wednesday, November 2, 2011
  49. 49. ConKnuous  IntegraKon 28Wednesday, November 2, 2011
  50. 50. 29Wednesday, November 2, 2011
  51. 51. Agile  Business  Roadmap Year 3:  Incremental Funding Safe-­‐fail  environment   Use  experimenta:on  as  a  compe::ve  advantage Combat  compe::ve  threats Integrate  technical  &  customer  feedback  promptly Aggressively  use  commit/transform/kill  for   porRolio  op:miza:on Pull  ini:a:ves  through  teams  rather  than  pushing   resources  to  projects 30Wednesday, November 2, 2011
  52. 52. PorEolio  Management  Decisions: Commit,  Transform,  Kill Source:  Johanna  Rothman “Manage  Your  Project  PorLolio” hNp://www.amazon.com/Manage-­‐Your-­‐Project-­‐PorLolio-­‐first/dp/B004SMU0OWWednesday, November 2, 2011
  53. 53. EsKmates  are  Unreliable  but  Useful Es:mate  using  rela:ve  size Affinity  Es:ma:ng  technique* Affinity  EsKmaKng  How-­‐To:  hWp://www.geYngagile.com/2008/07/04/affinity-­‐esKmaKng-­‐a-­‐how-­‐to/ 32Wednesday, November 2, 2011
  54. 54. Por_olio  Level  Project  Commitment 33Wednesday, November 2, 2011
  55. 55. Por_olio  Project  TransformaKon 34Wednesday, November 2, 2011
  56. 56. Early  Warning  Signs Early  Warnings: •Broken  Builds •Broken  Automated  Tests •Broken  Custom  Thresholds 35Wednesday, November 2, 2011
  57. 57. Early  Warnings: •Design  Debt  in  DuplicaOon  (DRY) •Technical  Debt  in  Code  Complexity •Quality  Debt  in  Bug  DB  (Break/Fix) •Other  Custom  Thresholds 36Wednesday, November 2, 2011
  58. 58. Project  Por_olio  Kill? Early  Warnings: •When  transform  and  re-­‐”commit”  is  not  a  valid  opOon: •“Kill”  should  be  an  opOon  on  the  table  MORE 37Wednesday, November 2, 2011
  59. 59. Thank  you! QuesOons  &  AnswersWednesday, November 2, 2011
  60. 60. Come  see  us  at  AgileAdvantage.com 39Wednesday, November 2, 2011

×