Fail fast is part of an agile culture. You want to know what you did not know before as early as possible so that you can adjust the direction. Yet, what you want even more is not to get hurt during that learning curve. But you will. And you should.
Have you noticed that big organizations always choose to get disappointed later? Of course, it is not the real choice, but deep inside that’s what’s going on.
Before a product launch we noticed that one of the features was not working properly, which could cause some extra load on customer service. The management was to decide what to do: to get the feature fixed and wait for the proper launch, or to launch it as it was and manage the aftermath. We tend to choose the latter one with an additional remark: let us try to fix it before the original launch date. There is one week left till launch, the development requires two weeks. It is crystal clear that you won’t succeed.
Yet they still grasp on something which is often called hope. But sometimes hope is not the tool you need. I understand that there is nothing impossible, it just has not been done yet, but also, there are the laws of physics. Sometimes understanding and acceptance help. So we are told to try the impossible, in which failure is coded by definition. You elaborate a plan which gets other resources on board (in this example customer service) instead of the one that is the only solution for the actual problem (IT).
What you basically do is focus on repairing over prevention. Yeah, yeah, I know there are situations where you need to jump, because you cannot get over the chasm in two steps. But I often feel we do so even in times when there is another option. When there is no pressure, when you have not ordered media spending for a huge campaign, when your yearly targets are not dependent on this particular move. In my ideal world, we intend to launch a product which features work as expected according to our knowledge. There will be enough to fix and modify even when we believe the product is capable of all the wanted features. But getting ignorant or crossing our fingers in case of known issues takes us to unsustainable operations.
Jim was working for a company that took employee engagement serious. At least in theory. Jim’s broader team had around 90 colleagues. For this size, they could get the results of the employee satisfaction survey applied to their unit. That’s how they learned that in their unit, recognition had one of the worst performance metrics. People did not really feel that their effort was acknowledged, valued or even paid. So Jim developed a multilayer plan of recognition that included a simple tool with which colleagues could give virtual high fives to each other. It was a simple form, you could pick a colleague, a category of values such as high performance or team player, and you saved it. The unit started using it and the tool got some appreciation in the first weeks. But enthusiasm got less and less in the course of some months. They learnt that notification was missing. There were feedbacks, but nobody knew about them, because it took extra effort to get the form results, which nobody really did actually. They needed to develop the notification feature.
At this point they got aware of the internal smartphone application HR was developing. The feedback functionality fit well into the general concept of the app. However, the HR decision maker did not support the idea of integrating the tool into the app, because they were already developing a feedback tool. The intentions seemed to be identical. Though they were not. HR was thinking of a separate tool that had the same problem as the form - it was not an integral part of every day operation within the company. Jim told HR what they had learned about notification needs, but HR went on with their tool. You might get what it resulted in. Rarely given feedbacks that were read rarely. HR simply did not use the knowledge Jim already had. They loved their own idea well enough to miss something very important. While Jim had already failed and learned from it, HR unconsciously chose to fail for sure.
Another failure (for sure) that the management recurrently makes is the car service dilemma.
It's not car service specific and others may know it by a different name. As of now, it serves as an example that is easy to understand. It shows the conflict of interests and it illustrates that often you have to choose among options that none of them is perfect. There are three priorities and you can get only two at a time.
In this dilemma, you cannot get a good, cheap and fast solution to your problem. Why?
If you have a good and cheap solution, you won't get it fast as it takes time to find or deliver it, otherwise it would be obvious to do so, but you still don't have it, that's why you face the problem. If you have a good and fast solution, it will probably cost you much more. Don't forget, time is money. To deliver something promptly, it requires many resources (either a rare tool or many workers). If you have a cheap and fast solution, don't get surprised if it doesn't last long. It's usually the case when you have chosen something temporary, but that's exactly why you will likely face the problem again.
In corporate projects, the scope or the circumstances often change as you cannot predict the future perfectly during the planning phase. Being a project leader, you might have already experienced in your past that your bosses changed their minds during the project, they asked for more, but they did not accept changing the deadline and you had to keep the budget restrictions too. Meaning that they wanted something fast and cheap, however you had your original plan for your original scope. When you have defined the project for the given scope that defines the quality as well: you promise to deliver the desired outcome within the certain timeframe and budget. Changing the scope adds more tasks, therefore you cannot deliver the quality, because you won't have enough time for all the tasks, you will have to skip some, you will have a quick and dirty solution for others, or you will not have more money to allocate the necessary resources and involve more co-workers. As a result, the project will not be good in terms of the original plan. Or at least it could have been better, if you could have had it at full throttle.
If this example is familiar to you and you were frustrated when it happened to you, please know that it was the car service dilemma you faced. Next time think of it, and try to convince the decision makers that a changed scope means change in other aspects of the project or the delivery will suffer. Hopefully they can understand it by this simple car service case.
