Fail fast and pivot

Last updated on August 30th, 2019 at 07:06 am

In the current model of rapid software development, the goal is to get something in front of the customer quickly, to see their reaction, and adapt. One of the expressions that is used is to ‘fail fast and pivot’. The goal here is to see which ideas work and which don’t. You do lots of iterations of your product, throwing out the aspects that are not working (fail fast and pivot) and keeping hold of the parts that are working.

This is an aspect of design that I think does not align well with academia – and in particular with doing educational design research in the context of a PhD study. Too many things require that you set things up and follow a give path, regardless of what that data is telling you. There is no easy way to fail fast and pivot, as you are continually encouraged to ‘stick with the program’ in order to get through it.

As I reflect back on my project – I see that there are several points where I did ‘fail fast and pivot’ – but unfortunately, the pivots were not enough to sustain the project. There were other points where I see that the project should have failed and didn’t, which helped to keep the momentum going – just enough momentum to allow the ‘stick with the program’ to win out over pivoting.

There is a tension with the ‘stick with the program’ versus ‘fail fast and pivot’. I appreciate the need for that tension. If I changed projects every time I saw something not going according to plan I’d be on my 5th or 6th project by now. But there also needs to be room for pivoting within the projects themselves. If we are to truly do design, we need to recognize that we never get design right the first time. The design needs multiple iterations before it can succeed, but also, that not all designs succeed regardless of how good they are. The business word helps teach us that lesson – some excellent designs don’t get market traction, where inferior designs might (classic example is the betamax versus VHS). With any technology intervention, there is a need to be there at the right time, or the opportunity gets missed.

Now I just need to figure out how to make all of this into a dissertation – just because the project itself was not something I would consider a success, does not mean that the act of going through the process wasn’t a useful learning experience. There is stuff to be learned from my project, that is the important thing.

 

2 responses

  1. Scott Johnson Avatar

    That’s a good term. Allows for a kind leapfrogging over a blockage then incorporate the fix in the next version. Why keep trying when the attempts stop teaching anything?

    Have you read “Dreaming in Code” by Scott Rosenberg? http://en.wikipedia.org/wiki/Dreaming_in_Code

    Or the term Dog Fooding
    http://en.wikipedia.org/wiki/Eating_your_own_dog_food

    There’s also project fatigue where your heart goes out of it. I like to start things but don’t do well at finishing. Used to love a roof repair job I had where our small crew did a lot leak finding and leaving it to others to finish.

    1. Rebecca - @rjhogue Avatar
      Rebecca – @rjhogue

      Interesting … I remember when I first heard the term “eating your own dog food” … it was when I was a co-op student working for Microsoft (back in ’93) … it was expected that we would load the beta versions on our systems and open bug reports for anything we found wrong … I didn’t know a lot about software testing back then (our processes were not so organized as they were at BNR/Nortel) … but it was the term where I discovered that I really liked software testing … a lot more than I liked software programming!

Leave a Reply

Your email address will not be published. Required fields are marked *

css.php