Hi Willem-Jan, all great points and questions!
Even though my post was somewhat emphatically stated, I am well aware that the actual practicalities of starting to implement something like this would need to be handled a great deal more delicately. Each context will differ based on numerous different things, including the management.
I agree there are all sorts of underlying issues, and I would consider trying to move to a more “no estimates” (it’s not a great name, there is still some estimation, just a different sort) not as tackling a symptom, but instead helping break old mindsets — many of which are held by very well meaning people. I think you said it best when you said “estimates are there to predict the future as good as we can” — a lot of people don’t really get that that’s exactly what they are doing when coming up with an estimate — predicting, not planning, the future.
So, to some of your points…
With a limited budget and a number of initiatives, how are you going to choose which initiative to pick? Is it the one with the biggest value? How do you know this value if you have no idea about the estimated costs?
Deciding something’s value is one of the hardest things to do. However, often there can be an over-reliance on using how much something will cost to do, rather than looking at other factors. It can be much more useful to ask “how much will this cost us if we don’t do it”. Realistically for any business priority should be based on money saved or made, but often it isn’t, we do things because they are small and easy, or we do them because some executive wants that feature. Taking ‘cost to do’ off the table until later in the discussion can help focus on what the value really is. This one is easier to talk about in a specific context — there are so many different types of work and projects. Choosing which of two applications to build is very different than choosing which features to add to an existing application.
How will dropping estimates help you out in a bad management situation as described above? Is management magically going to accept no estimates where they previously misused estimates as certainties?
It’s not going to magically fix bad management, but neither is continuing on the same as before. It would force an uncomfortable conversation, but as we both know it would be better to understand the context and the root of why we were seeing those specific management behaviours, and seek to work on those.
We simply are bad at estimating. Why would one invest in this then?
The accuracy that something can be estimated will obviously be very specific to the type and size of work we are discussing. The key factor here is the scope of the unknowns. If there are hardly any unknowns then estimating is easier, if everything is unknown then it’s impossible (I actually sometimes do work in spaces where everything is unknown — new technology, no real requirements). The key thing here is to make sure you are getting a return on your investment. I see many projects spend way too long on estimation exercises, and not really ever consider the amount of money spent on having the whole team in meetings. A lot of money can be spent working out how much money will need to be spent — with finite budget let’s make sure we are spending it wisely and not using it to create overly detailed estimates when much more high level ones would have sufficed.
How do you determine the priority without knowing the estimated costs? You might invest in something that may turn out to be costing far more than you will ever get back.
We did talk about this a bit before. The first thing of course is making sure your prioritisation process is really properly about value — something I’m not even going to pretend is easy. The second is that agile processes are designed to provide the checks and balances to prevent you investing too much in something that won’t add value. When you start doing something you reduce the number of unknowns and allow a better understanding of the amount of work involved, and hopefully the value that will be gained. At the end of each iteration (hopefully only a week or two) you should always be willing to consider something a sunk cost and pivot away from if it becomes apparent that it will cost you far more than you will ever get back.
I have to say I’ve seen things with very detailed estimates created also end up costing far more than was every got back. This one is a risk that isn’t possible to completely remove from software development.
Estimates, No Estimates, Some Estimates…
This is where the discussion gets interesting. There are so many types of things that could be considered estimates, and they aren’t all the same.
For instance, I would recommend breaking work down into small pieces (let’s call them “stories”, although that depends on your own agile flavour). That is in itself a way of estimating the work. It works for the immediate future of what is being worked on. It doesn’t work out to plan out how long building an entire new application will take. I unfortunately know this because I have seen this tried, and it ends up in a lot eventually deleted stories and wasted time. Turning your gantt chart 90 degrees does not a backlog make. I don’t imagine that you are talking about doing this. What level of estimates worry you the most — is it at inception, for new epics, at a sprint/story level? Each is very different and I definitely don’t want to comment on them as if they were the same.
The main reason I bring up #noestimates is to really push people to consider why they are estimating and what it is giving them, just the same as any process. As we move to a point where we can create and release software so quickly we can push to Production every day it changes a lot of things about how we plan and implement, and it’s worth re-evaluating what that sort of cycle time means for every stage in software development. I know it’s something I’ve been spending a lot of time considering and exploring, and will likely change my mind on many many times as the world changes and I learn new things.
