On the subject of fail early – I had a great lesson in this in the fall of 2013.
I went to a shooting range for a social event. I participated in 3 rounds at three different locations. It was the first time I had ever held a gun let alone shot one, and I was really intimidated at the first station. We were grouped in teams, and each person got two shots per turn at clay pigeons that came from varying locations. Then the teams would switch.
At the first station I received minimal instruction and minimal feedback. I would take aim and fire, but only ended up hitting one over the entire series.
At the second station, each person still took a turn to shoot, with a rotating launcher for the pigeons that might send your target out in any direction, but this time only one shot per turn. The feedback was very detailed. I got feedback after each shot. I shot maybe two total in the series.
At the third station, in the same location, we then shot each person, each turn, and I being the only lady in the group, got to call when to release the pigeons. I shot and hit every one.
For me, being able to participate and get immediate feedback on every shot without pause between to wait for others taking their turn was essential for my success. I needed the experience of taking the shot, every time for all the feedback I had received to really work. You could have spent all night talking to me about how I needed to aim higher or to the left, or not to pause when I got the target in my sights, but none of that could substitute for the actual experience of aiming, shooting, then repeating the whole thing again.
Developers need that experience in their work as well. Taking aim at a target, attempting to complete it, and learning from that experience. The most important part of this equation is learning!
Eric Ries, author of The Lean Startup was rumored to release up to 100 times a day for his product IMVU. The product was released after 6 months. It was buggy, but it got out and into use with the people who were interested in it, allowing improvement and refinement of the product to the customer’s needs.
He compares the release of IMVU and it’s buggy performance so bad it didn’t perform half of the time when presenting to venture capitalists to the release of another perfectly planned over the span of 3 years that failed miserably.
The difference is that they didn’t try to predict what was wanted or needed in 3 years, they tried to figure out what was wanted / needed now, and got fast and early feedback from customers to quickly iterate over the product to make it more and more into the ideal.
We should take these lessons to heart. Getting early and often feedback is important. Making mistakes is essential to improving and innovating. Finding out about these mistakes early has a much lesser cost to fix than finding out about mistakes late.
Fail early, fail often – otherwise you aren’t stepping out of your comfort zone into what is possible and stretching your potential. Otherwise you are playing it so safe you never take a risk at all. That might be comfortable, but it also probably won’t get us very far in the long run. The problems we have today will be the same problems we talk about in one year or two years.
Take a risk and try something new. Maybe even consider the possibility that we may want to start something radical – like the new management of the Toyota plant Nummi – taking the roughest union workers and turning them into team players by treating everyone as valuable, allowing anyone to stop the production line when there was an issue, using a pull workflow, and problem solving together.
This goes beyond methodology and into practice. What do we want our work environment to be like? Do we want to look forward to working together as a team, and value all contributions? Do we want to raise the level of accountability to the products we work on and to our teammates? Do we want to encourage innovation and measured risk taking? Do we want to look forward to the possibilities new technologies may offer us and experiment with what they might be able to give us?
Change is a scary but necessary and expected part of technology work. Expecting things not to change is like expecting it to rain and to not get wet.
Rather than avoid change- let’s embrace it, and the learning potential it brings with it, whenever we can.
