I was watching a No Estimates video that someone tweeted recently and I was reminded why I hate and love No Estimates at the same time. The video in question is a No Estimates presentation by Allen Holub. You can find the video here.
I’d like to review the key points of the presentation and discuss the split personality of No Estimates.
0:20Â – “We need to stop doing all estimates, now” – As much as some No Estimate proponents say it isn’t about not doing estimates at all, these extreme statements arise again and again. There much be some kernel of truth that they truly believe in this statement. It seems only when no options are available do they concede that you could do estimates if needed.
0:25 – “Estimation has no value at all” – Not your call. The only person that defines value is the client. If the client determines estimates have value, then the estimates have value.
1:01 – “Estimates are always wrong” – Not true. Many estimates are correct. In fact, I’ve had more correct estimates than incorrect estimates in my career.
2:12 – “Estimation leads to dysfunction. Estimation leads to working endless hours without needing to” – This is just bad leadership. Trust me, if you didn’t provide estimates these bad leaders would find other ways to set up a toxic environment. This is not the fault of estimates.
2:55 – “As soon as you have estimates you can’t have a sustainable pace” – Again bad leadership. Estimates are made to evolve and change. Just like other aspects of Agile, our estimates also need to have short feedback loops so we learn from estimates and then modify the future estimates for the project. It is curious how No Estimates proponents are well versed in Agile, but can only envision doing estimation in a waterfall method. It seems like estimates were the only item on their Agile projects that weren’t Agile. If they considered estimation with short feedback loops, I can imagine they would be less adverse to estimates.
3:06 – “As soon as you have deadlines you have people working 18 hour days” – See bad leadership mentioned above. If this is your environment, don’t blame the estimates. There are much deeper problems.
3:23 – “Your boss asks you how long something will take and you have no idea how long it will take, so you make a wild ass guess” – Really? If you have 3-5 years experience and have no idea how long something will take, you might want to find another career. Now there are some components that if you haven’t done before, you really may not know. But for the most part we are building things where we have some experience building similar items in the past. (I exclude from this Research and Development projects. I have been on these and understand they can’t be estimated easily. But those projects are not common.)
5:00 – “People don’t understand how estimates work” – This I agree with. It does take a lot of effort and communication to manage expectations.
6:12 – “CHAOS Report – Projects are late 80% of the time because of bad estimates” – Incorrect and oversimplification. I have been on projects where we were late but that was caused by people leaving, client needs changing, scope creep, and many other factors.
I really do like some of what Allen says in regards to Velocity, but it seems that Allen doesn’t even want to commit to a steady team velocity if nothing changes. In a sense, Allen proposes committing to nothing.
13:29 – “Estimating Software is like estimating Physics – How long will it take to create a Warp Drive” – This is a ill conceived argument. If you are creating something that hasn’t been done before, I agree you can’t estimate it. 95% of all Software Development is a variation on existing patterns and you can estimate it. Not perfectly, but adequately.
14:46 – “There is a disconnect from the people on the team. The catcher is disengaged and need to be engaged” – Again another bad analogy. The catcher and batter are not on the same team. So no, the catcher doesn’t not need to be engaged with the batter’s ritual. The pitcher’s ritual yes. This analogy is just totally incorrect and as a result, is not compelling at all.
15:15 – “There is no difference is estimating and locking your door 7 times” – I hear this from No Estimates proponents now and then. Comparing estimating to known Psychological disorders is dangerous, insensitive, and unprofessional.
15:50 – “Instead of a year long project, how about a month long project?” – Now we get into the part of No Estimates that I love! Enough about bashing estimation. Let’s talk about how we should shorten the feedback loops and minimize inventory. I would propose that we can also do this when we estimate. It just takes good leadership and management of expectations.
19:09 – “Mentally Deranged” – This is similar to my comment earlier about comparing estimating to true Psychological Disorders. This is just unprofessional and terribly insensitive.
21:32 – “The Business decides what to build and you decide how long it will take” – Agree 100%. Most of the previous bad examples seem to propose environments where the managers determine the estimates. I have never been on a project like that. Every project I have been on has empowered the developers with creating their own estimates. So we have taken 21:32 to get to how estimating can work. OK
22:35 – “Managers just manage schedule” – Great managers and leaders spend less than 10% of their time managing a schedule. The vast majority is working issues and helping to remove roadblocks for the team. Again the concept of manager is the Waterfall manager instead of the Agile Servant Leader manager.
23:25 – Never mind previous point. 🙂
24:27 – “Waste is whatever does not put valuable Software into the client’s hands” – Allen changes the definition of waste here to suit his point. Waste is whatever doesn’t provide value, not valuable software. Estimates may still provide value to the client even if it doesn’t create software.
25:48 – “estimates don’t help, because you don’t know you in trouble until later in the project” – Huh? If I have estimates I will get feedback very quickly on whether we are in trouble. Again, this seems to imply a waterfall approach where you are not running iterations that you learn from every week.
30:04 – “counting stories is enough, we don’t need to estimate” – Allen’s point is we only need to make two decisions. Either we kill the projects because the end date is too far out or we can add people. That assumes the only criteria is date. He ignores the fact that the cost of the project may need to be known to ensure it makes money for the company. Killing the project wastes money already spent, adding people increases the cost of the project. As usual, No Estimates is ignoring the need for budgetary decisions.
34:00 – “User Story Map is not a static document” – exactly like estimates. Both are not static documents and they change all the time. But it takes effort and expertise to manage that change.
Summary
As you can see, I disagree with much of the presentation. I align myself with the concepts and principles of No Inventory that you find in No Estimates. I believe that No Inventory is crucial to successful Agile Projects.
The No Commitment and No External Empathy part of No Estimates I patently don’t agree with. Can estimates have adverse effects? Absolutely. But we need to manage those and appreciate why estimates help others in the business and managerial roles. Software Development Projects are there to make the corporation more money. We need to be careful to balance what makes sense from a Software Development point of view with what makes sense from a business point of view.
Agile PMO 