Being consistently wrong LAST Adelaide

Transcript

1. Tom Ridge Sta ff Engineer Culture Amp Father D&D Nerd Has Attack Eyebrows tom-j-ridge
2. Being consistently wrong Lots of time for questions at end if all goes well. 
 
 Otherwise fi nd me in the breaks / after the conf
3. Remote, distributed team Make a performance product Team morale not great
4. We’re well behind schedule
5. 12 24 Weeks Negative feedback loop One large up front project after another large up front project Whats a PM and designer going to do whilst theyre waiting for you to fi nish being horribly over-estimate Talk about feedback from customers being 2 x a year Release process / prd marketing Can’t really respond to urgent requests or leave without needing to push out time
6. We’re stuck in this loop
7. Large up-front project Horribly over-estimate We just got out of a 6 week turned into 6 months One large project behind estimate after another
8. Quality issues Not many chances to celebrate & learn Cut scope hurts product Poor collaboration Hard to respond to urgent requests Over-time
9. We’re always wrong About what our customers want About our estimates
10. “We need to improve our delivery predictability” About what our customers want About our estimates
11. Delivery Lead
12. Pyschological safety Team wants change New(ish) leadership Tech lead wants team to have a more managed backlog and good re fi nement too
13. How do we get out of this? Better collaboration Smaller projects Tighter feedback cycles (even if only for the team)
14. We want to move from this big build measure learn loop
15. Even if our customers are only using our product twice a year, I want us to be here Where we not only have a smaller loop, but we’re moving faster through that loop because
16. Tighter feedback loops Better quality & less risk Deliver value sooner Stronger collaboration Tech lead wants team to have a more managed backlog and good re fi nement too
17. I still have a big problem to solve
18. Estimation (Making sh*t up) Around this time - delivery predictability at our company was a big issue, as well
19. We’re bad at it So naturally instead of attempting to get better at it, I ruminated on why we shouldn’t do it instead
20. Estimation is waste We’re not adding value to the product We’re spending large amounts of time in meetings or discovery attempting to quanitfy something we’ve not done before when we could just be doing the thing
21. The larger the project the worse the estimate is going to be Start to think
22. The start of the project is when we know the least And sure - we can communicate con fi dence ranges but at the same time, we’re incentivising sticking to the plan instead of responding to change, which I dunno seems pretty anti-agile to me Ok but sure lets take those numbers that we’re con fi dent in and pad them
23. Wat? “No matter what estimate you give me as a Software Engineer, I am going to add 25-50% to it” We play games with estimates We play poker to tell you how long something will be We take times given to us and pull random math out of thin air so it sounds “right” do us Parkinson’s law tells us that work expands to fi ll the time available - so worse, when we pad the time - we end up taking longer anyway
24. Estimation isn’t forecasting We’re making guesses as to how long stu ff will take, but forecasting is about taking data about a system to predict how that system will behave
25. But we do need to be able to communicate when something is going to be done In my case - we have marketing and customer work to do before a release Depending on the release that may mean a decent deadline So what do we do?
26. How can I deliver on time? How can I ensure I deliver the thing I say I’m going to How can I ensure I don’t harm the team? How can I ensure I don’t harm the product? How do I deliver all that I set out to deliver?
27. Days remaining = # of stories remaining / (WIP / avg. cycle time) Instead of trying to estimate all the possible work, optimise the queue of work instead
28. Time for queue to process = size of queue / how fast the queue moves Seems pretty straightforward
29. 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 So I start tracking these 3 variables in a spreadsheet, each fortnight I review JIRA and collect data to help build a map of our system of work We dont track individuals - teams cards
31. What is my crystal ball telling me?
33. New small project
34. Small projects ✅ We continued to track this on a small trial project involving a smaller subset of the team and once again, this worked great
35. Large(r) projects..? But I was still worried about larger projects, we had a larger series of work planned for an entirely new domain for us, and I was pretty sure my magic 8 ball was going to feel like this
36. Well I don’t think its going to go quite as well - because we haven’t started to really optimise for 2 things and improve them
37. Size of the queue & how fast the queue moves 2 levers If I accept that the work is the work, then I can work to reduce the size of the queue and improve the fl ow of that queue
38. Days remaining = # of stories remaining / (WIP / avg. cycle time) This is the size of the queue part
40. User story mapping
41. https://jpattonassociates.com/the-new-backlog/
42. https://www.altexsoft.com/blog/a-complete-guide-to-user-story-mapping-process-tips- advantages-and-use-cases-in-product-management/ We start with our high level epics or objectives And our user activities - the big things your users are going to want to do, but is too big to fi t a single story Then we’re going to break that down further from highest priority to lowest and start marking out the releases For us we used a miro plugin that let us work with JIRA to accomplish this, if JIRA’s your thing EasyAgile makes a bunch of tools one of which is for user story mapping in JIRA. This let us explore and take a lot of the initial planned work and descope or deprioritise it. It let us learn more about the domain as a team You may not get to those other releases and that’s ok but you immediately develop a pretty focussed backlog
43. Shared understanding Outcomes > output Enables collaboration Helps us get to wrong sooner Quick anecdote about excalidraw designers and devs Importance of slicing already - mapping out release slices Impact on our projects - helped us learn a new domain
44. Days remaining = # of stories remaining / (WIP / avg. cycle time) This is the how fast the queue moves part
45. WIP
46. Keep WIP low Always less wip than # of team members - usually about 2 less Helped us to respond to urgent requests or mobbing on unblocking issues Encourages sharing of learning and domain knowledge Handle folks sick or team changes or have learning time In the same way that you’d be setting alarms if your systems were at 100% CPU, we don’t want our teams at 100% capacity at all times Increasing wip will increase time spent at each step in your system of work
47. Cycle Time
48. Variance You’ve heard me talk a lot about managing a queue, and that’s true But I haven’t talked about how we manage ensuring a relatively consistent processing time of each item in that queue and why its important
 So naturally, I’m going to talk about Maccas
