What is fail fast? 

At the heart of every startup and every new product is that "one great idea" that someone thinks the market needs. But not every great idea is that great. Sometimes an idea needs a few changes to become great. Other times, it's hopeless. In the early stages, it's hard to distinguish the good ideas from the not-so-good ones.

Every team's objective is to deliver high-quality function—that great idea that customers love—and to do it fast. One technique to meet this objective is to quickly change course when something isn't working instead of continuing down the wrong path. This technique is known as failing fast.

In a fast-changing VUCA world of volatility, uncertainty, complexity and ambiguity, it’s much more effective, not just more efficient, to iterate on good-enough solutions and accelerate learning. Using simple rules in the process to create rapid feedback loops to create simple local interaction, which produce extraordinarily complex global patterns is essential for radical innovation.

When you develop applications, you have a limited amount of time, people, and money to get an idea right. The longer it takes you to realize that an idea isn't a winner, the more resources you waste. Conversely, the faster you can verify that an idea is great, the faster you can get more investment to make the idea a reality.

The key to failing fast is to develop enough of your idea to determine whether it's useful to customers. You can have customers validate the function with as little investment as possible, reducing business risk. If a customer doesn't like the new function, you can find out before you invest more time or resources into developing the function and move on to the next idea.

Failing fast requires a culture where the team has the freedom to fail but can learn something from each failure that helps the team succeed faster the next time.

Imagine yourself in a 10-week beginner's pottery course. Half of the students spend the entire 10 weeks working on one clay pot. For those students, the overall grade for the course is based on the quality of that one pot. The other half of the students make as many pots as possible; their grades are based on the quality of pots that they create. At the end of the 10 weeks, an independent expert is brought in to see which pots are the best.

Which half of the class will likely have a higher percentage of great pots? Experiment after experiment suggests that the "trial and error" group will have more great pots. Because the second group of students must try different ideas and techniques, they can more quickly find ideas that work and then use those ideas to produce amazing results.

This idea is at the heart of Enterprise Design Thinking. In the words of David Kelley, "Enlightened trial and error beats the panning of the lone genius."

Fail Fast Approach in System Design

In systems design, a fail-fast system is one which immediately reports at its interface any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process.

Fail-fast-designed code decreases the internal software entropy, and reduces debugging effort.

How to fail fast?

You can fail fast—and learn fast—in many ways.

• The costliest failure that you can make is investing in a project that your customers don't want. The first step in failing fast is to prove that your intended customers want and need what you're planning to create. Work with your stakeholders and validate your idea.

• During the workshop phase of a project where the team and stakeholders define the application features and minimum viable product (MVP), mandate that participants explore "crazy" ideas to see whether elements of those ideas lead to good ones. In this way, teams can quickly separate the good ideas from the others.

• In a hypothesis-driven development process, the entire team—design, development, and business—identifies the riskiest assumptions that underpin an idea. Then, the team builds experiments to test them. If the idea is based on flawed assumptions, it fails, and the team can pivot and avoid wasting its limited resources. When the team tests the riskiest parts of the project at the beginning, the cost, risk, and design of the project become more predictable.

• When you work with a new project that requires a large infrastructure and hardware investment, such as an Internet of Things (IoT) project, you must validate how the platform and devices affect your design. Implement as little of your infrastructure as possible to validate an assumption and then implement a bit more to validate the next assumption. If a significant part of your IoT platform isn't built before you encounter a failure, you'll have a better idea about where the failure is happening. 

• From an application-delivery point of view, development teams that use DevOps can get immediate feedback to find out whether code or a deployment is flawed. In this way, a team can move to higher-quality code and a more stable deployment environment.

As your team embraces the notion of failing fast, it gets used to experimenting and recovering from unexpected circumstances as part of the development cycle. Everyone becomes confident that discovering the unknown and reporting on it is respected and treated as a contribution to the project's success. What counts is a great solution that is achieved by making failure and correction part of the team's culture.

Conclusion

In the complex digital revolution era, trying to predict, control, and eliminate variances is a losing game. Reducing variance inevitably meets the law of diminishing marginal returns: the cost of reducing variance eventually exceeds the benefit. In addition, the goal of controlling and minimizing variance can be deceptive, because we don’t know what to measure in a complex environment that changes so rapidly, and we can’t control what we can’t measure.