Failing Fast, the Sunk Cost Fallacy, and Scrum
When playing Silicon Valley Startup bingo, the term “Failing Fast” might as well be a free space. Nearly every hip web-3.0 company uses this term in their mission statement, and it’s slowly making its way into the minds of companies in traditionally-conservative industries as well. Scrum & it’s timeboxed sprints provides the perfect playground for failing fast.
What is Failing Fast?
Failing Fast is really just a catchier term for fast-paced experimentation. The organization should constantly prototype and user-test idea after idea, hoping that one of them will be the hit that makes them billions. Google is a perfect example of this with their “moonshot” projects. Most of these projects will fail. Some will be the butt of jokes for years to come. But maybe one or two will be hailed as groundbreaking innovations, and place the company at the forefront of an all new field.
On a smaller scale, failing fast for a software development project means constantly trying new processes, development techniques, tools, and working on requirements that haven’t gone through 6 months of management advisory boards and focus groups. A development team that fails fast is always experimenting and striving towards improvement. If an experiment works, great! The team will adopt & tweak it for their specific needs. If an experiment falls flat on its face, the team will study what went wrong, and use that data when selecting new ideas & experiments to try.
As you might expect, Failing Fast has some pretty noticeable pros and cons. On the pro side, if a team throws more ideas at the wall, they’re more likely to create home-run features that differentiate the product, and stumble upon processes that greatly improve their ability to deliver value. It’s much easier to hit the bullseye with 100 darts than with 1. On the con side, these experiments cost time and money. Even if the fast part of Failing Fast is emphasized, a failed experiment is still time that could have been spent on work that more safely delivers value. When done right, the team will gain value by learning from failed experiments, but 100% learning doesn’t keep the lights on. At the end of the day something must be delivered.
The Sunk Cost Fallacy
The Sunk Cost Fallacy is a quite well-known theory in psychology & behavioral economics, and once you know how to spot it, you’ll find its occurrences (and effects) pretty much everywhere. Essentially if we’ve invested time & money into something that we now realize won’t provide any positive returns, we often decide to waste more time & money on it, instead of rationally cutting our losses and moving on. At the casino, after loosing 10 hands in a row (and $200) in blackjack, the next rational move would be to cut our losses and walk away. But since we’re already in the red, we feel like we need to play until we win our money back, completely forgetting how we lost it all in the first place. The result is almost always a heaping helping of regret the last morning. This is the sunk cost fallacy incarnate.
Large software projects are expensive, time consuming, and often major gambles for any organization. Because stakes can be so high, failure often feels unfathomable. It’s not that we can’t imagine how this project can fail, it’s more that we can’t (or don’t want to) imagine the consequences for if the project fails. Therefore even when things take a turn for the very worst, like a gambler floundering away at the craps table, we refuse to call the project a failure and move on.
How Scrum Can Save the Day
With enterprise-level Waterfall, everything but the most trivial of projects would be considered a large investment. Most corporate systems are both highly novel (since they need to fit into the enterprise’s specific processes), and feature a large amount of complex integrations into existing company systems. Therefore what seems like simple functionality development will become expensive and time-consuming fast. As a result, the minimal investment required to produce anything of value will be quite high, and strike fear into any IT manager’s heart. A higher minimal investment equals a greater risk of even the most rational managers falling into the sunk cost fallacy.
Scrum on the other hand requires fast and cheep delivery of small and functional value increments. This combats the sunk cost fallacy in two ways:
- Faster Delivery of Value: Due to the dramatic increase in delivery frequency, each delivery of the product (and therefore value) becomes cheaper. There’s no worse feeling than sinking money into a project with absolutely no quantifiable return delivered. With a Scrum team that’s delivering production-ready value every sprint, there will almost always be some delivery of value. Whether it’s enough to justify costs and continue the project is up to management, but that decision can be made 8 weeks in as opposed to 8 months in.
- Frequent Inspection from Stakeholders: One of the greatest fears of any product owner in a waterfall environment is finally seeing the product they’ve payed millions of dollars for, and realizing it’s not at all what they wanted. This is prime Sunk Cost Fallacy territory, as very few managers could stomach the thought of throwing away 9 months of hard work, even if the product is worse than what they currently have. With Scrum, not only do stakeholders receive functionality more frequently, but they also play a greater part in directly shaping the project towards providing maximal value for their dollar.
<quick-aside> There are two caveats to consider with point number one. First, there will always be startup costs for any project (environment setup, team formation, initial requirements discovery & backlog build-out). Second, The amount of value delivered by a Scrum project per sprint will change over the course of the project. Often the team struggles to function optimally for the first few months, due to situations like learning brand new technologies, being unfamiliar with the domain, trying Scrum for the first time, and good ol’ fashioned team storming. Stakeholders should factor these two points in before deciding to cancel a Scrum project due to low output. </quick-aside>
Fail Fast, Not Neck Deep in Costs
Failing fast is one of the ultimate antidotes to the Sunk Cost Fallacy in software. By implementing a culture of constant innovation, and considering more tasks as experiments that will be learned from instead of projects that have to succeed, the all-too human drive to completely ignore even the most obvious of red flags is subdued, and a more rational cost-value analysis can be conducted. As a result, not only will the team be more free to innovate and create truly amazing and novel features, but the company may be shielded from death march projects and initiatives that go on forever, even if they provide no value.