Sometimes we distil wisdom (Fail Fast) down too much and the lesson is lost. I see people rushing out to try "new" things in rapid succession. Testing is good but you also need a plan otherwise you are just hoping to hit gold by pure luck. I also see smart people playing it safe avoiding any failures at all costs. If you don't even have small failures, then you haven't stretched yourself and you are capable of more.
IMHO… it should be “Fail Fast, Learn, and Iterate” but that doesn't roll off the tongue the same way. I've also heard this approach described as "Launch Ugly". Aim to do a big project perfectly in one "go" is a recipe for disaster. Big failures should be avoided but little ones that you can easily recover from are part of the process of pushing the limits and aggressive growth.
What is the critical essence of Fail Fast?
To understand the essence of Fail Fast we need to look at how traditional projects work. A lot of planning is front loaded into the project, where time is taken to make assumptions and predictions on top of those assumptions. Then we build all the pieces around those assumptions. Even with very experienced competent people can make bad assumptions from time to time. If the assumption was critical the entire project could be a failure.
Fail Fast makes smaller assumptions, builds it in less time, and tests assumptions. If it works we can improve on it or move to the next small assumption / improvement and build and test to see if it works, and so on. Environments and conditions are constantly changing, testing and delivering smaller pieces ensure we are adjusting with those changes. This philosophy lines up nicely with Agile methodology.
Confidence can be your detriment
I've seen an excellent yet simple real world example… At a team building event, we were divided into groups, given a box of dry spaghetti and 1ft of clear tape and 15 mins to build a structure. The group with the tallest structure wins.
Most adults tend to dream up a design and jump right into building the final structure and testing doesn't happen until the very last minute… It's a do-or-die approach and most structure failed.
Children doing this same activity are constantly building small structures and scale them up or piecing them together throughout the 15 mins. They end up with the tallest structure winning over their more confident adults.
Why do adults take the high risk approach? This might be a little counter-intuitive... It's partly because we want to optimize both height and time. In the end we fail at both when we don't do the basics of testing and validating.
It's better to create related small projects/tasks/stories than large grandiose ones where we only know if we have success once we are done the whole project. Iteration of testing and validating is key.
Help your team make the leap
As manager, we need to instil a culture of measurement in all that we do so we can learn and see what works. This approach takes time and not all tests will work out the way we want... but that's ok. It's better to have a 1 week project not work out than a 6 months project fail. In the long run, these smaller projects will use less time than a single large traditional project. You may need to provide air cover for the team when external forces are trying to compress timelines. We all know what gets thrown out first (test/validating/iteration). We need to encourage our employees to think about how to evolve their work product... it's not won and done and move on. Help them feel ownership of their work product by ensuring they get credit for their successes.
