Failing fast is one of the most overworked business tropes. The underlying motivation is for companies to take big risks with immense potential payoffs.
To fail fast, the company must put sensors in place to recognize early if the risky move is panning out and worth continuing.
In comparative mythology, the hero’s journey requires the protagonist to face and overcome adversity before they become worthy of winning.
Biographers of business titans use the hero’s journey construct to explain the role of failures in their ultimate successes. It’s one thing for Bill Gates to bemoan his reviled Clippy Office Assistant, which debuted in Microsoft Office 97.
Everyone else who hasn’t achieved Gates’ level of success should be wary of highlighting their failures.
Interviewers generally want to hear about the lessons job candidates learn from failures. Candidates who glean especially insightful lessons may paint a positive picture of their failures.
Ideally, fast failures are preferable to long failures, but time is relative. In some business scenarios, a one-year failure is considered short-term, while a three-month failure is considered long-term in another company.
Most prospective employees are savvy enough not to brag about their littered highways of failures during job interviews. Although a perceptive interviewer may want to dig into a candidate’s failures to discover what they learned from the experience, this is red-flag territory, regardless of the beautiful credo of failing fast.
Most corporate failures occur excruciatingly slowly, like watching a tomato seed sprout without time-lapse photography. Companies with a Waterfall* mentality may initially scrutinize a nascent idea with a gimlet eye, but green light it based on a projected profitability assessment.
*Waterfall is a development approach with lengthy design, documentation, development, and testing periods. When one group finishes, the work is handed off for the next group to begin.
The problem with Waterfall is its lack of mid-cycle milestones to recognize possible cost overruns, unforeseen development complications, or an altered business landscape that changes the idea’s profitability calculus. Since the completed product isn’t delivered until the very end of a Waterfall project, failure awaits the final evaluation.
The ethos of Agile* sprints is that they are discrete. A team may elect to follow one sprint with a second sprint to continue the work, but this is a conscious decision and not a fait accompli. Sometimes, a Development team encounters unforeseen complications that slow their sprint progress.
*A refutation of the Waterfall process, Agile is about decomposing large problems into smaller ones, working on them in short iterations, and soliciting user feedback after each iteration.
Before electing to continue the work in a follow-up sprint, Product Management will revise its estimates for the feature’s completion date. The cost or time overrun may render the feature unviable, and it’s killed or shelved after the first failed sprint.
Failure’s not shameful when it’s recognized after one or two sprints. Low-cost failures are easy to sweep under the carpet. Realistically, however, recognizing failure takes longer than one or two sprints.
A sunk cost mentality frequently overtakes reason in Waterfall’s slow failures. Managers reason that they’ve already invested so much it’s best to keep pouring money into the feature. Buying one’s way out of failure is an expensive proposition that compounds the problem.
Does this intrigue you? Are you interested in learning more? If so, it’s your lucky day. My new book expounds upon this modified excerpt. Buy The Agile Enterprise: Applying Agile Principles to Drive Organizational Success in digital or print format to better understand applying the principles of Agile Programming across the board in a company.
