“Fail Fast” or “First Time Right” – Which is the correct approach to follow?

“Fail Fast” or “First Time Right” – Which is the correct approach to follow?

“Fail Fast” or “First Time Right” - Which is the correct approach to follow?

Success Story of Fail Fast Approach in Motilal Oswal

“Fail Fast” or “First Time Right”

Which is the correct approach to follow?

- Krushna Sahoo

First Time Right (FTR) involves making sure that all the activities are carried out in the right manner and deliver product or service 100% right the first time meeting the customer expectation. We, at Motilal Oswal have a strong belief in this concept and have successfully set this framework to deliver FTR which is strongly followed by all. This is now reaping the benefits.

In this article I am sharing a different concept which is contrary to First Time Right’, that is “Fail Fast”.

In today’s age of tough competition and time to market, everyone wants to reach their customer first, so every team's objective is to deliver high-quality product wand want to do it fast. This means that, one needs to provide the solution at speed and at accuracy. This leads to the technique, where, you need to do a quick course correction when something isn't working instead of continuing down the wrong path. This technique is known as “failing fast”.

Sometimes we have to choose very carefully whether we should go with “Fail Fast” approach or FTR. Recently we had delivered Lead Squared Cloud based product (Software as a Service) with complete integration with EKYC system using Fail Fast approach which was a very successful project. I would say In short, “Fail Fast” helps you deliver “First Time Right”.

We are first in the Financial Industry to launch such a scalable product which is complete digital Lead conversion and Account Opening System with zero down time. Here we chose Fail Fast approach from start to end and realized Fail Fast approach is better when compared to FTR, reason being complete Agile way delivery.

Let me bring clarity on “Fail Fast” Vs “First Time Right”?

“Fail Fast” assumes that there are certain unknowns / risks associated with achieving the goal. If all the steps in achieving the goal are well understood, then “Fail Fast” would not be required. In short, “Fail Fast” helps you deliver “First Time Right”. The riskier your project, i.e. the higher the cost of getting it wrong the first time, the more important it becomes to “Fail Fast” in order to get it “First Time Right”.

“First Time Right” has been popularized by the quality movement, especially by the Six Sigma methodology. Hence, it is not uncommon to get the question: Does “Fail Fast” contradict with “First Time Right”?

There are multiple reasons of failure, sometime it is very difficult to find all the issues and resolve proactively, giving example of few scenarios:-

  • Late discovery of serious project flaws (integration)
  • Poor software quality (Architecture, risks unanticipated…)
  • Unacceptable software performance
  • Team members in each other’s way, unable to reconstruct who changed what, when, where, why (software architecture)
  • Inaccurate understanding of end-user needs
  • Inability to deal with changing requirements
  • Modules that don’t fit together (integration)
  • Software that’s hard to maintain or extend (brittle architecture)
  • Sloppy development practices (No coding standards, reviews)
  • Poor Quality Control
  • Business specific scenarios not considered

When we choose “Fail Fast” such type of issues discovered during multiple iteration of testing and ensures closure of all the issues before release in live.

To explore this question, it would help to understand “Fail Fast” and “First Time Right” better. Let’s start with “Fail Fast”. Does “Fail Fast” imply failing in any kind of way? No. To understand this better, let’s see the difference between a failure due to checklist-oversight and a negative result during hypothesis testing.

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.

What happen when you choose wrong Approach?

Let’s borrow an example from Jeff Bezos of Amazon. In an interview, “First Time Right” uses all the available past data in constructing the process to be followed for delivery of a solution.

In contrast, let’s look at the following hypothetical assumption: Amazon will be able to deliver a book size packet reliably on the terrace of a ten storied building in Bangalore via drone delivery. Let’s assume Amazon has experience of this kind of delivery in countries like the US but not in India. And if the first attempt at doing this delivery fails, then it would be a failure of the second kind – hypothesis test failure.

Note that this failure would result in some learning which can be incorporated in the second attempt and so on. Depending upon the difficulty encountered the cost of each experiment and the importance of this use-case for Amazon, more attempts would be made to learn more about this use-case.

When I say “Fail Fast” I mean fast testing of the assumptions associated with an idea. Now, we can see that “Fail Fast” is quite complementary with “First Time Right”. If Amazon were to launch the drone delivery on the terrace and get it right the first time, then it would help to do as many tests in different contexts – weather conditions, building locations, different building structures etc. Thus it would help to Fail Fast to get it right the first time you go live.

Fail first is completely Agile Delivery Approach

In Motilal Oswal we have done exactly same thing, Project was completely experimental for us. We have started with MVP (Minimum Viable Product) for selected set of users and started testing with a pre-defend check list where our QA played a very important role. The entire team embraces the notion of failing fast, it gets used to experimenting and recovering from unexpected circumstances as part of the development cycle

Each failed scenario of first iteration we have resolved in 2nd iteration and did same exercise multiple times. In each iteration we increased number of functionality and scenario which we have received from end customer as feedback. We have done extensively testing with multiple scenario and increased number users at the same time, this is practical and helpful approach. In short we have removed many functionality and added few functionality based on end user feedback in each iteration.


In fact it is true “Fail First” approach helps to achieve “First Time Right”

We have to choose very carefully when we are selecting a project. Both approach are correct approach, there are scenarios where ‘Fail First” approach is very beneficial for Business. Example Amazon drone delivery project should be Fail Fast approach. When multiple factors unknown and risk is very high, it is better choose “Fail Fast” approach.