“Fail Fast” can be a really useful technique.  There is a Wikipedia description and a famous software engineering article.  But I am going to talk here about “fail fast” with respect to Agile.

In “The Art of Agile Development” there is a chapter on Fail Fast.  It starts out

It may seem obvious, but failure is another source of waste. Unfortunately, the only way to avoid failure entirely is to avoid doing anything worthwhile. That’s no way to excel. As [DeMarco & Lister 2003] said, “Projects with no real risks are losers. They are almost always devoid of benefit; that’s why they weren’t done years ago.”

Instead of trying to avoid failure, embrace it. Think, “If this project is sure to fail, I want to know that as soon as possible.” Look for ways to gather information that will tell you about the project’s likelihood of failure. Conduct experiments on risk-prone areas to see if they fail in practice. The sooner you can cancel a doomed project, the less time, effort, and money you’ll waste on it.

How to make a project fail fast?  A simple thing to do is to tackle the hard problems first, not last.  The harder areas are where failure is most likely. When planning for a longer release, spend some time identifying project risks up front.  Then shoot for those areas first (rather than doing higher business value items first).  It is much better to fail fast and adjust than waste more time doing the less risky areas first, only to stumble later.

Now this does require maturity up and down the organization.  Engineering needs to be upfront about risk on the project, and tackle it early on knowing that things may go badly.  Management needs to be on board too.  They need to understand that projects have risk.  Fail Fast will mean that things will most likely go wrong closer to the start of the project.  This can make a new project feel like it is starting off on a bad foot – it feels risky.  The reality however is that it ultimately is less risky as the problems were going to have to be faced anyway – its better to get them out of the way early on.

One of the goals of Agile is to enable businesses to adapt. In the real world, laying out a really long term plan is risky. The world may change by the time you complete it! A truly Agile organization is one that is able to deal with change as it happens. A sign of a strong Agile organization is recognizing and accepting failing fast, and then coping with the change. It is better to do this early on in a project – it costs less over all and increases trust. But it does mean that engineering need to make it clear to the business side when this is happening, and the business side needs to be on board.