DDD Adelaide - Being Consistently Wrong

Transcript

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