
Why fail fast and learn fast?
Last updated: October 31, 2022 Read in fullscreen view



- 01 Oct 2020
Fail fast, learn faster with Agile methodology 864
- 18 Oct 2020
How to use the "Knowns" and "Unknowns" technique to manage assumptions 813
- 16 Jun 2022
Rapid Application Development (RAD): Pros and Cons 759
- 14 Oct 2021
Advantages and Disadvantages of Time and Material Contract (T&M) 703
- 19 Oct 2021
Is gold plating good or bad in project management? 671
- 20 Jan 2021
Fail early, fail often, fail cheap, fail safe but always fail forward 614
- 06 Mar 2021
4 things you need to do before getting an accurate quote for your software development 557
- 08 Oct 2022
KPI - The New Leadership 514
- 19 Apr 2021
7 Most Common Time-Wasters For Software Development 513
- 01 Sep 2022
Facts Chart: Why Do Software Projects Fail? 500
- 21 Jun 2021
6 Useful Tips To Streamline Business Processes and Workflows 476
- 28 Dec 2021
8 types of pricing models in software development outsourcing 388
- 20 Jan 2022
TIGO Self-Organization Practice: Change Management Workflow 386
- 31 Oct 2021
Tips to Fail Fast With Outsourcing 359
- 16 Apr 2021
Insightful Business Technology Consulting at TIGO 354
- 11 Jan 2024
What are the Benefits and Limitations of Augmented Intelligence? 354
- 07 Jul 2021
The 5 Levels of IT Help Desk Support 342
- 23 Sep 2021
INFOGRAPHIC: Top 9 Software Outsourcing Mistakes 338
- 11 Nov 2021
What is an IT Self-service Portal? Why is it Important to Your Business? 330
- 13 Feb 2021
Why is TIGOSOFT a software house for Enterprise Application Development? 325
- 10 Dec 2023
Pain points of User Acceptance Testing (UAT) 322
- 03 Apr 2021
How digital asset management streamlines your content workflow? 288
- 13 Dec 2020
Move fast, fail fast, fail-safe 280
- 01 May 2023
CTO Interview Questions 279
- 02 Nov 2021
[Case Study] Streamlined Data Reporting using Tableau 264
- 03 Nov 2022
Top questions and answers you must know before ask for software outsourcing 253
- 17 Feb 2022
Prioritizing Software Requirements with Kano Analysis 244
- 07 Aug 2022
Things to Consider When Choosing a Technology Partner 226
- 10 Apr 2021
RFP vs POC: Why the proof of concept is replacing the request for proposal 225
- 18 Aug 2022
What are the consequences of poor requirements with software development projects? 224
- 20 Nov 2022
Software Requirements Are A Communication Problem 219
- 06 Nov 2019
How to Access Software Project Size? 214
- 10 Nov 2022
Poor Code Indicators and How to Improve Your Code? 200
- 08 Nov 2022
4 tips for meeting tough deadlines when outsourcing projects to software vendor 193
- 02 Dec 2022
Success Story: Satsuki - Sales Management Software, back office app for School Subscription Management 192
- 26 Dec 2023
Improving Meeting Effectiveness Through the Six Thinking Hats 180
- 09 Feb 2023
The Challenge of Fixed-Bid Software Projects 180
- 03 Sep 2022
The secret of software success: Simplicity is the ultimate sophistication 177
- 01 Mar 2023
Bug Prioritization - What are the 5 levels of priority? 171
- 09 Mar 2022
Consultant Implementation Pricing 168
- 07 Oct 2022
Digital Transformation: Become a Technology Powerhouse 164
- 06 Nov 2023
How do you streamline requirement analysis and modeling? 160
- 09 Jan 2022
How to Bridge the Gap Between Business and IT? 150
- 16 Feb 2021
Choose Outsourcing for Your Non Disclosure Agreement (NDA) 143
- 01 Jan 2024
The pros and cons of the Centralized Enterprise Automation Operating model 142
- 01 Mar 2023
How do you deal with disputes and conflicts that may arise during a software consulting project? 137
- 05 Jan 2024
Easy ASANA tips & tricks for you and your team 132
- 12 Mar 2024
How do you create FOMO in software prospects? 97
- 10 Jul 2025
Building AI-Driven Knowledge Graphs from Unstructured Data 89
- 14 Mar 2024
Why should you opt for software localization from a professional agency? 85
- 17 Mar 2025
IT Consultants in Digital Transformation 48
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.