#NoEstimates: Forget Buildings and make Digital Products

This is a complicated matter. Every single company on the planet deal with estimates somehow and use some kind of estimates. There are people who are pro-estimate and belive giving an estimate is a professional thing and we need to do it and there are people who believe we need to reduce the number of estimates we do(I'm the second kind of people). Estimates often are wrong and incorrect. However, there are people who are really good on the estimate and get it right with very few error margins however when you look into details you might realize that being good on estimates might be killing your business. You might think is enabling you to sell more and get better but easily it could be the other way around, no worries I will answer why. This is a very hot and passionate topic so brace your self and let's go. Estimates are old, most of the time they are lies and they are not reliable however we continue to work with estimates expecting they will work when they dont work.


The Issue with Estimates

There are several issues with estimates, let's get started with some:

* Estimates are done when there is too much uncertain(Uncertain cone)
* Estimates are often done by the manager who does not deliver the work
* Estimates are often done when "requirements" are not clear
* Estimates does not take variation into account
* Estimates tend to be "underestimated" meaning always assuming is easier when is not
* Estimates tend to not count, judge or be cased on any concrete thing
* Estimates does not take continuous improvement into account

There are many issues with estimates. Several managers estimate things in hours or even minutes with makes things even more complicated and hard to make it real. Estimates are used for the wrong reasons like:

* Feeling SAFE
* Selling Software
* Measure of progress
* Return of Investment

Several issues related to Estimates are related to traditional projects. Projects are often problematic too because they make us go for (Escope, Time and Cost) instead of Value or Organic Growth of our product. Estimates make Investors and non-tech people feel "SAFE" because they know when will be over.  However great digital products are never over, so does anyone think when Facebook or Lyft will die? Does anyone estimate when your company will be over? I dont think so, A business is a "live" thing we assume it will never be over and we try to invent and re-invent the business so it never dies. If the business never dies, there is no over, if there is no over, there is no DONE if there is no DONE why do we need to know when the software is over? (Because it makes us feel better).

Most people and companies still do not understand software, people think they understand software but in reality, people see and threaten software as a building or a bridge. A building or a Bridge can only be used when they are over but the software does not have the same properties. What are the properties that software has:

* It's easy to change (compared with bridge and building)
* It can be used before the "whole" software is done
* Is cheaper when it is LESS(1-4 weeks), Expensivier when is MORE(bigger project - 1,3,5 years).

Software under the wrong architecture and full of Debt can be very expensive and slow to change. However, a good architect and managed debt software is super fast to change and allow fast cycles of innovation for the company.

Why we can only think about the "whole" software? Could your business start thinking in smaller batches(Lean principle)? Smaller means less investment up-to front, less risk, and fast LED time.

Commitment vs Involvement  


Estimates should be a "Forecast" which means it might not happen. The big issue is companies take Estimate as "Commitment" which means you need to deliver on that date - often called DEADLINES. In my experience what I see is companies producing because of results, because they want, follow they estimate like:

* Produce Poor Tested and Poor Coverage software
* Create more bugs
* Sacrifices user experience
* Build a mediocre product because only prioritize easy user stories which are easy to estimate
* Bad Culture: pushing talent away and getting old mediocre engineers

Estimates can be really demanding for your business. Pursuing bad target date will make you compromise things that might cost your business in a long wrong. Especially if you just prioritize Features and dont do refactorings, so in this case you are really creating a time bomb.

The #NoEstimates way

#NoEstimates like anything in Tech has a bad meaning. It sounds like we are killing estimates completely. Actually, #NoEstimates means reducing craziness. Reduce the usage of estimates and work in a different way, however, you will have a "forecast" and will be able to have some kind of "prediction" still gonna have issues and might not happen but is the best thing we have so far.

* Use User Stories
* Estimate every user story maximum 1 day == 8 hours effort
* Use Statistics or yesterday wheater technique
* Use Moscow and have: MUST, SHOULD, COULD Targets
* Use BurnUp release charts
* Have small releases 1 week to 1-month maximum
* Stop asking people to "estimate" things
* Consider the role of Variation

Software projects still focus too much on OUTPUTs and we should be focused on OUTCOMES/IMPACT for the end-user which matters most. Remember users do not care about features, they care about you fixing their problems.

The Role of Variation 

The hardest part of estimates is variation. We often do not control variation, variation is never taking into account when we do estimates. Variation is not necessarily bad. You actually need variation, this is the tricky part. What is the variation? Let's talk about some variations sources:

* New Technology
* Cloud Computing
* NoSQL
* Big Data / Streaming
* Machine Learning
* New Team Members
* New Markets
* New Personas
* Team composition (Add / Drop People)
* Domain Knowledge
* Dependencies
* Competitors
* Waiting For Availability
* Blocks
* Workload Factor
* User Story Size

There are many more sources of variation. Variation make our estimates to grow unpredictably. As you work more in the same: Team + Domain + Tech you tend to get better however do not think variation is the root of all evil because having no variation might mean super BAD NEWS for your business.

Why Getting Estimates right might kill your business

If I get my estimates right it means I controlled variation. Which is good if you want to create the same CARs all the time. Let's say you are producing TELSA model X cars, great! However, at some point, you will need to introduce a new model and innovate In that case you will need to introduce variation them your predictability will get low and there is nothing you can do.

Innovation means adding more variation and blowing up estimates. Diego, I', not blowing up my estimates, I always get them right, awesome. Are you using new and better technology? Are you improving your Ux? probably the answer is NO. Which is bad right, you are killing your business because you are not exploring new markets and maybe not growing. The selling feature has a very limit window of opportunity as you hit that you will be forced to innovate. This means, add variation and have estimate issues which are good because it means your company is alive.

The good news is this is the same constraint for all Tech and digital product companies so are fare for everybody. At the end of the day, dont worry much about competitors, worry about doing the right things and deliver great user experience via A/B Testing and Discovery Experiments, sound and safe engineering and be able to adapt and deliver fast - this better property then getting estimates right.

Cheers,
Diego Pacheco

Popular posts from this blog

C Unit Testing with Check

Image
When I start on IT, several years ago(+15), C was the first language that I learned. But was not the first language I mastered and deployed in production which was...surprisingly Visual Basic 6.0. However, when I learned C or any language back on that old and arcane time noddy was into testing. However now is impossible to work professionally in any language without tests. C is a low-level language but still kicks ass and has several interesting libs/frameworks. People use to fear C a lot because of lack of syntactical sugar but once you get used to it is not that hard at all. Today I want to show how you can do Unit Testing with C. I will not show how to do Unit Testing with C++ but with C ANSI actually. We will be using Check a unit test lib for C ANSI.
read more »

Having fun with Zig Language

Image
Zig is a general-purpose language created in 2016 by Andrew Kelly .  Zig aims to fix the issues C language has while being pragmatic and simple at the same time. Zig really shines as being simple by not having any hidden control flows, not having hidden memory allocations, no pre-processors, and no macros. Basically, it's one language and one language only. Since pre-processors and macros can get really complex and become their own universe. Sure it's not the Zig Philosophy.  Zig Compiler(Zig cc) also is a C compiler, and the interoperability from C to Zig is very good. Clearly, we can see influence from other languages like Go and Rust; however, Zig is pretty unique and different from Go and Rust.  Zig is fast. Zig is perfect for system programming. I bet we will see a lot of solutions being built in Zig. As a languages aficionado, I like to learn at least one language per year and sometimes more; Zig was my 2021 pick, did not regret it. Even if you dont use all language...
Keep reading

HMAC in Java

Image
In 2018 AWS CTO(Vogels) said : "Security is everyone's job". For the last 2 years, there was so many famous and big data leaks and breaks that made that statement be very true more than ever. Security often could mean worst performance and worst user experience so in order to get it right you really need to think about the designs before jumping into to code and consider performance and user experience has main requirements.  I was thinking about writing about how to do HMAC in Java for a while and recently Redis 6.0.0 come out and to my surprise, there was a refactoring on the password part in order to use HMAC.  Security easily could scare engineers often because it is not something well spread yet but I believe this will change soon. It does not matter if you have to deal with PII Data or not, security is super relevant because everybody is running their workloads at the cloud or with IoT and Edge devices which means more distribution, more code, more points of fail...
read more »