Before you begin to build a house and break ground on the foundation you better have a blueprint and know exactly what you’re going to build. In physical construction, we really need to plan things out ahead of time to ensure that we have the right materials at hand and that things come together as we want them to.
This is a fundamental constraint of physical construction and it forces us to think about and construct physical things in certain ways. Virtual things do not have the same limitations and so in many cases we can find more effective and efficient ways of constructing virtual things then if we were to just follow a similar plan that we would for constructing a physical thing.
Virtual things don’t have the same limitations as physical things and Agile attempts to leverage this fact when we construct software. Instead of designing a system up front, we can design it as we go and if we do this correctly, it can be more straightforward and yield a far better product that if we were to plan it out all upfront.
I did not believe this at first and so I was reluctant to try Agile in the early 2000’s as a successful Waterfall developer. How can I start coding when I don’t know what it is that I’m coding? That’s what I thought but at the time I didn’t realize that I actually knew a lot about what I needed to build, I just didn’t know everything, and I didn’t need to.
In my experience, we rarely know everything about a project before we start and operating under the false assumption that we think we know everything can cause problems. Also trying to figure everything out upfront in the planning stage is like trying to visualize the future. There are so many variables and we as visualizers are so imperfect, we often wind up getting the wrong impressions and missing key concepts that we don’t recognize until were in the midst of it and it costs a fortune to change.
Writing software is the process of working through problems and so when we get requirements that ask us to address these problems and ask us to estimate how long it will take to resolve these problems, we are at a significant disadvantage. It’s like asking a scientist to give them the results of an experiment that they haven’t yet designed.
Managers are constantly asking developers how long it will take them to accomplish a task and the truth is that most of the time developers really don’t know. Developers are asked for estimates and when they give a date their estimate there taken as commitments. The word “estimate” and the word “commitment” are different, and they imply different things but I find almost universally that a programmers estimate is immediately turned into a commitment to finish a piece of work on a certain date, whether they’re aware of it or not.
In my experience, software developers are very well intended and many times optimistic about how much they can get done in a short period of time. They shouldn’t be faulted or penalized for their optimism.
I think the whole estimation process is often a waste of valuable time and resources. I’m a big proponent of the #NoEstimates movement. No estimates doesn’t mean never, ever do estimation but rather do it appropriately, as needed, but also recognize much of the work that one has to do to build a component is involved in doing the estimation except at the end of the process you get a number instead of a working feature, which is not nearly as valuable.
If you were really hungry and went to a restaurant to ordered dinner and the waiter gave you a number instead of your meal then you’d probably be very upset but somehow in the software industry is okay for us to expend enormous amounts of time and effort to deliver just a single number, which is often wrong anyway.
A single number is fallacious because estimation is a probability and probabilities are not expressed as a number but as a range of numbers. Rarely do I see managers ask for a range of numbers when doing estimation, but having a range of probabilities can inspire the right kinds of conversations about the work to be done, such as adding an additional feature that pushes out a delivery date by X number of days and reduces the probability that this release will be ready at a specific date by a specific amount. Now we can engage in a conversation about if it’s worth it or what’s our backup plan is or any number of productive things.
When managers ask developers how long it will take to finish a feature they are giving their power away, they’re playing victim. Developers don’t want this responsibility. Instead, what if management said, “Look, we have this much money, which means that we can have you work for this amount of time with this size of a team. Build as much as you can of the most important features within those limitations.”
If you trust that the team is doing the best that they can and that you have a good software development process, then you will always get the best results that you could with the resources that you have, so what need is there for estimates? It’ll get done when it gets done. Estimates don’t change that, and they just take time to generate so they’re not always worth it.
Of course, there’re planning and release cycles and other issues that do need delivery dates but remember, in these scenario management is coming to the developers and saying that want to release on a specific date and asking how much they can deliver by then. Taking this approach can often lead to a better product and a more effective software development process.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Product Owners
Previous Post: « Be the SME
Next Post: Help Developers Understand Why and for Whom »