Fail Fast and Win Fast
The phrase “Fail fast” has become one of the most misunderstood and misused clichés in the Business and Agile context. This article attempts to apply different perspectives and insights into the phrase to clarify its intent.
We have been conditioned throughout our lives by the belief that “failure” is bad. This comes from society’s simplistic thinking that if winning is good then failing must be bad. Therefore, failure must be avoided. That is the nature of failure in competitive contexts such as sports, elections, other contests, etc. There is no benefit in failing in those contexts. Therefore, if failing is bad then failing fast seems worse according to populist belief. Another commonly applied cliché in the context of success and failure is “to never give up and keep trying”. These common views are often based on an incorrect assumption or belief that failure can be avoided. They also ignore the time and cost aspects of failure. This commonly prevailing negative connotation of failure may be relevant only for competition and not for collaboration.
In the Systems approach, failing fast is a good outcome. Fail-fast systems are usually designed to stop normal operation rather than continue a flawed process. The systems approach assumes that components or aspects of the system will eventually fail. If failing is inevitable, then it is better to fail early than late. Also, in this perspective it is better for components or parts to fail compared to the failure of the whole. From a process perspective, it is better for failure to occur in the earlier stages than in later ones.
Let us apply this concept to the process of development of any product - software, electronic, automobile, aircraft, etc. as shown in the diagram below.
Most phased development approaches go through the standard phases of Requirements, Design and Development, Testing and Deployment (Production). They generally tend to be sequential (unlike in Agile). Failure can be due to factors such as missed key requirements, incorrect specification, incorrect design, defects or bugs, poor integration, etc. There is a large body of work that clearly shows that cost of failure rises exponentially with time.
The cost of addressing a missed key requirement in the early stages of product development is relatively low compared to fixing it in later phases. The cost of fixing a major defect found in the testing stage can be very expensive because of the effort of change required to the product. Cost of failure also varies significantly with the type of product. As an example, cost of failure in a critical health-care related product can be astronomical when it occurs in the production phase. There are numerous examples of product recalls bankrupting companies.
It is important to recognise the challenge of balancing a defect or failure-free development cycle with the time pressures of launching the product in the market. This balance involves a trade-off cost. That cost will be through a lost market opportunity or the cost of failure in the development cycle. The “fail fast approach” tries to minimise the cost of failure by catching errors early in the cycle. As an approximation, the relationship between cost to fix an issue and the stage at which the issue is uncovered can be illustrated thus;
If cost of failure at the requirements stage = 1 Unit, then cost of failure at the design and development stage = 4 Units and cost of failure at the testing stage = 16 Units and worse yet, cost of failure in production = 256 Units.
Failing fast is far less expensive than failing slow. Obviously, the best solution is not to fail at all. However, that is an unrealistic and impractical objective.
The Agile approach to failing fast and winning fast
The Agile approach, based on empiricism, accepts failure as inevitable in dealing with ambiguity and change. Further, it promotes failure as an opportunity for learning and improvement. The iterative nature of the Agile approach is shown in figure below.
Fundamental to the Agile concept is the arranging of requirements (known as backlog) in an ordered list of priorities based on value to the user or business. These requirements are worked on in short time-boxed cycles known as Sprints. Teams focus on completing all the work for a small subset of the overall requirements. As much as possible, Agile teams aim to deliver usable features of the software in every iteration. This means they tackle the design, development and testing functions for a smaller subset of the overall requirements in every sprint. The objective is to evolve the product quickly and continuously through a set of minimal but usable features to the complete product. This is very different to the traditional approach of working in a functionally phased manner. Traditional teams tend to complete all the design work for all the requirements before starting development. They then complete all development activities before undertaking comprehensive testing. This approach leads to failing slowly resulting in significantly higher cost of failure.
Thus, the Agile approach significantly reduces the cost of failure through short sprint cycles of 1 to 4 weeks. Teams learn quickly from any failures and apply that learning in the next sprint. This facilitates continuous learning and continuous improvement leading to faster successes. Delivering product iterations in short sprint cycles delivers value faster to businesses. This is the essence of failing fast and winning fast.
