Fail Fast Furiously

The other day, I read a tweet by @gnat (nat torkington), saying that fail fast as a mantra was misleading – because the objective was to learn, not to fail.


Actually when I exhort people to fail fast, the objective is to retire a risk. Sure, learning is important, but what is really important to the delivery of software is retiring risk. Either we know something will work, or we know it won’t work. Risk retired, the rest is just work.

What is necessary to fail is a set of success criteria. If it doesn’t meet all the criteria (at the same time), it fails. So when you send your team down the path of a POC or a Spike – with the exhortation to “fail fast”, you also need to provide them with some hard criteria to compare their results against. These criteria should give you an ability to predict whether your POC or Spike has really retired the risk, or whether you are simply kicking the can.


So while learning is important to the team. Risk is important to the project, and to the ultimate delivery. If I can’t retire a risk, then I have to carry it. If I carry it, what was the point of my POC or my Spike anyway.

When I exhort a team to fail fast, that means (or it should) they should sequence the work in a way to do the least amount of work before retiring the largest portion of the risk. This “risk wise” ordering of work is important on a project where there are great chunks of unknown – new technologies, unclear direction, poor support, etc.

The goal of “fail fast” is to identify “infeasibilities”:

  • Things that can’t be accomplished with the tools (or people) at hand.
  • Things that can’t be accomplished on the schedule required.
  • Things that can’t be accomplished within the budget allotted.

The faster we get an infeasibility “on the table”, the faster management can engage and make a decision. Spend more, take longer, cut scope, kill the project. The faster we get there, the easier it is to make tough decisions. If those decisions are exposed too late, management has fewer choices.  Kill the project has less benefit, as money is already spent. Cut scope helps less, because half of the work to deliver the thing being cut is already spent. Take longer may take even longer, because we are not staffed correctly. Spend more may mean spend even more, because we have spent too much just getting to this point.

Fail fast is not an exhortation that can be given without context, or without the team understanding the risk they are trying to retire, or without some knowledge of the impact of some infeasibility that they might identify. If you simply tell people to fail fast, and they do, it is totally on you to understand the impact. If those people understand the context and what is at stake, they will fail faster, and provide you more insight into your decision making.

No Comments

Leave a Reply