We love to predict the future. Predicting the future reduces our uncertainty. It reduces ambiguity. And it’s often wrong.
Predicting the future comes in many forms. There are the seers and guides who issue pronouncements, whether it’s that the world will end a week on Friday, or that 2015 will be the year of Wearable Nano Drones.
But it’s not just through soothsayers that we try to predict the future. We also do it through the medium of process. With genetic lines from Adam Smith and FW Taylor, processes and methodologies provide repeatable, assured ways of working. “Best” practices. And in many instances such ways of working can become very effective. The modern motor industry, with a century of practice and adaptation of those methods, churn out cars in their millions, reliable and quality products.
Of course whether we need or want these millions of cars, or if they are serving our needs either as individuals or as a society is a completely different point. And one of the downsides of highly refined, scaled and repeatable processes is that because they are very good at churning out a mass-produced product, they are very difficult to change to deliver a different product. Retooling to change the model of the car coming out of the production line would be expensive. Retooling to change to producing, say, kettles, next to impossible.
Mass production and repeatable processes works well in the world of things that are like clocks. Possibly complex, but predictable worlds. In a world of things that are like clouds, drawing on Karl Popper’s wonderful analogy, predictability and by their nature then the use of repeatable processes becomes less and less valuable.
In a world of things like Clouds – chaotic, unpredictable things – the moment you begin to interact things begin to change. Applying a process to changing a cloud-like thing is not particularly valuable because you’ll not get the same outcomes.
The founders of the Agile movement kind of got this. They realised that the development of software, whilst maybe sometimes repeatable through the use of lower-level design patterns, was a bespoke thing most times (after all if it wasn’t a bespoke thing, why were you building a bespoke piece of software?). The delivery of software is a small part of a socio-technical system: a combination of people, culture, behaviours and technology. A software development team is in itself a socio-technical system. It’s the combination of the people involved and the code that they produce, and the people that they are interacting with outside of the team that delivers a unique set of outputs and outcomes.
In a world of uniqueness, repeatable processes give succour but don’t deliver results. Twenty different teams working on twenty different problems will deliver twenty different solutions. If it were possible to do it, twenty different teams working on the same problem with the same process would still deliver 20 different outputs and outcomes.
So Agile talks about frameworks and manifestos, not processes. But the subtle difference between a framework and a process tends to get lost in translation when delivered out at scale. People fixate on the methods, espousing outputs and techniques over the actual work. They start to believe that as long as the framework is doggedly followed, predictable, successful outcomes will follow.
Poppycock. But it provides that comfort blanket of predicting the future.
Take, for example, the way in which Lean Startup has become a process. How everyone is delivering lean these days. But whilst I’m sure that there are a stack of successful startups who’ve followed Eric Ries’ advice, there are a hundredfold who have fallen by the wayside. The illusion of the success of the process comes through the confirmation bias of focusing only on the ones that are successful. It’s like Derren Brown’s hugely successful method to beat the bookies.
If you are doing something that no-one has ever done before (and that uniqueness includes the people involved) you can use processes or frameworks, but ultimately the success or failure of your venture will be down to those involved. Processes or frameworks can mitigate a bit of risk, but that’s only part of the equation.
Believing that your initiative will be a success because people are following a process when you are working in a world of clouds is putting your faith into the predictive power of a set of diagrams. Believing that there is only one approach to delivering successfully is verging into the behaviour of a cult.
Ultimately, in the world of the unpredictable, understanding that frameworks will only be an aide to your delivery and not the be-all and end-all will help foster a pragmatic approach that will be more likely to deliver successful outcomes.
(Thanks to Bob Marshall for yesterday’s Twitter conversation that led to this post.)