#NoEstimates: Forget Buildings and make Digital Products
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
