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.