49. Part of the problem we already have is that work can be very di ff erently sized. So that can make it di ffi cult to accurately assess when it will be done by Explain queing system and impact of large items in the queue or large orders
50. We can visualise this impact with the control chart in Jira where the variation in cycle time is displayed in these blue bands. This variance has a big impact on our magic equation
51. Days remaining = # of stories remaining / (WIP / avg. cycle time + variation) We now have to consider the days remaining as a lower and upper bound. And that upper bound is determined by the amount of variation in your cycle times
52. If we have a std deviation of 7 from our avg cycle time of 5 - we have a range of 20 - 48 days, far too big
53. How do we minimize variation?
54. How much capacity we have How work enters the system How work fl ows through the system Quick anecdote about excalidraw designers and devs Importance of slicing already - mapping out release slices Impact on our projects
55. Slicing, Re fi nement, and Backlogs
56. Anyone can pick the card up Shift-left on QA Backlogs kept small - to reduce waste and rework Shared learning Smallest card was a story
57. Less rework Less risk Less time spent in meetings
58. Slicing Coming into this larger project I was pretty clear that we needed to remove a lot of the variance around our cards. I also wanted to minimise the amount of time spent estimating in a re fi nement session vs outlining the desired customer outcomes. So we needed to learn collectively, how to slice our cards in order to try and make them roughly the same size.
59. Took this execerise - workshop hosted by colleagues Implemented next day Learning stuck - great example of short learning cycles More business options and fl exibility, easy to drop a story without the burden of sunk cost. Less time “underwater”, helps prevent assumptions which can lead to bloat
60. Is it 3 days worth of work? * Is it 3 days worth of work? - for some folk your smallest unit might be a day, we knew our legacy codebase was going to make stu ff hard * why this works - how much we can think in our head * And those small cards are going to be relatively consistently sized and move through your system of work that much easier * Its a pretty easy thought process / decision which is about how much time I want the team to think about estimation because the rest of the session is more important * Cant under-state how important this was for us. This quick check, if not we discussed and sliced
61. Role Function eg exports Seams eg “and” Allowed us to minimise variation by same sizing things Keep cycle times smaller because easier to process small things - eg easier to review a small PR compared to a large one
62. Mary & Tom Poppendieck - Lean Software Development “How can I learn most effectively? The answer is often to have many short learning cycles” Above all else I want to optimize the team for learning - that applies as much to creating short learning cycles through slicing at a story level, as it does at an epic, or project level. We want to create more opportunities for learning
63. Once we pull it in, we execute quickly But what happens when stu ff doesn’t go well?
64. Address bottlenecks
65. Create visibility over bottle necks
67. Swarm
68. Now we can forecast
69. By reducing our range
70. By reducing our range
71. We’re still bad at estimating
72. Is it 3 5 days worth of work?
73. We are consistently, frequently wrong
74. We are consistently, frequently learning
75. So what happened?
76. We have this mindset that delivering massive projects is amazing, that we fi nally made it over the fi nish line Break your work up into small batches and you get to celebrate just about every other week and not feel stressed from being over estimate
77. Team less stressed Bottlenecks addressed Quality improved Conversations become about value not dates More experimentation More team celebrations and learning Opp for tam member growth through leadership of projects
78. It’s worked in other teams, too
79. It’s just Lean Eliminate waste Amplify learning Decide as late as possible Deliver as fast as possible Empower the team Build integrity in See the whole
80. We’ve created a system that delivers consistent streams of value when we say we’re going to* Within a very acceptable range
81. So how can you do this yourself?
82. Measure Slice Optimise your queue By optimising for making your estimate more correct, you create dysfunction. By optimising for the queue, we were able to improve how the team worked, and how it felt to be in that team.

83. Recommended resources
84. Is it done yet? (How about now?) Slicing Heuristics #NoEstimates Lean software development (an agile toolkit) Spreadsheet Tool Michele’s great talk Neil Killick Allen Holub Mary and Tom Poppendieck’s book Link to spreadsheet there - will share the slides on LinkedIn 
 Linear B - dont love this tool personally but you might fi nd value
85. Link to slides
86. Link to slides
87. Tom Ridge Sta ff Engineer Culture Amp Father D&D Nerd Has Attack Eyebrows tom-j-ridge Colleague Jas giving a talk after this you should de fi nitely check out Can fi nd me on blue sky