Buzzword bingo
Failing fast.
A phrase you've probably heard countless times in agile literature, in books about start-up and lean culture, and in umpteen articles on the Internet. And yes, here I am: yet another monkey on the proverbial typewriter. Fail early, fail often, fail smart. In the software development world it's safe to say that we've all been bonked on the head with the proverbial fail-stick enough times for it to have been driven home.
However, I would like to make an argument that the phrase has become so much of a buzzword that it has lost much of its impact. The phrase is applicable much more widely than within the bounds of your team's scrum ceremonies. It's applicable to all work that you do.
As a manager, the bounds of your work are wider than just the code that you and your team are producing. Your job is about doing the most with what you have as efficiently as you can. You are involved in discussions, hiring, processes, and decisions that can all benefit from the mindset and methodology that encapsulates failing fast. Before we look at specific scenarios to explain this further, let's explore a factory metaphor that neatly demonstrates the core concepts.
A factory
Imagine, if you will, that you are running a factory.
Let's pretend that the production line produces cars. We'll envisage an unrealistic scenario where the factory builds the cars completely from end-to-end, starting with the raw materials such as sand, metals and plastics turning up in trucks at the loading bay. At the end of the production line the cars are ready to be sent to showrooms nationwide.
There are some observations that we could make about the production line. The raw materials are very cheap (e.g. sand) when compared to the end result (a car). Therefore at each stage of the production process value is being added. A moulded, painted bonnet is worth more than the raw alloy that it is made of because a process has been applied which added more value. The same can be said about the cost of sand compared to a sheet of glass, compared to working electric heated window.
Therefore the closer that you are to the start of the production process, the more options that exist for what you can do with a given component. For example, even after sand has been made into glass, you could still make a window, windscreen, or mirror. For comparison, it's a lot of effort to turn a finished car into a motorbike, even if the raw materials and components have many similarities. It's hard to disassemble and go backwards.
This highlights the issue of waste. The more value that has been added to a component, the less reusable it is, and the more there is to lose when failure occurs. It is more expensive to fail further down the production line. It would be much better to check for defects in the sheet glass immediately after it has been made rather than discovering the defect in an installed windscreen at the end of the line.
If you were running this imaginary factory, I suspect you would be embracing the principle of failing fast in order to prevent issues upstream where they are more expensive to deal with. I find that when imagining the creation of physical products, from cars to computers to furniture, the principle is fairly obvious. But as a manager in mainly knowledge-based work, have you had ideas, projects, and decisions take a long time via lot of effort only to be thrown away?
Will we ever learn?
The ideas factory
The production line that produces software is complex and also much less tangible than the physical products that we alluded to in our example. Additionally, as a manager in a knowledge-based job, there is more to your role than just producing software. There are processes, discussions, prototypes, ideas, happy and unhappy staff, hiring... you name it. There's a lot on the periphery. Can we apply the fail fast principle there too? I think that we can.
Let's loop through some examples of areas you will operate in as a manager, and see where the fail fast principle can be used.
Software development. This is the area in which it's likely you've heard the phrase used most often. If your production line is creating software, then failing fast is a very good idea. Do the riskiest and least known pieces of work first in order to learn more and fail if you need to. Do technical explorations as early as possible to fail smartly or understand what's next more clearly. You don't want to find yourself months down the line with code that you can't work with. As lines of code increase in your project through ever more thought, time, and toil, the more value that codebase represents, and the bigger the potential waste if it isn't fit for purpose. Get it right up front. Or even better, get it wrong quickly multiple times.
Product ideas. We can now move upstream to the Empyrean realm of product ideas and think about how we could fail faster there, so we don't even need to consider writing any code! Before an idea goes anywhere near a developer's keystrokes, it is worth considering that the more time that is spent on it, the more value that it has, even if it is still just an idea. How can an idea fail as quickly as possible? Let's see. Can it be put in front of a user verbally or through some simple sketches to confirm that it's worth doing at all? Before building something to test user adoption, can you fake a sign-up page to gauge interest? Can you build a quick financial model in a spreadsheet to see if six months of work pay off? Ideas can be generated and discarded so quickly and easily: capitalize on this.
Technical explorations. How can technical ideas fail fast? How fast can you prototype an approach to see whether it is going to suit your application's needs at a required scale? Can you try something out quickly in the cloud to fail on somebody else's hardware before you even think of buying your own? Instead of needing to collect petabytes of real data from production data stores in order to perform benchmarks, can you instead just generate petabytes of random data to meet your needs instead? The salaries of your technical staff are not insignificant, so you should be treating their time as an investment of company money. The same is true about serious production deployments in the cloud or in the data center: getting it wrong could prevent you from hiring a whole new team. Make sure that time and money is spent wisely.
Hiring. You'll want to fail quickly with hiring. Is your interview process set up so that candidates that are not going to make the cut are screened out as early as possible? Do you perform a quick pre-screen on the phone? Interviews, like technical explorations, are an investment of time from your technical staff. Make sure that your interview process is like a funnel, with the best candidates getting the most of your time. Also, treat hiring decisions very seriously: you can consider the hiring process as adding value to a candidate, and when they are hired it becomes much harder to "fail" once you've gotten past a probation period. Nobody likes dealing with performance problems. It's easier to say no after the second interview, or come to an agreement that it's not working out after the probation period.
Decisions. The longer that a decision goes unmade, the more value that it gains, for better or for worse. Unmade decisions attract ever more opinions and become more diluted and complicated and harder to execute. This is especially true for decisions that are not being made because they may cause conflict, such as a strong veto that will inevitably cause some friction. Act confidently on decisions and do not be afraid to say no. If the team shouldn't go in a particular direction, be firm and say so. Cognitive power can then be spent elsewhere with loose ends neatly tied.
Your currency
If you need motivation to fail fast then it can always help to think about time and money. One could argue that in the workplace time is money, because everybody there is getting paid; all activity can be considered an investment from the company.
If you don't fail fast, you're effectively wasting money. The bigger your team(s), the more investment that you risk by not doing so. A few engineering teams could easily represent a yearly investment of £500K-£1M. Thinking of it in raw currency, would you really let that project run for six months, or would you try to prove whether it is worth doing in the first two weeks? Would your team really interview those candidates with applications that you were on the fence about, just on the off chance that they were better in person? It's critical to think about how you spend your currency, as your company expects a good return on their investment in your function.
In summary
You have a responsibility to ensure that you fail fast in all aspects of your job. After all, Plan C might have been the best plan all along. Bring the fail fast mentality to software development, product ideas, technical explorations, the hiring process and decision making and make sure that the company's investment in your team yields the best possible results.
Are you unsure about anything you're doing right now?