Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Guerrilla portfolio management

2.709 Aufrufe

Veröffentlicht am

  • Als Erste(r) kommentieren

Guerrilla portfolio management

  1. 1. GUERRILLA LARGE SCALE PORTFOLIO PLANNING @ziobrando
  2. 2. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta
  3. 3. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD
  4. 4. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Developer
  5. 5. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Developer #Coach
  6. 6. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Agile #Developer #Coach
  7. 7. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Agile #Developer #Coach #Facilitator
  8. 8. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Agile #Developer #EventStorming #Coach #Facilitator
  9. 9. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Agile #Developer #EventStorming #Coach #Facilitator #Consultant
  10. 10. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Agile #Lean #Developer #EventStorming #Coach #Facilitator #Consultant
  11. 11. About me @ziobrando I do something else instead @ziobrandoAbout me avanscoperta #DDD #Agile #Lean #Entrepreneur #Developer #EventStorming #Coach #Facilitator #Consultant
  12. 12. THE ANTAGONIST The quintessential stereotype
  13. 13. OUR HERO
  14. 14. I am a certified X-Wing Fighter PilotTM Trust me!
  15. 15. Too obvious
  16. 16. WE NEED A BETTER HERO Ladies Gentlemen, let me introduce you Mr…
  17. 17. Drummer with Nirvana Singer Guitar with Foo Fighters Plus amazing appearances (QoTS) Cancelled a gig to bring the daughter to a party Didn’t cancel a show when he broke his leg on stage.
  18. 18. THE DARK SIDE OF CAPACITY PLANNING SOMETHING REALLY BASIC: JUST IN CASE
  19. 19. The setting • Large organisations • Multiple teams • Many concurrent projects • Shared portions of the codebase
  20. 20. Our resources
  21. 21. Empire’s capacity planning I need a fixed story-point/man-day ratio in order to convert the estimation into FTE1s, so that I can plan projects at full capacity. FTE = Full Time Equivalent. A unit of cost traditionally abused in the empire
  22. 22. Empire’s capacity planning I would be happy to get rid of this agile stuff and just get Guaranteed Dates of Delivery
  23. 23. My resources Risk management?
  24. 24. Rigid dress code Predictable salary Predictable value Excel-level replaceability
  25. 25. Empire’s capacity planning The business is growing so that I need to hire more developers in order to catch the new opportunities FTE = Full Time Equivalent. A unit of cost traditionally abused in the empire
  26. 26. My resources * Fred Brooks …1975 Nine women can’t make a baby in one month*
  27. 27. Our goal is to make 9 babies (projects) in 6 months! That’s the power of the force!
  28. 28. We must have parallel projects
  29. 29. THE UNTOLD QUESTION It’s still wired in Kahneman’s System One
  30. 30. I doubled the number of developers. Why the S*th can’t I double productivity?
  31. 31. It’s not about individuals, it’s about the bands
  32. 32. It’s about team’s capacity -Ramp-up time -Domain knowledge -Good teams have a style -Mastery of key practices
  33. 33. It’s about system capacity -Teams should be able to deliver independently -1 cross functional team -1 backlog -1 product owner That’s pretty much agile by the book
  34. 34. But in the empire… • Large organisations • Multiple teams • Many concurrent projects • Shared portions of the codebase
  35. 35. But in the empire… • Large organisations • Multiple teams • Many concurrent projects • Shared portions of the codebase •Teams can’t deliver by themselves
  36. 36. Cross Functional? The larger the organisation, the more the idea of Cross-Functional teams becomes a fairytale.
  37. 37. THE FORCE DOESN’T WORK What cannot be seen cannot be improved
  38. 38. Unfortunately • Large organisations • Multiple teams • Many concurrent projects
  39. 39. Unfortunately • Large organisations • Multiple teams • Many concurrent projects •Teams can’t deliver by themselves
  40. 40. Above the surface… Project #1 8 weeks Project #1 4 weeks Team Alpha Team Tango QA Integration team Project #1: 4 weeks Project #1: 2 weeks January February March Project #1: 3 weeks
  41. 41. Above the surface… Project #1 8 weeks Project #1 4 weeks Team Alpha Team Tango QA Integration team Project #1: 4 weeks Project #1: 2 weeks January February March Project #1: 3 weeks … and below
  42. 42. Above the surface… Project #1 8 weeks Project #1 4 weeks Team Alpha Team Tango QA Integration team Project #1: 4 weeks Project #1: 2 weeks January February March Project #1: 3 weeks … and below PO Clear business goal Visible team capacity Supporting goals, not so visible team capacity often, conflicting ownership
  43. 43. fairly common setup Frontline teams Service Teams With no cycles, hopefully
  44. 44. The problem looks like…. Dependent activities pile up in some teams more than others. Frontline teams experience delays from service and platform teams —> extra management rework Platform Service are burdened with growing incoming requests
  45. 45. My resources
  46. 46. My resourcesOur backlog is too full!
  47. 47. My resourcesOur backlog is too full! Our is overloaded too!!
  48. 48. Ours too !! My resourcesOur backlog is too full! Our is overloaded too!!
  49. 49. Ours too !! My resourcesOur backlog is too full! Our is overloaded too!! You haven’t seen mine!
  50. 50. Same problem
  51. 51. Show the problem -Find a way to visualise investigate the system constraint —> the real team capacity -Put key stakeholders in the same room and co-create the corresponding model
  52. 52. Guess where…
  53. 53. Guess where…
  54. 54. Whoops! -Once the constraint is visible, we can do sensible planning around that.
  55. 55. Once the constraint is visible…
  56. 56. Once the constraint is visible…
  57. 57. The empire view Heavily unbalanced system Many idle resources are not producing value Adding more resources to the system isn’t really improving the system
  58. 58. Theory of constraints Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  59. 59. There’s no 100% -Non bottleneck resources shouldn’t be allocated 100% - …or they’ll create more mess and interruptions around the bottleneck -Bottleneck resources shouldn’t be allocated 100% either - They’re humans - ripple effects are more expensive then slack.
  60. 60. ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  61. 61. Empire ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  62. 62. Empire Hide the system constraints ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  63. 63. Empire Hide the system constraints ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  64. 64. Empire Hide the system constraints Overload the bottleneck ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  65. 65. Empire Hide the system constraints Overload the bottleneck ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  66. 66. Empire Hide the system constraints Overload the bottleneck punish the bottleneck ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  67. 67. Empire Hide the system constraints Overload the bottleneck punish the bottleneck ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  68. 68. Empire Hide the system constraints Overload the bottleneck punish the bottleneck Recruit more people ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  69. 69. Empire Hide the system constraints Overload the bottleneck punish the bottleneck Recruit more people ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  70. 70. Empire Hide the system constraints Overload the bottleneck punish the bottleneck Recruit more people The constraint is still there, only worse ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  71. 71. Empire Hide the system constraints Overload the bottleneck punish the bottleneck Recruit more people The constraint is still there, only worse ToC Identify the constraint Exploit the bottleneck Subordinate the system to the constraint Elevate the constraint identify the new constraint
  72. 72. I played in Nirvana and in Foo Fighters
  73. 73. I played in Nirvana and in Foo Fighters But NOT at the SAME time!!
  74. 74. A CLOSER LOOK AT COSTS What cannot be seen cannot be improved
  75. 75. A simplified view costs accumulate during development phases apparently small or no cost in waiting to release Revenues pop in (minus operations)
  76. 76. Cost of delay Costs go down during development (apparently) no cost in waiting to release Revenues pop in (minus operations) End of period Cost of delay
  77. 77. Putting costs together It’s just man_days * average_salary. Easy.
  78. 78. Overall…
  79. 79. But if we mess it up…
  80. 80. My resources We’ll never finish that!
  81. 81. A CLOSER LOOK TO VALUE Can you control that?
  82. 82. Problem solving Does it happen in working hours only? Can you relate that to timesheet?
  83. 83. Learning Does it happen in working hours only? Can you relate that to timesheet?
  84. 84. There’s no direct linear connection between cost value Unless we want to destroy it
  85. 85. Interruptions While working on different projects they’re disruptive or ineffective They’re valuable while working on the same one
  86. 86. Dependencies Are they the root of all evil? What about self-inflicted mandatory dependencies?
  87. 87. Can’t solve the problem -Without allowing for some duplication -Without putting architecture under scrutiny -Without allowing some heterogeneity
  88. 88. Estimations An experienced agile team can be pretty good estimating their own activity
  89. 89. Estimations The same team is helpless estimating activities depending on somebody else
  90. 90. Estimations In corporate scenarios, the part which is out of control could easily get over 50% … yep, talking about #noestimates
  91. 91. Unfortunately, one of our key resources quit
  92. 92. Unfortunately, one of our key resources quit Unfortunately
  93. 93. Turnover Turnover is a major disruptive force It’s not bad luck.
  94. 94. It’s learning
  95. 95. Put the WiP under control Remember the old… stop starting, start finishing?
  96. 96. KEEP THE WIP SMALL That’s the real ‘corporate-level’ force
  97. 97. As you said… Nine women can’t make a baby in one month.
  98. 98. Oh c’mon…!
  99. 99. https://www.youtube.com/watch?v=JozAmXo2bDE
  100. 100. It’s viable -Build around the learning -create a shared (temporary) context -build together a vision (#UserStoryMapping, #EventStorming) -pride and ownership are your friends
  101. 101. Remember the old talks Software development is a learning process Working code is a side effect Still valid at this scale too
  102. 102. THE DARK SIDE OF HR
  103. 103. Rigid dress code Predictable salary Predictable value Excel-level replaceability
  104. 104. Rigid dress code Predictable salary Predictable value Excel-level replaceability What about TALENT?
  105. 105. Talent cannot easily be replaced Replaceability is for piano- bar, not for great bands Can you name a great band with continuous turnover? Can you name a band that outsourced? * …well Dave hasn’t really said that ;-)
  106. 106. A losing game If you’re not working to attract retain talent, then you’re actively working to lose talent
  107. 107. WRAP IT UP
  108. 108. The hard way Being counterintuitive means that you’ll have to fight for the basics Management with no specific IT background is very likely to blow it. IT background is no guaranteed recipe for success either
  109. 109. Can’t solve invisible problems Make the system constraint visible Make the implicit goals visible Make the system constraint visible Make the implicit goals visible
  110. 110. Competing goals Competition on key resources is poisonous Please STOP it (including the invisible part: bonuses etc.)
  111. 111. There is no 100% Slack is good think twice before throwing in resources, then think again
  112. 112. Not a process only It is an ecosystem, not a factory HR is part of the problem and of the solution Talent Pride are your friends
  113. 113. Dependencies are making the problem harder It’s an architecture governance problem too
  114. 114. Ecosystem it is always an ecosystem whether you like it or not ignoring this, just places yours at the lower end of the spectrum
  115. 115. THANKS alberto.brandolini@avanscoperta.it @ziobrando Special thanks to @papachrismatts for (re)opening my eyes at ALE 2015 Sofia www.infoq.com/presentations/theory-constraints-portfolio
  116. 116. REFERENCES http://www.infoq.com/presentations/theory-constraints-portfolio

×