Fail Fast - Fail Safe Book Excerpt
Harnessing failure helps teams learn and adapt faster.
The most successful organizations know the secret to success is harnessing failure to drive their innovation. I’m sure you have heard the Silicon Valley phrase “fail fast and fail often” but that didn’t fully make sense.
The light bulb lit up when we realized that experimenting and failure are keys to collaboratively learning and produces amazing innovation. Teams who learn and adapt to the challenges presented to them creating amazing new capabilities with the Fail Fast - Fail Safe techniques.
Here’s a short excerpt from the book “Fail Fast - Fail Safe”.
What is Failing Faster?
Failing faster is about creating situations and environments in which an individual or organization can quickly prototype, demonstrate, test, and learn. It is a strategy of building a product by quickly getting feedback from users or customers, and rapidly adapting the design. Lessons learned are incorporated promptly into the solution design so that the process can start again quickly.
When there is a high level of uncertainty, it is often less expensive to start building a working product to learn whether or not the product is viable or feasible. Additionally, this method allows you to quickly get feedback from potential customers on the process or product. A benefit of this method and approach is to kill products fast before too much money is invested in their creation. Organizations don’t want to spend significant time and money into a process or product that will not work or will not sell. The key to being successful with this method is small incremental steps.
Silicon Valley and startups use the phrase “fail fast, fail often” when talking about product development. These companies are looking to get something out there to see if it sticks as fast as they can. If it doesn’t work, they can “pivot” or adapt to what they learned from their failure to try a new approach.
“Ready, Fire, Aim” is another phrase that is commonly used and associated with the failing faster. This method gets ready by building out a prototype (or “ready”), then puts the prototype out for the customer to test (or “fire”) and learn about why it missed the target (or “aim”).
Agile Methodology also adopts this method in their fail fast approach. Get something out there for the customer to interact with, get their feedback and then adapt. Other terms that have a similar meaning are “Fail Better” and “Fail Forward.”
This approach can be used in our daily lives when we as individuals try out something new like for example trying on a pair of new sunglasses. We need to get new sunglasses because the old ones broke, so we head out to the store. You look through the rack of sunglasses to see which ones might work. You try them on and look at yourself in the mirror. You ask your friends or spouse for their feedback. Based on what you see in the mirror and the input you get, you then create an image of the sunglasses that will fit your needs. You discard sunglasses that don’t fit your vision, and a new pair is tried on for size. You keep trying on sunglasses until you find a pair that looks the best.
This approach allows you to try a variety of sunglasses quickly. It also allows you not to choose any sunglasses and walk away from the store. You are abandoning the sunglasses effort because all the attempts to succeed in finding sunglasses that meet your needs failed. Remember those feelings of failure? To a smaller extent, you are feeling them in this case. You can always go to another store and the process of trying on sunglasses all over again. You might revise your criteria for the sunglasses or address if you need them at all.
What is Failing Safely?
Understanding how to fail safely is as important to understanding the importance of why failure helps us learn.
A few years ago, on a server migration project, the Database Administrator on our team announced in an impatient tone, “This database can’t go down! It’s mission critical.” That was an interesting little bomb to drop on the conference room table, so I asked, “Why can’t it go down? What makes this database mission critical to the organization?”
The Database Administrator elaborated further on the database purpose and its critical nature to the organization. There was a backup done every night, but no one had ever tested the restore process. There really should be a commandment in technology that says, "Thou shalt not backup or archive data without ensuring the data can be retrieved later.”
The team decided that it was too risky to move a database from one server to another without first ensuring the data would not be lost. The group performed a full backup and then attempted to restore it on the new server. A significant disaster occurred as the new server configuration did not match the old server configuration. We were still okay because the old server was still in production and there was no disruption to the business teams accessing the data. The team wouldn’t switch over to the new database until the restore process worked.
After a dozen attempts and countless hours of documenting the steps needed to move from one server to another, the team was successful. A dozen attempts ended in complete failure. Even though we failed repeatedly, we had a safe place to land.
After each failure, the team got more and more scrutiny from management. Management had a tough time with how long the migration was taking. Management expectations were that the migration would take a few days. They conducted more and more meetings. Management kept asking, “Why didn’t you see that coming?” We replied, “We have never done this type of migration before.” Thisled to putting all new players on the team that was more experienced so that the migration could move more quickly. Did that migration go faster? Not at all. The new players didn’t experience the failures of migrations we previously attempted. The new team proceeded to make the same mistakes the old team made. The new team’s strategy was to keep pounding on it until it worked.
That didn’t quite work out so well. After 36 hours of non-stop troubleshooting, the new team was no closer to solving the issues than the old team. It took them two days to recover from pulling a marathon 36-hour shift. We had another meeting with management, and they too reported they made no significant progress.
We sat down and set management’s expectations more clearly. No silver bullets or SWAT teams are going to speed up this migration. The teams together created a list of lessons learned. The document outlined what went wrong on each attempt, the root causeof why it occurred, and the steps we took to make sure it wouldn’t happen again. After every attempt, the team got together and went through our list. In the beginning, it was excruciating, but as we progressed, we grew more dependent on the list as a tool to help us move past errors and even avoid potential future failures. There were a lot of “chained” events that were discovered using this technique. You must do this step first and then this step second. Logical GO and NO-GO decisions got added to the implementation plan.
In the end, we had successfully moved the database from one server to another. Our list became a standard that other database moves would later follow.
Getting Past the Word Failure
The word failure has a lot of bad connotations, and many people don’t like to use the word even if it means we learn and therefore is something positive. Say the word failure, and you will get an adverse reaction every time. To get past these impressions, you need to frame the word as something that is just natural and part of the process. Find another word that makes you comfortable as long as you understand the meaning behind it is still failing or missing the target.
Creating the right environment for failure can be culturally tricky. In some cultures, you can’t even say the word failure without being insulting. Nobody will let you say the word failure in a meeting. In this situation, you might need to change the word to avoid adverse reactions. Find a word that will work for the culture. The label for failure may vary, but it still has the same meaning as failure.
Just replacing the word failure with success creates an impression that we need to have a high level of perfection before it can be released. This perfection defeats the ability to learn. It also slows down the speed at which you can learn. You are asking for feedback and valuable insight by putting out a working product with which that your users or customers can interact. By focusing too strictly on success outright with complete perfection, you won’t be able to get the valuable insight from your users and customers. Ideas come from many different perspectives and those perspectives strengthen your product.
Find a word that will work for your organization but understand the concept of failure. You may label it differently to get a more positive reaction, but it has the same meaning nonetheless.
In today’s business world, nobody throws a product out there without some testing even if the product is tested entirely within your organization. The feedback from testing that is performed by only internal staff limits the amount of perspective or feedback you can get on the product. The broader the audience, the more likely you are to get broader perspectives and feedback. Stronger feedback gives you stronger ideas for creating an excellent product.
“We didn’t fail – we found defects in the application code!” I would argue those defects found in testing are in failures and that your testers will learn from those failures. They will even adapt to work around those failures. A meets the definition of failure:
“Failure is the state or condition of not meeting a desirable or intended objective.”
If it doesn’t work in the technology world, it is labeled a defect. A defect causes the product not to meet customer expectations. The business side of the world doesn’t typically use the word “defect,” but it is applicable for use on the business side. Customers interacting with a product at an early stage quickly uncover defects. These defects can, in turn, generate new features and capabilities previously not discovered.
Embrace Failure and Stop Fear
Many start-ups and growing companies talk about embracing failure. They repeat the Silicon Valley phrase “Fail fast, fail often” like a mantra over and over. It doesn’t necessarily mean they are not afraid of failure or that they will accept it. Speed to market for a fledgling start-up company is mission critical. Start-up companies are always in a battle to show their venture capitalists they can quickly turn a profit.
Fear is a strong motivator for any organization. The practical way to combat the fear of failure is failing in small increments, not large ones. Blowing through a million dollars on a prototype only to discover it wouldn’t work for the organization isn’t acceptable. Investors will set funding constraints for prototypes out of the desire not to have their funding exhausted on products that are not unfeasible. The product may sound great on paper, but building it is an entirely different matter. The practical approach is to quickly create a prototype to demonstrate the product can be realized and profitable.
There are no shortcuts here. Doing the work is still required. No magical formula can ensure a prototype is feasible. Take shortcuts where you can to deliver quickly but be aware those shortcuts can cause you to overlook possible opportunities to learn about undiscovered capabilities.
The term “hacking” implies creativity, imagination, and a relentless drive to solve a puzzle. It also suggests cybercrime and guys stealing your credit card information. If you have a genuine commitment to embracing failure and learning from it, you won’t feel a need to take shortcuts. Taking shortcuts that do not allow you time to think or research get a negative response. You will recognize alternatives as either bad in that they introduce noise into solving the puzzle, or useful as they are discoveries of doing the work differently and faster.
Failing Fast Aftermath
Figuring out what works means you have to shut down a lot ofideas and there are many products that getsignificant criticism from your users and clients. It can be demoralizing. The best way to soften the blow of this criticism is to have everyone in the right state of mind.
Set expectations that new ideas are valued but encourage those ideas to flow. Ideas can come from anyone in your organization, the team, or customers of the product. Just because an idea is shot down doesn’t mean it didn’t spark other ideas or won’t be addressedin the future. Keep a list of all the product’s ideas and the outcome of those ideas. Think of it as a capabilities list that is tracking all the potential capabilities and whether or not added to the product. With many ideas swirling around it’s hard to keep track of them all but keeping them together in a list has benefits. The list ensures ideas are not lost or don’t get brought up and shot down all over again.
Encourage the organization and team to keep giving ideas even when it seems there aren’t any more ideas. Keep looking at things from different angles both internal and external to get a broader view. By creating products with small enhancements over and over, you give more opportunities for customers to provide feedback on your product. Daily product updates are confusing because your customer can’t get their head around what it is you are trying to create. Choose a product update or release schedule that make sense for your product. Updates to a software product usually find their way to customers once or twice a month. Heavy equipment or durable goods might only update their product once or twice a year.
Positively acknowledge ideas. When an individual gives an idea, they are putting themselves out there. Criticism or negative responses to ideas will shut down new ideas from being created from the entire team. If the team observes consistent adverse reactions to new ideas, they will no longer offer new ideas.
Recognize that after a stream of failures, your team building the product can lose momentum. Don’t always focus on the negative. Look for the positive feedback. Show the team the journey has been incredible with everything that we have built and learned about the product.
Customers can be critical for the sake of being critical. Ignore the overly critical and focus on criticism that is constructive to keep your team from being beaten down by critical feedback. Read all the feedback but understand that the purpose of feedback is to understand where the product can be improved rather than torn apart.
Build Small, Be Smart, Pause and Learn, Build Again
Fail fast isn’t about the significant failures or changes, it’s about little ones. It’s an approach to running a company or developing a product that embraces lots of small experiments with the idea that some ideas will work and grow while other ideas will fail and whither.
Build Small. Make small incremental improvements with each version of the product. Avoid trying to boil the ocean in one large increment. Focus on a specific function, feature or capability of the product for each version.
Be Smart. Verify incremental improvements are not overwhelming for the team to analyze and build. Make sure they are realistic to achieve.Break up large functions, features or capabilities into the smallest pieces as possible. Look for dependencies been small steps, so they will logically progress forward step after step. Verify how everything can be chained together to understand the best way capabilities can be added incrementally to the product.
Pause and Learn. Allocate enough time to test the product with customers for more comprehensive feedback. Take the time to reflect and learn. Look for better approaches to delivering the product to the customer.
Learn and Repeat. Take what you learned from the feedback and build it into the product. Track what you learned and new ideas.