All estimates are wrong, some are useful
The year was 2014. And the iPhone Model 5S. And Apple added Touch ID to the phone for the first time. In an earlier post I wrote about the Credit card company which focused on building features that their competitors were forcing them to. This is another story from the same set of teams.
It was iPhone 5S launch day and several of the teams spent the afternoon watching the launch event online. The same day during lunch time, there was a Technology event. The CTO took the floor standing on top of one of the work tables (it was an open concept floor with around 20 teams working in that area - so at least 200 people were gathered around) and he threw in the gauntlet. He asked the developers who in them can develop the Touch ID functionality to support it as a password option by working over the evenings and weekends. And there were prizes $5,000 for the first working validated solution along with an iPhone 5S and also an Apple Watch. Remember the first edition of the Apple Watch?
Pray may I ask why this was not the next regular feature built by the mobile teams in their very next Sprint? The answer was simple. There was no budget for this feature. No one knew who will fund the budget for a password functionality. Not the MyAccount (multi-card display screen) department. Not the transaction details and statements department. Not the rewards department. Not the customer support department. They had no money to own this feature - but they were happily building features for customers that was on the roadmap for the year and would not deviate the spend from it.
Well short story of it is that several teams stopped their work to get this done over the course of next week. Of course, they all pretended to have done the work over evenings and weekends, since they did not want anyone to know that this is at the cost of regular work. And this got done in double-time and no one was none the wiser about how it got done.
Except, what has estimates got to do with all this? I just wanted to point out there was no estimations for this work. The focus was on action, getting the stuff done.
If this feature had been estimated formally in planning or in refinement (assuming Scrum being used for software development) - the feature might have been estimated to have been a couple of Sprints or more. But in reality when there was pressure to ship and people were enabled to do it, it got done in 3-4 days time and shipped to the Appstore in the next weekly cycle. Just points out to the amount of ballooning of the estimates that happen (I have seen crazy estimates that was 100X-200X the actual work) when we actually focus on the estimates.
What if the teams focused not on having estimates but on getting stuff done and delivered off to customers as quickly as possible. That would be a "Small move" with "Big payoff's". Every time.
