Why Estimates and Timelines Are the Biggest Enemy to Delivering Value
Obsessive Focus on ‘When Will It Be Done?’ Moves Value to the Backseat
Shigeru Miyamoto, the mastermind behind the best-selling game series Mario and The Legend of Zelda, said the following about delayed games:
“A delayed game is eventually good, a bad game is bad forever.” — Shigeru Miyamoto
When given the choice to release something bad, or delay, Shigeru prefers to postpone. By reworking and polishing, you can still end up releasing something good if you know what you’re doing.
Shigeru isn’t the only one that believes this. Valve, the company behind Steam, operates on a similar concept it calls ‘Valve Time’. Most of their game releases are delayed significantly. Valve pokes fun at the concept by keeping track of the promised release dates compared to the actual release dates on their developer wiki.
You might be thinking now, Nintendo and Valve are rich. They can afford to be picky and delay releases. Let me tell you the story behind the release of the first game of Valve Software.
Getting Valve’s first game out of the door
Valve started working on their first game in 1996. Valve was ambitious and aimed to have their release coincide with Quake II. Close to the release date, Valve decided to postpone. The game wasn’t as fun and groundbreaking as they wished. It did not meet their standards of what a good game should be like.
Imagine the tension at Valve’s office. The future of the company was riding on this first-person shooter. Valve had never released any game before and was quickly running out of money. Their first release would be postponed even though the release date had already been announced to the public. It was a tough decision to make. Valve would burn even more money with zero guarantees it would pay off. The only thing they would know for sure is that delaying would make them lose face.
Valve carefully reworked every level and tweaked all aspects of the game design. The pressure cooker environment resulted in the invention of the cabal design process, still used by Valve to this day. The game was finally released in 1998 and became one of the best games of all-time: Half-life.
Of course, you can argue now, there are also examples of games that were delayed almost indefinitely (Duke Nukem Forever anyone?), yet never was a critical success. You’d be right. But I can guarantee you, those games would have failed too without any delays. Their failure had nothing to do with the delays, but how those games were created.
Stop being a victim of crystal ball
Allow me to give an example. Let’s say I ask you how much time it takes to cook a three-course dinner you’ve never cooked before. If you don’t meet the timeline, you will be punished. What do you think will happen if you are squeezed for time? The dinner will suffer at the expense of meeting some imaginary timeline proposed before you even got started!
Let’s be honest here. Most software product timelines are decided at a point when you simply lack the information to predict anything meaningful. Before you start doing the work, you’re limited to the knowledge of beforehand. Only by doing the work can you begin to learn what really matters in the product you’re undertaking.
When you come up with a timeline, before starting the work, you’re extrapolating based on noise. In statistics, this is called overfitting. You make a line that perfectly predicts the data, but it’s meaningless in the real world. It’s like asking a fortune teller to rub the crystal ball and provide you with a date.
When you cling to an arbitrary timeline you don’t meet and consider it as a delay, then you’re delusional. It’s not the timeline that is off, but your expectation of the accuracy of said timeline. You’re placing your trust in an unreliable fortune-teller who rubbed their crystal ball and gave you a flimsy date.
When teams try to meet the illusory timeline produced by the crystal ball, tunnel vision creeps in. Like a Fata Morgana that appears when you’re stuck in the desert, the only thing everyone sees is the looming deadline. The whole discussion reverts to ‘How can we meet that deadline?’. ‘Is it good enough?’ moves to the backseat, and ‘How can we move faster?’ climbs to the driver’s seat.
Moving faster doesn’t mean you will get where you want to be faster.
Worry less about meeting timelines and more about whether what you’re building is good enough
In the eyes of the law, we are all innocent until proven guilty. Use the same logic when building a feature. All your features are innocent of delivering value until you prove otherwise. Doing what your customer says doesn’t constitute proof of value.
Expect all your features to suck, until you can hand over evidence to prove the contrary. This is what you should be most worried about. Not about the exact moment that feature is delivered. You don’t even know yet for sure that it is valuable when you deliver it on time.
When you treat all features as innocent of delivering value until proven guilty, you will actually deliver fewer features. You will spend more time investigating, editing, polishing, removing and reworking features. As a result, it will become even more difficult to predict when something is finished.
But does it really matter if you’re able to predict exactly when something is finished? If you’re confident you’re making the best progress you can towards delivering something valuable, does it matter if it’s slower than you expected if that expectation was always flawed and imprecise to begin with?
Increase confidence that you’re moving in the right direction before hitting the gas pedal to move faster. By initially moving slower and establishing your bearings first, you’ll get where you want to be much quicker. It isn’t about moving fast, it’s about knowing you’re moving in the right direction.
As writer William Arthur Ward has beautifully said:
“The pessimist complains about the wind. The optimist expects it to change. The realist adjusts the sails.” — William Arthur Ward”
Adjust your sails, instead of being angry at the winds, you will never be able to predict and control. You can’t make your estimates accurate, or guarantee you will deliver on time. You can only make sure you are moving in the right direction towards delivering a valuable product.
The issue is it’s so much easier to track time than it is to track quality, people (managers) tend to focus on the things they feel like they can control.