WEBVTT 1 00:00:00.480 --> 00:00:04.570 Happy New Year everyone, and welcome to this reluctant product video. 2 00:00:04.600 --> 00:00:09.220 In this video, I am going to suggest a New Year's resolution to you. 3 00:00:09.250 --> 00:00:14.420 And that suggestion is to stop asking developers for estimates. 4 00:00:14.450 --> 00:00:17.060 No more estimates, no more velocity 5 00:00:17.080 --> 00:00:20.740 measurements, no more story points, none of those. 6 00:00:20.760 --> 00:00:22.020 Why? 7 00:00:22.050 --> 00:00:25.020 Because estimates kill innovation. 8 00:00:25.050 --> 00:00:30.240 They prevent you from building the right thing and they harm the bottom line. 9 00:00:30.320 --> 00:00:33.020 To begin with, estimates are based on this 10 00:00:33.050 --> 00:00:36.860 misconception of how software development works. 11 00:00:36.890 --> 00:00:39.260 Product people often think in analogies 12 00:00:39.290 --> 00:00:42.420 with manufacturing, but there is a problem with that. 13 00:00:42.450 --> 00:00:45.220 Manufacturing is about replication. 14 00:00:45.250 --> 00:00:47.460 Software development is not. 15 00:00:47.490 --> 00:00:51.940 Manufacturing is about making 100,000 copies of the same design. 16 00:00:51.970 --> 00:00:55.380 Software development creates only one copy. 17 00:00:55.410 --> 00:01:00.380 So this whole notion that handing over a design to the development team is somehow 18 00:01:00.410 --> 00:01:06.380 comparable to handing over a prototype to the factory floor, is bollocks. 19 00:01:06.410 --> 00:01:10.620 The notion that programming is merely implementation, 20 00:01:10.650 --> 00:01:16.290 like working out the details of a solved problem, is bollocks 21 00:01:16.320 --> 00:01:21.020 the notion that shaping and designing are inherently unpredictable, 22 00:01:21.050 --> 00:01:24.900 but programming is predictable, is bollocks. 23 00:01:24.930 --> 00:01:27.460 And deep in our hearts we already know this. 24 00:01:27.490 --> 00:01:29.900 Because if programming is just 25 00:01:29.930 --> 00:01:33.930 implementation, how come it takes so much time? 26 00:01:33.960 --> 00:01:37.850 How come that the development team has more people than the product team? 27 00:01:37.880 --> 00:01:42.020 if they are working on a solved problem or a predictable process? 28 00:01:42.050 --> 00:01:47.460 How come that building something requires more developers than designers? 29 00:01:47.490 --> 00:01:51.180 Let's take one of my recent software projects as an example. 30 00:01:51.210 --> 00:01:53.700 It had roughly 50,000 lines of code. 31 00:01:53.730 --> 00:01:57.660 I'm rounding the numbers here a bit for ease of calculation. 32 00:01:57.690 --> 00:02:00.740 So 50,000 lines of code. 33 00:02:00.770 --> 00:02:04.210 It was built by five developers in ten months time. 34 00:02:04.240 --> 00:02:09.300 That translates into, let's say, 50 lines of code per developer per day. 35 00:02:09.330 --> 00:02:12.020 How much time does it take to type 50 lines of code? 36 00:02:12.050 --> 00:02:15.260 Let's say, let's be generous, 20 minutes. 37 00:02:15.290 --> 00:02:21.170 So on an average eight hour workday, a developer spends 20 minutes on writing 38 00:02:21.200 --> 00:02:26.020 code and 7 hours and 40 minutes on something else. 39 00:02:26.050 --> 00:02:29.220 What are those 7 hours and 40 minutes per day spent on? 40 00:02:29.250 --> 00:02:32.860 They're spent on thinking, on problem solving. 41 00:02:32.890 --> 00:02:37.340 They are spent on designing solutions for unsolved problems. 42 00:02:37.370 --> 00:02:40.260 So if you think of it, there is no such 43 00:02:40.290 --> 00:02:43.900 thing as an implementation phase in software development. 44 00:02:43.930 --> 00:02:48.660 There's no transition from an unpredictable phase to a predictable one. 45 00:02:48.690 --> 00:02:51.860 In fact, all of software development is 46 00:02:51.890 --> 00:02:58.140 design, all of it is problem solving and all of it is unpredictable. 47 00:02:58.170 --> 00:03:01.300 And so most of the innovation in software 48 00:03:01.330 --> 00:03:05.740 development comes in fact, from developers. 49 00:03:05.770 --> 00:03:09.260 So asking for an estimate is like saying, 50 00:03:09.290 --> 00:03:14.340 hey guys, we, the product team, just invented the law of universal gravitation. 51 00:03:14.370 --> 00:03:16.700 Why don't you guys, the programmers 52 00:03:16.730 --> 00:03:21.760 implement this law by describing it in terms of particle physics and you need to 53 00:03:21.760 --> 00:03:23.740 tell us upfront how much time it's going to take. 54 00:03:23.760 --> 00:03:24.420 Should be easy, no? 55 00:03:24.450 --> 00:03:28.020 After all, we just described the problem for you at a higher level. 56 00:03:28.050 --> 00:03:31.060 You just need to fill in the blanks. 57 00:03:31.090 --> 00:03:32.980 Does that even make sense? 58 00:03:33.010 --> 00:03:34.860 No, of course it doesn't. 59 00:03:34.890 --> 00:03:39.060 In controlling the developers' time, we are hugely unfair to developers. 60 00:03:39.090 --> 00:03:41.180 But we are also hurting ourselves. 61 00:03:41.210 --> 00:03:43.700 When developers encounter an unforeseen 62 00:03:43.730 --> 00:03:49.140 problem or an opportunity for innovation, we are forcing them to choose between 63 00:03:49.170 --> 00:03:53.500 going over time or cut a few corners and live up to the estimate. 64 00:03:53.530 --> 00:03:56.380 But while they do that, they are looking 65 00:03:56.410 --> 00:04:00.300 at only one side of the balance sheet, the cost side of things. 66 00:04:00.330 --> 00:04:06.260 But in order to make a smart trade-off, a trade off that makes economical sense, 67 00:04:06.290 --> 00:04:13.460 developers need to understand the entire balance sheet. When they go over time, 68 00:04:13.490 --> 00:04:19.380 in addition, developers are making a guilt trip because estimates are promises that 69 00:04:19.410 --> 00:04:22.780 they can't really fulfill but need to live up to anyway. 70 00:04:22.800 --> 00:04:25.380 They constantly need to say, I thought 71 00:04:25.400 --> 00:04:29.060 this was going to take two days, but it's taking a little longer than I thought. 72 00:04:29.090 --> 00:04:36.460 This becomes very energy draining and makes developers feel dreadful. 73 00:04:36.480 --> 00:04:39.540 So this is not working. No more estimates. 74 00:04:39.570 --> 00:04:41.580 What alternatives do we have? 75 00:04:41.600 --> 00:04:45.180 For one, there's an answer to this problem in finance. 76 00:04:45.210 --> 00:04:50.980 In investment. We are going to place a stop-loss order. 77 00:04:51.010 --> 00:04:53.740 Investors use stop-loss orders all the time. 78 00:04:53.770 --> 00:04:56.420 An investor sees this stock with, let's say, 79 00:04:56.450 --> 00:05:01.700 a 100% upward potential, but they want to limit the downward risk. 80 00:05:01.720 --> 00:05:04.940 One of the instruments available to them is a stop-loss order. 81 00:05:04.970 --> 00:05:07.460 The investor says if this stock goes down 82 00:05:07.480 --> 00:05:11.180 by more than 10%, I will sell automatically. 83 00:05:11.210 --> 00:05:15.740 Yes, I will lose money, but I'm limiting my losses to 10%. 84 00:05:15.770 --> 00:05:19.460 A potential loss of 10% is an acceptable 85 00:05:19.480 --> 00:05:23.780 risk given the 100% upward potential of this stock. 86 00:05:23.800 --> 00:05:26.140 So if I spread my risk over multiple 87 00:05:26.160 --> 00:05:31.340 stocks and over time, overall, I will still be making money. 88 00:05:31.360 --> 00:05:34.700 We can apply the same idea to software development cycles. 89 00:05:34.730 --> 00:05:37.380 We start off by defining an opportunity in 90 00:05:37.410 --> 00:05:41.140 economical terms, preferably in terms of cost of delay. 91 00:05:41.170 --> 00:05:44.840 And we say this opportunity has a cost of 92 00:05:44.860 --> 00:05:50.020 delay of €20,000 per week for at least the next twelve months, roughly a million. 93 00:05:50.040 --> 00:05:52.740 So it has this big upward potential. 94 00:05:52.770 --> 00:05:56.420 The development team costs €10,000 per week. 95 00:05:56.450 --> 00:06:00.860 We, as a business are willing to risk eight weeks of development on this idea. 96 00:06:00.890 --> 00:06:04.500 So we have a shot at this million euros. 97 00:06:04.520 --> 00:06:06.480 Product management has shaped a bunch of 98 00:06:06.510 --> 00:06:09.500 ideas that the development team has prototyped. 99 00:06:09.530 --> 00:06:11.380 We have a plan B and a plan C. 100 00:06:11.410 --> 00:06:13.620 We talk them through with the whole team 101 00:06:13.650 --> 00:06:17.140 and we all feel reasonably confident about this plan. 102 00:06:17.170 --> 00:06:20.060 Reasonably confident is all you're going to get. 103 00:06:20.080 --> 00:06:21.540 Whether we're talking about software 104 00:06:21.570 --> 00:06:25.660 development or investment, reasonably confident is already good. 105 00:06:25.690 --> 00:06:32.300 So if everything works out, our expense is €80,000 in development cost. 106 00:06:32.320 --> 00:06:35.100 Right? Eight weeks times €10,000. 107 00:06:35.130 --> 00:06:40.180 But on the profit side, we have 52 minus 8 weeks - 108 00:06:40.210 --> 00:06:45.980 - we had this twelve month expectation of making cost of delay of €20,000, 109 00:06:46.010 --> 00:06:49.260 we spent eight weeks of those 52 on development, 110 00:06:49.290 --> 00:06:53.140 that leaves us with 44 weeks times €20,000 per week 111 00:06:53.170 --> 00:06:58.900 is €880,000 in profit. If things do not work out, 112 00:06:58.920 --> 00:07:02.100 we made €80,000 investment in development costs. 113 00:07:02.130 --> 00:07:03.980 Those are sunk costs. 114 00:07:04.010 --> 00:07:05.860 In addition, we lose the opportunity, 115 00:07:05.890 --> 00:07:08.380 but we learned something. 116 00:07:08.410 --> 00:07:12.620 As it turns out, the opportunity wasn't really there in the first place. After all, 117 00:07:12.650 --> 00:07:16.300 its realization turned out to be much more difficult than we thought. 118 00:07:16.330 --> 00:07:17.980 It was actually out of reach. 119 00:07:18.010 --> 00:07:19.860 It wasn't a real opportunity. 120 00:07:19.890 --> 00:07:24.740 Reality pushed back and we learned something. 121 00:07:24.770 --> 00:07:28.860 So let's place a stop-loss order at eight weeks of development. 122 00:07:28.880 --> 00:07:30.840 And after eight weeks, we either have the 123 00:07:30.860 --> 00:07:35.700 feature in place or we write off the opportunity in its entirety. 124 00:07:35.730 --> 00:07:38.740 Now, you might say this approach still requires estimation. 125 00:07:38.760 --> 00:07:40.480 After all, the development team needs to 126 00:07:40.480 --> 00:07:43.900 feel confident enough that they can build a feature in eight weeks, right? 127 00:07:43.920 --> 00:07:45.140 That is correct. 128 00:07:45.170 --> 00:07:48.780 But everyone understands that we are just placing a bet. 129 00:07:48.800 --> 00:07:50.580 Just like in the stock market. 130 00:07:50.600 --> 00:07:52.620 We're not going to blame anybody. 131 00:07:52.650 --> 00:07:54.700 The development team has been part of the 132 00:07:54.730 --> 00:08:00.140 decision making and they understand the economic costs and benefits of this bet. 133 00:08:00.170 --> 00:08:02.580 The development team also knows that there 134 00:08:02.600 --> 00:08:07.060 is a brick wall after eight weeks, and this helps them make the detailed 135 00:08:07.090 --> 00:08:11.220 day to day trade-offs without having to renegotiate with project and higher 136 00:08:11.250 --> 00:08:15.780 management who anyway understand very little of what's going on. 137 00:08:15.800 --> 00:08:20.360 So, reluctant project managers, let's make a meaningful difference this year in the 138 00:08:20.360 --> 00:08:22.860 lives of the programmers that we love and work with. 139 00:08:22.890 --> 00:08:25.820 We must stop asking for estimates. 140 00:08:25.850 --> 00:08:28.820 We need to stop making programmers' lives miserable. 141 00:08:28.850 --> 00:08:33.100 We need to start thinking in terms of economic trade offs. 142 00:08:33.130 --> 00:08:35.700 Getting it to work will take practice, but 143 00:08:35.730 --> 00:08:40.900 once you've mastered the techniques, you will see a whole slew of improvements in 144 00:08:40.930 --> 00:08:46.060 economic return, in coding standards, and most importantly, motivation. 145 00:08:46.080 --> 00:08:48.640 I wish you a very happy 146 00:08:48.670 --> 00:08:50.280 estimate-free 2023.