Uploaded byHelen Meek
Multiple team forecasting with Troy Magennis
The document discusses the complexities of multiple team forecasting in project management, highlighting the difficulties faced by both leaders and tech teams in accurately estimating timelines and dependencies. It emphasizes the importance of understanding when work can start rather than simply how long it will take, and suggests methodologies for forecasting based on historical data and prioritization. Solutions are proposed for managing dependencies and improving prediction accuracy, with a focus on optimizing resource utilization.
More Related Content
Similar to Multiple team forecasting with Troy Magennis
Multiple team forecasting with Troy Magennis
- 1.
- 2. WELCOME • The problemof multiple team forecasts • How “leaders” feel the problem • How “tech” feels the problem • This history of “forecasting” • Single piece of work by a team • Batch of pieces of work by a team • Single piece of work by multiple teams • Batch of pieces of work by multiple teams • What can we do…
- 3.
- 4. TECH FEELS… • Reliableestimation of new stuff impossible • They will be held accountable for unknowns • That leadership doesn’t understand difficulties
- 5. LEADERS FEEL… • Thejourney through uncertainty • Its NOT how long to build, its when it can be started given all of the other stuff…
- 6. When can we startthis work? If I said we needed it now, what gets dropped?
- 7. A 1-minute devchange that wont be started for 3 months takes - 3 months and 1 minute
- 8. WE ASK THEWRONG QUESTIONS • “When will it be done” <- root of all evil • Better • When do we need to know if it will be possible? • What don’t we know about delivering x and when will we know? • What can we most definitely get by date x? • What work should we start? • If we can’t start by x, then should we continue? • Keep options open until necessary!
- 9. RISK OF MULTIPLETEAM COORD • Every added team halves the chances of forecasting truth • 1 team is 50% base odds, then it’s all downhill • One chance in 2 power n Team 1 Delay On-time T 1 T 2 Delay On-time On-time On-time Delay Delay On-time Delay T 1 T 2 T3 Delay On-time On-time Delay On-time Delay Delay Delay On-time Delay Delay Delay On-time On-time On-time On-time On-time Delay On-time Delay On-time On-time Delay Delay https://observablehq.com/@troymagennis/impact-of- multiple-team-dependencies-in-software-developm
- 10. INTERACTION OF UTILIZATION& TIME A. Utilization has very little interaction with time B. Utilization has an exponential interaction with time
- 11.
- 12. KINGMANS FORMULA • Itsnot as simple as just utilization • Arrival rate • Cycle-time • If arrival is spread over time and is predictable, higher utilization is “OK” • If the cycle-time is relatively fast, higher utilization is OK • Meter the “on-ramps” https://observablehq.com/@troymagennis/the-economic-impact-of-high-system-utilization
- 13. WHERE DO WETRADE IDLE FOR RESPONSE TIME? • Where do we pay for “something” we may not need? • Something mostly idle or unused until … • Firefighting / Police • Insurance • WHERE COST IS HUGE • WHERE COST GROWS FAST WITH ELAPSED TIME It’s not that they are 10x firefighters; it’s that they have a near-immediate START
- 14. WHERE DO WETRADE RESPONSE TIME FOR NEVER IDLE? • Where are we unwilling to pay extra for response time, and rarely accept or allow idle… • Hospital Emergency Rooms • Surgical Waiting Lists • Software development? • CONSTRAINTS ON SPECIALIZATION • TRIAGE THOSE CONSTRAINTS Surgery takes the same time, its WHEN that surgery starts that matters to the patient!
- 15. Problem – We thinkplanning is about “how long something will take” (tooling, taught process, typical planning, etc)
- 16. WE CANNOT KNOW “whenwill it be done” unless we know “when will it start”
- 17.
- 18. FORECASTING SINGLE PIECESOF WORK • When I was younger, estimates were in hours based on hundreds of pages of specification • Then we moved to points (~2000) to somewhat account for system factors, still taught today • Cycle time and lead time historical data started to be used • Throughput started to be used rather than velocity • Monte Carlo methods started to be common
- 19. BATCHES OF WORKFOR ONE TEAM • Sum of total hours / number of “developers” • Burndown sum of points of count (estimated pace) • Burndown of the sum of points or count (velocity avg.) • Monte Carlo burndown on points or throughput • Reference class forecasting – based on prior work
- 20.
- 21. SINGLE PIECE WORKBY > 1 TEAM • Sum hour estimates for each teams’ work + contingency • Teams estimate # “sprints” and these are added • Teams predict and account for dependencies • Epics are created and estimated as a “meta-team” then traditional burndown method used at this level • Reference class forecasting used at this level “what is similar that we have done in the past like this”
- 22. BATCHES WORK BY> 1 TEAM (REALITY) • Quarterly planning • Big room planning • … • We look to understand what we “might get” completed in a period of time. • Regular planning swarming…
- 23.
- 24. DO DEPENDENCIES MATTER? •Not “all” (stop the red string) • Define dependencies…. None Some All
- 25. DO DEPENDENCIES MATTER? NoneSome All Longest Longest + Longest Thing 1 + Thing 2 + Thing 3 + Thing 4 + Thing 5
- 26. DO DEPENDENCIES MATTER? Sprint1 Sprint 2 Sprint 3 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Best Case Likely Case
- 27. FORECASTING PROCESS • Identifythe build order of the parts • “What needs to be done before “x” can START • Group the work into concurrent groups • Forecast the longest piece of work in each group • Account for late starting dates (other things going on) • Sum those forecasts • Minimum – just sum • Likely – 50% go longer by “x” sprints / or typical buffer • Extreme – 100% go longer by “x” sprints / or buffer
- 28.
- 29.
- 30.
- 31. CAN TEAMS PREDICTSTART DATE? • This is the problem • Teams having changing priorities • Teams “should” react faster to higher priorities • This is what teams and companies should do • If you can solve the “When will this be started” problem, you have solved multi-team forecasting
- 32. DOES PROCESS MATTER? •The longer the sprints, the more delay on “misses” • Do we need sprints (imagine a production outage)? • Prioritization • If the work in a group is done but… • Even if it takes 1 minute, if you can’t get that one minute until October, then the forecast is October + 1 minute • Managing Blockers on the “Longest”
- 33. WHAT CHANGES THEORDER WE “SHOULD” START THINGS
- 34. HOW CAN WEGET TEAMS TO KNOW WHAT TO START NEXT
- 35.