Failure Is Not An Option, It Is A Requirement.

Of course that statement on it’s own can obviously be shown to be fallacy. When you consider the context of continuous improvement, learning or generally advancing our own capabilities and understanding, though, this statement can be quit liberating. Why? Because without failure, you are not learning anything.

Let’s say you are faced with a problem, a challenge, or a need that you are trying to fulfill. If your first attempt and creating a solution is successful you have learned nothing. You already knew how to provide the solution. it only took some thinking to analyze the situation and apply your existing knowledge. If, however, you stretch yourself as far as you can, put every last effort that you currently have into the solution and employ all of your existing knowledge, capabilities and resources but you still fail the first time, fail again and fail some more before finding a solution, then you are learning. You are stepping outside of your own knowledge and capabilities, learning new things and gaining new insight and experience that leads to new solutions for situations that you did not know how to previously solve.

Consider any endeavor to learn, from this light. Whether it’s adopting a new process or methodology such as an agile process or lean toolkit, using a new tool or technology, contributing to an open source project, or learning how to ride a bicycle – having the correct mentality, that failure is required, will undoubtedly help you succeed.

Mike Rother said it quite well in his book, Toyota Kata (p.138-139), when faced with people who are merely capitulating because they were told to do so, or because they want to prove that some change or new way of doing things won’t work:

Eventually it dawned on me how to deal with this question. Now, when arms fold up and people say, “Let’s see if this will work,” I say, “I can save you the time. We already know it probably won’t work. Despite our best efforts to plan this, we know that within a short time there will be ‘charred and glowing pieces’ lying around. We just don’t know in advance when, where, or why it will fail.”

Think about the last time you delivered any fragment of functionality to a customer or customer representative for feedback. Did you expect that they would be 100% satisfied and would accept it as is? Not if you were asking for feedback. When the customer responds with changes or updates that they would like, you have effectively failed. Hopefully you have failed within a very short cycle, though, and are able to incorporate the feedback of the customer into the next delivery or demonstration.

They key is not learning from mistakes and failures. The key is failing fast, failing cheap, and responding to those failures in a timely manner so that you can learn quickly and still reach your objectives. Failure is critical to success and learning, and short feedback cycles are critical to the effective use of failure as a learning tool.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Agile, Continuous Improvement, Education, Kaizen, Lean Systems, Retrospectives. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Thank, Derick. This is more than a software development lesson, but a life lesson!

  • Nice article.

    I’d like to add that there exist other options for individual learning:
    - get a mentor/teacher/sensei/master/… who will show you something she knows but you don’t.
    - use e.g. Acceptance Test Driven Development to provide you with a frame within which you can experiment and learn without acctual failing (yeah, you will fail some tests ;-) ).

    There is not always failure required,

  • I should have read this article just a month ago. I failed in some ways to deliver what the customer needed. But there are just a few chances to work on those failures and improve the next delivery.

    “Deliver fast and get feedback to deliver better the next time” is going to be my motto of the year.

  • Isn’t there a better word for failure? Sounds far too strong for me. Something like “in need of corrective action” would better fit the bill, albeit not as clumsy. Also , I disagree a lil’ bit with this: “If your first attempt and creating a solution is successful you have learned nothing.” (sic) – You can learn a lot from the stuff you’ve done right. It reinforces what is good. You can’t live in failure all the time. You’ll need to figure out the good stuff, too. The good stuff is e.g. short delivery cycles, because it helps you NOT to fail. Maybe I’m saying the same thing, in which case I apologize.

  • @Frank,

    i like your point about reinforcement. success is a tremendously valuable thing for many different reasons, including that one. i’m going to split hairs, though, and say that reinforcement and learning are separate (though related) concepts… that’s such a minuscule point to debate, though. i think we agree, overall.

    that sentence you quoted could certainly use a little less “black vs. white” tone, too. guess i didn’t catch that one when i was proof reading yesterday. :)


    I like your bullet points and very much agree with them. i don’t agree that failure is not needed, though. short iterations and feedback loops of test first development provide the kind of micro-level failures that allow you to change and still accomplish your objectives.

    i think the word ‘failure’ is stigmatized to a higher level, “permanent” state, which I don’t really agree with anymore. i’m not saying you should fail to deliver your project on time. i’m saying the iterative, incremental approach to software development is a series of small failures that lead to much greater success through rapid learning on a small scale.

  • I also dislike the use of “failure” when applying creativity to solve problems. I think of failure as “capable of doing something, but not applying sufficient effort to perform the task”, not “create a solution for an unsolved problem”.

    I realize I’m splitting semantic hairs here. But I really think the choice of words affects our self-image and attitude. Thomas Edison tried thousands of experiments to create the incandescent bulb. When asked about his “failures”, he is reported to have said “I have not failed 10,000 times. I have found 10,000 solutions that do not work”.

    Likewise, I don’t want to view product development that isn’t accepted by the client as “failures”, especially considering that often the client doesn’t know what they want until they see it.