DEV Community

Discussion on: Why Estimates Are Waste

Collapse
 
quooston profile image
Quooston

If you can't estimate with some degree of certainty, that you can often achieve within 10% of that estimate, you're not in a great environment. All my teams in the last 12 years have been able to do this. I've been in the industry for 22 years, and in the last 12 years, I'm referring to 10 teams in 3 different environments.

The reason you can't estimate is because your environment has not been set up for you to be able to do so. You need technical and architectural standards, an excellent team and support structure, a rock solid process that empowers you to decompose complex domains methodically and systematically, methods of implementing and addressing true domain complexity, and last and not least, the right people.

I work in digital health, we have crazy regulatory requirements and deal with super complex domains, and we consistently estimate to within 10% of our initial guestimate. These are multi-million dollar projects that run for 9-18 months to reach v1.0. They often continue well beyond this.

It's much, easier than you think. It's just that creating the environment that makes it possible is the hard part. This is about leadership and responsibility. I don't blame you for thinking it's a load of crap if you've not been empowered this way. What is sad is that it's the case more often than not, and that is not good. Not for you or your project sponsor or customer. What a shit-show.

Collapse
 
raslanove profile image
raslanove

A great leadership and an empowering environment won't make the task any less unpredictable. If it's the first time you do something, you can't put an estimate on it. Being able to make good estimates means your work isn't really creative. You can live your entire life selling the same thing, though. Which is ok by the way.

Collapse
 
quooston__be35d28bae9b9b7 profile image
Quooston

We certainly don’t do the same thing project to project, but we don’t introduce new tech or change our architectural preferences unnecessarily either. That then just leaves the domain, which is far more predictable if you can decompose it responsibly. The idea is to create an environment that eliminates most technical risk, leaving people to solve for the domain with a great process and support structure in place.

This leaves every project in an 80/20 state from really early on, where 80% is what we’re pretty certain we’ll be able to figure out without any real heavy risk. Risk is then buried in that 20%, which is what we’ll focus on very early on to identify and address. Honestly, it’s just a recipe that works and I know can be replicated anywhere. Unfortunately as I said, it’s just really rare to find environments like this. Which is nuts.