Being Consistently Wrong

Ditching estimation for cycle time forecasting and how it can make your team a better place to be

Transcript

1. Proudly sponsored by
2. Tom Ridge Sta ff Engineer Culture Amp Father D&D Nerd Has Attack Eyebrows tom-j-ridge
3. Play bingo and you can win
4. Being consistently wrong
5. Remote, distributed team Make a performance product Team morale not great
6. We’re well behind schedule
7. 12 24 Weeks
8. We’re stuck in this loop
9. Large up-front project Horribly over-estimate
10. Quality issues Not many chances to celebrate & learn Cut scope hurts product Poor collaboration Hard to respond to urgent requests Over-time
11. We’re always wrong
12. “We need to improve our delivery predictability”
13. Delivery Lead
14. Pyschological safety Team wants change New(ish) leadership
15. How do we get out of this?
18. Tighter feedback loops Better quality & less risk Deliver value sooner Stronger collaboration
19. I still have a big problem to solve
20. Estimation (Making sh*t up)
21. We’re bad at it
22. Estimation is waste
23. The larger the project the worse the estimate is going to be
24. The start of the project is when we know the least
25. Wat? “No matter what estimate you give me as a Software Engineer, I am going to add 25-50% to it”
26. Estimation isn’t forecasting
27. But we do need to be able to communicate when something is going to be done
28. How can I deliver on time?
29. Days remaining = # of stories remaining / (WIP / avg. cycle time)
30. Time for queue to process = size of queue / how fast the queue moves
31. Story Time in Progress Time in Review Time in QA Cycle Time Enable sharing for admins 4 2 1 7 Enable sharing for managers 3 1 2 6
35. New small project
36. Small projects ✅
37. Large(r) projects..?
39. Size of the queue & how fast the queue moves
40. Days remaining = # of stories remaining / (WIP / avg. cycle time)
42. User story mapping
43. https://jpattonassociates.com/the-new-backlog/
44. https://www.altexsoft.com/blog/a-complete-guide-to-user-story-mapping-process-tips advantages-and-use-cases-in-product-management/
45. Shared understanding Outcomes > output Enables collaboration Helps us get to wrong sooner
46. Days remaining = # of stories remaining / (WIP / avg. cycle time)
47. WIP
48. Keep WIP low
49. Cycle Time
50. Variance
53. Days remaining = # of stories remaining / (WIP / avg. cycle time + variation)
55. How do we minimize variation?
56. How much capacity we have How work enters the system How work fl ows through the system
57. Slicing, Re fi nement, and Backlogs
59. Less rework Less risk Less time spent in meetings
60. Slicing
62. Is it 3 days worth of work?
63. Role Function eg exports Seams eg “and”
64. Mary & Tom Poppendieck - Lean Software Development “How can I learn most effectively? The answer is often to have many short learning cycles”
65. Once we pull it in, we execute quickly
66. Address bottlenecks
69. Swarm
70. Now we can forecast
73. We’re still bad at estimating
74. Is it 3 5 days worth of work?
75. We are consistently, frequently wrong
76. We are consistently, frequently learning
77. So what happened?
79. Team less stressed Bottlenecks addressed Quality improved Conversations become about value not dates More experimentation More team celebrations and learning
80. It’s worked in other teams, too
81. It’s just Lean
82. We’ve created a system that delivers consistent streams of value when we say we’re going to*
83. So how can you do this yourself?
84. Measure Slice Optimise your queue
85. Recommended resources
86. Is it done yet? (How about now?) Slicing Heuristics #NoEstimates Lean software development (an agile toolkit) Spreadsheet Tool
87. Tom Ridge Sta ff Engineer Culture Amp Father D&D Nerd Has Attack Eyebrows tom-j-ridge
88. Proudly sponsored by