You can only FAIL BETTER only if you learn from the failures. And then failing is something that prompts you to move ahead.
No one likes failures, but often failure knocks our door before success. Failure in ancient Latin is "defectum," and defectum share the same root of the word "deficere" ("missing" in English) that comes from the ancient Greek αποτυχία means failure. εποτυχία means success. The meaning is that understanding that the difference between failure and success is just in one letter... α and ε ... and just one letter can dramatically change the outcome. If failure is inevitable, either running an organization or undergoing a life journey, how do you fail fast and fail forward?
All failure should be a learning experience, some failures are good and some are bad. Failure is a failure and a fantastic opportunity to learn something and then to have another go. Regardless of if it’s good or bad, the outcome is not anticipated and expected. If you never fail, you're never taking any risks, or you're calling things successful that weren't, or you're exceptionally lucky. So embrace failures. See them as part of life, part of being human and part of what we do. Business teams innovate, create, research and resolve problems and are full of complexity, uncertainty, and unpredictability, failure will happen. If you accept that the occasional failure is a certainty as an outcome of taking risks, then it makes sense to detect and deal with them in an efficient manner.
Failing is something that prompts you to move ahead. The concept is that failure is good, as has been expressed and promulgated in the annals of agile, but only if you "fail well." Basically, there can be a value judgment placed on failures, even expected failures, whether the failure is a "good failure" or a "bad failure" and the deciding measure is not just whether you have learned something or not. There are always two questions to ask, among others when a failure is detected; 1) can you turn this into a success, and 2) could you have detected the problem sooner. We should be learning all the time as we go, on successes just as much as on failures. The amount we learn is probably closely related to the amount of risk we take, failure or otherwise.
“Fail fast" and alike is legitimate only when these basic engineering practices are in place and valued. Emotionally, no one wants to fail even if it is a small failure. So all failures should be avoided. However, one should not be paralyzed fearless if there is a possible failure and one should learn to embrace it. Avoid late failures. Where there is a risk, you want to investigate this early and find out whether or not it can be addressed. If it can't be solved, you want to have spent as little effort as possible in which the only outcome is learning, not valuable software. If you have delivered a reasonable proportion of the scope, and this is precious and being used to good effect already, then there is no failure if you choose to cancel the rest of the scope because it would be of insufficient value to be worth developing. This is much more preferable than delivering the entirety of the original scope, in a system that will not be used effectively and to good value. Calling that a 'success' is either ignorant or mendacious. There is no value in failure itself, be it fast or slow. The value is how you respond to failure. And how you respond is dependent upon what you learn from it. Only then can "failing fast" be utilized as a tactical advantage.
Risk and uncertainty are inherent in development work, even more so in research work. Projects can fail, but if you consider agile product developments to be computational experiments then stopping earlier, and then predict because new information about likely return on investment has become available is a perfectly valid outcome. And with risk and uncertainty comes a statistical probability of failure - eventually you will have a failure if you are in the business. If you are in research, one would expect failure; you might go through a whole series of failures until you find one success. In development the balance is pretty much the other way; you may go through a full range of achievements before you have a failure. So, accept that failure is a matter of chance and statistics; that this reality is inherent in development work. You want to avoid failures that you should have known would fail when you started out. There's no shame in knowingly starting something that might succeed, but might fail.. provided we address the risk appropriately. The reality of failure is that it is also a way to learn. Sure nobody wants to fail, but it's going to happen eventually if you are really doing development work; if you really are taking risks and working in uncertain areas. Similarly yes, problems are problems, but they are also opportunities. Failure is a failure, but it is also a learning experience. See both sides of reality, if you insist on seeing reality.
Failure is failure. Life is bitter, we just have to overcome it. Life is a complex process, and we can only improve learning from our errors or others’ mistakes, but the great challenge in the everyday life is to call things with the right words and to be concrete. Some say failure is a subset of opportunities. You need a balanced viewpoint or either you will go too far one way and become risk-averse, or go too far the other and fail to make use of the learning or the learning opportunities. The first outcome means you will not learn as fast as others and you will grow ever more obsolete; the second outcome means you will waste more on failures, spend less time on profitable work than you ought to be doing. You can only FAIL BETTER only if you learn from the failures. And then failing is something that prompts you to move ahead.
0 comments:
Post a Comment